GM/T 0111-2021Technical requirements for blockchain cryptography application (English PDF)

3.1 Blockchain

A new application model and fusion technology that uses distributed data storage, peer-to-peer transmission, consensus mechanism, cryptographic algorithm, smart contract and other technologies.

3.2 Consensus mechanism

An algorithm that implements trust building and rights acquisition between different nodes in the blockchain system.

3.3 Smart contract

A set of conventions defined in numerical form.

NOTE: A treaty that is jointly observed by the contract participants and the blockchain system.

3.4 Decentralized ledger

A data record that can be shared across a network of multiple nodes, geographical locations, or organizations.

3.5 Transaction record

A message broadcasted in a blockchain network.

NOTE: It contains information such as the transaction initiator, transaction content, transaction recipient, and the user signature of the transaction initiator.

3.6 Transaction

A transfer of digital assets or a call to a smart contract.

3.7 Public blockchain

A blockchain system in which each node can freely join or exit the network and participate in the reading and writing of data on the chain.

3.8 Consortium blockchain

A blockchain system in which each node corresponds to an entity organization and can only join or exit the network after authorization.

3.9 Private blockchain

A blockchain system in which the write and read permissions of each node are internally controlled.

3.10 Merkle tree

A type of binary tree based on the hash pointer that can quickly verify the integrity of information.

3.11 Digital assets

A valuable asset that exists in the form of electronic data and can be sold or exchanged by the holder.

3.12 Identity-based cryptographic

An identity-based password system.

NOTE: It is an asymmetric public key cryptography system.

7.2 Digital signature requirements

The digital signature format and usage requirements shall comply with GB/T 35276, GB/T 35275, GB/T 38635.1 and GB/T 38635.2.

7.3 Security requirements for cryptographic devices

It shall pass commercial cryptography testing and certification.

7.4 Key management security requirements

Identity authentication keys, data encryption keys, etc. in blockchain applications shall use cryptographic devices or modules that have passed commercial cryptography testing and certification to achieve secure management of key generation, storage, distribution, import and export, use, backup and recovery, archiving, and destruction.

The keys for the encryption of communication data between blockchain nodes and the encryption of data stored on blockchain nodes shall be properly stored by cryptographic devices or modules that have been certified by commercial cryptography testing. The keys shall also be strictly managed for their life cycle, shall not be permanently valid, and shall be replaced after a certain period of time.

7.5 Certificate management requirements

Digital certificates in blockchain are mainly divided into two categories: one is the digital certificate used by end users to complete identity authentication, secure communication and transaction signature; the other is the digital certificate used by blockchain nodes to complete identity authentication, transaction endorsement and secure communication.

a) The construction of the certificate authentication system and related key management system shall comply with GB/T 25056, GM/T 0037 and GM/T 0038;

b) The digital certificate and CRL format shall comply with GB/T 20518.

7.6 Data security requirements

In principle, data exchange between nodes of the blockchain shall not be transmitted in plain text. It is advisable to use asymmetric cryptographic technology to negotiate keys and use symmetric encryption algorithms to encrypt and decrypt data. Data providers shall also strictly evaluate the sensitivity and security level of the data, decide whether to send the data to the blockchain, whether to desensitize the data, and adopt strict access control measures.

Secure channels can be configured between nodes of the blockchain and between the application end and nodes to ensure the security of data communication. The secure channel shall use cryptographic algorithms and cryptographic protocols that meet the requirements of national cryptographic standards and industry standards to ensure the confidentiality and integrity of transmitted data.

7.7 Consensus protocol security requirements

The consensus protocol shall provide clear cryptographic mechanisms to ensure that the consensus protocol has the following properties in the operating environment:

a) All parties involved in consensus negotiation shall use cryptographic technology to achieve identity authentication;

b) Sensitive information sent during the execution of the consensus protocol shall use cryptographic technology to ensure confidentiality, integrity, and non-repudiation;

c) Clear security boundaries shall be proposed to ensure the fault tolerance, consistency and availability of consensus protocol execution;

d) All honest consensus negotiation nodes reach consensus within the agreed time;

e) All honest consensus negotiation nodes record the same content;

f) All consensus requests from honest consensus negotiation nodes shall be responded to;

g) All honest consensus negotiation nodes process consensus requests in the same order;

h) The consensus protocol should also be able to resist attacks such as DoS and double spending;

i) In the event of a malicious attack, the data security of each node must be guaranteed; or through appropriate intervention, each node can automatically return to normal.

7.8 Smart contract security requirements

When deploying smart contracts, it is necessary to check whether the user has obtained

d) When creating a block, SM3 specified in GB/T 32905 shall be used to calculate the hash value of the previous block, and SM3 shall also be used when generating the hash values of each level of the Merkle tree based on transaction information;

e) If there is a need for data privacy, cryptographic technology should be used to process transaction information or block information. If a symmetric encryption algorithm is used, it shall comply with GB/T 32907;

f) If a third-party trusted timestamp is included in the block, the timestamp service specification shall comply with GM/T 0033.

8.4 Transaction verification

After a transaction is generated, it needs to be broadcast to the nodes in the blockchain network, which then verify the transaction, package it into blocks, and run the consensus protocol to ensure that the nodes in the network reach a consensus on all legal transactions. The cryptographic requirements for the blockchain to reach a consensus on transactions shall meet the following:

a) If a digital certificate is used, the validity of the digital certificate shall be verified first, including the certificate trust chain verification, certificate validity period verification, whether the certificate has been revoked, and whether the usage policy is correct;

b) Verify the digital signature in the transaction record to ensure the authenticity of the transaction initiator and the integrity of the transaction record;

c) Verify the validity of transaction signature time, etc.;

d) The validity verification of the block should ensure the validity of the hash value of the previous block recorded in the block. The verification of other aspects is similar to the verification of transactions;

e) If a third-party trusted timestamp is included in the block, check the validity of the timestamp digital signature in accordance with GM/T 0033 and check whether the timestamp signature certificate is connected to the trusted root CA.

8.5 Ledger storage

In the blockchain, the user's transaction records are organized in blocks, and then the blocks are connected in series through a block chain structure to form a blockchain ledger. Each block contains a block header and a block body. The block body is used to record specific transaction records, and the block header is mainly used to link the previous block and ensure the integrity of the ledger. The storage security management of the blockchain ledger shall meet the following requirements:

a) Blocks are identified by the hash value of the block header, which is used to link adjacent blocks and ensure the integrity of block data;

b) Encryption measures shall be used to ensure the confidentiality of important contents of the ledger;

c) Identity authentication and access control measures need to be adopted to ensure authorized access to ledger data.

8.6 Off-chain transactions

The blockchain can also support off-chain transaction models, which shall use digital signatures to confirm the true identities of the parties to the transaction, keep audit records of all transactions, and use cryptographic technology to ensure the integrity of the audit records.

When the off-chain transaction system performs periodic on-chain operations, the blockchain system shall check the validity of all unregistered transactions and check the correctness of transaction settlement according to pre-defined business rules.

8.7 Identity management of nodes and users

In the blockchain, it is necessary to ensure the identifiability and legitimacy of the identities of all nodes and users in the system. In the consortium blockchain, when a node enters or exits, the node identity should be verified through digital certificate technology and audit logs shall be generated.

8.8 Transaction supervision

Cryptographic technology is used to ensure that the regulatory nodes can view user entity identities, transaction information, etc.; to ensure that the authority of the regulatory nodes is controlled; and in certain specific scenarios, to ensure that transactions are legal and revocable without affecting subsequently generated transaction blocks or changing the verifiability of the entire chain.

Banks, insurance companies, Internet platforms, electronic data forensic expertise centers, CAs, notary offices, and third-party data service providers serve as nodes of the consortium blockchain, and courts join the blockchain as regulators to uniformly formulate the operating standards and contract conditions of the blockchain evidence storage platform. All nodes and participants on the blockchain shall participate and operate in accordance with the transaction rules formulated in advance, jointly maintain the consortium blockchain, solve various electronic evidence identification issues in Internet disputes, and record and access the status of the entire process of Internet contracts, intellectual property rights, etc. through the blockchain, effectively solving problems such as unreliable evidence and insufficient legal effect in Internet disputes.

Banks, insurance companies, Internet platforms, and third-party data service providers store relevant contract data and ownership evidence on the blockchain; when relevant contract and ownership disputes occur, the court, as a regulator, views the relevant electronic data evidence information and uses the blockchain electronic evidence information for judicial acceptance and the next step of trial.

The scheme adopts SM2, SM3, and SM4, as well as digital certificates and secure communication TLS protocols based on these algorithms. As a regulator, the court is responsible for identity verification for users joining the blockchain and issues digital certificates to them after the verification. Users holding legal certificates can participate in consensus accounting as nodes of the blockchain service platform and jointly maintain the blockchain electronic evidence ledger. The hash value of the block is obtained through SM3 calculation, and it also supports cross-chain operations between this blockchain and external blockchains. The hash value of the block header of the external blockchain is obtained through SM3 calculation and stored in this blockchain to realize the tamper-proof feature of the blockchain. The TLS protocol is used to ensure communication security between each blockchain node to achieve consistent storage of the blockchain ledger.

A.2 Cryptographic application design A.2.1 General design requirements for cryptographic applications

a) Use SM4 to protect sensitive data;

b) Use SM2 and SM3 to complete the signature and verification operations, and use the algorithm to generate a digital certificate;

c) Use SM3 to complete data hashing operation;

d) Establish a TLS secure channel using SM2, SM3, and SM4.

A.2.2 Cryptographic application design of privacy protection modules ......