Log auditing method and system for quantum key distribution equipment

Abstract

The invention relates to the technical field of quantum, and discloses a log auditing method and system for quantum key distribution equipment. The method comprises the following steps: acquiring log data of quantum key distribution equipment in a current period; performing Hash calculation on the identifier of the quantum key distribution device, the identifier of the current period and the log data of the current period to obtain an evidence chain of the current period; releasing the log data of the current period and the evidence chain of the current period to a block chain for storage; detecting whether the smart contract on the block chain is triggered; and under the condition that the intelligent contract on the block chain is triggered and the content identifier and the zero-knowledge proof pi are obtained, verifying the log data indicated by the content identifier by using a preset zero-knowledge proof circuit and the zero-knowledge proof pi so as to obtain and output an evidence chain of a period corresponding to the log data which does not pass verification. In the log auditing process of the quantum key distribution equipment, the problem tracing of the log data of the quantum key distribution equipment is safely and automatically realized.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of quantum technology, and in particular to a log auditing method and system of a quantum key distribution device. BACKGROUND

[0002] Quantum Key Distribution (QKD) is a technology that uses quantum mechanics to ensure the security of communication. It enables two parties to generate and share a random, secure key to encrypt and decrypt messages. The security of the quantum key distribution device is the basis of the quantum key distribution technology. In order to ensure the security of the quantum key distribution device, log data of the quantum key distribution device is usually maintained, and through auditing of the log data, problem discovery, positioning and processing are realized.

[0003] However, the current log auditing scheme of the quantum key distribution device still has security risks, and manual problem tracing is required. SUMMARY

[0004] In the embodiments of the present application, a log auditing method and system of a quantum key distribution device are provided, which can safely and automatically realize problem tracing of log data of the quantum key distribution device in the log auditing process of the quantum key distribution device.

[0005] According to some embodiments of the present application, the embodiments of the present application provide a log auditing method of a quantum key distribution device, comprising: obtaining log data of a quantum key distribution device in a current period; performing hash calculation on an identifier of the quantum key distribution device, an identifier of the current period, and log data of the current period to obtain an evidence chain of the current period; publishing the log data of the current period and the evidence chain of the current period to a blockchain for storage; detecting whether a smart contract on the blockchain is triggered; in the case that the smart contract on the blockchain is triggered and a content identifier and a zero-knowledge proof π are obtained, verifying log data indicated by the content identifier by using a pre-set zero-knowledge proof circuit and the zero-knowledge proof π, to obtain and output an evidence chain of a period corresponding to log data that fails to pass the verification.

[0006] In some embodiments, detecting whether a smart contract on the blockchain is triggered includes: obtaining a first sequence and a second sequence based on the log data of the quantum key distribution device, wherein the first sequence is a sequence composed of quantum channel physical parameters of the quantum key distribution device, and the second sequence is a sequence composed of device operating parameters of the quantum key distribution device; detecting whether there is an anomaly in the log data of the quantum key distribution device based on the correlation coefficient of the first sequence and the second sequence, wherein if there is an anomaly in the log data of the quantum key distribution device, the smart contract on the blockchain is triggered, and an alarm is issued and the quantum key distribution device is frozen.

[0007] In some embodiments, detecting whether a smart contract on the blockchain is triggered includes: acquiring noise data through an on-chain oracle of the blockchain; determining the current qubit error rate threshold of the quantum key distribution device based on the noise data; detecting the qubit error rate in the log data of the quantum key distribution device based on the current qubit error rate threshold; wherein, if the detection result of the qubit error rate in the log data of the quantum key distribution device meets a first preset condition, triggering the smart contract on the blockchain and issuing an alarm to freeze the quantum key distribution device, the first preset condition includes detecting that the qubit error rate in the log data of the quantum key distribution device exceeds the current qubit error rate, or detecting that the qubit error rate in the log data of the quantum key distribution device exceeds the current qubit error rate for a preset number of consecutive times.

[0008] In some embodiments, detecting whether a smart contract on the blockchain is triggered includes: detecting whether the polarization angle deviation in the log data of the quantum key distribution device meets a second preset condition, wherein the second preset condition includes: the polarization angle deviation in the log data of the quantum key distribution device exceeds a preset range; if the polarization angle deviation in the log data of the quantum key distribution device meets the second preset condition, the smart contract on the blockchain is triggered, and the quantum key distribution device is alerted and frozen.

[0009] In some embodiments, publishing the log data of the current period and the evidence chain of the current period to the blockchain for storage includes: generating a hash value for the log data of the current period and broadcasting the hash value to the blockchain so that the hash value is stored on at least two nodes of the blockchain; updating the hash value to a leaf node of a hierarchical Merkle tree so that the updated root hash of the hierarchical Merkle tree is broadcast to the blockchain so that the root hash is stored on the blockchain; and storing the evidence chain of the current period on a secure node of the blockchain.

[0010] In some embodiments, consensus verification is achieved on the log data of the current period in the following manner: consensus verification is performed on the log data of the current period based on the random sequence generated by the quantum entropy source device and the quantum Byzantine consensus protocol.

[0011] In some embodiments, obtaining the log data of the quantum key distribution device in the current period includes: obtaining a preset proportion of the transmission signal of the quantum key distribution device using a split-beam bypass, detecting the quantum key distribution device according to the preset proportion of the transmission signal, and outputting the detection result as the log data of the current period.

[0012] According to some embodiments of this application, another aspect of this application provides a log auditing system for a quantum key distribution device, comprising: a collection module for acquiring log data of the quantum key distribution device in the current period; a security module for performing hash calculations on the identifier of the quantum key distribution device, the identifier of the current period, and the log data of the current period to obtain an evidence chain for the current period; and publishing the log data of the current period and the evidence chain for the current period to a blockchain for storage; detecting whether a smart contract on the blockchain is triggered; and a tracing module for, when the smart contract on the blockchain is triggered and a content identifier and a zero-knowledge proof π are obtained, using a zero-knowledge proof circuit to verify the log data indicated by the content identifier, so as to obtain and output the evidence chain for the period corresponding to the log data that failed verification.

[0013] In some embodiments, the system further includes a consensus verification module, configured to perform consensus verification on the hash value and the root hash broadcast to the blockchain based on a random sequence generated by the quantum entropy source device and a quantum Byzantine consensus protocol.

[0014] In some embodiments, the log data for the current period may further include the temperature data for the current period; the security module is further configured to determine temperature control parameters based on the temperature data for the current period, and control the quantum key distribution device and / or the environment in which the quantum key distribution device is located based on the temperature control parameters, so as to control the temperature of the quantum key distribution device within a specified range.

[0015] The technical solution provided in this application embodiment has at least the following advantages:

[0016] Building upon the use of blockchain to store log data from quantum key distribution devices (QKD) to ensure its security, consistency, and integrity, this approach further utilizes the blockchain to store the QKD's identifier, the current period identifier, and an evidence chain for the current period obtained through hash calculation of the log data. This allows for the detection of anomalies by checking whether smart contracts on the blockchain are triggered. When a smart contract is triggered and the content identifier and zero-knowledge proof π are obtained, the zero-knowledge proof circuit can be used to verify the log data indicated by the content identifier, identifying unverified log data (i.e., detecting anomalies). Simultaneously, the evidence chain for the corresponding period of the unverified log data can be obtained and output, enabling source tracing of the problem. Furthermore, the evidence chain stores hash values, and the output also uses hash values, preventing data leakage. Therefore, during the log auditing process of QKD, secure and automated source tracing of log data issues can be achieved. Attached Figure Description

[0017] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application;

[0019] Figure 2 This is a flowchart of a log auditing method for a quantum key distribution device provided in another embodiment of this application;

[0020] Figure 3 This is a flowchart illustrating some steps of the log auditing method for a quantum key distribution device provided in another embodiment of this application;

[0021] Figure 4 This is a flowchart illustrating some steps of the log auditing method for a quantum key distribution device provided in another embodiment of this application;

[0022] Figure 5 This is a flowchart illustrating some steps of the log auditing method for a quantum key distribution device provided in another embodiment of this application;

[0023] Figure 6 This is a flowchart illustrating some steps of the log auditing method for a quantum key distribution device provided in another embodiment of this application;

[0024] Figure 7 This is a schematic diagram of the structure of the log auditing system of the quantum key distribution device provided in another embodiment of this application;

[0025] Figure 8 This is a schematic diagram of the structure of the log auditing system of the quantum key distribution device provided in another embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of this application to enable readers to better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments.

[0027] The division of the following embodiments is for ease of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0028] One embodiment of this application provides a log auditing method for a quantum key distribution device, applicable to electronic devices.

[0029] In some embodiments, such as Figure 1 As shown, the electronic device includes: at least one processor 101; and a memory 102 communicatively connected to at least one processor 101; wherein the memory 102 stores instructions executable by at least one processor 101, the instructions being executed by at least one processor 101 to enable at least one processor 101 to perform the log auditing method of the quantum key distribution device described in the embodiments of this application.

[0030] The memory 102 and processor 101 are connected via a bus, which may include any number of interconnecting buses and bridges, connecting various circuits of one or more processors 101 and memory 102. The bus may also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver may be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 101 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 101.

[0031] Processor 101 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 102 can be used to store data used by processor 101 during operation.

[0032] In some embodiments, the electronic device may also be a device equipped with a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program, when executed by a processor, implements the log auditing method of the quantum key distribution device described in the embodiments of this application.

[0033] That is, those skilled in the art will understand that all or part of the steps in the log auditing method for the quantum key distribution device described in the embodiments of this application can be implemented by a program in an electronic device instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0034] The log auditing method for the quantum key distribution device described in the embodiments of this application will be explained below with reference to different embodiments.

[0035] In some embodiments, such as Figure 2 As shown, the log auditing method for a quantum key distribution device includes at least the following steps:

[0036] Step 201: Obtain the log data of the quantum key distribution device in the current period.

[0037] Step 202: Perform hash calculation on the identifier of the quantum key distribution device, the identifier of the current period, and the log data of the current period to obtain the evidence chain of the current period.

[0038] Step 203: Publish the log data and evidence chain of the current period to the blockchain for storage.

[0039] Step 204: Check whether the smart contract on the blockchain has been triggered.

[0040] Step 205: When the smart contract on the blockchain is triggered and the content identifier and zero-knowledge proof π are obtained, the log data indicated by the content identifier is verified using the pre-built zero-knowledge proof circuit and zero-knowledge proof π, so as to obtain and output the evidence chain corresponding to the period of the log data that failed verification.

[0041] exist Figure 2 In the illustrated embodiment, in addition to using blockchain to store the log data of the quantum key distribution device to ensure the security, consistency, and integrity of the log data, the blockchain further stores the identifier of the quantum key distribution device, the identifier of the current period, and the evidence chain of the current period obtained by hashing the log data of the current period. This allows for the detection of anomalies by checking whether smart contracts on the blockchain are triggered. When a smart contract on the blockchain is triggered and a content identifier and zero-knowledge proof π are obtained, the zero-knowledge proof circuit can be used to verify the log data indicated by the content identifier, identifying unverified log data (i.e., detecting anomalies). Simultaneously, the evidence chain corresponding to the unverified log data of the corresponding period can be obtained and output, enabling source tracing of the problem. Furthermore, the evidence chain stores hash values, and the output is also a hash value, preventing data leakage. Therefore, in the log auditing process of the quantum key distribution device, the source tracing of problems in the log data of the quantum key distribution device can be achieved securely and automatically.

[0042] For ease of understanding, the following will be... Figure 2 The steps of the illustrated embodiment will be explained.

[0043] In step 201, the log data of the quantum key distribution device in the current period is obtained. Here, "period" refers to the log data cycle of the quantum key distribution device, and "log data" refers to the data generated by the quantum key distribution device during its operation that reflects the working status of the quantum key distribution device.

[0044] It should be noted that this application does not limit the size of the time period. In some examples, to observe and locate anomalies more promptly and accurately, the time period can be set to 10 seconds (s). In this case, the time period is relatively short, and the location of anomalies during source tracing can reach the second level. In some examples, to reduce the processing and management pressure of log data, the time period can be set to 1 hour (h). In this case, the time period is relatively long, and the processing and management operations of log data will not be too frequent, thus reducing the processing and management pressure. Of course, the above are just examples, and the size of the time period can be flexibly set according to the application scenario, user needs, time period characteristics, etc., which will not be listed here.

[0045] It should also be noted that the embodiments of this application do not limit the type of data included in the log data. It may include quantum channel physical parameters of the quantum key distribution device, or it may include device operating parameters of the quantum key distribution device. The quantum channel physical parameters of the quantum key distribution device are obtained by measuring the channel of the quantum key distribution device, while the device operating parameters are obtained by measuring the device itself. In some examples, the quantum channel physical parameters of the quantum key distribution device may include at least one of the following: fiber birefringence coefficient, polarization mode dispersion coefficient, and single-photon source wavelength drift. In some examples, the device operating parameters of the quantum key distribution device may include at least one of the following: polarization angle deviation, qubit error rate, photon arrival rate, ambient temperature, etc. Of course, the above are merely examples, and will not be listed exhaustively here.

[0046] In some embodiments, obtaining the log data of the quantum key distribution device in the current period can be achieved as follows: A preset proportion of the transmission signal of the quantum key distribution device is obtained using optical splitting bypass; the quantum key distribution device is detected based on this preset proportion of transmission signal, and the detection result is output as the log data for the current period. In other words, a preset proportion is extracted from the transmission signal of the quantum key distribution device to prevent the transmission signal from being attenuated to the point of affecting the normal communication process of the quantum key distribution device.

[0047] To facilitate understanding of the implementation of step 201, the following will provide an example of how to obtain log data by retrieving different parameters from the log data.

[0048] Obtaining the polarization angle: First, extract 5% of the quantum signal from the transmitter of the quantum key distribution device using an FC-780 fiber optic coupler (splitting ratio 95:5), and input it into a Mach-Zehnder interferometer (wavelength 1550nm, extinction ratio ≥30dB); then, calculate the polarization angle deviation using the two light intensity results output by the interferometer according to the following expression:

[0049]

[0050] Where Δθ is the polarization angle deviation, I1 is one of the two light intensity results output by the interferometer, and I2 is the other of the two light intensity results output by the interferometer. The units of I1 and I2 are both microwatts (μW).

[0051] In some embodiments, in order to periodically acquire log data, the polarization angle is also periodically output to form log data. For example, every 10 milliseconds (ms) the polarization angle deviation data is output once via RS-485 interface (baud rate 115200 bits per second (bps)), and the output format is: timestamp, polarization angle deviation (e.g., 1625030400000 microseconds (μs), 0.12°).

[0052] To obtain the bit error rate of a quantum bit: Step 1: Calculate it on a Field Programmable Gate Array (FPGA) using the following expression:

[0053]

[0054] Where QBER is the bit error rate of a quantum bit, and N error The number of erroneous qubits, N, is obtained by comparing the basis selection sequence with the actual measurement results. total The total number of transmitted bits is determined by the synchronization signal triggered by the quantum key distribution protocol.

[0055] At this point, the error range of the qubit error rate is guaranteed by the clock frequency of the field-programmable gate array (e.g., possibly 200 MHz) and the accuracy of the 32-bit accumulator, with the error typically within ±0.05%.

[0056] In some embodiments, in order to periodically acquire log data, the polarization angle is also periodically output to form log data. For example, a sliding window method (window size 1000 bits) is used to update the qubit error rate every 1 millisecond, and the data is cached in memory (such as DDR3, whose bandwidth can be 1600MHz).

[0057] For obtaining the photon arrival rate: The transmitted signal is acquired using a single-photon detector (SPD), and the pulse signal output by the SPD is amplified by a transimpedance amplifier and then the photon arrival rate is recorded by a 16-bit counter (e.g., NIPCIe-6343 can be used). In some examples, the efficiency of the single-photon detector can be set to 25%, the dark count rate ≤ 100 Hz, and the gain of the transimpedance amplifier can be configured as 1 × 10⁻⁶. 6 V / A, of course, this is just an example.

[0058]

[0059] Among them, R photon To express photon arrival rate, the unit is usually Hertz (Hz) or counts per second, N. countT represents the total number of photons detected within the sampling period. sample The sampling period can be 1 second, and this sampling period can be synchronized using an atomic clock (accuracy ±1 ppm); R dark The dark count rate is calibrated by measuring background noise with the light source off.

[0060] For temperature acquisition: The internal temperature T(t) of the device is collected using a temperature sensor (resolution ±0.03℃).

[0061] Regarding the acquisition of operation records: When log data needs to be output, the operation records recorded by the quantum key distribution device are read. After each operation, the quantum key distribution device can record the operation time, operation content, and reason for the operation in the operation record table.

[0062] Of course, the above are just examples, and they will not be listed one by one here.

[0063] In step 202, a hash calculation is performed on the identifier of the quantum key distribution device, the identifier of the current period, and the log data of the current period to obtain the evidence chain of the current period. Specifically, the identifier of the quantum key distribution device can uniquely identify a single quantum key distribution device among multiple devices; the identifier of the current period can uniquely determine the period in which the log data was generated.

[0064] It should be noted that this application does not limit the identification of quantum key distribution devices. In some examples, the identifier of a quantum key distribution device can be a device ID number. This not only uniquely identifies a quantum key distribution device among multiple devices, but also uniquely identifies the quantum key distribution device among multiple devices (including other devices involved in the quantum key distribution network). In other words, it can support the unique identification of a quantum key distribution device within the quantum key distribution network. In some examples, the identifier of a quantum key distribution device can also be identification information configured by the administrator of the quantum key distribution device. This can distinguish quantum key distribution devices in different quantum key distribution networks, making it easier for the administrator to manage the quantum key distribution device. Of course, the above are just examples, and will not be listed in detail here.

[0065] It should also be noted that the embodiments of this application do not limit the identifier of the current period. In some examples, the identifier of the current period can be the timestamp of the current period, which can be generated by directly reading and writing data. The generation logic is simple, requires no additional configuration, and the time can be directly determined during subsequent tracing without any other conversion. In some examples, the identifier of the current period can also be the identification information or period sequence number configured by the administrator of the quantum key distribution device, which facilitates the management of the quantum key distribution device. Of course, the above are just examples, and will not be listed in detail here.

[0066] It is understandable that hash calculation is irreversible. Therefore, the identifier of the quantum key distribution device, the identifier of the current period, and the log data of the current period can be directly concatenated and calculated to ensure the security of this data, while also being simple and easy to implement. In some embodiments, considering the different security requirements of some data, additional processing can be added, such as encrypting the identifier of the quantum key distribution device separately before hash calculation, etc., which will not be listed here.

[0067] For example, in some embodiments, hashing the identifier of the quantum key distribution device, the identifier of the current period, and the log data of the current period can be achieved by concatenating the quantum key distribution device ID, timestamp t (ISO8601 format), quantum channel fingerprint FF (SHA3-256 hash), environmental data EE (JSON format), and operation record OO (opcode list) and then hashing them. The quantum channel fingerprint FF (SHA3-256 hash), environmental data EE (JSON format), and operation record OO (opcode list) are all obtained by processing relevant data from the log data.

[0068] In step 203, the log data and evidence chain for the current period are published to the blockchain for storage. This embodiment of the application does not limit the method of publishing to the blockchain.

[0069] In some embodiments, to ensure data security and prevent leakage, such as Figure 3 As shown, publishing the log data and evidence chain for the current period to the blockchain for storage can be achieved through the following steps:

[0070] Step 203a: Update the hierarchical Merkle tree based on the hash value of the log data in the current period, and broadcast and store the updated root hash of the hierarchical Merkle tree on the blockchain.

[0071] Step 203b: Broadcast the compressed result of the log data for the current period to the blockchain so that the compressed result of the log data for the current period is stored on at least two nodes of the blockchain.

[0072] Step 203c: Store the evidence chain for the current period on a secure node of the blockchain.

[0073] exist Figure 3 In the illustrated embodiment, the log data of the current period is stored using its own hash value and the hierarchical Merkle tree it participates in constructing. This ensures security and also guarantees its correlation with log data from other periods. The data storage is more comprehensive, enabling subsequent verification and tracing to obtain more comprehensive data, and resulting in better analysis and processing of the problem.

[0074] The following will be about Figure 3 The steps of the illustrated embodiment will be explained.

[0075] In step 203a, the hierarchical Merkle tree is updated based on the hash value of the log data for the current period, and the updated root hash of the hierarchical Merkle tree is broadcast and stored on the blockchain. This embodiment does not limit the method for generating the hash value of the log data for the current period.

[0076] In some embodiments, the hash value of the log data for the current period can be calculated using the following expression:

[0077] H = XMSS(D, SK) OTS MT height ),

[0078] Where H is the hash value of the log data for the current period; XMSS represents the extended Merkle Signature Scheme (XMSS) algorithm function; D represents the log data for the current period; SK OTS The private key, based on WOTS+ (Winternitz one-time signature), is generated by a quantum random number generator; MT height This represents the height of the Merkle tree; a value of 10 indicates support for 2. 10 That is, 1024 data blocks (one period of log data forms one data block) are stored.

[0079] In some embodiments, the output of H can also be set to JSON format, with the length of H ≤ 512 bytes, which facilitates management and saves storage.

[0080] Of course, the above are just examples. In some embodiments, the hash value of the log data for the current period can be obtained in other ways, which will not be listed here.

[0081] It should be noted that this application does not limit the storage method of the root hash. In some embodiments, the root hash can be stored on the blockchain node through the InterPlanetary File System (IPFS) protocol (e.g., version 0.12.3). Of course, the above are just examples, and other file systems or storage methods can also be used, which will not be listed here.

[0082] In step 203b, the compression result of the log data for the current period is broadcast to the blockchain, so that the compression result of the log data for the current period is stored on at least two nodes of the blockchain. This embodiment does not limit the compression method used to obtain the compression result; it can be any compression method. For example, in some embodiments, the compression result can be obtained using the following expression:

[0083] C i =LZ4(B i );

[0084] Among them, C i For the compression result, LZ4 represents the LZ4 compression algorithm function, B i This is the log data for the current period.

[0085] It should be noted that in some cases, the compression ratio can be set to reduce storage usage. Of course, the above are just examples. In some embodiments, the compression ratio may not be set, or other compression ratio thresholds may be set instead of 60%, etc., which will not be listed here.

[0086] It should be noted that the embodiments of this application do not limit the method of broadcasting to the blockchain. For example, it can be broadcast to blockchain nodes through the P2P (Libp2p) protocol, etc., which will not be listed here.

[0087] It should also be noted that, if the blockchain is considered a secure space, it is also possible to publish the log data directly without processing the current period's log data, etc., which will not be elaborated on here.

[0088] Furthermore, regardless of how the log data for the current period is published (or broadcast) to the blockchain, it will undergo a certain consensus verification process. This application does not limit the consensus verification process. In some embodiments, consensus verification of the log data for the current period can be achieved in the following way: consensus verification is performed on the log data for the current period based on a random sequence generated by a quantum entropy source device and a quantum Byzantine consensus protocol. That is, quantum security is used to ensure the security of the random sequence required for consensus verification, while quantum-related protocols are used to reduce the number of blockchain nodes participating in the verification, thereby improving verification efficiency and saving resources. Of course, the above is only an example; other consensus verification methods can be used in some embodiments, which will not be listed here.

[0089] For ease of understanding, the following example will be provided to illustrate the consensus verification method that uses the random sequence generated by the quantum entropy source device and the quantum Byzantine consensus protocol to verify the log data of the current period.

[0090] First, a 1550 nm distributed feedback laser (DFB) (e.g., with a linewidth ≤ 1 MHz) is used as the quantum entropy source. Its output phase noise is sampled by a 14-bit analog-to-digital converter (ADC) (configured with a sampling rate of 1 GS / s). The output of the ADC is the desired random sequence. The expression for the random sequence is:

[0091]

[0092] Among them, R k It is a random sequence; The phase fluctuation at the k-th sampling point of the analog-to-digital converter (which can be measured by an interferometer); k = 1, 2, ..., N; N is the total number of sampling points in one effective sampling process of the analog-to-digital converter; 1 represents the floor operation, and mod represents the modulo operation.

[0093] Then, two-thirds of the nodes on the blockchain are selected as validator nodes (for example, if the blockchain contains 100 nodes, then 67 validator nodes are selected). The probability of a node on the blockchain being selected as a validator node is determined by the following expression:

[0094]

[0095] Among them, P j Let W be the probability that the j-th node in the blockchain is selected as a validator node; jLet be the weight of the j-th node, and let be the success rate of consensus reached by the remaining j-th nodes in the past. The initial value is 1.

[0096] Finally, based on the verification nodes selected above, a Byzantine vote is performed on the data published on the blockchain, and the conditions for reaching consensus are as follows:

[0097]

[0098] Among them, V j agree This indicates whether the j-th verification node has reached a consensus. A value of 1 indicates that a consensus has been reached, and a value of 0 indicates that a consensus has not been reached. M is the total number of verification nodes.

[0099] It should be noted that the block generation time is guaranteed by the PBFT (Practical Byzantine Fault Tolerance) optimization algorithm, ensuring that the average partitioning time does not exceed 2 seconds. Of course, this is just an example, and in some embodiments, optimization may not be performed, etc., which will not be listed here.

[0100] In step 203c, the evidence chain for the current period is stored on a secure node of the blockchain. This application embodiment does not limit the method of broadcasting to the blockchain; for example, it can be stored using the IPFS `ipfs dag put` command, returning a content identifier (CID format: bafyrei...), and recorded in the blockchain event log, etc., which will not be listed here.

[0101] It should also be noted that the embodiments in this application do not... Figure 3 The execution order of the steps shown is specified. Figure 3 The example shown is only one example. In some embodiments, step 203c may be executed simultaneously with step 203a or step 203b, etc., which will not be listed here.

[0102] In step 204, it is detected whether the smart contract on the blockchain has been triggered. In this embodiment, the triggering conditions for the smart contract are not set; however, they can be adaptively set according to abnormal situations. Examples will be provided below.

[0103] In some embodiments, such as Figure 4 As shown, detecting whether a smart contract on the blockchain has been triggered can be achieved through the following steps:

[0104] Step 204a: Obtain a first sequence and a second sequence based on the log data of the quantum key distribution device, wherein the first sequence is a sequence composed of the quantum channel physical parameters of the quantum key distribution device, and the second sequence is a sequence composed of the device operating parameters of the quantum key distribution device.

[0105] Step 204b: Based on the correlation coefficient of the first sequence and the second sequence, detect whether there are any anomalies in the log data of the quantum key distribution device. If there are anomalies in the log data of the quantum key distribution device, trigger the smart contract on the blockchain to alert and freeze the quantum key distribution device.

[0106] exist Figure 4 In the illustrated embodiment, a further method is proposed to correlate and verify the physical state of the quantum channel with the device logs, which supports the triggering of smart contracts when there are anomalies in the quantum physical layer. This allows the anomalies in the quantum physical layer to be monitored and detected, thus better ensuring the security of the quantum key distribution device.

[0107] For ease of understanding Figure 4 The steps of the illustrated embodiment will be explained below.

[0108] In step 204a, a first sequence and a second sequence are obtained based on the log data of the quantum key distribution device. The first sequence is a sequence composed of the quantum channel physical parameters of the quantum key distribution device, and the second sequence is a sequence composed of the device operating parameters of the quantum key distribution device. The quantum channel physical parameters and device operating parameters have been explained previously and will not be listed again here.

[0109] It is important to emphasize that the quantum channel physical parameters included in the first sequence and the device operating parameters included in the second sequence are related, indicating the same characteristics at the quantum physical layer. For example, the polarization angle deviation in the device operating parameters could correspond to the fiber birefringence coefficient, or the fiber polarization mode dispersion coefficient, etc., which will not be listed here.

[0110] In step 204b, based on the correlation coefficients of the first and second sequences, anomalies are detected in the log data of the quantum key distribution device. If anomalies are found in the log data, a smart contract on the blockchain is triggered to alert and freeze the quantum key distribution device. This application does not limit the type of correlation coefficient; it can be the Pearson correlation coefficient, distance correlation coefficient, etc., which will not be listed here. The following example uses the Pearson correlation coefficient for illustration.

[0111] In some embodiments, the correlation coefficient between the first sequence and the second sequence is determined by the following expression:

[0112]

[0113] Where ρ is the correlation coefficient between the first sequence and the second sequence, n is the length of the first sequence and the second sequence, and x i Let y be the i-th data in the first sequence. iThis is the i-th data point in the second sequence. Taking polarization angle deviation and fiber birefringence coefficient as examples, x i Let y be the i-th polarization angle deviation value in the log data of the current period. i This is the i-th fiber birefringence coefficient value in the log data of the current period (the fiber birefringence coefficient can be measured by an optical time-domain reflectometer (OTDR)).

[0114] It should also be noted that the embodiments of this application do not limit the method of anomaly detection. In some embodiments, a threshold can be used for judgment, where the threshold can be set according to the application scenario, user needs, etc. For example, the correlation coefficient threshold can be set to 0.85 (this is just an example, other values ​​can also be used, such as 0.95, 0.92, or 0.81, etc.). Only when the correlation coefficient threshold is exceeded can it be temporarily determined that there is no anomaly. In some embodiments, the existence of anomalies can also be determined based on the fluctuation of the correlation coefficient, etc., which will not be elaborated here.

[0115] In addition, Figure 4 In the illustrated embodiment, the alarm is primarily intended to alert the administrator to any problems, enabling them to resolve them promptly. The freeze is mainly to prevent the quantum key distribution device from continuing to operate under abnormal conditions, thereby affecting network security or device security. In some embodiments, smart contracts on the blockchain can also be triggered to perform other processing, which will not be described or listed here or thereafter.

[0116] In some embodiments, such as Figure 5 As shown, detecting whether a smart contract on the blockchain has been triggered can be achieved through the following steps:

[0117] Step 204c: Obtain noisy data through the blockchain's on-chain oracle.

[0118] Step 204d: Determine the current qubit error rate threshold of the quantum key distribution device based on the noise data.

[0119] Step 204e: Based on the current qubit error rate threshold, detect the qubit error rate in the log data of the quantum key distribution device. If the detection result of the qubit error rate in the log data of the quantum key distribution device meets a first preset condition, trigger the smart contract on the blockchain and issue an alarm to freeze the quantum key distribution device. The first preset condition includes detecting that the qubit error rate in the log data of the quantum key distribution device exceeds the current qubit error rate, or detecting that the qubit error rate in the log data of the quantum key distribution device exceeds the current qubit error rate for a preset number of consecutive times.

[0120] existFigure 5 In the illustrated embodiment, a further method for detecting anomalies using dynamic qubit error rate is proposed, which supports more flexible, accurate, and reliable smart contract triggering and can better ensure the security of quantum key distribution devices.

[0121] For ease of understanding Figure 5 The steps of the illustrated embodiment will be explained below.

[0122] In step 204c, noisy data is obtained through an on-chain oracle of the blockchain. The use of on-chain oracles has been documented in relevant technologies and will not be elaborated upon here.

[0123] In step 204d, the current qubit error rate threshold of the quantum key distribution device is determined based on the noise data. Since noise affects the qubit error rate, noise data is introduced into the current qubit error rate threshold to adapt it to the noise levels in the current environment, reducing misjudgments.

[0124] It should be noted that the embodiments of this application do not limit the way noise data is introduced into the current qubit bit error rate threshold. In some embodiments, the current qubit bit error rate threshold can be achieved by the following expression:

[0125] Threshold QBER =α×σ noise +β;

[0126] Among them, Threshold QBER The current qubit error rate threshold is α, which is a preset ratio, and σ is the qubit error rate threshold. noise β represents the variance of the noise data, and β is a preset parameter whose value can be set according to the application scenario, user needs, etc. For example, it can be set to 8%, 3%, 12%, etc., which will not be listed here.

[0127] In step 204e, the qubit error rate (BER) in the log data of the quantum key distribution device is detected based on the current BER threshold. If the detected BER in the log data meets a first preset condition, a smart contract on the blockchain is triggered, and the quantum key distribution device is frozen. The first preset condition includes detecting that the BER in the log data exceeds the current BER, or detecting that the BER exceeds the current BER for a preset number of consecutive times. The first preset condition can also be any other condition based on the BER to determine if the log data has been attacked or tampered with; these will not be listed here.

[0128] In some embodiments, such as Figure 6 As shown, detecting whether a smart contract on the blockchain has been triggered can be achieved through the following steps:

[0129] Step 204f: Detect whether the polarization angle deviation in the log data of the quantum key distribution device meets the second preset condition, wherein the second preset condition includes: the polarization angle deviation in the log data of the quantum key distribution device exceeds the preset range; if the polarization angle deviation in the log data of the quantum key distribution device meets the second preset condition, trigger the smart contract on the blockchain, and issue an alarm and freeze the quantum key distribution device.

[0130] exist Figure 6 In the illustrated embodiment, anomaly detection using polarization angle deviation is further proposed, supporting smart contract triggering based on polarization angle, which can better ensure the security of quantum key distribution devices.

[0131] For ease of understanding Figure 6 The steps of the illustrated embodiment will be explained below.

[0132] In step 204f, it is detected whether the polarization angle deviation in the log data of the quantum key distribution device meets a second preset condition. The second preset condition includes: the polarization angle deviation in the log data of the quantum key distribution device exceeds a preset range. If the polarization angle deviation in the log data of the quantum key distribution device meets the second preset condition, a smart contract on the blockchain is triggered, and an alarm is issued and the quantum key distribution device is frozen. This application embodiment does not limit the preset range; it can be set according to application scenarios, user needs, device status, etc., and will not be listed here.

[0133] Of course, the above are just examples. In some embodiments, the triggering conditions of smart contracts can be set from other perspectives, which will not be listed here.

[0134] In step 205, when the smart contract on the blockchain is triggered and the content identifier and zero-knowledge proof π are obtained, the log data indicated by the content identifier is verified using a pre-built zero-knowledge proof circuit and zero-knowledge proof π to obtain and output the evidence chain for the period corresponding to the log data that failed verification. In this embodiment, the content identifier and zero-knowledge proof π can be obtained through uploads by log administrators or by third parties (such as auditors), etc., which will not be listed here.

[0135] It should be noted that the embodiments in this application do not limit the verification method. The following examples are mainly provided for ease of understanding.

[0136] In some embodiments, during the verification process, a zero-knowledge proof π' is first generated using the following expression:

[0137] π′=Prove(C,{H i}), D i );

[0138] Where Prove represents the zk-SNARKs (Groth16 scheme) algorithm function; C represents the pre-defined zero-knowledge proof circuit. In some cases, the constraints of the pre-defined zero-knowledge proof circuit can be set as: H i+1 =SHA256(H i ||D i );D i This represents the log data for the i-th period.

[0139] It should be noted that the above proof generation process can be accelerated using GPUs, reducing the generation time to less than 5 seconds.

[0140] Then, compare the currently generated zero-knowledge proof π' with the obtained zero-knowledge proof π to see if they are consistent. If they are, the verification passes; otherwise, it fails.

[0141] It should be noted that the embodiments of this application do not limit the triggering conditions of smart contracts, which can be configured according to needs. The following will provide examples of triggering smart contracts in conjunction with different embodiments.

[0142] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.

[0143] Another aspect of this application embodiment also provides a log auditing system for a quantum key distribution device, such as... Figure 7 As shown, it includes: a data acquisition module, a security module, and a traceability module.

[0144] In some implementations, the acquisition module is used to acquire the log data of the quantum key distribution device in the current period; the security module is used to perform hash calculations on the identifier of the quantum key distribution device, the identifier of the current period, and the log data of the current period to obtain the evidence chain of the current period; and publish the log data and the evidence chain of the current period to the blockchain for storage; and detect whether the smart contract on the blockchain has been triggered; the tracing module is used to verify the log data indicated by the content identifier using a pre-built zero-knowledge proof circuit and zero-knowledge proof π when the smart contract on the blockchain is triggered and the content identifier and zero-knowledge proof π are obtained, so as to obtain and output the evidence chain of the period corresponding to the log data that failed verification.

[0145] In some embodiments, based on the above embodiments, the log data for the current period also includes the temperature data for the current period; the security module is further configured to determine temperature control parameters based on the temperature data for the current period, and control the quantum key distribution device and / or the environment in which the quantum key distribution device is located based on the temperature control parameters, so as to control the temperature of the quantum key distribution device within a specified range.

[0146] It should be noted that the embodiments of this application do not limit the method of temperature control. In some embodiments, the temperature control of the environment or the interior of the quantum key distribution device is achieved by outputting a compensation voltage based on a digital PID controller (proportional coefficient, integral time, derivative time). That is to say, the temperature control parameter in this case is actually a voltage control parameter. The following will provide a principle explanation using this as an example.

[0147] The driving voltage of the TEC cooling chip is determined by the following expression:

[0148]

[0149] Among them, V comp (t) represents the driving voltage, K p K i K d As preset parameters, e(t) = T target -T(t), T target The desired temperature is configurable.

[0150] In some embodiments, such as Figure 8 As shown, the system includes: a data acquisition module, a security module, a consensus verification module, and a source tracing module. The data acquisition module, security module, and source tracing module have already been described and will not be repeated here.

[0151] In some embodiments, the consensus verification module is used to perform consensus verification on the hash value and root hash broadcast to the blockchain based on the random sequence generated by the quantum entropy source device and the quantum Byzantine consensus protocol.

[0152] It is not difficult to see that this embodiment is a system embodiment corresponding to the method embodiment, and this embodiment can be implemented in conjunction with the method embodiment. The relevant technical details mentioned in the method embodiment are still valid in this embodiment, and will not be repeated here to reduce repetition. Correspondingly, the relevant technical details mentioned in this embodiment can also be applied to the method embodiment.

[0153] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.

[0154] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A log auditing method for a quantum key distribution device, characterized in that, include: Obtain the log data of the quantum key distribution device in the current period; The identifier of the quantum key distribution device, the identifier of the current period, and the log data of the current period are hashed to obtain the evidence chain of the current period; The log data for the current period and the evidence chain for the current period are published to the blockchain for storage; Detect whether the smart contract on the blockchain has been triggered; When a smart contract on the blockchain is triggered and a content identifier and a zero-knowledge proof π are obtained, the log data indicated by the content identifier is verified using a pre-built zero-knowledge proof circuit and the zero-knowledge proof π, so as to obtain and output the evidence chain corresponding to the period of the log data that failed verification.

2. The log auditing method for a quantum key distribution device according to claim 1, characterized in that, The detection of whether a smart contract on the blockchain has been triggered includes: Based on the log data of the quantum key distribution device, a first sequence and a second sequence are obtained, wherein the first sequence is a sequence composed of the quantum channel physical parameters of the quantum key distribution device, and the second sequence is a sequence composed of the device operating parameters of the quantum key distribution device. Based on the correlation coefficient between the first sequence and the second sequence, anomalies are detected in the log data of the quantum key distribution device. If anomalies are detected in the log data of the quantum key distribution device, the smart contract on the blockchain is triggered, and an alarm is issued and the quantum key distribution device is frozen.

3. The log auditing method for a quantum key distribution device according to claim 1, characterized in that, The detection of whether a smart contract on the blockchain has been triggered includes: Noise data is obtained through the on-chain oracle of the blockchain; Based on the noise data, determine the current qubit error rate threshold of the quantum key distribution device; Based on the current qubit error rate threshold, the qubit error rate in the log data of the quantum key distribution device is detected. If the detection result of the qubit error rate in the log data of the quantum key distribution device meets a first preset condition, a smart contract on the blockchain is triggered, and an alarm is issued to freeze the quantum key distribution device. The first preset condition includes detecting that the qubit error rate in the log data of the quantum key distribution device exceeds the current qubit error rate, or detecting that the qubit error rate in the log data of the quantum key distribution device exceeds the current qubit error rate for a preset number of consecutive times.

4. The log auditing method for a quantum key distribution device according to claim 1, characterized in that, The detection of whether a smart contract on the blockchain has been triggered includes: The polarization angle deviation in the log data of the quantum key distribution device is detected to meet a second preset condition, wherein the second preset condition includes: the polarization angle deviation in the log data of the quantum key distribution device exceeds a preset range; If the polarization angle deviation in the log data of the quantum key distribution device meets the second preset condition, the smart contract on the blockchain is triggered, and the quantum key distribution device is alerted and frozen.

5. The log auditing method for a quantum key distribution device according to any one of claims 1 to 4, characterized in that, The step of publishing the log data of the current period and the evidence chain of the current period to the blockchain for storage includes: Based on the hash value of the log data in the current period, update the hierarchical Merkle tree, and broadcast and store the updated root hash of the hierarchical Merkle tree on the blockchain; The compression result of the log data for the current period is broadcast to the blockchain so that the compression result of the log data for the current period is stored on at least two nodes of the blockchain. Store the evidence chain for the current period on a secure node of the blockchain.

6. The log auditing method for a quantum key distribution device according to any one of claims 1 to 4, characterized in that, Consensus verification is achieved on the log data of the current period in the following manner: Consensus verification is performed on the log data of the current period based on the random sequence generated by the quantum entropy source device and the quantum Byzantine consensus protocol.

7. The log auditing method for a quantum key distribution device according to any one of claims 1 to 4, characterized in that, The acquisition of log data from the quantum key distribution device in the current period includes: A preset ratio of the transmission signal of the quantum key distribution device is obtained using a split-beam bypass, and the quantum key distribution device is detected based on the preset ratio of the transmission signal. The detection result is then output as the log data for the current period.

8. A log auditing system for a quantum key distribution device, characterized in that, include: The acquisition module is used to acquire log data from the quantum key distribution device in the current period; The security module is used to perform hash calculations on the identifier of the quantum key distribution device, the identifier of the current period, and the log data of the current period to obtain the evidence chain of the current period; and publish the log data of the current period and the evidence chain of the current period to the blockchain for storage. Detect whether the smart contract on the blockchain has been triggered; The traceability module is used to verify the log data indicated by the content identifier when the smart contract on the blockchain is triggered and the content identifier and zero-knowledge proof π are obtained, using a pre-set zero-knowledge proof circuit and the zero-knowledge proof π, so as to obtain and output the evidence chain of the period corresponding to the log data that failed verification.

9. The log auditing system for the quantum key distribution device according to claim 8, characterized in that, The system also includes: The consensus verification module is used to perform consensus verification on the hash value and the root hash broadcast to the blockchain based on the random sequence generated by the quantum entropy source device and the quantum Byzantine consensus protocol.

10. The log auditing system for the quantum key distribution device according to claim 8, characterized in that, The log data for the current period also includes the temperature data for the current period; The security module is also used to determine temperature control parameters based on the temperature data of the current period, and control the quantum key distribution device and / or the environment in which the quantum key distribution device is located based on the temperature control parameters, so as to control the temperature of the quantum key distribution device within a specified range.

Images