A blockchain-based trusted relay operation auditing method and system

Abstract

The application belongs to the technical field of QKD network security operation and maintenance, and discloses a trusted relay operation auditing method and system based on a block chain, which comprises key life cycle identification allocation, relay operation record generation, block chain storage, key validity period verification, key operation traceability and other schemes.Compared with the prior art, the application adopts a key life cycle identification mechanism, a relay operation record chain storage, an intelligent contract key validity period verification and other technical means, and realizes full-process auditability of trusted relay node key forwarding operation.The application promotes the evolution of trusted relay from 'assumed trust' to'verified trust', and records each key forwarding operation of the relay node on the block chain, thereby solving the problems of lack of tamper-proof records of key forwarding operation of the relay node, inability to trace the operation behavior afterwards, inability to associate and audit the relay operation with the specific used key, and inability to automatically verify whether the relay operation is executed within the key validity period.

Description

Technical Field

[0001] This invention relates to the technical field of quantum key distribution (QKD) network security operation and maintenance, and in particular to a blockchain-based trusted relay operation auditing method and system. Background Technology

[0002] In quantum communication networks, quantum key distribution (QKD) technology establishes a theoretically absolutely secure key between communicating parties through a quantum channel. However, due to the limited transmission distance of quantum channels (typically not exceeding 100 kilometers), long-distance QKD communication relies on key relay technology. Key relay was first proposed by Elliott of BBN. ​​Its basic idea is to use a quantum key shared between adjacent nodes to encrypt and decrypt the relay key, enabling encrypted relaying of the key between one or more relay nodes, ultimately reaching the destination user. During this process, relay nodes have access to the plaintext key, hence the term "trusted relay"—the system assumes these nodes will not steal or tamper with the data. However, in practice, auditing methods are needed to record and trace these actions.

[0003] In the prior art, invention patent CN202111197177.1 discloses a blockchain-based secure communication method and security event tracing method. Its core is to upload the logs of each stage of quantum key generation, distribution, use, destruction and update to the blockchain to realize log tracing of the entire life cycle of the key. This patent is mainly aimed at two-party end-to-end secure communication scenarios, and the audit object is the life cycle log of the key itself.

[0004] In addition, invention patent CN202510918353.8 discloses a log auditing method and system for quantum key distribution devices. The main technical features of this patent include blockchain-based QKD device log storage, QBER anomaly detection triggered by smart contracts, zero-knowledge proof verification of log integrity, and hierarchical Merkle tree storage structure. This patent solves the "log integrity" problem at the QKD device level, that is, whether the log has been tampered with. It does not involve key lifecycle management, nor can it trace which key was used in a certain relay operation. Summary of the Invention

[0005] In view of the above-mentioned defects in the existing technology, this invention proposes a blockchain-based trusted relay operation auditing method and system to solve the technical problems of untraceable operation behavior of trusted relay nodes and lack of standardization in key usage in QKD networks.

[0006] The technical solution of this invention is implemented as follows: A blockchain-based trusted relay operation auditing method includes the following steps: S101 Key Lifetime Identifier Allocation: In a quantum key distribution network, whenever two nodes generate a shared key through the QKD protocol, a globally unique key identifier is assigned to the shared key, and the key identifier and its validity period information are written into the blockchain for evidence storage. S102 Relay Operation Record Generation: When a trusted relay node receives an encrypted data packet sent by an upstream node and encrypted with a shared key, it performs a forwarding operation of "decrypting with the input key → re-encrypting with the output key → forwarding to the downstream node". When performing this operation, the relay node generates an operation record. The operation record is generated immediately after the forwarding operation is completed. S103 Blockchain Evidence Preservation: The relay node submits the generated operation record to the blockchain. The consensus node in the blockchain first verifies the format integrity of the operation record and the validity of the node's digital signature. Then, it calls the audit smart contract to perform a preliminary verification of the operation record. After the verification is passed, the operation record is packaged into the blockchain and stored. The operation record after evidence preservation cannot be tampered with or deleted. S104 Key Validity Verification: When an operation record is submitted to the blockchain for notarization, the audit smart contract automatically extracts the input key identifier, output key identifier, and operation timestamp from the operation record, queries the validity information of the corresponding key identifier stored on the chain, and determines whether the operation timestamp is within the valid time range. If the verification passes, the operation record is allowed to be uploaded to the blockchain; if any key has expired or been revoked, the request to upload the operation record to the blockchain is rejected, and an abnormal alarm event is triggered. S105 Key Operation Traceability: The auditor can trace the operation through the blockchain query interface based on multiple dimensions.

[0007] Preferably, the key identifier includes at least the following fields: Session identifier, identifying the current QKD session; Node pair identifier, which identifies the two nodes sharing the key and the directionality of the session route; The sequence number is the Nth key generated by this node. Generation time, the time when the key was generated by the QKD device; Effective date: The time when the key can be used. Expiration time: the time when the key expires.

[0008] Preferably, the operation record further includes: operation type, relay node identifier, upstream node identifier, downstream node identifier, hash value of forwarded data payload, and digital signature of the node.

[0009] Preferably, the multi-dimensional traceability includes: (1) Specify a key identifier, query the complete lifecycle information of the corresponding key, and all relay operation records that reference the key. The complete lifecycle information includes the generation time, validity period, and the node pair to which it belongs. (2) Specify a time range and / or node identifier, query all relay operation records executed by the corresponding node within the time range, and extract the input key identifier and output key identifier from the records, and then analyze the key usage path; (3) Generate an audit report, which includes the source of the key, its validity period, the time of each relay operation, upstream and downstream nodes, and data hash.

[0010] Preferably, in step S102, each operation record is associated with two key identifiers: an input key identifier and an output key identifier, used to trace the source and destination of the key.

[0011] Preferably, after blockchain notarization in step S103, a signature verification step is also included: when the auditor queries the operation records on the blockchain, the auditor verifies the digital signature of the relay node to confirm that the operation records were generated by legitimate nodes and have not been tampered with.

[0012] Preferably, step S104, key validity verification, further includes: checking whether the key corresponding to the key identifier has been revoked; if it has been revoked, the verification fails; after successful verification, the verification result is written into the blockchain as audit evidence.

[0013] Preferably, step S105 key operation tracing supports forward tracing and reverse tracing. Forward tracing involves finding all relay operations using the corresponding key based on the key identifier, while reverse tracing involves finding all key identifiers and corresponding key information used by the node based on the node identifier and time range.

[0014] Preferably, the blockchain adopts a consortium blockchain architecture, with consensus nodes jointly maintained by multiple QKD network operators, and the consensus mechanism adopts a practical Byzantine fault-tolerant algorithm; data does not go on the public network, but only circulates within the operator's internal network, ensuring the privacy and controllability of audit data.

[0015] Preferably, the binding relationship between the key identifier and the key content adopts on-chain and off-chain separate storage: the blockchain only stores the key identifier and its validity period, node pair metadata, and does not store the key plaintext; the actual key content is only stored locally on the two nodes that share the key.

[0016] This invention also discloses a blockchain-based trusted relay operation auditing system, comprising: Key lifecycle management module: Deployed within each QKD network operator, it is used to allocate key identifiers when keys are generated and write the key identifiers and validity information to the blockchain; Relay Operation Record Module: Deployed on each trusted relay node, it is used to generate an operation record containing the input key identifier and the output key identifier after each key forwarding operation, and submit it to the blockchain; Blockchain evidence storage module: Composed of consortium blockchain consensus nodes, it is used to verify the signature and format of operation records, and to perform validity checks through smart contracts, and finally store the legitimate records in the block; Audit traceability module: Provides a query interface, allowing auditors to retrieve operation records by key identifier, time range, node identifier, and other conditions, and generate readable audit reports.

[0017] Preferably, the system further includes a key lifecycle management module, deployed within each QKD network operator, used to allocate key identifiers during key generation and write the key identifiers and validity information into the blockchain; and a relay operation record module, deployed in each trusted relay node, used to generate an operation record containing input key identifiers and output key identifiers after each key forwarding operation, and submit it to the blockchain for evidence storage.

[0018] Preferably, it also includes an audit traceability module, which provides query interfaces based on dimensions such as key identifier, time range, and node identifier, supporting the auditor to retrieve operation records and generate readable audit reports.

[0019] Preferably, the system comprises two parts: a QKD trusted relay communication network and a blockchain auditing network. The two parts interact via a key management interface, including: The QKD trusted relay communication network includes a sending node, a receiving node, and at least one trusted relay node; the sending node and the first trusted relay node establish a shared key K_in through the QKD protocol, and the first trusted relay node and the next node establish a shared key K_out through the QKD protocol; the trusted relay node is used to perform a key forwarding operation of "decrypting with K_in → re-encrypting with K_out → forwarding"; The blockchain audit network adopts a consortium blockchain architecture, including multiple consensus nodes and one or more audit smart contracts. The consensus nodes are jointly maintained by multiple QKD network operators and optional regulators. The consensus nodes reach consensus through practical Byzantine fault tolerance or other suitable consensus algorithms. The audit smart contracts are deployed on the blockchain and are used to perform key lifecycle management, operation record verification, and key validity period checks.

[0020] Compared with the prior art, the present invention has the following beneficial effects: (1) Operation behavior is immutable: Through blockchain notarization, every key forwarding operation of the relay node is permanently recorded, and any subsequent tampering can be detected.

[0021] (2) Fine-grained association between key and operation: Through the Key_ID mechanism, the relay operation is bound to the key used (including source, validity period, node pair), so as to realize bidirectional traceability from key to operation and from operation to key.

[0022] (3) Automated verification of key validity period: The smart contract automatically verifies whether the operation time is within the key validity period during the notarization stage, preventing the use of expired or revoked keys and improving the standardization of key management.

[0023] (4) Trustworthy cross-domain audit: The consortium blockchain architecture is jointly maintained by multiple operators, providing a trustworthy third-party witness between different operators, reducing the trust cost of cross-domain cooperation, and providing undeniable evidence for the determination of responsibility for security incidents. Attached Figure Description

[0024] Figure 1 This is a flowchart of the blockchain-based trusted relay operation auditing method of the present invention; Figure 2 This is a flowchart illustrating the key generation and Key_ID allocation process in an embodiment of the present invention. Figure 3 This is a flowchart illustrating the relay operation record generation and on-chain process in an embodiment of the present invention. Detailed Implementation

[0025] The present invention will now be clearly and completely described with reference to the accompanying drawings in the embodiments of the present invention.

[0026] like Figure 1 As shown, the present invention provides a blockchain-based trusted relay operation auditing method, comprising the following steps: S101 Key Lifetime Identity Allocation: In a quantum key distribution network, whenever two nodes generate a shared key via the QKD protocol, the key management module assigns a globally unique key identifier, Key_ID, to that key. Key_ID contains at least the following fields: session ID (identifying the current QKD session), node pair ID (identifying the two nodes sharing the key and the directionality of the session route, such as "Alice->Relay A"), sequence number (the Nth key generated by this node pair), generation time (the time the key was generated by the QKD device), valid start time (the time the key can be used), and valid end time (the time the key expires). After allocation, the Key_ID and its validity period information are written to the blockchain for record-keeping. S102 Relay Operation Record Generation: When a trusted relay node receives an encrypted data packet from an upstream node and encrypted with a shared key, it performs a forwarding operation of "decrypting with the input key → re-encrypting with the output key → forwarding to the downstream node." This forwarding operation may also include a data integrity verification step after decryption with the input key. During this operation, the relay node generates an operation record, which includes at least: the input key identifier Key_ID_in, the output key identifier Key_ID_out, the operation type (decrypt_forward_encrypt), the relay node identifier, the upstream node identifier, the downstream node identifier, the operation timestamp, the hash value of the forwarded data payload, and the node's digital signature. The operation record is generated immediately after the forwarding operation is completed. S103 Blockchain Notarization: Relay nodes submit the generated operation records to the blockchain network. Consensus nodes in the blockchain first verify the format integrity of the operation record and the validity of the node's digital signature. Then, they call the audit smart contract to perform preliminary verification of the operation record (e.g., checking if the Key_ID format is valid and if the corresponding key ID exists on the chain). After successful verification, the operation record is packaged into a block and stored. The notarized operation record cannot be tampered with or deleted. S104 Key Validity Verification: When an operation record is submitted to the blockchain for notarization, the auditing smart contract automatically extracts the Key_ID_in, Key_ID_out, and operation timestamp from the operation record, queries the validity information of the corresponding Key_ID stored on the chain, and determines whether the operation timestamp is within the range [valid_start, valid_end]. If the verification passes, the record is allowed to be uploaded to the chain; if any key has expired or been revoked, the smart contract rejects the request to upload the operation record to the chain and triggers an abnormal alarm event. S105 Key Operation Traceability: The auditor can trace the key based on the following dimensions through the blockchain query interface: (1) Specify Key_ID to query the complete lifecycle information of the key (generation time, validity period, and node pair to which it belongs) and all relay operation records that reference the key; (2) Specify time range and / or node identifier to query all relay operation records executed by the node within the range, and extract Key_ID_in and Key_ID_out from the records to analyze the key usage path; (3) Generate an audit report, the report content of which includes the source of the key (QKD session and node pair to which it belongs), validity period, time of each relay operation, upstream and downstream nodes, data hash, etc.

[0027] In step S101, the specific structure of the Key_ID also includes optional extended fields: key generation protocol (such as BB84, BBM92, etc.) and key length (number of bits).

[0028] In step S102, the specific content of the operation record includes: operation type, relay node identifier, upstream node identifier, downstream node identifier, timestamp, hash value of forwarded data payload, and node digital signature; each operation record is associated with two Key_IDs—input key identifier Key_ID_in and output key identifier Key_ID_out, which are used to trace the source and destination of the key.

[0029] Step S103, after blockchain notarization, also includes a signature verification step: when the auditor queries the operation records on the blockchain, he / she can verify the digital signature of the relay node to confirm that the operation record was generated by a legitimate node and has not been tampered with.

[0030] Step S104, key validity verification, also includes: checking whether the key corresponding to Key_ID has been revoked (e.g., expired due to a security event). If it has been revoked, the verification fails. After successful verification, the verification result (including verification time and verification conclusion) is written into the blockchain as audit evidence.

[0031] Step S105 Key operation tracing supports forward tracing (finding all relay operations using the corresponding key by Key_ID) and reverse tracing (finding all Key_IDs and corresponding key information used by the node by node identifier and time range).

[0032] The blockchain network adopts a consortium blockchain architecture, with consensus nodes jointly maintained by multiple QKD network operators. The consensus mechanism uses the Practical Byzantine Fault Tolerance (PBFT) algorithm. Data does not go on the public network, but only circulates within the operator's internal network, ensuring the privacy and controllability of audit data.

[0033] The binding relationship between Key_ID and key content adopts a separate on-chain and off-chain storage approach: the blockchain only stores Key_ID, its validity period, and node peer metadata, without storing the key plaintext; the actual key content is only stored locally on the two relay nodes sharing the key. This design ensures key traceability while avoiding the security risks associated with storing the key itself on the blockchain.

[0034] This invention also provides a blockchain-based trusted relay operation auditing system, comprising: Key lifecycle management module: Deployed within each QKD network operator, it is used to allocate Key_ID when the key is generated and write the Key_ID and validity period information into the blockchain; Relay Operation Record Module: Deployed on each trusted relay node, it is used to generate an operation record containing Key_ID_in and Key_ID_out after each key forwarding operation and submit it to the blockchain; Blockchain evidence storage module: Composed of consortium blockchain consensus nodes, it is used to verify the signature and format of operation records, and to perform validity checks through smart contracts, and finally store the legitimate records in the block; Audit traceability module: Provides a query interface, allowing auditors to retrieve operation records by Key_ID, time range, node identifier, and other conditions, and generate readable audit reports.

[0035] The overall architecture of the system described in this invention comprises two parts: a QKD trusted relay communication network and a blockchain auditing network. These two networks interact via a key management interface, including: The QKD trusted relay communication network includes a sending node, a receiving node, and at least one trusted relay node; the sending node and the first trusted relay node establish a shared key K_in through the QKD protocol, and the first trusted relay node and the next node establish a shared key K_out through the QKD protocol; the trusted relay node is used to perform a key forwarding operation of "decrypting with K_in → re-encrypting with K_out → forwarding".

[0036] The blockchain audit network adopts a consortium blockchain architecture, including multiple consensus nodes and one or more audit smart contracts. The consensus nodes are jointly maintained by multiple QKD network operators and optional regulators, and the consensus nodes reach consensus through Practical Byzantine Fault Tolerance (PBFT) or other suitable consensus algorithms. The audit smart contracts are deployed on the blockchain and are used to perform functions such as key lifecycle management, operation record verification, and key validity period checks.

[0037] The system also includes a key lifecycle management module, deployed within each QKD network operator, used to allocate Key_ID when keys are generated and write Key_ID and validity information to the blockchain; and a relay operation record module, deployed at each trusted relay node, used to generate an operation record containing Key_ID_in and Key_ID_out after each key forwarding operation and submit it to the blockchain for evidence storage.

[0038] The system also includes an audit traceability module, which provides query interfaces based on dimensions such as Key_ID, time range, and node identifier, enabling auditors to retrieve operation records and generate readable audit reports.

[0039] Embodiment 1 of the present invention: Example 1: This invention provides a trusted relay audit network topology comprising a QKD trusted relay communication network and a blockchain audit network. Taking a cross-domain secure communication application scenario of a government network as an example, its network topology includes: QKD Trusted Relay Communication Network: Taking cross-domain secure communication on a government network as an application scenario, this network involves three administrative levels and four communication nodes, forming a typical three-hop trusted relay QKD link. The sender, Alice, is a Level 1 security bureau located in city A, using QKD transmitter equipment. The first-hop relay (Relay A) is managed by a Level 2 cryptography bureau located in city B, using QKD relay equipment. The second-hop relay (Relay B) is managed by another Level 2 cryptography bureau located in city C, also equipped with QKD relay equipment. The receiver, Bob, is a Level 3 government bureau located in city D, using QKD receiver equipment. Each link is configured with one quantum channel and one classical authentication channel for key negotiation and blockchain interaction.

[0040] Blockchain Audit Network: Adopting a consortium blockchain architecture, the consensus algorithm is Practical Byzantine Fault Tolerance (PBFT), with a total of 4 consensus nodes. Consensus node 1 is the first-level cryptographic bureau (also acting as the administrator of Alice), consensus node 2 is the second-level cryptographic bureau (also acting as the administrator of relay A), consensus node 3 is another second-level cryptographic bureau (also acting as the administrator of relay B), and consensus node 4 is the third-level government bureau (an independent regulator). On-chain data is persistently stored and supports historical audits.

[0041] Embodiment 2 of the present invention: Example 2: Referring to Example 1, see... Figure 1 , Figure 2 As shown, the key lifecycle identifier allocation method in step S101 of this invention also includes sub-steps such as S201, S202, and S203, as follows: S201 First Hop Key Generation (Alic to Relay A). The Alice-end QKD device and the relay A-end QKD device perform quantum key distribution via the BB84 protocol. After basis vector comparison, bit error rate verification, and privacy amplification, the two parties negotiate a 256-bit shared key K_AB.

[0042] The key management module generates Key_ID_001 for this key. Key_ID uses UUID v4 format and concatenates node pair serial numbers to ensure global uniqueness. The structure of Key_ID_001 is shown below. Key_ID_001 = { session_id: "550e8400-e29b-41d4-a716-446655440000", node_pair: "Alice-Relay A", sequence_num: 1, generation_time: "2025-10-17T09:00:00Z", valid_start: "2025-10-17T09:00:00Z", valid_end: "2025-10-17T10:00:00Z", key_protocol: "BB84", Length: 256 }

[0043] The key management module calls the blockchain client's write interface to package the metadata of Key_ID_001 (excluding the plaintext key) into a transaction and send it to the blockchain network. Then, the consensus node verifies the transaction signature (using the private key of the provincial cryptography bureau) and writes Key_ID_001 into block height #1001.

[0044] Meanwhile, the plaintext key K_AB corresponding to Key_ID_001 is securely stored in the local hardware security module (HSM) of Alice and relay A, establishing a mapping relationship with Key_ID_001. Note that the plaintext key is not stored on the chain; only the Key_ID and its expiration date are stored.

[0045] S202 Second Hop Key Generation (Relay A to Relay B) Similarly, relay A and relay B generate a shared key K_BC through a QKD session and assign Key_ID_002. The structure of Key_ID_002 is shown below: Key_ID_002 = { session_id: "660e8400-e29b-41d4-a716-446655440001", node_pair: "Relay A-Relay B", sequence_num: 1, generation_time: "2025-10-17T09:00:10Z", valid_start: "2025-10-17T09:00:10Z", valid_end: "2025-10-17T10:00:10Z", key_protocol: "BB84", Length: 256 }

[0046] The metadata for Key_ID_002 was written to blockchain block height #1002.

[0047] S203 Third Hop Key Generation (Relay B to Bob) Relay B and Bob generate a key K_CD, assign Key_ID_003, and write the metadata to blockchain block height #1003. At this point, three Key_ID records have been stored on the blockchain, providing a key lifecycle benchmark for subsequent relay operation audits.

[0048] Embodiment 3 of the present invention: Example 3: Referring to Example 1, see... Figure 1 , Figure 3 As shown, the relay record generation and on-chain method flow in step S102 (relay operation record generation), S103 (blockchain notarization), and S104 (key validity verification) of this invention specifically includes sub-steps such as S301, S302, and S303, as follows: S301 Data Transmission and First Hop Relay Operation Alice needs to send a confidential file to Bob (assuming the file hash value is "0x7A8B9C..."). The sending process is as follows: 1) Alice uses the locally stored key K_AB (corresponding to Key_ID_001) to encrypt the file hash value and additional metadata (timestamp, serial number) to obtain ciphertext C1.

[0049] 2) Alice sends the ciphertext C1 along with Key_ID_001 to relay A.

[0050] After receiving the data, relay A performs the following operations: 1) Based on the received Key_ID_001, retrieve the corresponding key K_AB from the local HSM.

[0051] 2) Use K_AB to decrypt ciphertext C1.

[0052] 3) Relay A retrieves the key K_BC (Key_ID_002) corresponding to the next hop from the local HSM.

[0053] 4) Re-encrypt the file hash value using K_BC to generate ciphertext C2.

[0054] 5) Generate operation record Record_001, the content of which is shown below: Record_001 = { record_id: "rec-20251017-090100-001", operation_type: "decrypt_forward_encrypt", relay_node_id: "Relay A", input_key_id: "Key_ID_001", output_key_id: "Key_ID_002", previous_node: "Alice", next_node: "Relay B", timestamp: 1760662860, / / 2025-10-17 09:01:00 UTC data_hash: "0x7A8B9C...", / / Consistent with the file hash value sent by Alice node_signature: "3045022100..." / / Relay A signs the record hash using its private key. }

[0055] 6) Relay A submits Record_001 to the blockchain network.

[0056] The consensus node receives Record_001 and performs the following verification operation: 1) Verify the validity of the signature using the public key of relay A.

[0057] 2) Check if Key_ID_001 and Key_ID_002 already exist on the chain (check block heights #1001 and #1002) 3) Determine whether timestamp 1760662860 is within the validity period of Key_ID_001 [09:00:00, 10:00:00] and Key_ID_002 [09:00:10, 10:00:10].

[0058] 4) The audit smart contract automatically performs validity period verification. After passing the verification, Record_001 is packaged into block height #1004.

[0059] S302 Second Hop Relay Operation Relay A sends ciphertext C2 and Key_ID_002 to relay B. Relay B performs a similar operation: decrypts it using K_BC, re-encrypts it into C3 using K_CD (Key_ID_003), generates Record_002, and submits it to the chain at block height #1005.

[0060] S303 Recipient Decryption After receiving the ciphertext C3 and Key_ID_003, Bob retrieves K_CD from his local HSM to decrypt it, obtaining the original file hash value. He then compares this hash value with the one sent by Alice, confirming the communication is complete. At this point, two operation records (Record_001 and Record_002) have been stored on the blockchain, fully documenting the flow path of the file hash value during the three-hop relay process.

[0061] Embodiment 4 of the present invention: Example 4: Combining Examples 1, 2, and 3, the key operation tracing method flow in step S105 of this invention specifically includes sub-steps S401, S402, S403, and S404, as follows: The S401 Audit Center initiated an audit of the key operation behavior of a relay node within a specific time period to confirm whether expired or unauthorized keys were used. Auditors first logged into the audit traceability module, set query conditions, and assumed the audit target was relay A: the node identifier was "Relay A," and the time range was limited to between 09:00 and 10:00 on October 17, 2025.

[0062] The S402 audit traceability module sends a query request to the blockchain network. The audit smart contract on the blockchain searches within the range of block height #1001 to #1010, filters out all operation records of relay nodes identified as "Relay A" and whose operation timestamps fall within the specified time interval, and returns record Record_001 and other forwarding operation records of Relay A within that time period.

[0063] The S403 audit traceability module parses the specified operation record, extracting the input key identifier Key_ID_001 and the output key identifier Key_ID_002 from Record_001. The module then further queries the metadata of these two Key_IDs stored on the blockchain: the node pair corresponding to Key_ID_001 is "Alice-Relay A," valid from 09:00:00 to 10:00:00; the node pair corresponding to Key_ID_002 is "Relay A-Relay B," valid from 09:00:10 to 10:00:10. The smart contract automatically verifies whether the operation timestamp 1760662860 falls within the validity period of both keys, and the verification result is successful for both.

[0064] The S404 audit traceability module generates a complete audit report, which includes: the total number of forwarding operations performed by Relay A within the specified time range; the input key used for each operation, its source node pair, and its validity period; the output key, its target node pair, and its validity period; the timestamp and data hash value of each operation; and the validity period verification result. If there are any verification failures, the report will mark the exception and provide a specific reason, such as "Key_ID_001 has expired". Optionally, the audit report can be exported in PDF and JSON formats for regulatory archives or as a compliance certificate.

[0065] As can be seen from the various embodiments of this invention, this invention proposes a blockchain-based trusted relay operation auditing method and system. This invention employs key lifecycle identification (Key_ID) mechanisms, on-chain notarization of relay operation records, and smart contract key validity period verification technologies to achieve full-process auditability of key forwarding operations of trusted relay nodes. This invention promotes the evolution of trusted relays from "assumed trustworthiness" to "verified trustworthiness." Each key forwarding operation of a relay node is recorded on the blockchain, achieving immutability and auditability of trusted relay behavior.

Claims

1. A blockchain-based trusted relay operation auditing method, characterized in that, Includes the following steps: S101 Key Lifetime Identifier Allocation: In a quantum key distribution network, whenever two nodes generate a shared key through the QKD protocol, a globally unique key identifier is assigned to the shared key, and the key identifier and its validity period information are written into the blockchain for evidence storage. S102 Relay Operation Record Generation: When a trusted relay node receives an encrypted data packet sent by an upstream node and encrypted with a shared key, it performs a forwarding operation of "decrypting with the input key → re-encrypting with the output key → forwarding to the downstream node". When performing this operation, the relay node generates an operation record. The operation record is generated immediately after the forwarding operation is completed. S103 Blockchain Evidence Storage: The relay node submits the generated operation record to the blockchain. The consensus node in the blockchain first verifies the format integrity of the operation record and the validity of the node's digital signature. Then, it calls the audit smart contract to perform a preliminary verification of the operation record. After the verification is passed, the operation record is packaged into the blockchain and stored. S104 Key Validity Verification: When an operation record is submitted to the blockchain for notarization, the audit smart contract automatically extracts the input key identifier, output key identifier, and operation timestamp from the operation record, queries the validity information of the corresponding key identifier stored on the chain, and determines whether the operation timestamp is within the valid time range. If the verification passes, the operation record is allowed to be uploaded to the blockchain; if any key has expired or been revoked, the request to upload the operation record to the blockchain is rejected, and an abnormal alarm event is triggered. S105 Key Operation Traceability: The auditor can trace the operation through the blockchain query interface based on multiple dimensions.

2. The method according to claim 1, characterized in that, The key identifier shall contain at least the following fields: Session identifier, identifying the current QKD session; Node pair identifier, which identifies the two nodes sharing the key and the directionality of the session route; The sequence number is the Nth key generated by this node. Generation time, the time when the key was generated by the QKD device; Effective date: The time when the key can be used. Expiration time: the time when the key expires.

3. The method according to claim 1, characterized in that, The operation record also includes: operation type, relay node identifier, upstream node identifier, downstream node identifier, hash value of forwarded data payload, and digital signature of the node.

4. The method according to claim 1, characterized in that, The multi-dimensional tracing method includes: (1) Specify a key identifier, query the complete lifecycle information of the corresponding key, and all relay operation records that reference the key. The complete lifecycle information includes the generation time, validity period, and the node pair to which it belongs. (2) Specify a time range and / or node identifier, query all relay operation records executed by the corresponding node within the time range, and extract the input key identifier and output key identifier from the records, and then analyze the key usage path; (3) Generate an audit report, which includes the source of the key, its validity period, the time of each relay operation, upstream and downstream nodes, and data hash.

5. The method according to claim 4, characterized in that, In step S102, each operation record is associated with two key identifiers: input key identifier and output key identifier.

6. The method according to claim 1, characterized in that, Step S103, after blockchain notarization, also includes a signature verification step: when the auditor queries the operation records on the blockchain, the digital signature of the relay node is verified.

7. The method according to claim 1, characterized in that, Step S104, key validity verification, also includes: checking whether the key corresponding to the key identifier has been revoked; if it has been revoked, the verification fails; after successful verification, the verification result is written to the blockchain as audit evidence.

8. The method according to claim 1, characterized in that, Step S105 Key operation tracing supports forward tracing and reverse tracing. Forward tracing is to find all relay operations that use the corresponding key by using the key identifier. Reverse tracing is to find all key identifiers and corresponding key information used by the node by using the node identifier and time range.

9. The method according to claim 1, characterized in that, The blockchain adopts a consortium blockchain architecture, with consensus nodes jointly maintained by multiple QKD network operators, and the consensus mechanism uses a practical Byzantine fault-tolerant algorithm.

10. The method according to claim 1, characterized in that, The binding relationship between the key identifier and the key content adopts on-chain and off-chain separate storage: the blockchain only stores the key identifier and its validity period, node pair metadata, and does not store the key plaintext; the actual key content is only stored locally on the two nodes that share the key.

11. A blockchain-based trusted relay operation auditing system, used to implement the method according to any one of claims 1-10, characterized in that, include: Key lifecycle management module: Deployed within each QKD network operator, it is used to allocate key identifiers when keys are generated and write the key identifiers and validity information to the blockchain; Relay Operation Record Module: Deployed on each trusted relay node, it is used to generate an operation record containing the input key identifier and the output key identifier after each key forwarding operation, and submit it to the blockchain; Blockchain evidence storage module: Composed of consortium blockchain consensus nodes, it is used to verify the signature and format of operation records, and to perform validity checks through smart contracts, and finally store the legitimate records in the block; Audit traceability module: Provides a query interface, allowing auditors to retrieve operation records by key identifier, time range, node identifier, and generate readable audit reports.

12. The system according to claim 11, characterized in that, The system comprises two parts: a QKD trusted relay communication network and a blockchain auditing network. The two interact via a key management interface, including: The QKD trusted relay communication network includes a sending node, a receiving node, and at least one trusted relay node; the sending node and the first trusted relay node establish a shared key K_in through the QKD protocol, and the first trusted relay node and the next node establish a shared key K_out through the QKD protocol; the trusted relay node is used to perform a key forwarding operation of "decrypting with K_in → re-encrypting with K_out → forwarding"; The blockchain audit network adopts a consortium blockchain architecture, including multiple consensus nodes and one or more audit smart contracts. The consensus nodes are jointly maintained by multiple QKD network operators and optional regulators. The consensus nodes reach consensus through practical Byzantine fault tolerance or other suitable consensus algorithms. The audit smart contracts are deployed on the blockchain and are used to perform key lifecycle management, operation record verification, and key validity period checks.

Images