A Lamus-Based Flight Data Sharing Model on Consortium Blockchain

Currently, traditional ﬂight data sharing models cannot resist quantum attacks, which poses the risk of data leakage. The research on the ﬂight data sharing model against quantum attack has become one of the research hotspots. Lattice-based cryptography is recognized as an eﬀective way to resist quantum attacks. A ﬂight 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 ﬂight 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 eﬃciency and operating eﬃciency.


Introduction
e 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. e 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]. is 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.
is paper mainly consists of the following parts. e first part is a brief introduction to the background of this paper. e second part is an overview of related works. In the third part, a lattice-based multisignature scheme is proposed. e security and correctness of lattice-based multisignature schemes are proved in Section 4. e fifth part is the flight data sharing model based on the Lamus scheme. e last section concludes and lists some future work.

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. e 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. e 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-themiddle 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]. e 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. erefore, the combination of multisignature and blockchain received widespread attention. e 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.

Our Contribution.
is paper proposes a new identitybased 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. e proposed model solves data leakage during data sharing, flight resources wasting, and information leakage. e proposed model obtains high storage efficiency and high operating efficiency, ensuring high security against quantum attacks.
(3) e proposed flight data sharing model is secure against quantum attacks. e lattice-based multisignature scheme is secure under the assumption of the R-SIS hardness, which guarantees the postquantum security of our data sharing model.

Notations.
e notations used in this paper are presented in Table 1.

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. e 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. e 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. e private blockchain usually runs in a relatively controllable and credible intranet environment. e 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].

Basic Knowledge of Lattice Cryptography.
Lattice-based cryptography is the use of conjectured hard problems on point lattices in R n 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]. (1) Let n be the dimension of the lattice L(B), m is the rank, and B is a set of bases of the lattice.

Definition 2. (R-SIS n,m,q,β problem)
Given a security parameter n and a uniform random matrix A � [a 1 , a 2 , . . . , a m ] ∈ R 1×m q , find a nonzero solution u � (u 1 , u 2 , . . . , u m ) T ∈ R m that satisfies the following conditions:
is 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]. e iNTRU lattice trapdoor function contains two algorithms, which, respectively, implement the functions of trapdoor generation and preimage sampling (see Algorithm 1 and Algorithm 2).

Lattice-Based Multisignature Scheme (Lamus).
e 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 TrapGen and the Sample 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.
ere 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. e signer and the designated signer jointly generate a multisignature to protect the integrity of the signed data. e verifier verifies the multisignature to confirm its integrity.
e lattice-based multisignature scheme includes five algorithms: ParameterGen, ExtractKey, Aggregation, Sign, and Verify. e ParameterGen algorithm is run by KGC to generate system parameters and the master key pair of KGC.
e system parameter pp is the input of all other algorithms in the scheme. e Extract Key algorithm is run by the KGC and generates signer's private key after receiving the identity of the signer. e Aggregation algorithm is usually run by a designated signer. e designated signer generates an aggregated public key from the IDs of all signers to verify the validity of the signature. ( e Aggregation algorithm can also be run by the verifier.) e Sign algorithm is run by multiple signers and the designated signer. e signers generate their own partial signatures and send them to the designated signer. e designated signer generates a single multisignature from multiple partial signatures. e final output of the Sign algorithm is a multisignature. e Verify algorithm is run by the verifier and outputs 0 or 1 as the verification result. e overall structure is shown in Figure 1. KGC runs the system parameter generation function. is function generates related parameters of multisignature, such as master key pairs. e specific algorithm steps are described in Algorithm 3.
When receiving the identity id i sent by the signer, KGC generates the corresponding private key sk i for the signer (see Algorithm 4). e aggregation public key algorithm (Lamus.Aggregation) is executed by the specified signer or verifier. L id is the identity list of signers (see Algorithm 5).
M is the message for all signers to sign. L sk is a list of all signers' private keys. e signing process is divided into three steps. e first step is mutual interactions between signers to negotiate unanimous signature parameter R. e signers generate their partial signatures Z i 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).
Master public key and master private key id, L id Identify signer and the list of signer private key sk, L sk Private key of signer and the list of signer private key pk Aggregation public key M Message σ Multisignature of message i e order of signers, 1 < i < k. k e number of participating signers e verifier extracts the M, Z, pk, r from the multisignature and verifies the validity of the received multisignature (see Algorithm 7).

Security Analysis.
is 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 A, Z, R in the signature, the result of the hash function c, and the aggregation public key pk of signers.  (i) Input: e security parameter 1 λ .
(i) Input: A cost u ∈ R q , and a trapdoor (r, e).
(ii) Output: e system parameter pp.
(1) Run the TrapGen function, input the security parameter 1 λ , and get the system parameter A ∈ R n q and the corresponding trapdoor (r, e).
(i) Input: e system parameter pp, and the private key list L sk of the signers.
(1) All signers randomly select a vector r i , calculate v i � A · r i and t i � H(v i ), and send (t i , v i ) to other signers.
(2) Computer R � k i v i , for 1 < i < k, k is the number of signers in the identity list. c � H 2 (M, R), and c i ′ � H 1 (L id , id i ), the c i � c · c i ′ . e partial signature Z i � sk i · c i + r i is using the signer's private key sk.
(3) All signers send their own Z i and r to the designated signer. e designated signer computers the signature Z � k i Z i , and runs the Lamus.Aggregation outputting the aggregate public key pk.

Security and Communication Networks 5
e verifier can legally obtain the parameters of the left and the last row on right of equation (3). e correctness of the Lamus scheme is proved.

Proof of Security.
e 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 eorem 1 In eorem 2, we construct a security game between the simulator B and the malicious adversary A. Simulator B acts as KGC responds to adversary A queries. Meanwhile, simulator B controls the identity of an honest signer. Adversary A can act as all the signers except the honest signer. In the security game, it is assumed that the adversary A can forge a multisignature involving one honest signer. e simulator B can then use this ability of adversary A to solve the R-SIS problem instance. is 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 eorem 2 holds, it is proved that the multiple signature scheme with an honest signer is secure. eorem 2 holds; then eorem 1 holds.  , (r, e)). Simulator uses A and (r, e) as the master key pairs and randomly extracts an id * from the identity list L id as the identity of the honest signer and runs SamplePre to extract the original image sk * of id * as the private key.

Oracle Query.
e adversary A carries out ExtractKey oracle, H 1 oracle, H 2 oracle, and signature oracle queries.
(1) ExtractKey Oracle Query. First, simulator B 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 A. Else if the queried id (not id i * ) exists in the identity list L id , simulator B returns the corresponding private key sk for the adversary A and stores it. If the queried id does not exist in the identity list L id or the queried id � id i * , abort.

Forgery.
e adversary A produces a forged result of the message M; if the L id corresponding to the message does not contain id i * , abort. And message M should be queried by H 2 oracle or signature oracle. Check the validity of the signature. If the signature is valid, the security game is over.

Analysis of Security Game
Output. By using T id , simulator B obtains T sk . Simulator B makes another signature Z ′ by using T sk . Because the random number r i * corresponding to the signature is randomly selected by the simulator B, we make R of the two signatures the same. According to this conclusion, we obtain the following equation: en the simulator B finds the solution Q � (sk i * − sk i * ′ ) · c of a R − SIS (q,n,m,d) problem instance, and Q satisfies A · Q � 0. eorem 2 is proved.

Lamus-Based Flight Data Sharing Model on
Consortium Blockchain e current traditional flight data sharing model has privacy leakage in the quantum computer environment. is section proposes a flight data sharing model on consortium blockchain. e 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.

Model Architecture.
e model consists of four types of entities: Flight Data Center (FDC), Flight Management Agency (FMA), KGC, and client user (client). e 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. e FDC is the main component of the blockchain. It is responsible for storing blocks and providing transaction uploads and transaction queries for clients. e FMA is responsible for the ordering of transactions and the releasing blocks. e KGC is responsible for providing the private key query for the client user. e user provides the KGC with an ID, and the KGC sends the user's private key to the user through a secure channel. e generation of the transaction requires the participation of aircrew, airline, and ground personnel. FDC forwards the transaction sent by the client to FMA. e 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. e FDC sends the flight data to the data consumers. e data of the blockchain data sharing system is stored in blocks. e block is mainly divided into two parts: the Block Header and the Block Body. e Block Header stores PreHash, MerkleRoot, TimeStamp, and Index. PreHash stores the hash result of the previous block to ensure data immutability.
e MerkleRoot in the Block Header is generated from the hash values of all transactions in the Block Body. rough 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. e Block Body stores multiple transactions. e flight data and corresponding multisignatures are stored in the transaction. e 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.

Key Registration Interface.
e reply from this interface is answered by KGC, and the client users obtain the private key that matches their identity through this interface.

Transaction Generation Interface.
is 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.

Transaction Query Interface.
e 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. e area on the left shows the process of FDC submitting a transaction.
e 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. e detailed process is as follows.

Sharing of Flight Data.
e model is divided into three stages: the creation of the transactions, block release, and transaction query. e 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. e transaction query is corresponding to the data download in the data sharing system. Data consumers obtain the flight data through the corresponding transaction.

e 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.
e transaction generation process is as follows: (1) Aircrew, airline, and ground personnel generate their partial signatures of flight data. ey sign Z i for the data M generated during the flight process. public key and multisignature σ. FDC generates a transaction T by using the message M, σ, and pk. (3) Furthermore, the transaction T is submitted to the FMA by the FDC.
e process of transaction generation is contained in Figure 5. e specific process is as follows: (1) First, the aircrew, airline, and ground personnel, respectively, generate a random polynomial r i , cal- Aircrew, airline, and ground personnel use sk to generate partial signatures Z i � sk i · c i + r i .
(3) All signers send partial signatures Z i and r to the FDC. e FDC calculates Z � k i Z i and the aggregate public key pk � k i id i · c i ′ . e FDC uses multiple signatures and flight data to generate a transaction T i . (4) e FDC sends the generated transaction T i to the FMA.

Block
Release. e FMA sorts the received transaction information to form a transaction pool (T 1 , T 2 , T 3 , . . . , T n ).
e FMA takes out the transactions in the transaction pool to generate blocks B 1 � (T 1 , T 2 , T 3 , . . . , T j ) and sends the generated blocks to each FDC. Figure 6 shows the process of block release. e specific process is as follows: (1) e FMA extracts a set of (Z, pk, m, R) from the transaction T i and calculates c � H 2 (m, R).    Security and Communication Networks 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. e 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. e detailed process is as follows: (1) Data consumers initiate a request for flight data. e request message contains the message itself and the multisignature of the message. (2) e FDC extracts a set of (Z, pk, m, R) from the request message and calculates c � H 2(m,R) . (3) e FDC verifies the following equation, A · Z � c· pk + R. 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. e FDC returns the flight data to the querier.

Conclusion
is paper proposes a lattice-based multisignature scheme (Lamus) and applies it to the flight data sharing model on consortium blockchain. e 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. e 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. erefore, 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].