Abstract
Currently, traditional flight data sharing models cannot resist quantum attacks, which poses the risk of data leakage. The research on the flight data sharing model against quantum attack has become one of the research hotspots. Lattice-based cryptography is recognized as an effective way to resist quantum attacks. A flight data sharing model on consortium blockchain is proposed in this paper to resolve data leakage during data sharing. First, a new lattice-based multisignature scheme (Lamus) is proposed, capable of resisting quantum attacks. We prove the security of the proposed Lamus scheme in the random oracle model. Moreover, a flight data sharing model on consortium blockchain is proposed by applying the proposed Lamus scheme to resist quantum attacks. Security and performance analysis show that the model guarantees antiquantum security, and it achieves good performance in terms of storage efficiency and operating efficiency.
1. Introduction
The Air Transport industry is a highly interconnected industry that relies on data sharing to function properly. Data sharing process is vulnerable to attack such as eavesdropping attacks, which makes many data owners unwilling to share flight data. In view of the above reason, existing aviation data sharing systems can only realize data sharing in a certain range, which affects the effect of aviation data sharing to different degrees.
With the development of network technology, network security requirements are also increasing. Blockchain is a representative high-security network technology, which uses a unique data structure to verify and store data. Blockchain uses cryptography to achieve its nontampering. Digital signature technology is used to ensure the integrity and correctness of data transmission in blockchain.
The use of multisignature schemes in blockchain is mainly to improve storage efficiency by reducing the size of signatures, and most of these multisignature schemes are based on elliptic curves. With the development of quantum computers, the security of the existing signature schemes based on elliptic curves or integer factorization confronts severe challenges. Lattice-based cryptography is a typical postquantum cryptography [1]. This paper proposes a new lattice-based multisignature scheme and applies it to a blockchain-based flight data sharing system to improve the quantum resistance of the data sharing scheme.
This paper mainly consists of the following parts. The first part is a brief introduction to the background of this paper. The second part is an overview of related works. In the third part, a lattice-based multisignature scheme is proposed. The security and correctness of lattice-based multisignature schemes are proved in Section 4. The fifth part is the flight data sharing model based on the Lamus scheme. The last section concludes and lists some future work.
2. Related Work
In recent years, many schemes for flight data sharing systems have been proposed, such as Air Traffic Management data sharing. However, there are some cybersecurity threats in flight data sharing: eavesdropping and jamming. The interference in the data sharing process is mainly caused by malicious users publishing wrong information, which leads to wrong judgments on aircraft and ground stations. The authenticity and integrity of shared data is very important to management. In order to prevent the flight data from being maliciously tampered with, digital signature technology is used in many flight data sharing mechanisms. In [2], He et al. proposed a certificateless designated verifier proxy signature scheme to solve the problems of digital certificate management and key escrow in unmanned aerial vehicle networks. In [3], Li and Pu proposed a lightweight digital signature protocol to protect drones from man-in-the-middle attack. In [4], the authors proposed a lightweight authentication and key agreement scheme to implement the authentication problem between drones and users. In order to protect the integrity of flight data, a variety of digital signature schemes have been proposed. However, research of postquantum signature for flight data has not received much attention.
Blockchain is a decentralized distributed storage system, and the data stored in it is immutable. Many flight data sharing systems have been proposed on the basis of blockchain [5, 6]. In [7], the authors implemented secure communication between aircraft and ground station on the basis of blockchain. In [8], the authors implemented a blockchain-based PKI that implements “Secure Broadcast Authorization.” In [9], the authors treated each flight plan as a blockchain transaction but does not deal with the verification of the flight data. Reference [10] proposed a blockchain and cloud storage based framework to guarantee the unmanned aerial vehicle data integrity. In [11], the authors presented a data integrity assurance mechanism based on digital signatures in IoT environment. Reference [12] proposed a data placement strategy named DE-DPSO-DPS to consider shared datasets across various geographically distributed environments.
An important concept in blockchain technology is accounts, which includes multiple signature accounts [13]. The multisignature was first proposed by Itakura, which refers to a group of signers signing the same binary string information and finally forming a signature result of the size like a single ordinary signature [14]. A multisignature scheme enables a group of signers to produce a compact, joint signature on a common document and has many potential uses [15]. Micali et al. were the first to give the formal model and security proof of multisignature and proposed a multisignature scheme based on the Schnorr signature scheme [16]. If multisignature is not applied, the size of each block in the blockchain will be much larger. Therefore, the combination of multisignature and blockchain received widespread attention. The widely used signature scheme in the blockchain is ECDSA digital based on the elliptic curve. Lindell et al. proposed a multiparty ECDSA signature scheme with distributed key generation. Kansal et al. proposed a lattice-based multisignature scheme for the first time at the 2020 African Cryptographic Conference and improved the original scheme in 2021 [17, 18]. Chen et al. proposed a novel certificateless multisignature scheme over NTRU lattices in [19].
2.1. Our Contribution
This paper proposes a new identity-based multisignature scheme on lattice.(1)A lattice-based multisignature scheme is proposed in this paper. In order to solve the high overhead of certificates storage and management in current signature schemes, a lattice-based multisignature scheme is proposed by introducing the identity cryptography mechanism into the multisignature schemes. Moreover, we prove the security of the proposed scheme in the random oracle model.(2)A flight data sharing model on consortium blockchain is proposed in this paper. By applying the proposed lattice-based multisignature scheme into flight data management, a flight data sharing model on consortium blockchain is proposed in this paper. The proposed model solves data leakage during data sharing, flight resources wasting, and information leakage. The proposed model obtains high storage efficiency and high operating efficiency, ensuring high security against quantum attacks.(3)The proposed flight data sharing model is secure against quantum attacks. The lattice-based multisignature scheme is secure under the assumption of the R–SIS hardness, which guarantees the postquantum security of our data sharing model.
3. Preliminary
3.1. Notations
The notations used in this paper are presented in Table 1.
3.2. Blockchain
Blockchain is a linked list data structure. Each block is linked to the previous one and stores a series of ordered things. It is a particular type of distributed database. The main difference between blockchain and ordinary databases is that blockchain guarantees decentralization, as well as the consistency, nontampering, and traceability of the stored data. Among them, the characteristic of decentralization is the most critical. Essentially, the blockchain can be seen as a decentralized database.
According to the degree of network centralization, blockchain is generally divided into public blockchain, private blockchain, and consortium blockchain. The public blockchain is completely decentralized. Users may join the blockchain at any time, participate in any activity in the blockchain, and maintain and manage the ledger. A private blockchain is a completely closed blockchain, and only private individuals participate in releasing blocks and storing blocks. The private blockchain usually runs in a relatively controllable and credible intranet environment. The consortium blockchain is a kind of blockchain for specific groups or organizations. It is a semipublic blockchain, and only certain members participate in releasing and storing blocks [20, 21].
3.3. Basic Knowledge of Lattice Cryptography
Lattice-based cryptography is the use of conjectured hard problems on point lattices in as the foundation for secure cryptographic systems. Lattice-based cryptography is a typical postquantum cryptography [22, 23]. Another attractive feature of it is security under worst-case intractability assumptions [24].
Definition 1. ()
If by is composed of linearly independent vectors, then the lattice is defined as the linear combination of all integer coefficients of this group of vectors, denoted asLet be the dimension of the lattice , is the rank, and is a set of bases of the lattice.
Definition 2. (- problem)
Given a security parameter n and a uniform random matrix , find a nonzero solution that satisfies the following conditions:
3.4. iNTRU Trapdoor
The iNTRU is an inhomogeneous NTRU problem [25]. This paper mainly uses a kind of gadget-based iNTRU lattice trapdoor. Compared with other trapdoor functions, the size of the signature and key generated by the iNTRU trapdoor has obvious advantages. At the same time, the calculation process has no obvious disadvantage compared with other trapdoor generating functions, so we choose the iNTRU trapdoor function [26]. The iNTRU lattice trapdoor function contains two algorithms, which, respectively, implement the functions of trapdoor generation and preimage sampling (see Algorithm 1 and Algorithm 2).
|
|
3.5. Lattice-Based Multisignature Scheme (Lamus)
The lattice-based multisignature scheme proposed in this paper is postquantum security under the assumption of the R–SIS hardness. At the same time, our scheme is an identity-based multisignature scheme, which directly uses the signer’s identity ID as the public key. Identity-based signature solves the high overhead of certificate storage and management in PKI-based signature schemes. In addition, our scheme uses the and the in the iNTRU scheme to improve the efficiency of the key extraction algorithm. In this paper, we prove the security of the scheme in the random oracle model.
There are several types of entities in the scheme: Key Generation Center (KGC), signers, designated signer, and verifier. KGC is responsible for the production of public parameters and the signer's private key in the multisignature scheme. The signer and the designated signer jointly generate a multisignature to protect the integrity of the signed data. The verifier verifies the multisignature to confirm its integrity.
The lattice-based multisignature scheme includes five algorithms: ParameterGen, ExtractKey, Aggregation, Sign, and Verify. The ParameterGen algorithm is run by KGC to generate system parameters and the master key pair of KGC. The system parameter is the input of all other algorithms in the scheme. The Extract Key algorithm is run by the KGC and generates signer’s private key after receiving the identity of the signer. The Aggregation algorithm is usually run by a designated signer. The designated signer generates an aggregated public key from the IDs of all signers to verify the validity of the signature. (The Aggregation algorithm can also be run by the verifier.) The Sign algorithm is run by multiple signers and the designated signer. The signers generate their own partial signatures and send them to the designated signer. The designated signer generates a single multisignature from multiple partial signatures. The final output of the Sign algorithm is a multisignature. The Verify algorithm is run by the verifier and outputs 0 or 1 as the verification result. The overall structure is shown in Figure 1.
KGC runs the system parameter generation function. This function generates related parameters of multisignature, such as master key pairs. The specific algorithm steps are described in Algorithm 3.
|
When receiving the identity sent by the signer, KGC generates the corresponding private key for the signer (see Algorithm 4).
|
The aggregation public key algorithm (Lamus.Aggregation) is executed by the specified signer or verifier. is the identity list of signers (see Algorithm 5).
|
is the message for all signers to sign. is a list of all signers' private keys. The signing process is divided into three steps. The first step is mutual interactions between signers to negotiate unanimous signature parameter . The signers generate their partial signatures using their private key in the second step. In the third step, all signers send their partial signatures to the designated signer, and the designated signer combines the received partial signatures to form a multisignature (see Algorithm 6).
|
The verifier extracts the from the multisignature and verifies the validity of the received multisignature (see Algorithm 7).
|
3.6. Security Analysis
This section contains the correctness and security proofs of the multisignature scheme.
3.6.1. Proof of Correctness
A multiple signature generated according to the above scheme can be successfully verified, which means that the scheme proposed in this paper is correct. If signers correctly generate a multisignature, then the verifier can verify the following equation using in the signature, the result of the hash function , and the aggregation public key of signers.
The verifier can legally obtain the parameters of the left and the last row on right of equation (3). The correctness of the Lamus scheme is proved.
3.6.2. Proof of Security
The security of the proposed scheme mainly proves the unforgeability of multisignature. To prove the unforgeability of multisignature, we will prove the following theorem in the random oracle model.
Theorem 1. When there exists at least one honest signer, our scheme satisfies the unforgeability in the random oracle model.
Proof. of Theorem 1 In Theorem 2, we construct a security game between the simulator and the malicious adversary . Simulator acts as KGC responds to adversary queries. Meanwhile, simulator B controls the identity of an honest signer. Adversary can act as all the signers except the honest signer. In the security game, it is assumed that the adversary can forge a multisignature involving one honest signer. The simulator can then use this ability of adversary to solve the R–SIS problem instance. This is inconsistent with the fact that R–SIS does not have a polynomial-time solution algorithm, which proves the assumptions wrong in the security game. If Theorem 2 holds, it is proved that the multiple signature scheme with an honest signer is secure. Theorem 2 holds; then Theorem 1 holds.
Theorem 2. Suppose there exists a polynomial-time adversary , who makes at most queries to oracle, makes s queries to signature oracle, and succeeds in forging a multisignature with nonnegligible advantage within time . Then there exists a simulator that uses the ability of adversary A to solve problem instance within time ( is the running time of , is the running time of with the advantage of ).
Proof. of Theorem 2 The proof of the scheme is proved by a security game and analysis of game output. The security game includes two entities, simulator and adversary . The security game has three stages: Setup, Oracle query, Forgery. If the multisignature is successfully forged, the game is over. We analyse the output of the security game to get a solution to the problem.
3.7. Security Game
3.7.1. Setup
Simulator runs the function and obtains . Simulator uses A and as the master key pairs and randomly extracts an from the identity list as the identity of the honest signer and runs to extract the original image of as the private key.
3.7.2. Oracle Query
The adversary carries out ExtractKey oracle, oracle, oracle, and signature oracle queries.
(1) ExtractKey Oracle Query. First, simulator checks whether the queried $id$ is stored in the ExtractKey oracle query table. If it is in the table, return the result directly to the adversary . Else if the queried (not ) exists in the identity list , simulator returns the corresponding private key for the adversary and stores it. If the queried does not exist in the identity list or the queried , abort.
(2) Oracle Query. Simulator checks whether the queried is stored in the oracle query table. If it is in the table, return the result directly to the adversary . Else if the queried exists in the identity list , simulator returns the corresponding from the for the adversary and stores it. If the queried does not exist in the identity list , randomly select a result to return.
(3) Oracle Query. Simulator checks whether the queried is stored in the oracle query table. If it is in the table, return the result directly to the adversary . Else simulator returns the corresponding for the adversary and stores it.
(4) Signature Oracle Query. Firstly, simulator checks whether the is existing in the queried identity list . If it is not in the , abort. Else simulator checks whether the queried is stored in the oracle query table. Then simulator returns the corresponding for the adversary and stores it.
3.7.3. Forgery
The adversary produces a forged result of the message ; if the corresponding to the message does not contain , abort. And message should be queried by oracle or signature oracle. Check the validity of the signature. If the signature is valid, the security game is over.
3.8. Analysis of Security Game Output
By using , simulator obtains . Simulator makes another signature by using . Because the random number corresponding to the signature is randomly selected by the simulator , we make of the two signatures the same. According to this conclusion, we obtain the following equation:
Then the simulator finds the solution of a problem instance, and satisfies . Theorem 2 is proved.
4. Lamus-Based Flight Data Sharing Model on Consortium Blockchain
The current traditional flight data sharing model has privacy leakage in the quantum computer environment. This section proposes a flight data sharing model on consortium blockchain. The proposed flight data sharing model realizes flight data sharing among different agencies. At the same time, this model uses the lattice-based multisignature scheme proposed in the third section, enhancing security against quantum attacks. Our flight data sharing model ensures data integrity when data is shared between different institutions. In addition, the unforgeability of flight data and the traceability of signer are obtained.
4.1. Model Architecture
The model consists of four types of entities: Flight Data Center (FDC), Flight Management Agency (FMA), KGC, and client user (client). The clients include aircrew, airline, ground personnel, and data consumers. Client users do not participate in the operation and storing of the blockchain. Aircrew, airline, and ground personnel sign the flight data together and submit it to FDC. The FDC is the main component of the blockchain. It is responsible for storing blocks and providing transaction uploads and transaction queries for clients. The FMA is responsible for the ordering of transactions and the releasing blocks. The KGC is responsible for providing the private key query for the client user. The user provides the KGC with an ID, and the KGC sends the user's private key to the user through a secure channel.
The generation of the transaction requires the participation of aircrew, airline, and ground personnel. FDC forwards the transaction sent by the client to FMA. The following is the process of block release. Transactions sent to the FMA are deposited in the transaction pool in order. When the number of transactions is enough, the transactions are packaged into blocks, which are sent to all FDCs. After receiving the blocks, the FDC updates the local blockchain. In the transaction inquiry process, the data consumer first initiates a flight data request to the FDC. After receiving the request, the FDC performs signature verification on the request message. If the received request is valid, FDC extracts the flight data from the corresponding transaction. The FDC sends the flight data to the data consumers.
The data of the blockchain data sharing system is stored in blocks. The block is mainly divided into two parts: the Block Header and the Block Body. The Block Header stores PreHash, MerkleRoot, TimeStamp, and Index. PreHash stores the hash result of the previous block to ensure data immutability. The MerkleRoot in the Block Header is generated from the hash values of all transactions in the Block Body. Through MerkleRoot, it is possible to quickly determine whether a transaction is included in this block. TimeStamp marks the release time of the block. Index is the height of the block in the blockchain. The Block Body stores multiple transactions. The flight data and corresponding multisignatures are stored in the transaction.
The structure of transaction and block is shown in Figures 2 and 3.
Because client users do not participate in specific transactions and block storage, the model provides three interfaces for clients.
4.1.1. Key Registration Interface
The reply from this interface is answered by KGC, and the client users obtain the private key that matches their identity through this interface.
4.1.2. Transaction Generation Interface
This interface is mainly used by FDC to accept flight data and multisignature uploaded by client users. After receiving the relevant data, FDC generates a transaction and forwards it to FMA.
4.1.3. Transaction Query Interface
The reply from this interface is answered by FDC. Client users apply to the FDC to query a transaction on the blockchain through this interface.
Figure 4 contains “data upload” and “data download” areas. The area on the left shows the process of FDC submitting a transaction. The area on the right shows the process of querying a transaction. Aircrew, airline, and ground personnel can perform these two operations, but the only one-way operation is shown in the figure.
In this model, all clients need to obtain the key corresponding to the identity from the KGC through the key registration interface. The detailed process is as follows.(1)KGC runs , inputs security parameter , and outputs trapdoor pair .(2)Randomly select . is the parameter of .(3)Public system parameters . Let be master public key ; is master private key .(4)The signer sends the identity to the KGC. KGC runs after receiving the identity and inputs the signer identity and master private key . KGC outputs the original image of .(5)KGC sends the signer's private key to the signer through a secure channel.
4.2. Sharing of Flight Data
The model is divided into three stages: the creation of the transactions, block release, and transaction query. The block creation in the data sharing system is the process of data upload. Data is stored in transactions of block and uploaded as the block is released. The transaction query is corresponding to the data download in the data sharing system. Data consumers obtain the flight data through the corresponding transaction.
4.3. The Creation of the Transactions
To prevent malicious users from creating false flight data, an effective flight data needs to be signed jointly by aircrew, airline, and ground personnel.
The transaction generation process is as follows:(1)Aircrew, airline, and ground personnel generate their partial signatures of flight data. They sign for the data generated during the flight process.(2)The FDC composes the partial signatures of all signers into multisignature and generates a transaction with multisignature and flight data. As a designed signer, the FDC generates an aggregate public key and multisignature . FDC generates a transaction by using the message , and .(3)Furthermore, the transaction is submitted to the FMA by the FDC.
The process of transaction generation is contained in Figure 5. The specific process is as follows:(1)First, the aircrew, airline, and ground personnel, respectively, generate a random polynomial , calculate and , and send to other signers.(2)Calculate , for . Calculate , , . Aircrew, airline, and ground personnel use to generate partial signatures .(3)All signers send partial signatures and to the FDC. The FDC calculates and the aggregate public key . The FDC uses multiple signatures and flight data to generate a transaction .(4)The FDC sends the generated transaction to the FMA.
4.4. Block Release
The FMA sorts the received transaction information to form a transaction pool . The FMA takes out the transactions in the transaction pool to generate blocks and sends the generated blocks to each FDC. Figure 6 shows the process of block release.
The specific process is as follows:(1)The FMA extracts a set of from the transaction and calculates .(2)The FMA verifies the following equation, . If the equation holds, the transaction is considered legal.(3)Add legitimate transactions to the transaction pool.(4)The FMA writes the timestamp, the Merck tree, the current block ID, and the hash of the previous block into the Block Header. Write the transaction to the block.(5)The FMA broadcasts the block to all FDCs.
4.5. Transaction Query
Transaction queries are initiated by data consumers to the FDC. The FDC verifies the request message after receiving the request. If the message is successfully verified, the transaction in the blockchain is queried. If the verification fails, an error will be returned. After querying the transaction information, the FDC needs to extract the flight data and multiple signatures in the transaction information. The FDC checks whether the requester is in the multisignature public key list. Furthermore, the FDC returns the corresponding flight data of the queried transaction to the requesting user if the requester's identity is in the public key list. Figure 7 shows the process of transaction query.
The detailed process is as follows:(1)Data consumers initiate a request for flight data. The request message contains the message itself and the multisignature of the message.(2)The FDC extracts a set of from the request message and calculates .(3)The FDC verifies the following equation, . If the equation holds, the request message is considered legal. Otherwise, FDC returns an error message to the querier.(4)FDC performs message query in blockchain and returns error messages if message query fails. After the query is successful, FDC returns the query data. The FDC returns the flight data to the querier.
5. Conclusion
This paper proposes a lattice-based multisignature scheme (Lamus) and applies it to the flight data sharing model on consortium blockchain. The proposed data sharing model has solved the problem of data islands and the information leakage of flight data. In addition, the proposed Lamus scheme is secure against quantum attacks.
The proposed Lamus scheme requires the interaction of signers. In the scenario of the proposed data sharing model, the efficiency of Lamus scheme achieves the desired effect. However, the network delay affects the efficiency of the Lamus scheme when the signers are in different locations. Therefore, the efficiency of the Lamus scheme is affected by network conditions. In future work, we will consider constructing a noninteractive multisignature scheme to avoid network conditions affecting its efficiency.
Data Availability
No data were used to support this study.
Disclosure
An earlier version has previously been published as conference [27].
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This study was supported by Natural Science Foundation of Shandong Province, no. ZR2019MF062.