# A Lamus-Based Flight Data Sharing Model on Consortium Blockchain

Authors: Fengyin Li; Yang Cui; Baogui Huang; Siqi Yu; Peiyu Liu; Yilei Wang; Tao Li
Journal: Security and Communication Networks
 (2022)

---

## 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.


---

## Body

## 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 Section4. 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.


## 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 Table1.Table 1
Notations.
NotationsDescriptionppSystem parametersR,ZSet of real numbers (integers)n,q,lSecurity parameterRqRq=R/qR=Zqx/fxmpk,mskMaster public key and master private keyid,LidIdentify signer and the list of signer private keysk,LskPrivate key of signer and the list of signer private keypkAggregation public keyMMessageσMultisignature of messageiThe order of signers,1<i<k.kThe number of participating signers


### 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 inRn 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.
(Lattice)
IfB=b1,b2,…,bm by Rn is composed of m linearly independent vectors, then the lattice LB is defined as the linear combination of all integer coefficients of this group of vectors, denoted as(1)Λ=LB=∑i=1mxibi|xi∈Z.
Letn be the dimension of the lattice LB, m is the rank, and B is a set of bases of the lattice.Definition 2.
(R-SISn,m,q,β problem)
Given a security parametern and a uniform random matrix A=a1,a2,…,am∈Rq1×m, find a nonzero solution u=u1,u2,…,umT∈Rm that satisfies the following conditions:(2)Au=0modq,u∞≤β.


### 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).Algorithm 1: iNTRU.TrapGen.
(i)
Input: The security parameter 1λ.(ii)
Output: A function-approximate trapdoor partial vk,T.(1)
Sampler←X,e←Xm.(2)
SetA:=r−1f+e∈Rqn(3)
Returnvk,T:=A,r,e∈Rqn+1×Rqn+1Algorithm 2: iNTRU.SamplePre.
(i)
Input: A cost u∈Rq, and a trapdoor r,e.(ii)
Output: An approximate pre-image u.(1)
Sample perturbationp←DRn+1,∑≤ for ∑p:=s2In+1−σg2etd−r¯et−rerr¯Im.(2)
Set cosetv:=u–Atp∈Rq.(3)
Sample the G-latticex=x1,x2←SamplePrev,σg.(4)
Define theiNTRU⋅trapdoor as R:=−etrIm.(5)
Set the approximate pre-imagey:=Rx2+p∈Rm.(6)
Returny.


### 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 theTrapGen 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.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 parameterpp 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.Figure 1
The lattice-based multisignature scheme.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.Algorithm 3: Lamus.ParameterGen.
(i)
Input: The security parameter 1λ.(ii)
Output: The system parameter pp.(1)
Run theTrapGen function, input the security parameter 1λ, and get the system parameter A∈Rqn and the corresponding trapdoor r,e.(2)
Samples three cryptographically secure hash functionsH0:Rq⟶Rq , H1:0,1∗⟶Pn,H2:0,1∗⟶D32n. n,q is the parameter of Rqn(3)
Publish system paramentpp=A,n,q,H0,H1,H2. Let A be the master public key mpk and r,e the master private key msk.When receiving the identityidi sent by the signer, KGC generates the corresponding private key ski for the signer (see Algorithm 4).Algorithm 4: Lamus.ExtractKey.
(i)
Input: The system parameter p , master key pairs msk,mpk, and the id of the signer.(ii)
Output: The private key ski for the signer.(1)
Run the functionSamplePre, input the identity idi and trapdoor r,e. Output the approximate pre-image ski of idi.(2)
Send the private keyski to the signer via secure communication.(3)
Return 0.The aggregation public key algorithm (Lamus.Aggregation) is executed by the specified signer or verifier.Lid is the identity list of signers (see Algorithm 5).Algorithm 5: Lamus.Aggregation.
(i)
Input: The system parameter pp, and the identity list Lid of the signers.(ii)
Output: The aggregation public key pk for the signers.(1)
Input the public key listLid.(2)
Calculateci′=H1Lid,idi, for 1<i<k, k is the number of signers in the identity list.(3)
Computerpk=∑ikidi⋅ci′, for 1<i<k.M is the message for all signers to sign. Lsk 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 R. The signers generate their partial signatures Zi 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).Algorithm 6: Lamus.Sign.
(i)
Input: The system parameter pp, and the private key list Lsk of the signers.(ii)
Output: The multisignature σ=Z,pk,M,R.(1)
All signers randomly select a vectorri, calculate vi=A⋅ri and ti=Hvi, and send ti,vi to other signers.(2)
ComputerR=∑ikvi, for 1<i<k, k is the number of signers in the identity list. c=H2M,R, and ci′=H1Lid,idi, the ci=c⋅ci′. The partial signature Zi=ski⋅ci+ri is using the signer's private key sk.(3)
All signers send their ownZi and r to the designated signer. The designated signer computers the signature Z=∑ikZi, and runs the Lamus.Aggregation outputting the aggregate public key pk.The verifier extracts theM,Z,pk,r from the multisignature and verifies the validity of the received multisignature (see Algorithm 7).Algorithm 7: Lamus.Verify.
(i)
Input: The system parameter pp, multisignature σ.(ii)
Output:0 or 1.(1)
The verifier confirms theZ∈Rqn, computers c=H2M,R.(2)
The verifier verifiesA⋅Z=c⋅pk+R. If the equation is true, output 1, otherwise output 0.


### 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 usingA,Z,R in the signature, the result of the hash function c, and the aggregation public key pk of signers.(3)A⋅Z=A⋅∑ikzi=A⋅∑ikski⋅ci+ri=∑ika⋅ski⋅ci+∑ika⋅ri=∑ikidi⋅ci+∑ikvi=c⋅∑iKidi⋅ci′+R=c⋅pk+R.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 simulatorB 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. The simulator B can then use this ability of adversary A 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 adversaryA, who makes at most h0,h1,h2 queries to H0,H1,H2 oracle, makes s queries to signature oracle, and succeeds in forging a multisignature with nonnegligible advantage ϵ within time t. Then there exists a simulator B that uses the ability of adversary A to solve R−SISq,n,m,d problem instance within time t+t1+t2 (t1 is the running time of TrapGen, t2 is the running time of SamplePre with the advantage of ϵ/qH,qH=h0+h1+h2).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, simulatorB and adversary A. 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 R−SISq,n,m,d problem.


### 3.7. Security Game

#### 3.7.1. Setup

SimulatorB runs the function TrapGen and obtains A,r,e. Simulator uses A and r,e as the master key pairs and randomly extracts an id∗ from the identity list Lid as the identity of the honest signer and runs SamplePre to extract the original image sk∗ of id∗ as the private key.


#### 3.7.2. Oracle Query

The adversaryA carries out ExtractKey oracle, H1 oracle, H2 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 idi∗) exists in the identity list Lid, 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 Lid or the queried id=idi∗, abort.(2)H1 Oracle Query. Simulator B checks whether the queried idi,Lid is stored in the H1 oracle query table. If it is in the table, return the result directly to the adversary A. Else if the queried idi exists in the identity list Lid, simulator B returns the corresponding QI from the QqH for the adversary A and stores it. If the queried id does not exist in the identity list Lid, randomly select a result to return.(3)H2 Oracle Query. Simulator B checks whether the queried Ml,rl is stored in the H2 oracle query table. If it is in the table, return the result directly to the adversary A. Else simulator B returns the corresponding H2Ml,rl for the adversary A and stores it.(4) Signature Oracle Query. Firstly, simulator B checks whether the idi∗ is existing in the queried identity list Lid′. If it is not in the Lid′, abort. Else simulator B checks whether the queried Ml is stored in the H2 oracle query table. Then simulator B returns the corresponding σi∗ for the adversary A and stores it.


#### 3.7.3. Forgery

The adversaryA produces a forged result of the message M; if the Lid corresponding to the message does not contain idi∗, abort. And message M should be queried by H2 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 usingTid, simulator B obtains Tsk. Simulator B makes another signature Z′ by using Tsk. Because the random number ri∗ 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:(4)R=R′,AZ−pk⋅c=AZ′−pk⋅c,AZ−Z′=0,ATsk⋅c−Tsk′⋅c=0,Aski∗−ski∗′⋅c=0.Then the simulatorB finds the solution Q=ski∗−ski∗′⋅c of a R−SISq,n,m,d problem instance, and Q satisfies A⋅Q=0. Theorem 2 is proved.


## 3.1. Notations

The notations used in this paper are presented in Table1.Table 1
Notations.
NotationsDescriptionppSystem parametersR,ZSet of real numbers (integers)n,q,lSecurity parameterRqRq=R/qR=Zqx/fxmpk,mskMaster public key and master private keyid,LidIdentify signer and the list of signer private keysk,LskPrivate key of signer and the list of signer private keypkAggregation public keyMMessageσMultisignature of messageiThe order of signers,1<i<k.kThe number of participating signers


## 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 inRn 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.
(Lattice)
IfB=b1,b2,…,bm by Rn is composed of m linearly independent vectors, then the lattice LB is defined as the linear combination of all integer coefficients of this group of vectors, denoted as(1)Λ=LB=∑i=1mxibi|xi∈Z.
Letn be the dimension of the lattice LB, m is the rank, and B is a set of bases of the lattice.Definition 2.
(R-SISn,m,q,β problem)
Given a security parametern and a uniform random matrix A=a1,a2,…,am∈Rq1×m, find a nonzero solution u=u1,u2,…,umT∈Rm that satisfies the following conditions:(2)Au=0modq,u∞≤β.


## 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).Algorithm 1: iNTRU.TrapGen.
(i)
Input: The security parameter 1λ.(ii)
Output: A function-approximate trapdoor partial vk,T.(1)
Sampler←X,e←Xm.(2)
SetA:=r−1f+e∈Rqn(3)
Returnvk,T:=A,r,e∈Rqn+1×Rqn+1Algorithm 2: iNTRU.SamplePre.
(i)
Input: A cost u∈Rq, and a trapdoor r,e.(ii)
Output: An approximate pre-image u.(1)
Sample perturbationp←DRn+1,∑≤ for ∑p:=s2In+1−σg2etd−r¯et−rerr¯Im.(2)
Set cosetv:=u–Atp∈Rq.(3)
Sample the G-latticex=x1,x2←SamplePrev,σg.(4)
Define theiNTRU⋅trapdoor as R:=−etrIm.(5)
Set the approximate pre-imagey:=Rx2+p∈Rm.(6)
Returny.


## 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 theTrapGen 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.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 parameterpp 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.Figure 1
The lattice-based multisignature scheme.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.Algorithm 3: Lamus.ParameterGen.
(i)
Input: The security parameter 1λ.(ii)
Output: The system parameter pp.(1)
Run theTrapGen function, input the security parameter 1λ, and get the system parameter A∈Rqn and the corresponding trapdoor r,e.(2)
Samples three cryptographically secure hash functionsH0:Rq⟶Rq , H1:0,1∗⟶Pn,H2:0,1∗⟶D32n. n,q is the parameter of Rqn(3)
Publish system paramentpp=A,n,q,H0,H1,H2. Let A be the master public key mpk and r,e the master private key msk.When receiving the identityidi sent by the signer, KGC generates the corresponding private key ski for the signer (see Algorithm 4).Algorithm 4: Lamus.ExtractKey.
(i)
Input: The system parameter p , master key pairs msk,mpk, and the id of the signer.(ii)
Output: The private key ski for the signer.(1)
Run the functionSamplePre, input the identity idi and trapdoor r,e. Output the approximate pre-image ski of idi.(2)
Send the private keyski to the signer via secure communication.(3)
Return 0.The aggregation public key algorithm (Lamus.Aggregation) is executed by the specified signer or verifier.Lid is the identity list of signers (see Algorithm 5).Algorithm 5: Lamus.Aggregation.
(i)
Input: The system parameter pp, and the identity list Lid of the signers.(ii)
Output: The aggregation public key pk for the signers.(1)
Input the public key listLid.(2)
Calculateci′=H1Lid,idi, for 1<i<k, k is the number of signers in the identity list.(3)
Computerpk=∑ikidi⋅ci′, for 1<i<k.M is the message for all signers to sign. Lsk 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 R. The signers generate their partial signatures Zi 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).Algorithm 6: Lamus.Sign.
(i)
Input: The system parameter pp, and the private key list Lsk of the signers.(ii)
Output: The multisignature σ=Z,pk,M,R.(1)
All signers randomly select a vectorri, calculate vi=A⋅ri and ti=Hvi, and send ti,vi to other signers.(2)
ComputerR=∑ikvi, for 1<i<k, k is the number of signers in the identity list. c=H2M,R, and ci′=H1Lid,idi, the ci=c⋅ci′. The partial signature Zi=ski⋅ci+ri is using the signer's private key sk.(3)
All signers send their ownZi and r to the designated signer. The designated signer computers the signature Z=∑ikZi, and runs the Lamus.Aggregation outputting the aggregate public key pk.The verifier extracts theM,Z,pk,r from the multisignature and verifies the validity of the received multisignature (see Algorithm 7).Algorithm 7: Lamus.Verify.
(i)
Input: The system parameter pp, multisignature σ.(ii)
Output:0 or 1.(1)
The verifier confirms theZ∈Rqn, computers c=H2M,R.(2)
The verifier verifiesA⋅Z=c⋅pk+R. If the equation is true, output 1, otherwise output 0.


## 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 usingA,Z,R in the signature, the result of the hash function c, and the aggregation public key pk of signers.(3)A⋅Z=A⋅∑ikzi=A⋅∑ikski⋅ci+ri=∑ika⋅ski⋅ci+∑ika⋅ri=∑ikidi⋅ci+∑ikvi=c⋅∑iKidi⋅ci′+R=c⋅pk+R.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 simulatorB 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. The simulator B can then use this ability of adversary A 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 adversaryA, who makes at most h0,h1,h2 queries to H0,H1,H2 oracle, makes s queries to signature oracle, and succeeds in forging a multisignature with nonnegligible advantage ϵ within time t. Then there exists a simulator B that uses the ability of adversary A to solve R−SISq,n,m,d problem instance within time t+t1+t2 (t1 is the running time of TrapGen, t2 is the running time of SamplePre with the advantage of ϵ/qH,qH=h0+h1+h2).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, simulatorB and adversary A. 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 R−SISq,n,m,d problem.


## 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 usingA,Z,R in the signature, the result of the hash function c, and the aggregation public key pk of signers.(3)A⋅Z=A⋅∑ikzi=A⋅∑ikski⋅ci+ri=∑ika⋅ski⋅ci+∑ika⋅ri=∑ikidi⋅ci+∑ikvi=c⋅∑iKidi⋅ci′+R=c⋅pk+R.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 simulatorB 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. The simulator B can then use this ability of adversary A 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 adversaryA, who makes at most h0,h1,h2 queries to H0,H1,H2 oracle, makes s queries to signature oracle, and succeeds in forging a multisignature with nonnegligible advantage ϵ within time t. Then there exists a simulator B that uses the ability of adversary A to solve R−SISq,n,m,d problem instance within time t+t1+t2 (t1 is the running time of TrapGen, t2 is the running time of SamplePre with the advantage of ϵ/qH,qH=h0+h1+h2).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, simulatorB and adversary A. 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 R−SISq,n,m,d problem.


## 3.7. Security Game

### 3.7.1. Setup

SimulatorB runs the function TrapGen and obtains A,r,e. Simulator uses A and r,e as the master key pairs and randomly extracts an id∗ from the identity list Lid as the identity of the honest signer and runs SamplePre to extract the original image sk∗ of id∗ as the private key.


### 3.7.2. Oracle Query

The adversaryA carries out ExtractKey oracle, H1 oracle, H2 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 idi∗) exists in the identity list Lid, 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 Lid or the queried id=idi∗, abort.(2)H1 Oracle Query. Simulator B checks whether the queried idi,Lid is stored in the H1 oracle query table. If it is in the table, return the result directly to the adversary A. Else if the queried idi exists in the identity list Lid, simulator B returns the corresponding QI from the QqH for the adversary A and stores it. If the queried id does not exist in the identity list Lid, randomly select a result to return.(3)H2 Oracle Query. Simulator B checks whether the queried Ml,rl is stored in the H2 oracle query table. If it is in the table, return the result directly to the adversary A. Else simulator B returns the corresponding H2Ml,rl for the adversary A and stores it.(4) Signature Oracle Query. Firstly, simulator B checks whether the idi∗ is existing in the queried identity list Lid′. If it is not in the Lid′, abort. Else simulator B checks whether the queried Ml is stored in the H2 oracle query table. Then simulator B returns the corresponding σi∗ for the adversary A and stores it.


### 3.7.3. Forgery

The adversaryA produces a forged result of the message M; if the Lid corresponding to the message does not contain idi∗, abort. And message M should be queried by H2 oracle or signature oracle. Check the validity of the signature. If the signature is valid, the security game is over.


## 3.7.1. Setup

SimulatorB runs the function TrapGen and obtains A,r,e. Simulator uses A and r,e as the master key pairs and randomly extracts an id∗ from the identity list Lid as the identity of the honest signer and runs SamplePre to extract the original image sk∗ of id∗ as the private key.


## 3.7.2. Oracle Query

The adversaryA carries out ExtractKey oracle, H1 oracle, H2 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 idi∗) exists in the identity list Lid, 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 Lid or the queried id=idi∗, abort.(2)H1 Oracle Query. Simulator B checks whether the queried idi,Lid is stored in the H1 oracle query table. If it is in the table, return the result directly to the adversary A. Else if the queried idi exists in the identity list Lid, simulator B returns the corresponding QI from the QqH for the adversary A and stores it. If the queried id does not exist in the identity list Lid, randomly select a result to return.(3)H2 Oracle Query. Simulator B checks whether the queried Ml,rl is stored in the H2 oracle query table. If it is in the table, return the result directly to the adversary A. Else simulator B returns the corresponding H2Ml,rl for the adversary A and stores it.(4) Signature Oracle Query. Firstly, simulator B checks whether the idi∗ is existing in the queried identity list Lid′. If it is not in the Lid′, abort. Else simulator B checks whether the queried Ml is stored in the H2 oracle query table. Then simulator B returns the corresponding σi∗ for the adversary A and stores it.


## 3.7.3. Forgery

The adversaryA produces a forged result of the message M; if the Lid corresponding to the message does not contain idi∗, abort. And message M should be queried by H2 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 usingTid, simulator B obtains Tsk. Simulator B makes another signature Z′ by using Tsk. Because the random number ri∗ 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:(4)R=R′,AZ−pk⋅c=AZ′−pk⋅c,AZ−Z′=0,ATsk⋅c−Tsk′⋅c=0,Aski∗−ski∗′⋅c=0.Then the simulatorB finds the solution Q=ski∗−ski∗′⋅c of a R−SISq,n,m,d problem instance, and Q satisfies A⋅Q=0. 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 Figures2 and 3.Figure 2
The structure of block.Figure 3
The structure of transaction.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.Figure4 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.Figure 4
Model architecture.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 runsTrapGen, inputs security parameter 1λ, and outputs trapdoor pair A,r,eA∈ℛqn.(2)
Randomly selectH0:ℛq⟶ℛq,H1:0,1∗⟶Pn,H2:0,1∗⟶D32n. n,q is the parameter of ℛqn .(3)
Public system parameterspp=A,n,q,H0,H1,H2. Let A be master public key mpk; r,e is master private key msk.(4)
The signer sends the identity to the KGC. KGC runsSamplePre after receiving the identity and inputs the signer identity idi and master private key r,e. KGC outputs the original image ski of idi.(5)
KGC sends the signer's private keyski 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 signZi for the data M 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 T by using the message M,σ, and pk.(3)
Furthermore, the transactionT is submitted to the FMA by the FDC.The process of transaction generation is contained in Figure5. The specific process is as follows:(1)
First, the aircrew, airline, and ground personnel, respectively, generate a random polynomialri, calculate vi=A⋅ri and ti=Hvi, and send ti,vi to other signers.(2)
CalculateR=∑ikvi, for 1<i<k. Calculate c=H2M,R, ci′=H1Lid,idi, ci=c⋅ci′. Aircrew, airline, and ground personnel use sk to generate partial signatures Zi=ski⋅ci+ri.(3)
All signers send partial signaturesZi and r to the FDC. The FDC calculates Z=∑ikZi and the aggregate public key pk=∑ikidi⋅ci′. The FDC uses multiple signatures and flight data to generate a transaction Ti.(4)
The FDC sends the generated transactionTi to the FMA.Figure 5
Creation of transactions.


### 4.4. Block Release

The FMA sorts the received transaction information to form a transaction poolT1,T2,T3,…,Tn. The FMA takes out the transactions in the transaction pool to generate blocks B1=T1,T2,T3,…,Tj and sends the generated blocks to each FDC. Figure 6 shows the process of block release.Figure 6
Block release.The specific process is as follows:(1)
The FMA extracts a set ofZ,pk,m,R from the transaction Ti and calculates c=H2m,R.(2)
The FMA verifies the following equation,A⋅Z=c⋅pk+R. 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. Figure7 shows the process of transaction query.Figure 7
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 ofZ,pk,m,R from the request message and calculates c=H2m,R.(3)
The 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. The FDC returns the flight data to the querier.


## 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 Figures2 and 3.Figure 2
The structure of block.Figure 3
The structure of transaction.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.Figure4 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.Figure 4
Model architecture.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 runsTrapGen, inputs security parameter 1λ, and outputs trapdoor pair A,r,eA∈ℛqn.(2)
Randomly selectH0:ℛq⟶ℛq,H1:0,1∗⟶Pn,H2:0,1∗⟶D32n. n,q is the parameter of ℛqn .(3)
Public system parameterspp=A,n,q,H0,H1,H2. Let A be master public key mpk; r,e is master private key msk.(4)
The signer sends the identity to the KGC. KGC runsSamplePre after receiving the identity and inputs the signer identity idi and master private key r,e. KGC outputs the original image ski of idi.(5)
KGC sends the signer's private keyski to the signer through a secure channel.


## 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.Figure4 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.Figure 4
Model architecture.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 runsTrapGen, inputs security parameter 1λ, and outputs trapdoor pair A,r,eA∈ℛqn.(2)
Randomly selectH0:ℛq⟶ℛq,H1:0,1∗⟶Pn,H2:0,1∗⟶D32n. n,q is the parameter of ℛqn .(3)
Public system parameterspp=A,n,q,H0,H1,H2. Let A be master public key mpk; r,e is master private key msk.(4)
The signer sends the identity to the KGC. KGC runsSamplePre after receiving the identity and inputs the signer identity idi and master private key r,e. KGC outputs the original image ski of idi.(5)
KGC sends the signer's private keyski 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 signZi for the data M 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 T by using the message M,σ, and pk.(3)
Furthermore, the transactionT is submitted to the FMA by the FDC.The process of transaction generation is contained in Figure5. The specific process is as follows:(1)
First, the aircrew, airline, and ground personnel, respectively, generate a random polynomialri, calculate vi=A⋅ri and ti=Hvi, and send ti,vi to other signers.(2)
CalculateR=∑ikvi, for 1<i<k. Calculate c=H2M,R, ci′=H1Lid,idi, ci=c⋅ci′. Aircrew, airline, and ground personnel use sk to generate partial signatures Zi=ski⋅ci+ri.(3)
All signers send partial signaturesZi and r to the FDC. The FDC calculates Z=∑ikZi and the aggregate public key pk=∑ikidi⋅ci′. The FDC uses multiple signatures and flight data to generate a transaction Ti.(4)
The FDC sends the generated transactionTi to the FMA.Figure 5
Creation of transactions.


## 4.4. Block Release

The FMA sorts the received transaction information to form a transaction poolT1,T2,T3,…,Tn. The FMA takes out the transactions in the transaction pool to generate blocks B1=T1,T2,T3,…,Tj and sends the generated blocks to each FDC. Figure 6 shows the process of block release.Figure 6
Block release.The specific process is as follows:(1)
The FMA extracts a set ofZ,pk,m,R from the transaction Ti and calculates c=H2m,R.(2)
The FMA verifies the following equation,A⋅Z=c⋅pk+R. 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. Figure7 shows the process of transaction query.Figure 7
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 ofZ,pk,m,R from the request message and calculates c=H2m,R.(3)
The 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. 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.



---

*Source: 5717185-2022-05-09.xml*