A Quantum Key Distribution and Verification System Combined with Blockchain and Its Working Method

Abstract

A quantum key distribution and verification system combined with blockchain and its working method belong to the technical field of key distribution. The present invention draws on the idea of edge nodes, adopts a user group mode, and after the user group representative performs BLS signature aggregation, the BLS aggregated signature is handed over to the background processing server for digital signature verification, so as to verify the authenticity of the user identities in the user group and the common quantum key requirements obtained by the users in the user group. It reduces the communication load of multiple users sending BLS digital signatures to the system individually, improves the operation speed of the system and reduces the occupancy of storage space. The present invention uses blockchain technology to place the hash value of the quantum key in the blockchain system. The blockchain sets multiple nodes, and each node will periodically compare the data with that of multiple other randomly selected nodes in the background to keep the block data status synchronized. The present invention uses a reverse proxy and a firewall to improve the security of the background processing server.

Description

Technical Field

[0001] The present invention belongs to the technical field of key distribution, and particularly relates to a quantum key distribution and verification system combined with a blockchain and a working method thereof. Background Art

[0002] Blockchain technology originated from the earliest distributed ledger technology. However, through development, it is no longer simply a distributed ledger technology. The main body of the blockchain is a distributed ledger implemented by a block-based chain structure, which integrates various technologies and knowledge such as distributed consensus, privacy and security protection, peer-to-peer communication technology, network protocol, digital signature, and smart contract. Blockchains are mainly divided into three categories according to their scope of use: public blockchains, consortium blockchains, and private blockchains. Among them, the consortium blockchain has an identity admission review mechanism and is not completely decentralized. However, it also has the functions of data immutability and traceability, and is suitable for communication and transactions between multiple organizations that do not fully trust each other.

[0003] The BLS aggregate signature technology is a technology that can fuse multiple digital signatures of different messages into a short signature and then verify this signature. The main advantage of the BLS aggregate signature is that it can compress multiple signatures, reduce the occupied space, and at the same time enhance security and privacy. Among them, the BLS aggregate signature algorithm depends on the bilinear mapping function and has special properties that can be used to verify signatures. In the traditional method, multiple users need to directly send BLS signatures to the background processing server for BLS digital signature aggregation and BLS BLS aggregate signature verification. However, this method will have a large communication overhead. When multiple users send BLS signatures to the background processing server at the same time, it will cause excessive pressure on the background processing server.

[0004] Generally speaking, quantum key distribution is based on the BB84 protocol. By using a quantum channel and a classical channel, the sending end and the receiving end can obtain the same quantum key. Theoretically, each generated quantum key is absolutely secure and cannot be eavesdropped. The generation of quantum keys has no fixed pattern and has complete randomness, which can be used for data encryption and decryption. At present, although traditional quantum key distribution has high security, the obtained quantum key is only limited to use by two parties. How to expand the scope of use and the usage efficiency of quantum keys; how to provide quantum keys to multiple users for use and how to verify that multiple users obtain the same quantum key are currently problems that need to be solved. Summary of the Invention

[0005] The technical problems to be solved by the present invention are as follows: to provide a quantum key distribution and verification system combined with blockchain and its working method to solve the technical problems in the prior art that multiple users need to directly send BLS signatures to the background processing server for BLS digital signature aggregation and BLS BLS aggregated signature verification, resulting in large communication overhead and excessive pressure on the background processing server; the use range of quantum keys is only limited to two parties and cannot be provided to multiple users, with a small use range and low use efficiency, etc.

[0006] A quantum key distribution and verification system combined with blockchain includes user clients, an Nginx reverse proxy server, a background processing server, a Redis database, a quantum key cloud platform, and a blockchain network.

[0007] The user client is used to register and log in to a quantum key distribution and verification system combined with blockchain, establish a group encrypted chat interface, obtain their respective BLS digital signatures, use the provided BLS digital signature generation program to generate BLS public and private key pairs of the BLS digital signature, and save the BLS private key locally on the user client, and upload the BLS public key to the background processing server for storage; the BLS private key encrypts the message data of the user's request to obtain the quantum key of the user group where the user is located to form a BLS digital signature; the BLS public key is used to verify the correctness of the BLS digital signature and the BLS public key is also used to encrypt the quantum key obtained after decryption by the background processing server again to form a quantum key ciphertext II.

[0008] One end of the Nginx reverse proxy server is connected to multiple user clients, and the other end of the Nginx reverse proxy server is connected to multiple background processing servers. The Nginx reverse proxy server is used for data forwarding between the user client and the background processing server, and the Nginx reverse proxy server can balance the data load and thus improve the efficiency of quantum key distribution, verification, or query of multiple user clients.

[0009] The background processing server is also connected to a firewall. The background processing server verifies the BLS aggregated signature, receives the BLS public key sent by the user client, generates an RSA public and private key pair using the RSA key generation program, saves the RSA private key locally on the background processing server, sends the RSA public key to the quantum key cloud platform to request and obtain the quantum key, encrypts the quantum key to obtain the quantum key ciphertext II, the quantum key ciphertext II corresponds to each user and is different from each other, the background processing server records the quantum key ciphertext II corresponding to each user one by one, and stores the key-value pair data in the form of {key = username, value = quantum key ciphertext II} in the Redis database and stores it in the Redis database.

[0010] The Redis database is connected to multiple background processing servers, and the Redis database is used to store key-value pair data in the form of {key = username, value = quantum key ciphertext II};

[0011] A QKD quantum key distribution device is set on the quantum key cloud platform, and a firewall is also set on the quantum key cloud platform. The QKD quantum key distribution device generates random quantum keys on the quantum channel and stores them in the key table. The quantum key cloud platform receives the RSA public key sent by the background processing server, randomly extracts unused quantum keys from the key table, encrypts the quantum keys with the RSA public key sent by the background processing server to obtain quantum key ciphertext I, and sends the quantum key ciphertext I to the background processing server;

[0012] The blockchain network is connected to multiple background processing servers. The blockchain network stores key-value pair data composed of the hash value string of the quantum key decrypted by the background processing server and all usernames in the corresponding user group. The blockchain network is provided with multiple nodes, and the data in each block of each node is synchronized and updated.

[0013] The blockchain network is a Hyperledger Fbric consortium blockchain network.

[0014] A working method of a quantum key distribution and verification system combined with blockchain uses the described quantum key distribution and verification system combined with blockchain, including the following steps, and the following steps are carried out sequentially:

[0015] Step 1: The user uses BLS aggregate signature to request the system to allocate quantum keys

[0016] (1). The user registers and logs in to a quantum key distribution and verification system combined with blockchain on the user client;

[0017] (2). The user uses the BLS digital signature generation program installed on the user client to generate a BLS public-private key pair for BLS digital signature. The BLS private key is saved locally on the user client, and the BLS public key is uploaded to the background processing server for storage through the Nginx reverse proxy server; Use the BLS private key to encrypt the message data of the user's request to obtain the quantum key of the user group, form a BLS digital signature. The user and other users form a user group, establish a group encrypted chat interface to elect a representative of the user group and send their respective BLS digital signatures to the representative;

[0018] (3). The representative of the user group synthesizes the BLS digital signatures of all users into a BLS aggregate signature and forwards it to the background processing server through the Nginx reverse proxy server and simultaneously sends a verification request;

[0019] (4) The back-end processing server verifies the BLS aggregate signature to determine the legal identities of the users within the group. For those with qualified verification, proceed to step (5). For those with failed verification, repeat steps (2) to (3) to conduct a re-verification of the BLS aggregate signature by the back-end processing server until the verification is qualified and then proceed to step (5).

[0020] (5) The back-end processing server uses the RSA key generation program to generate an RSA public-private key pair. The RSA private key is stored locally on the back-end processing server, and the RSA public key is sent to the quantum key cloud platform to request the allocation of quantum keys.

[0021] Step 2: The QKD quantum key distribution device connected to the quantum key cloud platform generates random quantum keys on the quantum channel and stores them in the key table. After receiving the request for allocating quantum keys, the quantum key cloud platform randomly extracts unused quantum keys from the key table, encrypts the quantum keys with the RSA public key sent by the back-end processing server to obtain the quantum key ciphertext Ⅰ, and sends the quantum key ciphertext Ⅰ to the back-end processing server.

[0022] Step 3: The back-end processing server obtains the quantum key ciphertext Ⅰ and caches it, then decrypts the quantum key ciphertext Ⅰ with the RSA private key local to the back-end processing server to obtain the quantum key. The back-end processing server uses the BLS public key of each user to encrypt the quantum key in sequence to obtain multiple quantum key ciphertexts Ⅱ corresponding to each user. The back-end processing server forms key-value pair data in the form of {key = username, value = quantum key ciphertext Ⅱ} for the multiple quantum key ciphertexts Ⅱ and stores them in the Redis database, and sets the survival time of each data in the Redis database to 24 hours.

[0023] Step 4: The back-end processing server performs a hash operation on the decrypted quantum key to obtain a hash value string. The back-end processing server uploads the key-value pair data composed of this hash value string and all the usernames in the corresponding user group to the blockchain network. The blockchain network sets multiple nodes, and the data of each node is randomly compared with the data of other multiple nodes periodically to keep the data of each block in the blockchain network synchronized and updated.

[0024] Step 5: Each user respectively obtains the quantum key ciphertext Ⅱ allocated to them from the blockchain network through the Nginx reverse proxy server and the back-end processing server; decrypts the quantum key ciphertext Ⅱ with the BLS private key saved locally on the user client to obtain the allocated quantum key.

[0025] Step 6: Each user separately sends a quantum key verification request, obtains the data returned by the blockchain network through the data transmission of the Nginx reverse proxy server and the background processing server, and verifies the consistency between the quantum key obtained by the user and the quantum keys of other users in the user group through the data returned by the blockchain network;

[0026] If the verification result shows consistency, the operation ends.

[0027] If the verification result shows inconsistency, start the request and verification of the quantum key again from Step 1 until the verification result shows consistency.

[0028] In Step 1, a user can enter multiple different user groups simultaneously and obtain different quantum keys accordingly. The different quantum keys obtained by the same user simultaneously are stored synchronously in the Redis database.

[0029] In Step (3) of Step 1, the specific steps for the user group representative to synthesize the BLS digital signatures of all users into a BLS aggregated signature are as follows:

[0030] (1) The user group representative sends the time of the BLS aggregated signature to the users within the group to remind all users within the group to promptly enter a quantum key distribution and verification system combined with blockchain to query the assigned quantum keys;

[0031] ](2) The users within the group generate their respective BLS signatures: [[ID=!9]]<\

[0032] When the BLS digital signature generation program generates the BLS public and private key pair, it can also obtain the common base point G of the mapping curve adopted by the BLS public and private key pair. The private key is denoted as sk, the public key is denoted as pk, and pk = sk * G;

[0033] The BLS signature generation program first obtains the message msg of the BLS digital signature, then maps the hash value of the message msg to a certain point on the mapping curve adopted by the BLS public and private key pair, denoted as q, and then multiplies it by the BLS private key sk to obtain the BLS digital signature Sig = sk * q;

[0034] (3) After each user in the user group obtains their respective BLS digital signatures, the BLS digital signatures are Base64 encoded, converted into a data format of String type, and then the String type data is serialized into a JSON format data. Multiple users send the JSON format data to the user group representative using the Https transmission protocol;

[0035] (4) After the user group representative receives the JSON data sent by all users, convert the JSON data into a String type string, respectively obtain the String type string of the BLS digital signature of each user and the message msg of the BLS digital signature. Decode the String type string of the BLS digital signature of each user by Base64 to obtain the BLS digital signature of each user. Add up the BLS digital signatures of all users to get the BLS aggregated signature. The user group representative encodes the BLS aggregated signature by Base64, converts it into a data format of String type, and then serializes the String type data into JSON format data. The user group representative sends the JSON format data to the background processing server through the Nginx reverse proxy server using the Https transmission protocol to request the quantum key.

[0036] The specific steps for the background processing server to verify the BLS aggregated signature in step (4) of step one are as follows: The background processing server stores the BLS public key pk corresponding to each user and the common base point G of the mapping curve used by the BLS public and private key pairs. After receiving the BLS aggregated signature and the verification request sent by the user group representative, the background processing server calculates the different points q on the curve where the hash values of the BLS digital signatures of each user are mapped. According to the verification formula of the BLS aggregated signature, the BLS aggregated digital signature is verified.

[0037] The specific steps for verifying the consistency of the quantum key obtained by the user with the quantum keys of other users in the user group in step six are as follows:

[0038] (1) The user uses the SHA256 algorithm to hash the obtained quantum key to get a 64-bit string H of a fixed length. Enter the string H in the user client and click the "Verify" button to send a query request to the Nginx reverse proxy server;

[0039] (2) The Nginx reverse proxy server forwards the request to the background processing server;

[0040] (3) After the background processing server obtains the request, the background processing server queries the data historical record on the blockchain through a peer node on the blockchain network. The blockchain network calls the getHistoryForKey function in the blockchain smart contract for data query and returns the queried data to the background processing server;

[0041] (4) The background processing server returns the queried data to the Nginx reverse proxy server, and the Nginx reverse proxy server returns the queried data to the client user;

[0042] (5) The user views the returned data and verifies whether the user names contained in the queried data are consistent with the user names in the user group where the user belongs. If they are consistent, the verification is completed, and the quantum keys of the user are consistent with those of other users in the same user group.

[0043] The blockchain network is a Hyperledger Fabric consortium blockchain network.

[0044] Through the above design, the present invention can bring the following beneficial effects:

[0045] 1. After the present invention generates a theoretically truly random quantum key on the quantum channel through the QKD device, it is stored in the quantum cryptography cloud platform for the background processing server to obtain.

[0046] 2. The present invention is used in the scenario where multiple users obtain the same quantum key, and the consistency of the results of obtaining the quantum key is verified securely. Although the security of quantum key distribution is reduced to a certain extent, and the quantum keys are not obtained between two users through the quantum channel strictly, the true randomness of the quantum key is still retained, the transmission distance limitation of traditional quantum key distribution is removed, and the efficiency of multiple users obtaining the quantum key is improved.

[0047] 3. The present invention draws on the idea of edge nodes and adopts a user group mode, enabling multiple users to form a user group. After the group representative performs BLS signature aggregation, the BLS aggregated signature is handed over to the background processing server for digital signature verification. The BLS aggregated digital signature of the user group is used to verify the authenticity of the user identities in the user group and the need for the users in the user group to obtain a common quantum key. The communication load of multiple users sending BLS digital signatures to the system individually is reduced, and the operation speed of the system is improved. At the same time, the shorter BLS aggregated signature also reduces the storage space occupied on the background processing server.

[0048] 4. The present invention uses the asymmetric encryption RSA algorithm to obtain an RSA public-private key pair, and at the same time uses the Https transmission protocol to ensure the security of the quantum key during distribution in the traditional network channel after encryption.

[0049] 5. The present invention uses blockchain technology to place the hash value of the quantum key in the blockchain system. The blockchain has multiple nodes, and each node will periodically compare the data with that of multiple other randomly selected nodes in the background to keep the block data status synchronized. Users who have registered for this system can enter the blockchain system to query to ensure that the final key they obtain is consistent with the key distributed by the background processing server to other users in the group, ensuring that the key has not been tampered with during the transmission process.

[0050] 6. The present invention uses reverse proxy and firewall to enhance the security of the background processing server. At the same time, each background processing server is connected to each node of the Hyperledger Fabric consortium blockchain to achieve information sharing. When multiple users query the authenticity of the same group of quantum keys they obtained, the Nginx reverse proxy server uses the load balancing principle to improve the query efficiency of multiple users.

[0051] 7. The present invention uses the Redis database to store the encrypted quantum key ciphertext, and users need to query and download the quantum keys they need in a timely manner. A user can be in different groups, that is, a user can have keys of multiple different groups at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The present invention will be further described below in conjunction with the drawings and specific embodiments:

[0053] Figure 1 It is a schematic structural diagram of the system in a quantum key distribution and verification system combined with blockchain and its working method of the present invention;

[0054] Figure 2 It is a method flow chart in a quantum key distribution and verification system combined with blockchain and its working method of the present invention;

[0055] Figure 3 It is a flow chart of a user requesting to allocate quantum keys in a quantum key distribution and verification system combined with blockchain and its working method of the present invention;

[0056] Figure 4 It is a flow chart of uploading data to the blockchain in a quantum key distribution and verification system combined with blockchain and its working method of the present invention;

[0057] Figure 5 It is a ledger structure diagram of the Hyperledger Fabric consortium blockchain in a quantum key distribution and verification system combined with blockchain and its working method of the present invention;

[0058] Figure 6 It is a flow chart of a user obtaining quantum keys in a quantum key distribution and verification system combined with blockchain and its working method of the present invention;

[0059] Figure 7 It is a flow chart of a user verifying quantum keys in a quantum key distribution and verification system combined with blockchain and its working method of the present invention;

[0060] Figure 8 It is a topological structure diagram of the blockchain network in a quantum key distribution and verification system combined with blockchain and its working method of the present invention;

[0061] Figure 9 This is the network topology diagram of the Nginx reverse proxy server in a quantum key distribution and verification system combined with blockchain and its working method according to the present invention;

[0062] Figure 10 This is the transaction flow diagram of the Hyperledger Fbric consortium blockchain in a quantum key distribution and verification system combined with blockchain and its working method according to the present invention. Specific embodiments

[0063] To make the objectives, technical solutions and advantages of the present invention clearer and more understandable, the present invention will be further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

[0064] The overall architecture diagram of the quantum key distribution and verification system combined with blockchain is as Figure 1 shown, including user clients, Nginx reverse proxy servers, background processing servers, Redis databases, quantum key cloud platforms and blockchain networks.

[0065] The user client is used to register and log in to a quantum key distribution and verification system combined with blockchain, establish a group encrypted chat interface, obtain their respective BLS digital signatures, use the provided BLS digital signature generation program to generate the BLS public and private key pairs of the BLS digital signature, and save the BLS private key locally on the user client, and upload the BLS public key to the background processing server for storage; the BLS private key encrypts the message data of the user's request to obtain the quantum key of the user group where the user is located to form a BLS digital signature; the BLS public key is used to verify the correctness of the BLS digital signature and the BLS public key is also used to encrypt the quantum key obtained after decryption by the background processing server again to form a quantum key ciphertext II;

[0066] One end of the Nginx reverse proxy server is connected to multiple user clients, and the other end of the Nginx reverse proxy server is connected to multiple background processing servers. The Nginx reverse proxy server is used for data forwarding between the user client and the background processing server. The Nginx reverse proxy server can balance the data load and thus improve the efficiency of quantum key distribution, verification or query of multiple user clients;

[0067] The background processing server is also connected to a firewall. The background processing server verifies the BLS aggregate signature, receives the BLS public key sent by the user client, generates an RSA public-private key pair using the RSA key generation program, stores the RSA private key locally on the background processing server, sends the RSA public key to the quantum key cloud platform to request and obtain the quantum key, encrypts the quantum key to obtain the quantum key ciphertext II. The quantum key ciphertext II corresponds to each user and is different from each other. The background processing server records the quantum key ciphertext II in a one-to-one correspondence with the user, and stores the key-value pair data in the form of {key = username, value = quantum key ciphertext II} in the Redis database; the Redis database is connected to multiple background processing servers;

[0068] The quantum key cloud platform is provided with a QKD quantum key distribution device, and the quantum key cloud platform is also provided with a firewall. The QKD quantum key distribution device generates a random quantum key on the quantum channel and stores it in the key table. The quantum key cloud platform receives the RSA public key sent by the background processing server, randomly extracts an unused quantum key from the key table, encrypts the quantum key with the RSA public key sent by the background processing server to obtain the quantum key ciphertext I, and sends the quantum key ciphertext I to the background processing server;

[0069] The blockchain network is connected to multiple background processing servers. The blockchain network stores the hash value string of the quantum key decrypted by the background processing server and all the usernames in the corresponding user group to form key-value pair data. The blockchain network is provided with multiple nodes, and the data in each block of each node is synchronously updated.

[0070] The blockchain network is a Hyperledger Fbric consortium blockchain network. The data storage of the Hyperledger Fbric consortium blockchain network is divided into two parts. One part is the chain composed of blocks, and the other part is similar to a traditional key-value database. The addition and change of all data are regarded as transactions, which are saved in the blocks after being processed. However, for the convenience of querying, a database is used to store the transaction data saved in the blocks. If the data in the blocks is directly searched, the time cost may be very large.

[0071] The state database saves the key-value values of the current data. For example, when querying the data with the key "dangren", the query result is {"dangren”:”3”}.

[0072] The historical database stores the respective historical change values of the data. For example, query the data with the key "dangren": [{"dangren": "1", "dangren": "2", "dangren": "3"}].

[0073] The ledger structure of the Hyperledger Fbric consortium blockchain is as Figure 5 shown.

[0074] A working method of a quantum key distribution and verification system combined with a blockchain. Using the described quantum key distribution and verification system combined with a blockchain, as Figure 2 shown, includes the following steps, and the following steps are carried out sequentially:

[0075] Step 1: A user forms a user group with other users and requests the system to allocate quantum keys using BLS aggregated signatures;

[0076] Step 2: The QKD quantum key distribution device connected to the quantum key cloud platform generates random quantum keys on the quantum channel and stores them in the key table. After the quantum key cloud platform receives the request to allocate quantum keys, it randomly extracts unused quantum keys from the key table, encrypts the quantum keys with the RSA public key sent by the background processing server to obtain the quantum key ciphertext Ⅰ, and sends the quantum key ciphertext Ⅰ to the background processing server;

[0077] The background processing server obtains the quantum key ciphertext Ⅰ and caches it, then decrypts the quantum key ciphertext Ⅰ with the local RSA private key of the background processing server to obtain the quantum key. The background processing server sequentially performs BLS encryption on the quantum key using the BLS public key of each user to obtain multiple quantum key ciphertexts Ⅱ corresponding to each user. The background processing server forms key-value pair data in the form of {key = username, value = quantum key ciphertext Ⅱ} for the multiple quantum key ciphertexts Ⅱ and stores them in the Redis database, and sets the survival time of each data in the Redis database to 24 hours;

[0078] Step 4: During the operation of the background processing server program, the quantum key is decrypted. It performs a hash operation on the quantum key to obtain a hash value string, assumed to be H. The background processing server uploads the key-value pair data composed of this hash value string and all the usernames in the corresponding user group to the blockchain network. For example, if all the usernames in the user group are A, B, C, D, the key-value pair data in the form of {"H": "[A,B,C,D]"} is uploaded to the blockchain network.

[0079] The blockchain network sets up multiple nodes, and the data of each node is randomly compared with the data of other multiple nodes periodically, so as to keep the data of each block in the blockchain network updated synchronously;

[0080] The structure of a block includes a block header, block data, and block metadata.

[0081] 1. The block header includes the block number, the current block hash, and the previous block hash.

[0082] Among them, the block number is an integer starting from 0 (genesis block), and increases by 1 for each new block appended to the blockchain.

[0083] The current block hash represents the hash of all transactions included in the current block.

[0084] The previous block hash represents the hash of the previous block.

[0085] 2. Block Data

[0086] The block data contains a set of transactions, which are written when the block is created.

[0087] 3. Block Metadata

[0088] The metadata contains the block creation time, the certificate of the writing program, the public key, and the signature.

[0089] In addition to the consistent block data in each node, the state database and the historical database in the node will also be consistent.

[0090] Step Five: Each user respectively obtains the allocated quantum key ciphertext II from the blockchain network through the Nginx reverse proxy server and the background processing server; decrypts the quantum key ciphertext II using the BLS private key saved locally by the user client to obtain the allocated quantum key;

[0091] Step Six: Each user respectively sends a quantum key verification request, obtains the data returned by the blockchain network through the data transmission of the Nginx reverse proxy server and the background processing server, and verifies the consistency of the quantum key obtained by the user with the quantum keys of other users in the user group through the data returned by the blockchain network;

[0092] The verification result shows consistency. The operation is ended.

[0093] The verification result shows inconsistency. Request and verify the quantum key again from the beginning of the steps until the verification result shows consistency.

[0094] I. The specific implementation of the Hyperledger Fbric consortium blockchain network construction plan is as follows:

[0095] (1) Plan the blockchain network topology as Figure 8 shown. According to the Fabric executable file and docker images, the blockchain network can be built according to the plan.

[0096] (2) Hyperledger Fbric consortium blockchain supports using the built-in certificate management tool fabric-CA or the built-in cryptogen program to generate identity certificate files. Select to use the cryptogen program to generate organization file identity certificates. According to the planned network topology as Figure 8 shown, write the configuration file crypto.yaml in yaml format. Each node of the Hyperledger Fabric blockchain needs an identity certificate file to start. Execute the cryptogen generate command to generate the identity certificate files of each organization in the blockchain.

[0097] (3) Write the configtxgen.yaml file according to the network topology and configuration requirements, and use the configtxgen program in fabric to execute this file to generate the genesis block and channel transaction files of the blockchain system channel.

[0098] (4) Write the orderer.yaml configuration file, configure 3 order nodes, namely order0, order1, and order2, and initially default order0 as the primary node. Execute the orderer start command to start all sorting nodes. The sorting nodes will create the system channel according to the specified genesis block file, and the sorting nodes are used to sort the transactions in the blockchain network.

[0099] (5) Write the core.yaml configuration file, configure 3 Org organizations, and there are 3 organization administrator nodes under each of the 3 organizations, namely peer0.org1, peer0.org2, and peer0.org3. Execute the peer node start command to start all peer nodes. Peer nodes mainly have two functions in the blockchain network, namely the endorsement function and the accounting function.

[0100] (6) Execute the peer channel create command on a certain peer node to create an application channel.

[0101] (7) Execute the peer join command to successively add other nodes to the application channel we just created.

[0102] (8) Write an intelligent contract for writing and reading quantum key-related data, and use the peer cli to execute the package command to generate a compressed package.

[0103] (9) Set the environment variable, set the current peer cli identity to the administrator identity of a certain node, and use the peer cli to execute the install command to download the intelligent contract in the form of a compressed package to the peer node. Similarly, download the intelligent contract to other peer nodes on the channel in turn.

[0104] (10) All peer nodes on the channel execute the approve command to agree to deploy the intelligent contract on the channel.

[0105] (11) Arbitrarily select a peer node and use the commit command to submit the intelligent contract to the channel.

[0106] (12) After the successful deployment of the intelligent contract, use the Hyperledger Fabric SDK to enable the application to interact with the blockchain network through the gPRC communication method, so that the background processing server can operate the Hyperledger Fabric blockchain.

[0107] II. The specific implementation of the BLS aggregate signature generation and verification scheme is as follows:

[0108] (1) Multiple users privately reach an agreement, agree to request the same quantum key, form a user group and elect a user group representative. The user group representative needs to send the time of the BLS aggregate signature to the users in the group to remind other users to enter the system in time to query the allocated quantum key.

[0109] (2) The core of the BLS aggregate signature method is to use the characteristics of the bilinear mapping function to verify the signature. In this embodiment, a symmetric bilinear mapping group is used. The process for a single user to generate a BLS digital signature is as follows: Randomly select a large integer as the BLS private key sk, select the generator G of the elliptic curve based on bilinear mapping, and obtain the BLS public key pk = sk * G. The BLS digital signature generation program first obtains the message msg of the digital signature, calculates the hash value of the message msg, maps it to a point on the curve, denoted as q, and then multiplies it by the BLS private key sk to obtain the digital signature sig = sk * q. Taking the user group consisting of 4 users {A, B, C, D} as an example, using the BLS digital signature generation program, generate the BLS public and private key pairs for BLS digital signatures, which are {(pkA, skA), (pkB, skB), (pkC, skC), (pkD, skD)}, where {pkA, pkB, pkC, pkD} are the BLS public keys and {skA, skB, skC, skD} are the BLS private keys. After the BLS public and private key pairs are generated, the BLS public keys of all users are uploaded to the database of the background processing server, and the BLS private keys of all users are stored locally on the users. The messages msg that each user needs to perform BLS digital signatures on are respectively "A in [A, B, C, D]", "B in [A, B, C, D]", "C in [A, B, C, D]", "D in [A, B, C, D]". Using the BLS digital signature method, the user group {A, B, C, D} finally obtains the BLS digital signatures {sig A, sig B, sig C, sig D}, and the points on the curve to which the message msg hash values are mapped are respectively {qA, qB, qC, qD}.

[0110] (3) After each user in the user group uses the BLS signature generation program to obtain the digital signature, the signature is Base64 encoded and converted into a data format of String type, strA = Base64(sig A), strB = Base64(sigB), strC = Base64(sig C), strD = Base64(sig D). Then the String type data is serialized into JSON format for transmission in the network using the Https transmission protocol. Multiple users send JSON data to the user group representative. The JSON data formats sent are {"sigA": strA, "msg": "A in [A, B, C, D]"}, {"sigB": strB,

[0111] "msg": "B in [A, B, C, D]"}, {"sigC": strC, "msg": "C in

[0112] {“sigA”:strA,“sigB”:strB,“sigC”:strC,“sigD”:strD},”msg”:“D in [A,B,C,D]”}。

[0113] (4) After the user group representative receives the JSON data sent by all users, convert the JSON data into a String type string to obtain {strA, strB, strC, strD} and the msg of each user. Decode {strA, strB, strC, strD} using Base64, sig A = Base64(str A), sig B = Base64(str B), sig C = Base64(str C), sigD = Base64(str D). Then, use the BLS signature aggregation program to generate a BLS aggregated signature for {sig A, sig B, sig C, sig D}. The process of generating the BLS aggregated signature is sigAll = sig A + sig B + sig C + sig D. After the user group representative generates the BLS aggregated signature, perform Base64 encoding on the BLS aggregated signature and convert it into a String type data format, strAll = Base64(sigAll). Then serialize strAll into JSON format for transmission in the network using the Https transmission protocol. The user group representative sends a request to obtain the quantum key to the Nginx reverse proxy server, and the JSON data format sent is {"sigAll": strAll, "users": "[A, B, C, D]", "msg": "[A in [A, B, C, D], B in [A, B, C, D], C in [A, B, C, D], D in [A, B, C, D]]"}.

[0114] The BLS aggregated digital signature is initiated by the user group representative, borrowing the idea of edge nodes. Let the user group representative perform the aggregation and sending of the signature, reducing the pressure on the background processing server to store and process signature data. And it can ensure that the demand for the quantum key by the users within the user group will be transmitted to the background processing server simultaneously. If the BLS aggregated signature is not sent by the user group representative, but each person in the user group sends their own individual BLS digital signature one by one, the background server needs to wait for everyone in the user group to send before sending the same quantum key to all of these users. The amount of data is large and the efficiency is low.

[0115] (5) After the background processing server receives the request sent by the representative of the user group, it parses the transmitted data for verifying the BLS aggregate signature. The background processing server stores the BLS public key P and the public base point G corresponding to each user. After receiving the BLS aggregate signature and the message for verification sent by the representative of the user group, the background processing server can also calculate the hash values of different messages mapped to different points q on the curve. According to the verification formula of the BLS aggregate signature, the verification of the aggregate digital signature can be carried out. Taking a user group consisting of four users A, B, C, and D as an example, the verification formula of its BLS aggregate signature is:

[0116] e(G, sigAll) = e(pkA, qA) * e(pkB, qB) * e(pkC, qC) * e(pkD, qD).

[0117] III. Specific implementation of the reverse proxy solution:

[0118] The reverse proxy accepts the requests sent by the user client browser in the form of a proxy server, and then forwards the requests to the internal server. The user requests will not directly reach the background processing server and the quantum key cloud platform. The reverse proxy solution hides the information of the internal server and improves the system security. Secondly, the reverse proxy can separate dynamic resources from static resources and speed up the system access speed. Finally, using the Nginx reverse proxy server can achieve load balancing, distribute the requests sent by multiple representatives of user groups to multiple background processing servers for processing, reduce the congestion of the background processing servers, and improve the system efficiency.

[0119] The present invention uses the Nginx reverse proxy server as the reverse proxy server, and the reverse proxy process is as follows:

[0120] (1) According to the system requirements, plan the reverse proxy network topology structure of the present invention, as Figure 9 shown.

[0121] (2) Configure the IP address and port number of the background processing server in the Nginx reverse proxy server configuration file nginx.conf to achieve reverse proxy and load balancing. The load balancing strategy uses the default polling method of Nginx.

[0122] (3) Upload the static resources of the system to the Static folder of the Nginx reverse proxy server, and store the dynamic resources in the Tomcat server.

[0123] (4) Start the Nginx reverse proxy server to achieve functions such as reverse proxy, load balancing, and separation of dynamic resources from static resources.

[0124] IV. Specific implementation of the background processing server caching quantum keys:

[0125] (1) The administrator starts the Quantum Key Distribution (QKD) device. The QKD device uses an optical fiber quantum channel to generate a theoretically absolutely secure quantum key that cannot be eavesdropped on, and the quantum key is securely stored in the quantum key cloud platform.

[0126] (2) All users use the BLS digital signature generation program to generate BLS public and private key pairs. The BLS private key is stored locally on the user's client, and the BLS public key is sent to the background processing server.

[0127] (3) The background processing server uses the RSA key generation program to generate RSA public and private key pairs. The RSA private key is stored locally, and the RSA public key is sent to the quantum key cloud platform. The background processing server sends a request to the quantum key cloud platform to obtain a quantum key.

[0128] (4) When the quantum key cloud platform receives the request from the background processing server, it selects an unused quantum key from the key table in the quantum key cloud platform.

[0129] (5) The quantum key cloud platform encrypts the quantum key using the RSA public key of the background processing server to obtain the encrypted quantum key ciphertext Ⅰ, and sends the encrypted quantum key ciphertext Ⅰ to the background processing server.

[0130] (6) The background processing server receives the encrypted quantum key ciphertext Ⅰ and decrypts it using the local RSA private key to obtain the quantum key.

[0131] (7) The background processing server uses the BLS public key of each user to encrypt the quantum key in turn to obtain multiple different encrypted quantum key ciphertexts Ⅱ, and the encrypted quantum key ciphertexts Ⅱ correspond to each user respectively.

[0132] (8) The background processing server stores the key-value pair data in the form of multiple {key = username, value = encrypted quantum key ciphertext Ⅱ} in the Redis database, and sets the survival time of each data in the Redis database to 24 hours.

[0133] (9) The same user can be a member of different user groups. When user A is a member of both user group S1 and user group S2, the user can have two different encrypted quantum keys secrectKey1 and secrectKey2, which can be stored in the Redis database in the form of {"A": [secrectKey1, secrectKey2]}.

[0134] V. Specific implementation of the background processing server uploading data to the blockchain:

[0135] As shown in Figure 4 the following are the specific steps for the background processing server to upload quantum key-related data to the blockchain:

[0136] (1) The background processing server processes a decrypted quantum key through the SHA256 algorithm to obtain a 64-bit string H of fixed length.

[0137] (2) The background processing server obtains all the member names within the user group that applied for the quantum key. Taking the example that the user group has 4 members, the user group members are {A, B, C, D}.

[0138] (3) The background processing server generates key-value pair data in the form of {"H": "[A, B, C, D]"}.

[0139] (4) The background processing server connects to the Hyperledger Fabric blockchain network as a blockchain client by using the Hyperledger Fabric SDK.

[0140] (5) The transaction process on the Hyperledger Fabric blockchain is as shown in Figure 10 The background processing server connects to multiple peer nodes and Order nodes through the gPRC communication method as a blockchain client, invokes the smart contract on the blockchain, and initiates a transaction to write the key-value pair data of {"H": "[A, B, C, D]"}. The peer nodes verify the correctness of the transaction in the block and write the correct transaction into the blockchain database. The blockchain network returns the successful transaction ID to the background processing server.

[0141] (6) The background processing server obtains the successful transaction ID returned by the blockchain, indicating that the data has been successfully written into the Hyperledger Fabric blockchain ledger.

[0142] VI. As shown in Figure 6 the specific implementation of the user obtaining the quantum key solution is as follows:

[0143] Assume that user A queries the quantum key assigned to himself in the system. The specific steps are as follows:

[0144] (1) User A clicks the obtain button in the browser to request the quantum key from the Nginx reverse proxy server.

[0145] (2) The Nginx reverse proxy server forwards the request to the background processing server.

[0146] (3) The background processing server verifies the user's identity and confirms the user name A.

[0147] (4) The background processing server uses the username A as the key to query data in the Redis database and obtains the data {“A”: quantum key ciphertext}.

[0148] (5) The background processing server returns the data to the Nginx reverse proxy server, and the Nginx reverse proxy server returns the data to user A.

[0149] (6) After receiving the data, user A obtains the quantum key ciphertext. Use the locally saved RSA private key to decrypt the quantum key ciphertext to obtain the assigned quantum key.

[0150] 7. The specific implementation of the user verification quantum key consistency scheme is as Figure 7 shown:

[0151] After multiple users decrypt the quantum key ciphertext, they judge whether the quantum keys are consistent with those of other users in the same user group. Taking the user group {A, B, C, D} as an example, the specific verification steps are as follows:

[0152] (1) User A uses the SHA256 algorithm to hash the quantum key to obtain a 64-bit string H of fixed length. Enter the string H in the browser and click the “Verify” button to send a query request to the Nginx reverse proxy server.

[0153] [[ID=...]]

[0154] (3) After obtaining the request, the background processing server connects to a peer node on the blockchain network through the Hyperledger Fabric SDK. To query the data history record on the blockchain, it is necessary to call the getHistoryForKey function in the blockchain smart contract, and return the data {"H": "[A, B, C, D]"} to the background processing server.

[0155] (4) The background processing server returns the data to the Nginx reverse proxy server, and the Nginx reverse proxy server returns the data to the client user.

[0156] (5) User A views the returned data and verifies whether the usernames contained in the data are consistent with the usernames in the user group. After verification, user A determines that the quantum keys are consistent with those of other users in the same user group. Note: In the original text, there is an incomplete ID number in step (20). I have translated it as is, but you may want to check and correct that if it's a mistake in the original. Also, I've continued the translation of step (23) as best as possible despite the missing ID number in the middle of the step in the original text.

Claims

1. A quantum key distribution and verification system combined with blockchain, characterized in that: It includes a user client, an Nginx reverse proxy server, a background processing server, a Redis database, a quantum key cloud platform, and a blockchain network. The user client is used to register and log in to a quantum key distribution and verification system combined with a blockchain, establish a group encrypted chat interface, obtain their respective BLS digital signatures, use the provided BLS digital signature generation program to generate the BLS public and private key pairs of the BLS digital signature, save the BLS private key locally on the user client, and upload the BLS public key to the background processing server for storage; the BLS private key encrypts the message data of the user's request to obtain the quantum key of the user group where the user is located to form a BLS digital signature; the BLS public key is used to verify the correctness of the BLS digital signature and the BLS public key is also used to encrypt the quantum key obtained after decryption by the background processing server again to form a quantum key ciphertext II. One end of the Nginx reverse proxy server is connected to multiple user clients, and the other end of the Nginx reverse proxy server is connected to multiple background processing servers. The Nginx reverse proxy server is used for data forwarding between the user client and the background processing server. The Nginx reverse proxy server can balance the data load and thus improve the efficiency of quantum key distribution, verification, or query of multiple user clients. The background processing server is also connected to a firewall. The background processing server verifies the BLS aggregated signature, receives the BLS public key sent by the user client, generates an RSA public and private key pair using the RSA key generation program, saves the RSA private key locally on the background processing server, sends the RSA public key to the quantum key cloud platform to request and obtain the quantum key, encrypts the quantum key to obtain the quantum key ciphertext II. The quantum key ciphertext II corresponds to each user and is different for each user. The background processing server records the quantum key ciphertext II corresponding to each user one by one, and stores the key-value pair data in the form of {key = username, value = quantum key ciphertext II} in the Redis database and stores it in the Redis database. The Redis database is connected to multiple background processing servers. The Redis database is used to store the key-value pair data in the form of {key = username, value = quantum key ciphertext II}. The quantum key cloud platform is provided with a QKD quantum key distribution device, and the quantum key cloud platform is also provided with a firewall. The QKD quantum key distribution device generates a random quantum key on the quantum channel and stores it in the key table. The quantum key cloud platform receives the RSA public key sent by the background processing server, randomly extracts an unused quantum key from the key table, encrypts the quantum key with the RSA public key sent by the background processing server to obtain the quantum key ciphertext I, and sends the quantum key ciphertext I to the background processing server. The blockchain network is connected to multiple background processing servers. The blockchain network stores the hash value string of the quantum key decrypted by the background processing server and all the user names in the corresponding user group to form key-value pair data. The blockchain network is provided with multiple nodes, and the data in each block of each node is synchronously updated.

2. The quantum key distribution and verification system combined with blockchain according to claim 1, characterized in that: The blockchain network is a Hyperledger Fbric consortium blockchain network.

3. A working method of a quantum key distribution and verification system combined with blockchain, using the quantum key distribution and verification system combined with blockchain described in claim 1, characterized in that: It includes the following steps, and the following steps are carried out sequentially: Step 1: The user uses the BLS aggregated signature to request the system to allocate a quantum key (1) The user registers and logs in to a quantum key distribution and verification system combined with blockchain on the user client; (2) The user uses the BLS digital signature generation program installed on the user client to generate a BLS public-private key pair for the BLS digital signature. The BLS private key is saved locally on the user client, and the BLS public key is uploaded to the background processing server for storage through the Nginx reverse proxy server; the message data of the user's request to obtain the quantum key of the user group where the user is located is encrypted using the BLS private key to form a BLS digital signature. The user and other users form a user group, and a group encryption chat interface is established to elect a representative of the user group and send their respective BLS digital signatures to the representative; (3) The representative of the user group synthesizes all the BLS digital signatures of the users into a BLS aggregated signature and forwards it to the background processing server through the Nginx reverse proxy server and simultaneously sends a verification request; (4) The background processing server verifies the BLS aggregated signature to determine the legal identities of the users in the group. If the verification is passed, step (5) is carried out. If the verification fails, steps (2) to (3) are repeated to perform a re-verification of the BLS aggregated signature by the background processing server until the verification is passed and then step (5) is carried out; (5) The background processing server uses the RSA key generation program to generate an RSA public-private key pair. The RSA private key is saved locally on the background processing server, and the RSA public key is sent to the quantum key cloud platform to request the allocation of a quantum key; Step 2: The QKD quantum key distribution device connected to the quantum key cloud platform generates a random quantum key on the quantum channel and stores it in the key table. After the quantum key cloud platform receives the request for allocating a quantum key, it randomly extracts an unused quantum key from the key table, encrypts the quantum key with the RSA public key sent by the background processing server to obtain the quantum key ciphertext Ⅰ, and sends the quantum key ciphertext Ⅰ to the background processing server; Step 3: The background processing server obtains the quantum key ciphertext Ⅰ and caches it. Then, it decrypts the quantum key ciphertext Ⅰ using the RSA private key on the local background processing server to obtain the quantum key. The background processing server uses the BLS public key of each user to perform BLS encryption on the quantum key in sequence, obtaining multiple quantum key ciphertexts Ⅱ corresponding to each user respectively. The background processing server forms key-value pair data in the form of {key = username, value = quantum key ciphertext Ⅱ} for each of the multiple quantum key ciphertexts Ⅱ and stores them in the Redis database, setting the survival time of each data in the Redis database to 24 hours; Step 4: The background processing server performs a hash operation on the decrypted quantum key to obtain a hash value string. The background processing server uploads the key-value pair data composed of this hash value string and all usernames in the corresponding user group to the blockchain network; the blockchain network sets multiple nodes, and the data of each node is randomly compared with the data of other multiple nodes periodically to keep the data of each block in the blockchain network synchronized and updated; Step 5: Each user respectively obtains the quantum key ciphertext Ⅱ allocated to them from the blockchain network through the Nginx reverse proxy server and the background processing server; decrypts the quantum key ciphertext Ⅱ using the BLS private key saved locally on the user client to obtain the allocated quantum key; Step 6: Each user respectively sends a quantum key verification request, obtains the data returned by the blockchain network through the data transmission of the Nginx reverse proxy server and the background processing server, and verifies the consistency between the quantum key obtained by the user and the quantum keys of other users in the user group through the data returned by the blockchain network; If the verification result shows consistency, the operation ends. If the verification result shows inconsistency, start the request and verification of the quantum key again from Step 1 until the verification result shows consistency.

4. The working method of a quantum key distribution and verification system combined with blockchain according to claim 3, characterized in that: In Step 1, a user can enter multiple different user groups simultaneously and obtain different quantum keys accordingly. The different quantum keys obtained by the same user simultaneously are stored synchronously in the Redis database.

5. The working method of a quantum key distribution and verification system combined with blockchain according to claim 3, characterized in that: The specific steps for the user group representative to synthesize the BLS digital signatures of all users into a BLS aggregated signature in Step (3) of Step 1 are as follows: (1) The user group representative sends the time of the BLS aggregated signature to the users in the group to remind all users in the group to enter a quantum key distribution and verification system combined with the blockchain in time to query the allocated quantum key; (2) The users in the group generate their respective BLS signatures: When the BLS digital signature generation program generates the BLS public and private key pairs, it can also obtain the common base point G of the mapping curve adopted by the BLS public and private key pairs. The private key is denoted as sk, the public key is denoted as pk, and pk = sk * G; The BLS signature generation program first obtains the message msg of the BLS digital signature, then maps the hash value of the message msg to a certain point on the mapping curve adopted by the BLS public and private key pairs, denoted as q, and then multiplies it by the BLS private key sk to obtain the BLS digital signature Sig = sk * q; (3) After each user in the user group obtains their respective BLS digital signatures, the BLS digital signatures are Base64 encoded, converted into a data format of String type, and then the String type data is serialized into JSON format data. Multiple users send the JSON format data to the user group representative using the Https transmission protocol; (4) After the user group representative receives the JSON data sent by all users, the JSON data is converted into a String type string. The String type strings of the BLS digital signatures of each user and the message msg of the BLS digital signature are obtained respectively. The String type strings of the BLS digital signatures of each user are Base64 decoded to obtain the BLS digital signatures of each user. The BLS digital signatures of all users are added together to obtain the BLS aggregated signature. The user group representative Base64 encodes the BLS aggregated signature, converts it into a data format of String type, and then serializes the String type data into JSON format data. The user group representative sends the JSON format data to the background processing server through the Nginx reverse proxy server using the Https transmission protocol to request the acquisition of quantum keys.

6. The working method of a quantum key distribution and verification system combined with blockchain according to claim 3, characterized in that: (4) The specific steps for the background processing server to verify the BLS aggregated signature in step (4) of step one are as follows: The BLS public key pk corresponding to each user and the common base point G of the mapping curve used by the BLS public-private key pair are stored in the background processing server. After receiving the BLS aggregated signature and the verification request sent by the user group representative, the background processing server calculates the different points q on the curve mapped by the hash values of the BLS digital signatures of each user, and verifies the BLS aggregated digital signature according to the verification formula of the BLS aggregated signature.

7. The working method of a quantum key distribution and verification system combined with blockchain according to claim 3, characterized in that: (6) The specific steps for verifying the consistency between the quantum key obtained by the user and the quantum keys of other users in the user group are as follows: (1) The user uses the SHA256 algorithm to hash the obtained quantum key to obtain a 64-bit string H with a fixed length. Enter the string H in the user client and click the "Verify" button to send a query request to the Nginx reverse proxy server; (2) The Nginx reverse proxy server forwards the request to the background processing server; (3) After the background processing server obtains the request, the background processing server queries the data historical records on the blockchain through a peer node on the blockchain network. The blockchain network calls the getHistoryForKey function in the blockchain smart contract to perform data query and returns the queried data to the background processing server; (4) The background processing server returns the queried data to the Nginx reverse proxy server, and the Nginx reverse proxy server returns the queried data to the client user; (5) The user views the returned data and verifies whether the user names contained in the queried data are consistent with the user names in the user group. If they are consistent, the verification is completed, and the quantum keys of the user and other users in the same user group are consistent.

8. The working method of a quantum key distribution and verification system combined with blockchain according to claim 3, characterized in that: The blockchain network is a Hyperledger Fabric consortium blockchain network.

Images