GM/T 0122-2022Cryptography test specification for blockchain (English PDF)

6.1.3 Hash cryptographic algorithm implementation correctness test

For given messages and parameters, call the hash algorithm, to test the correctness of its operation results, including:

a) Call the hash algorithm operation interface for the given message to calculate the hash value, and the result shall be exactly the same as the given hash value;

b) Call the hash algorithm operation interface for the given message and parameters to calculate the hash value, and the result shall be exactly the same as the given hash value.

6.1.4 Asymmetric cryptographic algorithm encryption and decryption

implementation correctness test for the given key and plaintext (ciphertext), call the asymmetric cryptographic algorithm, to test the correctness of its operation results, including:

a) Call the asymmetric cryptographic algorithm encryption operation interface to perform encryption operation on the given plaintext and key, and test the tool's decryption operation on the ciphertext. The decryption result shall be exactly the same as the given plaintext;

b) Call the asymmetric cryptographic algorithm decryption operation interface to perform decryption operation on the given ciphertext and key, and the decryption result shall be exactly the same as the given plaintext.

6.1.5 Asymmetric cryptographic algorithm digital signature and signature

verification implementation correctness test Call the asymmetric cryptographic algorithm to perform signature/verification operation on the data, and test the correctness of the operation results, including:

a) Call the asymmetric cryptographic algorithm signature operation interface to perform signature operation on the given message to be signed and the key, and test the tool's verification operation on the signature result, where it shall pass the signature verification;

b) Call the asymmetric cryptographic algorithm signature verification operation interface to perform signature verification on the given signature result, the message to be signed, and the key, where it shall pass the signature verification.

6.1.6 Asymmetric key pair consistency test

For the generated public and private keys, call the asymmetric cryptographic algorithm to test the correctness of the operation results, including:

a) Use the public key to encrypt the plaintext, and use the private key to decrypt the ciphertext. The decrypted result shall be the same as the original plaintext;

b) Test the asymmetric key pair consistency by calculating and verifying a digital signature, where the digital signature shall be verified.

6.2 Random number test

Random numbers shall be generated using cryptographic components or modules that have passed cryptographic testing and certification, and the quality of random numbers shall comply with the requirements of GM/T 0005.

6.3 Cryptographic protocol

The cryptographic protocols used shall comply with the relevant cryptographic requirements of national standards and industry standards:

a) When using the TLCP protocol, it shall comply with GB/T 38636;

b) When using IPSec protocol, it shall comply with GM/T 0022;

c) When using zero knowledge proof, ring signature, group signature, secure multi-party computing, etc. that have been reviewed and authenticated by the national cryptography authorities, protocol interaction data shall be collected to verify correctness and consistency.

6.4 Key management

Key management security shall meet the following requirements:

a) The key generation shall be done inside the cryptographic component or module that has passed the cryptographic testing and certification; the generation and negotiation of private keys and symmetric keys shall use random numbers that meet the requirements of GM/T 0005;

b) Symmetric keys and private keys shall be stored in a secure form or in encrypted form;

c) If the key distribution process is involved, security measures such as identity authentication shall be in place to ensure the authenticity of the key;

cryptographic technologies such as digital signature and HMAC shall be used to ensure the integrity of the distributed key, where HMAC shall comply with GB/T 15852.2; security measures shall be in place to ensure the confidentiality of the key;

cryptographic machine, VPN, cryptographic smart token, timestamp server, signature verification server, etc.

7.1.1 Account creation

Test requirements:

During the account creation phase, a transaction address that can identify the user shall be generated, and a public-private key pair of the SM2 algorithm shall be generated using a cryptographic component or module that has passed the cryptographic testing and certification. The user's private key shall be securely generated and stored inside the cryptographic module, which shall meet the relevant requirements of GM/T 0028.

Test steps:

a) Simulate account creation process;

b) Verify the public-private key pair mechanism for generating the SM2 algorithm during account creation, and verify whether the cryptographic components or modules that have passed the cryptographic testing and certification are used for generation;

c) Verify and analyze whether the user's private key is generated and stored in a cryptographic component or module that has passed cryptographic testing and certification.

Result judgment:

If the results of a) ~ c) are positive, the test item is judged PASS.

7.1.2 Real-name authentication

Test requirements:

When real-name transactions are required, digital certificate technology shall be used to verify the legitimacy and validity of the user's identity.

Test steps:

a) Simulate the real-name authentication process to verify whether the real-name information can be recorded;

b) Verify whether digital certificate technology is used to authenticate user identity.

Result judgment:

If the results of a) and b) are positive, the test item is judged PASS.

7.1.3 Authentication

Test requirements:

In the blockchain, the identifiability and legitimacy of all nodes and user identities between blockchain cryptographic modules shall be ensured. The entry or exit of nodes should use digital certificate technology to verify node identity, authorize node permissions, and generate audit logs. The authentication mechanism for nodes and user identities shall comply with one of the requirements in GB/T 15843.2, GB/T 15843.3, GB/T 15843.4, and GB/T 15843.5.

Test steps:

a) Verify and analyze whether the user's identity authentication mechanism adopts an authentication mechanism based on cryptographic technology;

b) Simulate the transaction process on the user chain. The authentication of legitimate user shall be successful, and the authentication of illegal user shall fail.

The access to the blockchain network through secure communication shall fail, or the transaction verification shall fail;

c) Simulate the node admission process. The legal node identity shall be successfully authenticated and admitted, and the illegal user identity shall fail to be authenticated and the node shall not be allowed to enter;

d) Simulate the process of node access and on-chain transactions. When using legal nodes for authorized permission operation, the node operations shall be allowed;

when using legal nodes for unauthorized permission operations, the node operations shall not be allowed;

e) Check whether audit logs are generated, and verify the integrity of audit logs;

f) If the user's identity authentication mechanism uses digital certificate technology, it shall pass the test in Clause 6.5.

Result judgment:

If the results of a) ~ e) are positive, the test item is judged PASS. If f) is involved and the result is positive, the test item is judged PASS.

7.2 On-chain transaction

7.2.1 Transaction creation

g) If a third-party trusted timestamp is included in the block, verify and analyze whether the timestamp used in the transaction creation process complies with GM/T 0033;

h) Check whether the transaction adds nonce value counts and other anti-replay attack measures;

i) If blind signature, ring signature, group signature, etc. that have been reviewed and authenticated by the national cryptographic authority are used, verify the correctness and consistency of the implementation of the relevant technologies.

Result judgment:

If the results of the test steps a) ~ e) and h) are positive, the test item is judged PASS. If the items in test steps f), g) and i) are involved and the results are positive, the test item is judged PASS.

7.2.2 Transaction verification

Test requirements:

After a transaction is created, 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 of the blockchain cryptographic module in the process of reaching consensus on transactions shall meet the following conditions.

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 record time, etc.

d) The validity verification of the block shall ensure the validity of the hash value of the previous block recorded in the block. Other aspects of verification are similar to transaction verification.

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.

Test steps:

a) Simulate transaction verification process;

b) If digital certificate is used, whether it can pass the test in Clause 6.5;

c) Check whether the transaction record has a digital signature and whether the digital signature can be verified;

d) Check whether the transaction record is provided with the anti-replay attack measure, modify the transaction signature time or nonce value count and other information, and see whether errors can be handled in a timely manner;

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

Result judgment:

If the results of test steps a), c), and d) are positive, the test item is judged PASS. If test steps b) and e) are involved and the results are positive, the test item is judged PASS.

7.3 Off-chain transaction

Test requirements:

In blockchain, off-chain transactions should use digital signatures to confirm the true identity of the parties to the transaction, keep audit records of all transactions, and use cryptographic technology to ensure the integrity of audit records and off-chain data.

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

Test steps:

a) Simulate off-chain transaction process;

b) Verify and analyze the identity authentication mechanism of all parties in the off-chain transaction process to verify whether the identity authentication mechanism is correct and valid;

c) Check and analyze the audit records in the off-chain transaction process to verify whether cryptographic technologies such as MAC and digital signature are used to ensure the integrity of the audit records;

d) Verify and analyze whether cryptographic technologies such as MAC and digital signatures are used to ensure the integrity of off-chain data;

7.5 Communication security

Test requirements:

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

Test steps:

a) Simulate the communication process between the application end and the node, and between nodes; verify and analyze whether the cryptographic algorithms and cryptographic protocols in the communication data comply with the relevant cryptographic requirements of national standards and industry standards;

b) Verify whether the integrity and confidentiality protection mechanism of communication data is correct and valid.

Result judgment:

If the results of a) ~ b) are positive, the test item is judged PASS.

7.6 Consensus mechanism

Test requirements:

The consensus mechanism used shall meet basic security requirements such as consistency and liveness, and provide a clear cryptographic mechanism. All parties involved in the consensus mechanism negotiation shall use cryptographic technology to achieve identity authentication. Sensitive information sent during the execution of the consensus mechanism shall use cryptographic technology to ensure confidentiality, integrity, and non-repudiation.

Test steps:

a) Simulate the consensus process, to verify and analyze whether the cryptographic mechanism of the consensus mechanism is consistent;

b) Simulate the process of consensus mechanism execution, to determine whether the identity of a legitimate consensus user can be successfully identified, and whether the identity of an illegal user cannot be identified and cannot participate in consensus execution;

c) Simulate the process of consensus mechanism execution, whether the sensitive information sent during the execution is encrypted and protected, whether it has integrity verification, and whether it has non-repudiation mechanism;

d) Review the design documents and security self-checking documents provided by the manufacturer to see if they contain instructions for ensuring the fault tolerance, consistency, and availability of the security boundaries of the consensus protocol execution;

e) Review the design documents and security self-checking documents provided by the manufacturer to check whether the documents contain instructions that all honest consensus negotiation nodes complete consensus within the agreed time, record the same content, and all consensus requests shall have processing responses and the order of processing consensus requests is the same;

f) Review the design documents and security self-checking documents provided by the manufacturer to see whether the documents contain information on the ability to prevent nodes from committing malicious acts, and the ability to defend against witch attacks, DoS attacks, and double-spending attacks.

Result judgment:

If the results of a) ~ f) are positive, the test item is judged PASS.

7.7 Smart contracts

Test requirements:

When deploying smart contracts, it is necessary to check whether the user has obtained the corresponding permissions, and cryptographic technology shall be used to prevent smart contracts from being tampered with. Before calling a smart contract, the integrity of the on-chain code shall be checked, and the execution of tampered smart contracts shall be refused.

Test steps:

a) Simulate the process of smart contract deployment and update;

b) Verify and analyze the user authority identification mechanism to determine whether authorized users can correctly deploy smart contracts and whether unauthorized users are refused to deploy smart contracts;

c) When the code is tampered during the deployment and update process, verify whether it can be discovered in time and respond appropriately;

d) Verify and analyze the smart contract code protection mechanism, to see whether digital signature, HMAC and other cryptographic technologies are used to prevent illegal tampering; whether the smart contract can be deployed successfully for codes that have not been tampered with; whether the smart contract can fail to be deployed for codes that have been tampered with.

Result judgment:

If transaction supervision is supported, and the results of a) ~ b) are positive, the test item is judged PASS.

7.10.1 Test scenario

The test scenario setting requirements are as follows:

a) Network scale: N (N can be 4, 8, 16 or more) consensus nodes should be set;

b) Transaction type: transfer transaction, evidence storage transaction, inquiry transaction and other types;

c) System resource consumption: record the consumption of CPU, memory, network, disk and other resources.

7.10.2 System performance

The system performance setting requirements are as follows:

a) Transaction delay: Under normal transaction load, the application initiates a transaction and continuously sends transactions for T seconds (T can be 600, 1 200, or 1 800 seconds), records the number of received transactions N, the number of confirmed transactions M, and the transaction delay time D, and calculates the delay TD (seconds/transaction) of each transaction.

b) Throughput: Initiate transactions from the application end and continuously send transactions for T seconds (T can be 600, 1 200, or 1 800); record the number of transactions received N, the number of transactions confirmed M; calculate the number of transactions received per second TPS (transactions per second) and the number of transactions confirmed per second CTPS (transactions per second).

c) Multi-node ledger synchronization delay: Count the ledger synchronization delay of blockchain network nodes. Pause one of the nodes; send N transactions per second; stop sending new transactions after 10 minutes; restart the paused node;

record the transaction volume sent, transaction size and synchronization time during the pause period; check whether the node can be synchronized within a reasonable time range (transaction synchronization time cannot exceed transaction suspension time); pause for 20 minutes; repeat the above steps.

Calculate the ledger synchronization delay.

d) Ledger synchronization time: Set the ledger data size to 1 GB, 5 GB, 10 GB;

record the ledger synchronization time.