Method for determining privacy set intersection cardinality for civil aviation risk coordination investigation

Abstract

The application discloses a privacy set intersection cardinality determination method for civil aviation risk coordination investigation, and relates to the fields of information security and aviation technology. In the method, a first server and a second server acquire a first key share and a second key share respectively; a providing end interacts with each element in a first data set held by the providing end based on a context identifier, and generates a first label set; a querying end interacts with each element in a second data set held by the querying end based on the context identifier, and generates a second label set; the first server and the second server obtain a first calculation result share and a second calculation result share based on the first key share, the second key share, the first label set and the second label set; and the querying end reconstructs an intersection cardinality according to the obtained calculation result share. The application solves the technical problems of high compliance risk of cross-institution data sharing and poor information security in the civil aviation risk coordination investigation scene in the prior art.

Description

Technical Field

[0001] This application relates to the fields of information security and aviation technology, and more specifically, to a method for determining the cardinality of the intersection of privacy sets for civil aviation risk investigation. Background Technology

[0002] With the deepening of digital transformation in the civil aviation industry, security assurance has shifted from passive response to precise risk verification and joint prevention and control based on big data. In a typical civil aviation risk investigation scenario, the querying party (such as the airport security center) holds a real-time flight passenger list, while the providing party (such as a regulatory agency) holds a list of sensitive risks. Both parties need to calculate the intersection cardinality of the two sets in order to know the number of high-risk personnel and carry out classified handling without disclosing the specific contents of the list.

[0003] Existing technologies primarily rely on cloud server-assisted intersection computation of privacy sets, but these typically require strong trust assumptions about a single cloud server, posing a single point of trust risk. Furthermore, most solutions focus solely on computation offloading, lacking authorization auditing and anti-probing / abuse mechanisms specific to civil aviation operations. In addition, existing dual-cloud solutions often assume no collusion between the two clouds, but fail to effectively address how to securely and efficiently compute the intersection cardinality under this assumption, resulting in significant compliance risks and information security challenges for cross-organizational data sharing.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method for determining the intersection cardinality of privacy sets for civil aviation risk investigation, in order to at least solve the technical problems of high compliance risk and poor information security in cross-agency data sharing in civil aviation risk investigation scenarios, which are caused by the inability to efficiently calculate the intersection cardinality on two servers (e.g., two cloud servers) without collusion and leakage of their respective original data.

[0006] According to one aspect of the embodiments of this application, a method for determining the intersection cardinality of privacy sets for civil aviation risk investigation is provided, applied to a system including a query terminal, a provider terminal, a first server, and a second server, comprising: obtaining a first key share and a second key share bound to a context identifier from an authorization center through the first server and the second server respectively; the provider terminal interacts with each element in a first data set held by the provider based on the context identifier to generate a first tag set, and stores the first tag set in the second server; the query terminal interacts with each element in a second data set held by the query terminal based on the context identifier to generate a second tag set, and sends the second tag set to the first server; the first server and the second server collaboratively execute a two-party secure computation protocol based on the first key share, the second key share, the first tag set, and the second tag set to obtain a first computation result share corresponding to the first server and a second computation result share corresponding to the second server; the query terminal obtains the first computation result share and the second computation result share from the first server and the second server respectively, and reconstructs the intersection cardinality based on the obtained computation result shares, wherein the intersection cardinality is used to identify the number of passengers on the flight who overlap with the risk list.

[0007] Optionally, the provider interacts with each element in the first data set held by the provider based on the context identifier to generate a first tag set, including: the provider normalizes and encodes each element in the first data set, and performs a hash operation on the encoded element and the context identifier to obtain a group mapping value; the provider determines a blinding value based on the group mapping value and a random blinding factor, and sends the blinding value to the first server and the second server respectively; the provider receives a first part of the evaluation result calculated by the first server based on the first key share held by the provider, and a second part of the evaluation result calculated by the second server based on the second key share held by the provider; and generates a first tag set based on the first part of the evaluation result and the second part of the evaluation result.

[0008] Optionally, generating a first tag set based on the first part of the evaluation result and the second part of the evaluation result includes: multiplying the first part of the evaluation result and the second part of the evaluation result by the provider to obtain an aggregate value, and performing a deblinding operation on the aggregate value using the inverse of the random blinding factor to obtain a deblinded aggregate value; inputting the deblinded aggregate value and the context identifier into a tag hash function by the provider to generate a token bound to the context identifier; inputting the token into a pseudo-random function by the provider to generate a final tag bound to the context identifier; and forming the first tag set by combining the final tags corresponding to all elements.

[0009] Optionally, before obtaining the computation result share pair by the first server and the second server collaboratively executing the two-party secure computation protocol based on the first key share, the second key share, the first tag set, and the second tag set, a fixed-length upper bound is obtained through the query terminal, wherein the fixed-length upper bound is greater than or equal to the actual size of the second data set; a target number of dummy tags are generated through the query terminal, wherein the target number is determined by the fixed-length upper bound; the dummy tags are tags that are different from the real tag indicator bits; the real tags and dummy tags are combined into a dual sequence according to their corresponding indicator bits through the query terminal, and the dual sequence is randomly scrambled to obtain a scrambled dual sequence; the scrambled dual sequence is sent to the first server through the query terminal.

[0010] Optionally, the first server and the second server collaboratively execute a two-party secure computation protocol based on a first key share, a second key share, a first tag set, and a second tag set to obtain computation result share pairs. This includes: when the first server uses its scrambled dual sequence as input and the second server uses the set structure information encoded by the stored first tag set as input, the first server and the second server run the two-party secure computation protocol based on the first key share, the second key share, the first tag set, and the second tag set. The two-party secure computation protocol includes the following steps: executing a membership determination function within the protocol, wherein the membership determination function is used to determine whether each queried tag generated by the query end and input into the protocol by the first server after scrambling belongs to the first tag set, obtaining the determination result for each queried tag; multiplying the determination result of each queried tag by the corresponding real indicator bit to obtain the contribution value of the queried tag; finally summing the contribution values ​​of all queried tags in the encrypted domain to obtain the intersection cardinality; and outputting the intersection cardinality in the form of additive secret sharing, so that the first server obtains the first computation result share and the second server obtains the second computation result share.

[0011] Optionally, the membership determination function is implemented using a cuckoo hash or Bloom filter structure. The operation of the membership determination function includes: selecting d public hash functions, storing each tag in the first tag set in at least one candidate position of the set structure, where d is an integer greater than or equal to 1; if a stored value equal to the queried tag exists in any of the d candidate positions of the queried tag, the membership determination function outputs 1; if no stored value equal to the queried tag exists in any of the d candidate positions of the queried tag, the membership determination function outputs 0.

[0012] Optionally, before obtaining the first key share and the second key share bound to the context identifier from the authorization center through the first server and the second server respectively, the authorization center's server generates a context identifier based on the current query task code, time slice, flight number, and airport code; the authorization center's server generates a context index key based on the master key and the context identifier through a key derivation function; the authorization center's server performs addition and splitting of the context index key to obtain the first key share and the second key share; the authorization center's server distributes the first key share to the first server and the second key share to the second server; the authorization center's server generates a tag mapping key based on the master key and the context identifier, and distributes the tag mapping key to the controlled components of the provider and query ends.

[0013] Optionally, a digital signature ticket including mandatory policy constraints is generated through the server of the authorization center. The mandatory policy includes at least pre-set constraints on the minimum data size of the query set, the maximum query frequency, and the output mode. The digital signature ticket is sent concurrently with the second tag set sent to the first server through the query terminal. The first server performs a signature verification operation on the digital signature ticket, which includes verifying whether the digital signature ticket is valid, whether the input length of the query digital signature ticket is equal to the upper bound of the fixed length, and whether the query frequency of the digital signature ticket exceeds the maximum query frequency. If the digital signature ticket fails the verification operation, both the first and second servers refuse to execute the two-party secure computation protocol.

[0014] Optionally, the query client submits the second data set to the authoritative source of the list, wherein the authoritative source of the list is the civil aviation departure system or the passenger reservation record system; the authoritative source of the list verifies the authenticity of each element in the second data set submitted by the query client, and for the elements that pass verification, the authoritative source of the list generates a first digital signature for the element based on the context identifier using a private key; when the query client sends the second tag set to the first server, the first digital signatures of the elements that pass verification by the authoritative source of the list are also sent to the first server.

[0015] Optionally, the superior regulatory authority of the provider generates a second digital signature for each tag in the first tag set; the provider submits the second digital signature corresponding to each tag in the first tag set to the second server while updating the first tag set; wherein the second server verifies each received second digital signature and stores and indexes the tags corresponding to the successfully verified second digital signatures.

[0016] Optionally, a minimum query set size is set for digitally signed tickets issued by the authorization center; when constructing the tag input sequence through the query terminal, the number of real tags in the tag input sequence is controlled to be no less than the minimum query set size; if the actual size of the second data set held by the query terminal is less than the minimum query set size, the query terminal expands the second data set with real tags by adding additional virtual elements that do not belong to any real flights, so that the number of real tags in the second data set reaches the minimum query set size.

[0017] Optionally, the query terminal obtains the first calculation result share and the second calculation result share from the first server and the second server respectively, and reconstructs the intersection cardinality based on the obtained calculation result shares, including: digitally signing the first calculation result share through the first server to generate a first result signature, and sending the first calculation result share and the first result signature to the query terminal; digitally signing the second calculation result share through the second server to generate a second result signature, and sending the second calculation result share and the second result signature to the query terminal; verifying the validity of the first result signature and the second result signature through the query terminal, and obtaining the intersection cardinality by performing a modulo operation on the first calculation result share and the second calculation result share after successful verification.

[0018] Optionally, in response to a change event in the second data set, the query terminal identifies the set of changed elements corresponding to the change event, wherein the change event includes an add operation, a delete operation, and a replace operation; for each element corresponding to the add operation, the query terminal re-executes the tag generation process to obtain the tag of the added element and the corresponding element authorization signature; for each element corresponding to the delete operation, the query terminal calculates the hash value of the token corresponding to the element as a delete pointer; for each element corresponding to the replace operation, the query terminal constructs an update instruction containing the replace operation type and the corresponding data item, and sends the update instruction to the first server; wherein, according to the received update instruction, the first server executes the corresponding element replacement operation on the locally stored sequence structure, while keeping the unchanged data unchanged.

[0019] Optionally, when the provider performs batch updates on the first data set, the provider packages multiple update instructions into update capsules, wherein the update capsule includes multiple operation types and corresponding tag data; the provider digitally signs the update capsule and sends the signed update capsule to the second server; the second server verifies the signature of the update capsule, and after successful verification, updates the tag information in the first tag set sequentially according to the order of the instructions in the update capsule; after the second server completes the update of the first tag set, it sends an update completion notification to the first server, along with a summary of the updated first tag set; the first server records the summary information for consistency verification during subsequent queries.

[0020] According to another aspect of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described method for determining the intersection cardinality of privacy sets for civil aviation risk investigation.

[0021] According to another aspect of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the above-described method for determining the intersection cardinality of privacy sets for civil aviation risk investigation.

[0022] According to another aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the above-described method for determining the intersection cardinality of privacy sets for civil aviation risk investigation.

[0023] It should be noted that, through the dual-server key share segmentation mechanism, the technical solution of this application solves the problems of single-point trust risk and information leakage. For example, when existing technologies rely on a single cloud server for auxiliary computing, this server may learn the original data or intermediate information of both parties. Once attacked or internally leaked, it will lead to large-scale leakage of sensitive data. This application, through an authorization center, segments the key bound to the context identifier into a first key share and a second key share, which are distributed to the first server and the second server respectively, making it impossible for any single server to independently complete the complete data transformation or decryption operation. The first tag set generated by the provider is stored on the second server, and the second tag set generated by the query is sent to the first server. This achieves physical separation of the original data of both parties (the first server only accesses the data of the query but does not hold the tag set of the provider, and the second server only holds the tag set of the provider but does not access the data of the query), thereby helping to eliminate the possibility of a single server simultaneously obtaining the original data of both parties, and thus helping to reduce the risk of data leakage.

[0024] Furthermore, the share output mechanism of the two-party secure computation protocol enables secure calculation of the intersection cardinality without exposing the original data. For example, existing technologies often require one party to expose its data to the other party or the cloud in some form when calculating the intersection, posing a data export compliance risk. However, in implementing the technical solution of this application, the first server and the second server, based on their respective key shares, first tag set, and second tag set, collaboratively execute the two-party secure computation protocol, but ultimately only output the first and second computation result shares in the form of addition secret sharing. This means that: first, during the protocol execution, the first server cannot know the content of the first tag set, and the second server cannot know the content of the second tag set; the original data of both parties is always in a state of encrypted protection; second, the output result is a share that has been secretly shared, and no single server can reconstruct the true intersection cardinality based solely on its own share; only when the querying end obtains both shares simultaneously can the result be reconstructed. This design ensures that even if a single server is compromised, the attacker cannot obtain the sensitive information of the intersection cardinality, let alone infer the membership relationship of any individual.

[0025] Finally, a key system bound to context identifiers enables cross-scenario data isolation and compliance control. For example, civil aviation risk investigations involve multiple queries across different flights, time slots, and airports. In existing technologies, if the same data is processed using the same key in different queries, it may lead to cross-scenario trajectory association, causing additional privacy and compliance risks. This application introduces context identifiers, deeply binding them to key shares and the tag generation process (the key shares obtained by the first and second servers are both bound to specific context identifiers, and the tags generated by the provider and query ends are also based on the same context identifier). This ensures that the tags generated for the same passenger in queries on different flights and dates are completely different and unlinkable, fundamentally preventing the correlation analysis of passengers' cross-scenario behavioral trajectories.

[0026] In summary, the technical solution of this application, through a systematic combination of mechanisms such as key share segmentation, dual-cloud separate storage, secure computation share output by both parties, and context identifier binding, achieves full-process privacy protection of the original data of both parties without relying on any single server for complete trust, while ensuring the security of the computation results. This helps to reduce the compliance risks and information security risks of cross-organizational data sharing, and provides a security technology solution that meets regulatory requirements for civil aviation risk investigation scenarios. Attached Figure Description

[0027] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0028] Figure 1 This is a flowchart of a method for determining the intersection cardinality of privacy sets for civil aviation risk investigation according to an embodiment of this application;

[0029] Figure 2 This is a schematic diagram of a system architecture according to an embodiment of this application;

[0030] Figure 3 This is a schematic diagram of an optional dual-cloud segmentation context token generation process according to an embodiment of this application;

[0031] Figure 4 This is a schematic diagram of an anti-probe abuse mechanism based on ticket authorization and element signature according to an embodiment of this application;

[0032] Figure 5 This is a flowchart illustrating the execution of a 2PC-based MPCCount share output protocol according to an embodiment of this application.

[0033] Figure 6 This is a logic block diagram of an optional differential update mechanism according to an embodiment of this application. Detailed Implementation

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0035] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0036] According to an embodiment of this application, an embodiment of a method for determining the intersection cardinality of privacy sets for civil aviation risk investigation is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0037] Figure 1 This is a flowchart of a method for determining the intersection cardinality of privacy sets for civil aviation risk investigation, according to an embodiment of this application. Figure 1 As shown, the method includes the following steps:

[0038] Step S101: Obtain the first key share and the second key share bound to the context identifier from the authorization center through the first server and the second server respectively.

[0039] Optionally, Figure 2 This is a schematic diagram of a system architecture according to an embodiment of this application, such as... Figure 2 As shown, the system involved in this application includes at least the following core hardware / logic modules:

[0040] Query Party (Q): Deployed at airports, security checkpoints, or public security collaboration platforms, it is responsible for holding and processing the original passenger lists for flights.

[0041] Provider Party (P): Deployed in regulatory agencies or large airlines, holding a large collection of sensitive risk lists.

[0042] Authorization and Key Management Center A (Authority): Responsible for issuing tickets and distributing context segmentation keys.

[0043] Manifest Source (M): For example, the Departure Control System (DCS) is responsible for providing an official signature on passenger information as a "digital endorsement" of the legitimacy of the input.

[0044] Collaborative cloud platform (Cloud 1 & Cloud 2): Two servers with independent management domains, which do not collude with each other and are responsible for performing core encryption comparison tasks.

[0045] Audit Ledger Log: Used to record summaries, invoices, and share signatures for each query, supporting post-event compliance traceability.

[0046] In some embodiments, Authorization Center A, acting as a trusted key management authority, holds the master key msk in advance. When a civil aviation risk investigation task is initiated (e.g., risk verification for departing passengers of flight CA1234 on May 20, 2024), the system first generates a unique context identifier ctx. This identifier includes fields such as scenario code (civil aviation risk investigation), time slice (20240520-10), airport code (PEK), flight number (CA1234), direction (departure), purpose code (risk verification), and version number, ensuring that this context is strictly bound to the current investigation task. Subsequently, Authorization Center A, based on the master key msk and the context identifier ctx, calculates the context index key k_ctx = KDF(msk, ctx) ∈ using the key derivation function KDF. p Where p is the prime order of the selected elliptic curve group. Next, the authorization center A performs additive partitioning of k_ctx, generating two key shares: a first key share k_ctx1 and a second key share k_ctx2, satisfying k_ctx ≡ k_ctx1 + k_ctx2 mod p. The authorization center A distributes the first key share k_ctx1 to the first cloud server C1 and the second key share k_ctx2 to the second cloud server C2 via a pre-established secure transmission channel (such as a TLS encrypted channel combined with two-way certificate authentication). Simultaneously, the context identifier ctx and related policy parameters are sent to both clouds. At this point, both the first and second servers each hold an incomplete key share uniquely bound to this flight investigation task. No single server can independently complete the complete cryptographic operation, laying the foundation for mandatory authorization that requires subsequent collaboration between the two clouds to complete token generation and intersection calculation.

[0047] In step S102, the provider interacts with each element in the first data set held by the provider based on the context identifier to generate a first tag set, and stores the first tag set in the second server.

[0048] In some embodiments, the provider P (such as a civil aviation regulatory agency or an airline risk control department) holds a set of sensitive risk lists (such as a list of dishonest passengers) for this investigation task, and performs collaborative interaction operations with the two clouds for each risk personnel element in the list based on the generated context identifier (such as ctx bound to flight CA1234).

[0049] Optionally, provider P first performs normalized encoding of each risk individual's identity identifier (such as ID number) and context identifier to ensure that the same individual produces different intermediate results in different contexts. Subsequently, provider P, as a client, engages in three-way interaction with the first and second servers. For example, provider P sends a blinded request to both clouds. The first server uses its first key share to calculate the request and returns the first part of the result, while the second server uses its second key share to calculate the request and returns the second part of the result. Provider P aggregates and deblinds the two parts of the result returned by the two clouds to obtain an irreversible risk token uniquely bound to the current context. Then, it further converts this token into a fixed-length risk tag using a locally held tag mapping key.

[0050] Through the above process, provider P converts each sensitive identity in the original risk list into a risk label strongly bound to flight CA1234, which is irreversible and cannot be associated across scenarios, forming a first label set. After label generation, provider P encodes this first label set into a set structure suitable for efficient querying (e.g., a Cuckoo Hash Table or Bloom Filter) and sends the encoded set structure to the second server for storage via a secure channel, explicitly indicating that the set can only be used for the query task corresponding to the current context identifier. The second server receives and stores the set structure, but because it does not hold the first key share and label mapping key, it cannot deduce the original risk personnel identity from the stored labels; the first server, on the other hand, does not hold the set structure and has no way of knowing any information about the risk list. At this point, the provider's data has been securely deployed on the second server side of the dual-cloud environment, preparing the data for subsequent collaborative intersection calculations.

[0051] In step S103, the query terminal interacts with each element in the second data set it holds based on the context identifier to generate a second tag set, and sends the second tag set to the first server.

[0052] In some embodiments, the query terminal Q (such as an airport security center or joint command center) performs collaborative interaction operations with the dual clouds for each passenger element in the flight passenger list involved in this investigation task (e.g., all check-in passengers on flight CA1234) based on the generated context identifier (the same ctx used by the provider).

[0053] Optionally, the query client Q first performs standardized encoding processing on the identity identifier (such as ID number) and context identifier of each passenger to ensure that the processing results generated by the same passenger on different flights and on different dates are not linked. Subsequently, the query client Q, as a client, conducts a three-way interaction with the first server and the second server. The query client Q sends a request that has been blinded to the two clouds. The first server uses its first key share to calculate the request and returns the first part of the result. The second server uses its second key share to calculate the request and returns the second part of the result. The query client Q aggregates and deblinds the two parts of the result returned by the two clouds to obtain an irreversible passenger token that is uniquely bound to the current context. Then, it further converts the token into a fixed-length passenger tag using the tag mapping key held locally (pre-issued by the authorization center).

[0054] Through the above process, query client Q converts each passenger's identity in the original flight passenger list into a passenger tag strongly bound to flight CA1234, which cannot be reversed or associated across scenarios, forming a second tag set. After tag generation, query client Q pads the second tag set according to the fixed length upper bound specified in the authorization center's ticket. If the number of actual passengers is less than the specified upper bound, a corresponding number of random dummy tags are generated for padding, and corresponding indicator bits are set for each actual tag and dummy tag (actual tag indicator bit is 1, dummy tag indicator bit is 0). Then, all tags and indicator bits are combined into a dual sequence, and finally, a random scrambling operation is applied to this sequence to eliminate positional association information. Query client Q sends the processed second tag set (i.e., the scrambled dual sequence) to the first server through a secure channel, along with the query ticket issued by the authorization center and the element authorization signature corresponding to each actual passenger tag (provided by the authoritative source of the list, M). The first server receives and stores the second tag set, but because it does not hold the first key share and tag mapping key, it cannot deduce the original passenger identity from the received tags. The second server, on the other hand, does not access the second tag set and has no way of knowing the specific query content from the query end. At this point, the query end's data has been securely deployed on the first server side of the dual-cloud environment, preparing the data for subsequent collaborative intersection calculations.

[0055] Step S104: The first server and the second server, based on the first key share, the second key share, the first tag set and the second tag set, collaboratively execute a two-party secure computation protocol to obtain the first computation result share corresponding to the first server and the second computation result share corresponding to the second server.

[0056] In some embodiments, when the first server receives the second tag set (i.e., the scrambled passenger tag dual sequence) sent by the query client and the second server has pre-stored the first tag set generated by the provider (i.e., the hash table structure of the risk tags), the dual clouds enter the core collaborative computing phase. The first server and the second server first independently verify the authorized ticket submitted by the query client to confirm the legality of the query, its validity period, and that the query frequency does not exceed the budget; after verification, the dual clouds start the collaborative computing process based on a preset two-party secure computing protocol. For example, this protocol uses the second tag set held by the first server (containing passenger tags and their true indicator bits) and the first tag set held by the second server (containing the encoded structure of the risk tags) as their respective private inputs, and performs a membership determination on each passenger tag in an encrypted state: determining whether the passenger tag exists in the first tag set.

[0057] The entire calculation process described above is protected by a cryptographic protocol. The first server cannot access the risk tag set held by the second server, nor can the second server know the specific values ​​and true indicator bits of the passenger tags held by the first server. Internally, the protocol uses techniques such as Boolean circuits or secret sharing to multiply the judgment result of each passenger tag with its true indicator bit to obtain the passenger's contribution to the final intersection cardinality (1 if the passenger is a real passenger and hits the risk list, 0 otherwise). All contribution values ​​are then securely accumulated within an encrypted domain. After the calculation is complete, the two-party secure calculation protocol splits and outputs the final intersection cardinality result in the form of additive secret sharing. The first server receives the first share of the calculation result, and the second server receives the second share. Both shares are random numbers, and neither share alone can reconstruct the true intersection cardinality. Only by combining the two shares according to preset rules can the final result be recovered. The first and second servers digitally sign their respective shares of the calculation result for subsequent auditing and verification. At this point, without exposing either party's original data, the two clouds have collaboratively completed the secure calculation of the intersection cardinality and prepared the results in the form of shares, waiting for the query end to retrieve them.

[0058] Step S105: Obtain the first calculation result share and the second calculation result share from the first server and the second server respectively through the query terminal, and reconstruct the intersection cardinality based on the obtained calculation result shares, wherein the intersection cardinality is used to identify the number of passengers on the flight and the risk list that overlap.

[0059] In some embodiments, after the first server and the second server complete collaborative computation, each cloud sends its respective share of the computation result to the query client Q through a secure channel. For example, the first server sends its first share of the computation result along with its digital signature to the query client Q, and the second server sends its second share of the computation result along with its digital signature to the query client Q. After receiving the two shares, the query client Q first verifies the signatures of both clouds to ensure the integrity and authenticity of the result shares. After successful verification, the query client Q reconstructs the first and second computation result shares locally according to a preset addition combination rule.

[0060] Because the two clouds employ an additive secret sharing mechanism when outputting the share, the sum of the two shares is the true intersection cardinality. The query terminal Q, through this reconstruction operation, ultimately obtains the actual number of passengers overlapping between the passenger list and the risk list for this flight. For example, if flight CA1234 has 180 passengers, and the reconstructed intersection cardinality is 3, it means that 3 passengers on this flight are on the risk list. The query terminal Q can then initiate corresponding tiered handling procedures based on this result. For instance, if the cardinality does not exceed a preset threshold, the flight can proceed according to the standard procedure; if it exceeds the threshold, an alarm is triggered, and ground security, the flight crew, and other relevant parties are notified to pay close attention and intervene. After completing the result reconstruction, the query terminal Q hashes the result share signature returned by the two clouds and writes the hash value, along with the context identifier of this query, ticket summary, and other information, into the audit ledger, forming an immutable query log for post-event compliance auditing and traceability. The entire process ensures that the query terminal Q only knows the total number of people in the intersection, but cannot know which specific passengers are on the risk list. The provider also cannot know the passenger list content of the query terminal, thus achieving the business compliance requirement of "only providing the quantity and not the details" in the civil aviation risk investigation scenario.

[0061] In some embodiments, the provider interacts with each element in a first data set held by the provider based on a context identifier to generate a first tag set, including: the provider performing normalized encoding on each element in the first data set, and performing a hash operation on the encoded element and the context identifier to obtain a group mapping value; the provider determining a blinding value based on the group mapping value and a random blinding factor, and sending the blinding value to a first server and a second server respectively; the provider receiving a first part of the evaluation result calculated by the first server based on a first key share held by the provider, and a second part of the evaluation result calculated by the second server based on a second key share held by the provider; and generating a first tag set based on the first part of the evaluation result and the second part of the evaluation result.

[0062] To facilitate an accurate understanding of the technical solution of this application, the relevant symbols and terms used in the specification and claims are uniformly defined and explained below.

[0063] All data processing involved in this application is carried out under a preset security parameter k. The value of k can be set according to actual security requirements. Usually, k≥128 is taken to ensure sufficient cryptographic strength.

[0064] Identity space : Elements in this space Used to uniquely identify various entities in civil aviation business scenarios, including but not limited to passenger identification (such as document number, passenger ID or its hash value) and risk object identification in risk lists. The same entity can use different identification methods in different business scenarios, as long as uniqueness is guaranteed within a specific context.

[0065] Context space C: For each civil aviation risk investigation task, the system generates a unique context identifier ctx∈C, which is used to bind all operations of this investigation to a specific business scenario. The context identifier ctx is defined using a combination of structured fields, as shown in formula (1):

[0066] (1)

[0067] The meanings of the fields in formula (1) are as follows:

[0068] Scenario code: used to distinguish different civil aviation business scenarios, such as civil aviation risk investigation, boarding gate verification, and transit passenger verification;

[0069] Time slice: Used to identify the time range to which the investigation task belongs. It can be in granularity such as year, month, day, hour (YYYYMMDDHH) and supports periodic key rotation.

[0070] Airport or station code, used to identify the physical location where the investigation task takes place;

[0071] Flight number, which may include flight segment information, is used to identify the specific flight corresponding to the investigation task;

[0072] : Inbound and outbound directions, used to distinguish passenger flow;

[0073] Purpose code: Used to specify the purpose of this investigation and prevent data misuse;

[0074] Version number or policy number, used to support key rotation and protocol upgrades.

[0075] The introduction of the context identifier ctx ensures that the processing results generated by the same raw data in different investigation tasks are not linked, effectively blocking cross-scenario trajectory correlation analysis.

[0076] Furthermore, this application involves two types of data holders and their corresponding original data sets:

[0077] The querying party Q (the party initiating the investigation, such as the airport security center) holds the original data set. , A typical example is the passenger list for a flight;

[0078] Provider P (the holder of the risk list, such as a regulatory agency) holds the original data set. , A typical example is a subset of the risk list or watch list related to this investigation.

[0079] Finally, the output target of this application is the intersection cardinality or its derivative, specifically including the following three modes:

[0080] Cardinality c: Directly outputs the number of elements in the intersection of the two sets, i.e. ;

[0081] Threshold flag: Outputs only a boolean value indicating whether the cardinality of the intersection reaches a preset threshold T. ;

[0082] Noise-enhanced basis : Output the cardinality after adding differential privacy noise, i.e. ,in To conform to a specific distribution of random noise, it is used to reduce the risk of privacy leakage in scenarios with a small number of users.

[0083] In this embodiment of the application, a context binding token mapping function can also be defined, as shown in formula (2):

[0084] (2)

[0085] In the function shown in formula (2), the identity identifier is... Mapped to a pseudo-random token uniquely bound to the context identifier ctx .function This is achieved through a dual-cloud segmentation unintentional pseudo-random function protocol. This protocol utilizes the context key shares held by the first and second servers respectively, enabling identity verification through dual-cloud collaboration without exposing the original input. Mapped to irreversible pseudo-random tokens that are not linkable across different contexts. Token length Typically, 128 bits or 256 bits are used to meet security requirements.

[0086] Optionally, the label mapping function can be defined as shown in formula (3):

[0087] (3)

[0088] The tag mapping function will use tokens Further mapping to labels ultimately used for cloud-side aggregation structures In practical implementation, the mapping function Instantiated as a pseudo-random function, its calculation method is as follows: ,in This is a unique tag mapping key derived by the authorization center based on the master key and context identifier. Tag length. It is usually consistent with the token length, taking 128 or 256 bits.

[0089] Optionally, such as Figure 2 As shown, provider P has a specific data set. Under a given context identifier ctx, by processing each element Token mapping and tag mapping are performed sequentially to generate the corresponding tag set. This tag set It will be encoded into a data structure suitable for efficient cloud querying (such as a Cuckoo Hash Table or a Bloom Filter) and stored on a second server for subsequent intersection cardinality calculation.

[0090] Optionally, define a membership determination function. Used to determine whether a given label t belongs to the label set. The abstract definition of this function is shown in formula (4):

[0091] (4)

[0092] In practical implementation, if probabilistic data structures such as Bloom filters or hash tables are used to store and query the tag set, a negligible probability of misjudgment is allowed. This probability of misjudgment can be controlled within an acceptable range by adjusting parameters, without affecting the practicality of the overall solution.

[0093] In some embodiments, this application uses the following standard cryptographic primitives as the foundation for its construction. The specific instantiation method of each primitive can be selected according to actual security requirements. This embodiment is only for illustrative purposes:

[0094] 1. Cyclic group: Choose a prime number as its order. Cyclic group (Using multiplication representation), its generator is This cyclic group satisfies the discrete logarithmic difficulty assumption. In this embodiment, the cyclic group can be implemented using a 256-bit secure elliptic curve group.

[0095] 2. From Hash to Group Function: Defining a Hash Function It is used to map bit strings of arbitrary length to cyclic groups. The elements in.

[0096] 3. Context Hash Function: Define the hash function. This is used to compress input data into a fixed-length hash value, where This is the output length parameter.

[0097] 4. Tag Hash Function: Define the hash function. This is used to map a combination of group elements and context identifiers to a fixed-length token, where For context space, This is the token length parameter.

[0098] 5. Pseudo-random function: Define a pseudo-random function. ,in This is the key length. This specifies the output label length. The output of a pseudo-random function is computationally indistinguishable from a true random number.

[0099] 6. Digital Signature Scheme: A digital signature scheme will be adopted. This scheme satisfies the existence-unforgeability property, meaning that an attacker cannot forge a valid signature for any message without access to the signature oracle.

[0100] 7. Two-Party Secure Computation Protocol: A two-party secure computation protocol that adopts any semi-honest security model. This protocol enables secure computation of Boolean or arithmetic circuits and satisfies the definition of simulation security, namely that the view of any participant can be simulated and generated in polynomial time from its inputs and outputs.

[0101] 8. Two-out-of-two secret sharing scheme: Adopt a secret sharing scheme. This method is used to divide a secret value into two shares, ensuring that the secret cannot be reconstructed from a single share; only by holding both shares simultaneously can the original secret be reconstructed. This scheme can also be used to directly output the result in share form from a two-party secure computation protocol.

[0102] 9. Parameter Selection Recommendation: In this embodiment, the security parameter k is set to 128. A 256-bit security curve group is used for the cyclic group to ensure 128-bit security strength. Token length. and tag length All values ​​are 128 bits. The output calculation ring is an integer ring modulo L. In practical implementation, a 32-bit or 64-bit integer ring natively supported by the computer can be used. To achieve this, the magnitude of the ring modulus L must satisfy the following condition. ,in The upper bound of the fixed length specified in the query request represents the maximum possible value of the intersection cardinality, and Range(Z) is the range of optional differential privacy noise values. This constraint ensures that when performing share modulo addition within the two-party secure computation protocol, the actual cardinality accumulation value and the injected noise value will not be distorted due to modulo overflow.

[0103] In some embodiments, this application implements the generation of context identifier-bound tokens through a dual-cloud segmentation unintentional pseudo-random function protocol. This mechanism is the core of this solution to achieve data privacy protection and cross-scenario unlinkability.

[0104] Optionally, Figure 3 This is a schematic diagram of an optional dual-cloud segmented context token generation process according to an embodiment of this application, such as... Figure 3 As shown, Authorization Center A, as the trusted key management authority, holds the system master key msk. For each context identifier ctx, Authorization Center A performs the following key derivation and splitting operations: First, Authorization Center A generates a context index key based on the master key msk and the context identifier ctx using the key derivation function KDF. Formula (5) can be used as a reference:

[0105] (5)

[0106] in Let G be the integer field modulo a prime number p, where p is the order of the selected cyclic group G.

[0107] Subsequently, Authorization Center A will transfer the context index key. Performing addition splitting yields two key shares, as shown in formula (6):

[0108] (6)

[0109] Among them, the first key share The second key share is distributed to the first server via a secure channel. Distribute to the second server.

[0110] In addition, authorization center A also derives a tag mapping key based on the master key msk and the context identifier ctx. As can be seen from formula (7):

[0111]

[0112] in This indicates a string concatenation operation. The tag mapping key is issued by the authorization center A to the legitimate entities that need to generate tags, including the provider P and the authoritative list source M. If necessary, it can also be issued to controlled components of the querying end Q. The cloud server does not hold this key, ensuring the controllability of tag generation on the client side.

[0113] In some embodiments, for any given input element The client, P or the authoritative source M of the manifest, interacts with the dual cloud servers to perform the following steps to generate a token τ bound to the context identifier ctx. ) and label t( ):

[0114] Step 1: Normalization Encoding and Group Hash Mapping:

[0115] The client first processes the input element Perform normalized encoding to obtain Canon( Normalized encoding ensures that the same entity can be mapped to a unified encoding result across different systems or representations. For example, fields such as document type, document number, and date of birth are combined into a standardized string according to a fixed format. Subsequently, the client concatenates the normalized encoded string with the context identifier ctx and uses a context hash function. Calculate the intermediate value .

[0116] Then, the client hashes the intermediate value m to the group function. Mapping onto the cyclic group G yields the group mapping value. .

[0117] This step injects the context identifier ctx into the hashing process, ensuring that the same original element is used. The generation of completely different group mapping values ​​h under different context identifiers is the basis for achieving cross-scenario unlinkability.

[0118] Step 2: Client-side randomization and blinding:

[0119] To prevent the cloud server from obtaining the original elements in subsequent interactions The true group mapping value h, the client generates a random blinding factor. And calculate the blinding value. .in, .

[0120] Optionally, the client will blind the value. The data is sent to the first server and the second server respectively. Due to the introduction of the blinding factor r, the data received by the dual cloud servers... Since the elements are randomized, the original input cannot be deduced through dictionary attacks or similar methods. Or group mapping value h, thereby protecting input privacy.

[0121] Step 3: Evaluate the double cloud portion:

[0122] Optionally, the first server receives the blinding value. Then, using the first key share it holds The first part of the evaluation result is obtained by performing an exponential operation on the blinded value. .in, .

[0123] The second server received the blinding value. Then, using the second key share it holds The second part of the evaluation result is obtained by performing an exponential operation on the blinded value. .in, .

[0124] The first server and the second server respectively calculate the first part of the evaluation results. The second part of the evaluation results Returned to the client. Due to the context index key. Divided into two key shares, no single cloud server can independently complete the full exponentiation calculation, thus realizing a mandatory authorization mechanism that requires "dual cloud collaboration".

[0125] In some embodiments, generating a first tag set based on the first part of the evaluation result and the second part of the evaluation result includes: multiplying the first part of the evaluation result and the second part of the evaluation result by the provider to obtain an aggregate value, and performing a deblinding operation on the aggregate value using the inverse of the random blinding factor to obtain a deblinded aggregate value; inputting the deblinded aggregate value and the context identifier into a tag hash function by the provider to generate a token bound to the context identifier; inputting the token into a pseudo-random function by the provider to generate a final tag bound to the context identifier; and forming the first tag set by combining the final tags corresponding to all elements.

[0126] Optionally, step 4: Client deblinding and token reconstruction includes:

[0127] The client receives the first part of the evaluation result. The second part of the evaluation results Then, the two are first multiplied and aggregated on the group, as shown in formula (8):

[0128]

[0129] because The aggregation result y is equivalent to the index key with the complete context. The result of exponentially operating on the original group mapping value h raised to the power of r.

[0130] Subsequently, the client uses the random blinding factor r to calculate its modular inverse p. And perform a deblinding operation on the aggregate value y, as shown in formula (9):

[0131] (9)

[0132] The deblinding operation eliminates the influence of the random blinding factor r, restoring the pure, unintentional pseudo-random function evaluation result. The result is h. The value is the result of exponentiation.

[0133] Finally, the client will display the deblinded results. With context identifier ctx input label hash function Generate a token bound to the context identifier. As can be seen from formula (10):

[0134] (10)

[0135] Step 5, final collection label generation, including:

[0136] To accommodate efficient collection storage and retrieval on the second server side, and to execute a secure two-party computation protocol between the first and second servers, the client uses a tag-mapped key. For tokens Further mapping is then performed. Specifically, the client will map the token... Input the pseudo-random function PRF to generate the final labels. As can be seen from formula (11):

[0137] (11)

[0138] The final label This refers to the label mapping function defined earlier. The specific implementation results.

[0139] By repeating steps 1 to 5 above for each element in the first data set held by the provider P, the provider P generates a first tag set S_ctx:={t(y)|y∈Y} bound to the context identifier ctx. Similarly, the querying end Q generates a second tag set by executing the same process.

[0140] It should be noted that, under a fixed context identifier ctx, for the same input element The final labels generated by the above algorithm This is unique and deterministic, ensuring that the query end Q and the provider end P can successfully perform an intersection comparison based on their respective generated tags. Secondly, throughout the process, the two cloud servers only access the intermediate values ​​that have undergone blinding processing and cannot obtain the original elements. Any information; the client-generated token τ( ) and tags All of these are irreversible cryptographic transformations, making it impossible to reverse the process and reconstruct the original element. Finally, for different context identifiers (ctx) (such as different flights or different dates), the same original element... Tags generated by the above algorithm It is computationally independent and uncorrelated, fundamentally blocking cross-scenario trajectory correlation analysis and effectively protecting passenger privacy.

[0141] In one optional embodiment, before obtaining the computation result share pair by the collaborative execution of a two-party secure computation protocol by the first server and the second server based on the first key share, the second key share, the first tag set, and the second tag set, a fixed-length upper bound is obtained through the query terminal, wherein the fixed-length upper bound is greater than or equal to the actual size of the second data set; a target number of dummy tags are generated through the query terminal, wherein the target number is determined by the fixed-length upper bound; the dummy tags are tags that are different from the real tag indicator bits; the real tags and dummy tags are combined into a dual sequence according to their corresponding indicator bits through the query terminal, and the dual sequence is randomly scrambled to obtain a scrambled dual sequence; the scrambled dual sequence is sent to the first server through the query terminal.

[0142] In some embodiments, after generating the second tag set, the query terminal Q (such as an airport security center) first obtains the fixed-length upper bound of this query from the policy information carried in the query ticket issued by the authorization center A. This upper bound is typically preset by regulatory agencies based on business security needs, for example, set to 200, to ensure that the length of the tag sequence input to the cloud remains constant regardless of the actual number of passengers on the flight (assuming there are 180 passengers on flight CA1234). The query endpoint Q detects that the actual number of passengers m=180 is less than the fixed upper bound. After setting the value to 200, the number of dummy elements to be filled is calculated to be 20. Then, 20 dummy tags with the same length as the real tags but with completely random content are randomly generated. These dummy tags are not associated with any real passengers, and their corresponding indicator bits are set to 0 to distinguish them from the indicator bits of the real tags, which are 1.

[0143] Subsequently, the query terminal Q combines 180 real labels (each with an indicator bit of 1) and 20 dummy labels (each with an indicator bit of 0) into a dual sequence W={(t1,d1),(t2,d2)……(t 200 ,d 200 To prevent the cloud server from inferring passenger information through positional analysis of tag sequences, the query client Q generates a random permutation locally. The entire dual sequence W is then rearranged according to this random permutation, shuffling the original order of all real labels and dummy labels, resulting in the scrambled dual sequence. .

[0144] Finally, the query terminal Q transmits the scrambled dual sequence through a pre-established secure transmission channel (such as a TLS encrypted channel). The request is sent to the first server, along with the query ticket and the authorized signature corresponding to the actual passenger. The first server receives the request. Afterwards, only a set of randomly ordered sequences containing a mixture of real and dummy labels can be seen, but it is impossible to distinguish which are real passenger labels and which are filled dummy labels, nor can the actual number of passengers on the flight be inferred from the sequence length. This effectively suppresses large-scale side-channel attacks and location correlation analysis, and provides privacy-enhanced input data for subsequent dual-cloud secure computing.

[0145] In one optional embodiment, a first server and a second server collaboratively execute a two-party secure computation protocol based on a first key share, a second key share, a first tag set, and a second tag set to obtain computation result share pairs. This includes: with the first server using its scrambled dual sequence as input and the second server using the set structure information encoded by the stored first tag set as input, the first server and the second server run the two-party secure computation protocol based on the first key share, the second key share, the first tag set, and the second tag set. The execution of the two-party secure computation protocol includes the following steps:

[0146] Within the protocol, a membership determination function is executed. This function determines whether each queried tag, generated by the querying end and input into the protocol by the first server after scrambling, belongs to the first tag set, thus obtaining a determination result for each queried tag. The determination result for each queried tag is multiplied by its corresponding real indicator bit to obtain the contribution value of that queried tag. Finally, the contribution values ​​of all queried tags are summed in the encrypted domain to obtain the intersection cardinality. The intersection cardinality is output in the form of additive secret sharing, so that the first server obtains the first share of the calculation result and the second server obtains the second share of the calculation result.

[0147] In some embodiments, when the first server receives the scrambled dual sequence sent by the query client... (Contains 200 tag-indicator pairs) and the second server has pre-stored the set structure encoded by the first tag set generated by the provider. (For example, using a cuckoo hash table to store the risk tag set) After that, the two clouds enter the core collaborative computing phase. The first server, with its scrambled dual sequence... As a private input, the second server uses its stored collection structure. As a private input, both parties initiate a collaborative computation process based on a pre-defined two-party secure computation protocol. This protocol, in an encrypted state, ensures... Each tag to be queried in Execute the membership determination function — By locating candidate positions using multiple hash functions of the Cuckoo Hash algorithm, it is determined whether the tag exists in the first tag set, resulting in a judgment of 0 or 1.

[0148] The protocol then compares the judgment result with the actual indicator bit corresponding to the label. (Real passengers are 1, dummy elements are 0) Perform multiplication to obtain the contribution value of each tag to the final intersection cardinality (the contribution value is 1 only if the tag is both a real passenger and hits the risk list, otherwise it is 0); the protocol securely accumulates the contribution values ​​of all 200 tags in an encrypted domain to obtain the intersection cardinality c of this query. To prevent any single cloud server from knowing the cardinality result, the protocol splits and outputs the intersection cardinality c in the form of addition secret sharing—the first server obtains the first calculation result share c1, the second server obtains the second calculation result share c2, and both shares are random numbers that satisfy... No single copy can reconstruct the true cardinality c of the intersection.

[0149] Throughout the calculation process, the first server cannot access the risk tag set held by the second server, and the second server cannot obtain the passenger tags and their indicator information held by the first server. The two parties only completed the secure calculation of the intersection cardinality in an encrypted state through cryptographic protocols, and prepared the results in the form of shares, waiting for the querying end to retrieve them.

[0150] In an optional embodiment, the membership determination function is implemented using a cuckoo hash or Bloom filter structure. The operation of the membership determination function includes: selecting d public hash functions, storing each tag in the first tag set in at least one candidate position of the set structure, where d is an integer greater than or equal to 1; if a stored value equal to the queried tag exists in any of the d candidate positions of each queried tag, the membership determination function outputs 1; if no stored value equal to the queried tag exists in any of the d candidate positions of each queried tag, the membership determination function outputs 0.

[0151] In some embodiments, after receiving the first tag set generated by the provider P, the second server encodes and stores the set using a cuckoo hash structure to achieve efficient membership determination in the two-party secure computation protocol. For example, the second server selects three publicly available hash functions h1, h2, and h3, the definitions and implementations of which are known to all participants in the system (including the querying client Q and the first server). For each risk tag t(y) generated by the provider P, the second server calculates its three hash values ​​h1(t(y)), h2(t(y)), and h3(t(y)) respectively, obtaining three candidate storage locations. Then, using the cuckoo hash's kick-out and replay mechanism, each risk tag is ultimately stored in one of these candidate locations, constructing a hash table containing B buckets. Each bucket either stores a risk label or is empty.

[0152] When the first server and the second server execute the two-party secure computation protocol, for each tag to be queried input by the first server... (Passenger tag from the query endpoint), the protocol first calculates the three hash values ​​h1 of the tag. h2( h3 This yields three candidate location indices; then, the protocol uses the hash held by the second server. The protocol secretly reads the values ​​stored in these three candidate locations; then, in an encrypted state, it compares the values ​​stored in these three locations one by one with... Equal to — if the value stored in any location is equal to If they are equal, then the membership determination function Mem( , Output 1 if the passenger's tag matches the risk list; otherwise, output 1 if the value stored in all three locations matches the risk list. If the values ​​are not equal (or both are empty), output 0, indicating a miss.

[0153] Using this cuckoo hash structure, membership determination can be completed in constant time. Furthermore, the entire comparison process is protected by encryption using a secure computation protocol between the two parties. The first server cannot access the risk tag content stored in the hash table, and the second server cannot access the passenger tag being queried. The specific value enables efficient membership determination while protecting privacy.

[0154] In one optional embodiment, before obtaining the first key share and the second key share bound to the context identifier from the authorization center through the first server and the second server respectively, the authorization center's server generates a context identifier based on the current query task code, time slice, flight number, and airport code; the authorization center's server generates a context index key based on the master key and the context identifier through a key derivation function; the authorization center's server performs addition and splitting on the context index key to obtain the first key share and the second key share; the authorization center's server distributes the first key share to the first server and the second key share to the second server; the authorization center's server generates a tag mapping key based on the master key and the context identifier, and distributes the tag mapping key to the controlled components of the provider and query ends.

[0155] In some embodiments, when a civil aviation risk investigation task is initiated, such as for risk verification of passengers departing from Beijing Capital International Airport on flight CA1234 at 10:00 AM on May 20, 2024, the authorization center's server first generates a unique context identifier based on the task information of this investigation. This context identifier is defined using a combination of structured fields, specifically including a scenario code (set to "civil aviation risk investigation"), a time slice (set to "2024052010", representing 10:00 AM on May 20, 2024), an airport code (set to "PEK"), a flight number (set to "CA1234"), arrival / departure direction (set to "departure"), a purpose code (set to "risk verification"), and a version number (set to "v1.0"). This ensures that the identifier is strictly bound to the current investigation task, and any change in any field will result in the generation of a completely different context identifier.

[0156] The authorization center's server, based on its internally securely stored master key and the newly generated context identifier, calls a key derivation function to calculate a context index key bound to that context. This key will play a crucial role in subsequent token generation. To prevent any single cloud server from gaining complete key control, the authorization center's server performs additive splitting of the context index key, resulting in two key shares—a first key share and a second key share. The first key share is then distributed to the first server via a pre-established secure transmission channel (such as a TLS encrypted channel based on two-way certificate authentication), and the second key share is distributed to the second server. Simultaneously, the authorization center's server also derives a tag mapping key based on the same master key and context identifier. This key is specifically used to further map the token to the final tag. The authorization center distributes this tag mapping key through a separate secure channel to controlled components on both the providing and querying sides for subsequent local tag generation operations.

[0157] At this point, all participating parties have obtained the key materials required to execute this collaborative investigation task: the first server holds an incomplete first key share, the second server holds an incomplete second key share, and the provider and querying parties hold complete tag mapping keys, laying a secure foundation for subsequent token generation, tag calculation, and dual-cloud collaboration.

[0158] In one optional embodiment, a digital signature ticket including mandatory policy constraints is generated by the server of the authorization center. The mandatory policy includes at least pre-set constraints on the minimum data size of the query set, the maximum query frequency, and the output mode. The digital signature ticket is sent concurrently with the second tag set sent to the first server via the query terminal. The first server performs a signature verification operation on the digital signature ticket, which includes verifying whether the digital signature ticket is valid, whether the input length of the query digital signature ticket is equal to the upper bound of a fixed length, and whether the query frequency of the digital signature ticket exceeds the maximum query frequency. If the digital signature ticket fails the verification operation, both the first and second servers refuse to execute the two-party secure computation protocol.

[0159] In some embodiments, before initiating the civil aviation risk investigation task, the query terminal Q first applies for legitimate query permissions from the authorization center A. After verifying the identity of the query terminal Q and its query requirements, the authorization center A generates a digital signature ticket containing mandatory policy constraints. This ticket is encoded in a structured format, where the mandatory policy includes at least three core constraints, such as: the minimum query set size is set to 50, requiring the query terminal Q to submit no fewer than 50 real passenger tags to prevent the construction of a minimal set to probe whether a specific person has hit the risk list; the maximum query frequency is set to 10 times / hour, limiting the number of queries per hour under a specified context identifier to no more than 10, to suppress high-frequency adaptive query attacks; and the output mode constraint is set to "cardinality output," limiting this query to only obtaining the intersection cardinality and disallowing the acquisition of other sensitive information.

[0160] Authorization center A uses its private key to digitally sign the ticket, generating a complete signed ticket TKT, and sends it to query client Q through a secure channel. When query client Q sends the second tag set to the first server, it sends the digitally signed ticket as an attachment; simultaneously, query client Q also needs to inform the second server of the relevant ticket information. Upon receiving the query request, the first server first uses authorization center A's public key to verify the ticket's authenticity and integrity. After successful verification, the first server further checks whether the ticket is within its validity period (e.g., whether the current time exceeds the expiration time recorded on the ticket), verifies whether the length of the second tag set submitted by query client Q is strictly equal to the fixed upper limit of 200 specified in the ticket, and queries the locally maintained frequency counter to confirm whether the number of queries by query client Q in the current context has reached the 10-time limit. The first server synchronizes the verification results and all check results to the second server, and the two clouds jointly confirm the ticket's legality.

[0161] If the ticket verification fails, expires, the input length is incorrect, or the frequency budget is exceeded, both the first and second servers immediately terminate the query process, refuse to execute the subsequent two-party secure computation protocol, and return the corresponding error message to the query client Q. Only if all checks pass will the two clouds continue to execute the core intersection cardinality calculation. Through this ticket-based authorization mechanism, the system enforces the principle of least privilege and access control policies at the protocol level, effectively suppressing malicious probing and abuse.

[0162] In one optional embodiment, the query client submits a second data set to an authoritative list source, wherein the authoritative list source is a civil aviation departure system or a passenger reservation record system; the authoritative list source verifies the authenticity of each element in the second data set submitted by the query client, and for elements that pass verification, the authoritative list source generates a first digital signature for the element based on a context identifier using a private key; when the query client sends the second tag set to the first server, the first digital signatures of the elements verified by the authoritative list source are also sent to the first server.

[0163] In some embodiments, before generating the second tag set for flight CA1234, the query terminal Q (such as the airport security center) first submits the original passenger list to the authoritative source M for authenticity verification. This authoritative source is specifically implemented as the civil aviation departure system or passenger reservation record system, which possesses first-hand authoritative data on passenger check-in and ticket purchase. After receiving the passenger list submitted by the query terminal Q, the authoritative source M verifies the authenticity of each passenger on the list—for example, verifying whether the passenger has indeed purchased a ticket for this flight, whether they have completed check-in, and whether their identity information matches the reservation record.

[0164] For each verified genuine passenger, the authoritative source M of the list uses its private key to generate a unique element-based authorization signature for that passenger based on the context identifier of the current investigation task (such as fields including flight number CA1234, date 20240520, airport PEK, etc.). This signature is essentially a cryptographic endorsement of the fact that "this passenger is indeed a genuine passenger on this flight." For example, for passenger Zhang San, the authoritative source M calculates... = (ctx || t(Zhang San) || meta), where meta can include optional audit fields such as seat number and check-in time. For individuals whose verification fails (e.g., those who have not purchased tickets, have already refunded their tickets, or whose identity information does not match), the authoritative source M of the list will not generate any signature.

[0165] After generating the second tag set, the query client Q sends data to the first server, including not only the scrambled dual sequence π(W) but also the authorization signatures of all verified genuine passengers, associating these signatures with their corresponding tags. Upon receiving the query request, the first server, before entering dual-cloud collaborative computing, first performs a signature verification operation on each tag with an accompanying signature—using the public key of the authoritative source M to verify the validity of the signature σ, confirming that the tag indeed originates from a genuine passenger authenticated by the authoritative source.

[0166] For tags that pass verification, the first server retains their true indicator bit as 1; for tags that fail verification (including dummy tags without a signature and tags that fail verification despite having a signature), the first server forcibly sets their indicator bit to 0, treating them as invalid input. Through this element-authorized signature mechanism, the system cryptographically ensures that the input of the query terminal Q must originate from a genuine flight passenger list, effectively preventing attackers from abusing the system by maliciously constructing specific sets of people for targeted probing.

[0167] In one optional embodiment, the superior regulatory authority of the provider generates a second digital signature for each tag in the first tag set; the provider submits the second digital signature corresponding to each tag in the first tag set to the second server while updating the first tag set; wherein the second server verifies each received second digital signature and stores and indexes the tags corresponding to the successfully verified second digital signatures.

[0168] In some embodiments, before converting its risk list into the first tag set, the provider (such as a civil aviation regulatory agency or an airline's risk control department) first submits the original risk list and its converted tags to a higher-level regulatory agency for authorization and review. The higher-level regulatory agency, as the authoritative source of the risk list, verifies the authenticity of each risk tag—confirming that the person is indeed included in a legally valid risk list, that the list type is accurate (e.g., terrorism-related, instability-related, dishonest travel, or public health risks), and that it is relevant to the current investigation scenario.

[0169] For each verified risk label, the higher-level regulatory agency uses its private key to generate a unique second digital signature, which is a cryptographic authentication of the fact that "the label belongs to a legitimate risk individual." For example, for the label t (Li Si) corresponding to risk individual Li Si, the higher-level regulatory agency calculates... = (ctx || t(Li Si)), where ctx is the context identifier of the current investigation task. When the provider P updates the first tag set to the second server, it not only sends the risk tag itself, but also sends the second digital signature corresponding to each risk tag, forming a "tag-signature" pair.

[0170] Upon receiving an update request, the second server first verifies each received second digital signature—using the public key of the higher-level regulatory body to verify the authenticity and integrity of the signature, confirming that the risk label has indeed been authorized by an authoritative institution. For labels that successfully verify, the second server adds them to the first label set and constructs a corresponding hash index structure (such as a cuckoo hash table) to support efficient subsequent queries; for labels that fail verification, the second server refuses to store them and logs the anomaly for audit traceability. Through this mechanism, the system cryptographically ensures that all risk labels stored in the cloud are legitimately authorized, preventing potential attacks that could maliciously inject false risk data or tamper with the existing list, while providing irrefutable audit credentials for updating the risk list.

[0171] In one optional embodiment, a minimum query set size is set for digitally signed tickets issued by the authorization center; when constructing the tag input sequence through the query terminal, the number of real tags in the tag input sequence is controlled to be no less than the minimum query set size; if the actual size of the second data set held by the query terminal is less than the minimum query set size, the query terminal expands the second data set with real tags by adding additional virtual elements that do not belong to any real flights, so that the number of real tags in the second data set reaches the minimum query set size.

[0172] In some embodiments, when issuing digitally signed tickets, the authorization center A sets a minimum query set size according to the security policy of civil aviation risk investigation, for example, setting the threshold to 50. The purpose of this setting is to prevent malicious querying parties from circumventing the "only output cardinality" privacy protection mechanism by constructing extremely small query sets (such as those containing only one or a few specific person tags) to probe whether they have hit the risk list.

[0173] Before constructing the tag input sequence for this query, query terminal Q first parses the minimum query set size constraint from the authorized ticket and counts the actual number of passengers in its second data set (i.e., the flight passenger list). Assuming the actual number of passengers on flight CA1234 is 38, which is less than the specified minimum query set size of 50, query terminal Q needs to perform a virtual element expansion operation—generating 12 additional virtual passenger tags that do not belong to any real flights, and generating corresponding element authorization signatures for these virtual tags (the authoritative source M of the list can issue a special signature for these virtual elements, or use other methods to mark them as expansion elements). Query terminal Q merges these 12 virtual tags with the 38 real tags, ensuring that the total number of real tags participating in subsequent calculations reaches 50. In subsequent dual-cloud security calculations, these virtual tags, because their indicator bit is still 1 (participating in the counting as real tags), but the corresponding passengers do not actually exist, will not hit any risk lists and have no actual impact on the final intersection cardinality.

[0174] Through this mandatory constraint mechanism, the system effectively suppresses the risk of attackers making member inferences through small set probing. Even if the actual number of passengers in query terminal Q is small, the input size must be expanded to above the safety threshold, thereby ensuring the privacy protection effect at the protocol level.

[0175] In one optional embodiment, a first server digitally signs the first calculation result share to generate a first result signature, and sends the first calculation result share and the first result signature to the query end; a second server digitally signs the second calculation result share to generate a second result signature, and sends the second calculation result share and the second result signature to the query end; the query end verifies the validity of the first result signature and the second result signature, and after successful verification, the intersection cardinality is obtained by performing a modulo operation on the first calculation result share and the second calculation result share.

[0176] In some embodiments, after the first server and the second server complete the secure computation protocol and obtain the first computation result share c1 and the second computation result share c2 respectively, each cloud digitally signs its own share to ensure the integrity and authenticity of the result. Specifically, the first server uses its private key to generate a first result signature Res1 for the first computation result share c1 along with associated data such as the current context identifier and policy information, and sends c1 and Res1 to the query client Q through a secure channel; at the same time, the second server uses its private key to generate a second result signature Res2 for the second computation result share c2, and sends c2 and Res2 to the query client Q. After receiving the two result shares and their signatures, the query client Q first uses the first server's public key to verify the validity of the first result signature Res1, confirming that the first computation result share c1 has not been tampered with during transmission and indeed originated from the first server; then it uses the second server's public key to verify the validity of the second result signature Res2, confirming the integrity and authenticity of the second computation result share c2.

[0177] After both signatures are verified, the query terminal Q performs an addition operation locally on the first calculated result share c1 and the second calculated result share c2. Because the two clouds use an addition secret sharing mechanism when outputting shares, the sum of the two shares is the true intersection cardinality c. Through this reconstruction operation, the query terminal Q ultimately obtains the actual number of passengers overlapping between the passenger list and the risk list for this flight. For example, calculating c=3 indicates that 3 passengers on this flight are on the risk list. After completing the result reconstruction, the query terminal Q hashes the result share signature returned by the two clouds and writes the hash value, along with the context identifier of this query, ticket summary, and other information, into the audit ledger, forming an immutable query log for post-event compliance auditing and traceability. Through this mechanism, the query terminal Q can verify the authenticity and completeness of the obtained result shares, and the two clouds cannot deny their output calculation results, achieving verifiable and auditable secure delivery of calculation results.

[0178] In one optional embodiment, in response to a change event in the second data set, the query terminal identifies the set of changed elements corresponding to the change event, wherein the change event includes an add operation, a delete operation, and a replace operation; for each element corresponding to the add operation, the query terminal re-executes the tag generation process to obtain the tag of the add element and the corresponding element authorization signature; for each element corresponding to the delete operation, the query terminal calculates the hash value of the token corresponding to the element as a delete pointer; for each element corresponding to the replace operation, the query terminal constructs an update instruction containing the replace operation type and the corresponding data item, and sends the update instruction to the first server; wherein, according to the received update instruction, the first server executes the corresponding element replacement operation on the locally stored sequence structure, while keeping the unchanged data unchanged.

[0179] In some embodiments, during the operation of civil aviation services, the flight passenger list changes frequently due to passenger check-in, ticket refunds, and rebooking. The query terminal Q needs to respond to these changes in real time to ensure the accuracy of risk verification. When the second data set changes, the query terminal Q first identifies the change type and the corresponding set of changed elements: for new operations, such as a passenger checking in and joining the flight 2 hours before departure, the query terminal Q re-executes the complete tag generation process for the new passenger.

[0180] Optionally, a token and tag for the passenger are generated through dual-cloud segmentation VOPRF protocol interaction, and the corresponding element authorization signature is obtained from the authoritative source M of the list to form a complete new data item. For deletion operations, such as a passenger canceling a trip by refunding a ticket, the query terminal Q does not need to retain the passenger's complete tag information. It only calculates the hash value of the token as a lightweight deletion pointer to uniquely identify the element to be deleted. For replacement operations, such as a passenger changing their ID number and checking in again, the query terminal Q recognizes it as a combination operation of first deleting the original record and then adding a new record. The query terminal Q encapsulates the identified changes into structured update instructions according to the operation type (Add, Del, Rep) and the corresponding data item, and sends them to the first server through a secure channel. After receiving the update instructions, the first server parses the operation type and data content: for the addition instruction, a new tag-indicator pair is inserted into the locally stored dual sequence and the indicator bit is kept at 1; for the deletion instruction, the corresponding element is located and removed according to the deletion pointer; for the replacement instruction, the deletion and addition operation is executed atomically.

[0181] Throughout the update process, the first server only processes the elements that have changed; passenger tags and their indicator bits that have not been changed remain unchanged. The update complexity increases linearly only with the number of changed elements. Through this differential update mechanism, the query client Q can achieve millisecond-level response in scenarios with high-frequency changes to the passenger list, without having to recalculate all passenger tags for every change. This significantly reduces computational and communication overhead, providing technical support for the efficient operation of civil aviation services.

[0182] In one optional embodiment, when the provider performs batch updates on the first data set, the provider packages multiple update instructions into update capsules, wherein the update capsule includes multiple operation types and corresponding tag data; the provider digitally signs the update capsule and sends the signed update capsule to the second server; the second server verifies the signature of the update capsule, and after successful verification, updates the tag information in the first tag set sequentially according to the order of the instructions in the update capsule; after the second server completes the update of the first tag set, it sends an update completion notification to the first server, along with a summary of the updated first tag set; the first server records the summary information for consistency verification during subsequent queries.

[0183] Optionally, when the risk list of the provider (such as a civil aviation regulatory agency) undergoes a large-scale update, such as adding a new batch of passengers whose expired records have been removed, the provider packages multiple change operations into a structured "update capsule" for batch processing. For example, the provider identifies all the change elements involved in this batch update, generates corresponding operation type (Add for addition, Del for deletion, Rep for replacement) and tag data for each change element, and assembles these operation instructions into the data payload of the update capsule in the order of execution. To prevent the update capsule from being tampered with or forged during transmission, the provider uses its private key to digitally sign the entire update capsule, ensuring the integrity and authenticity of the capsule's origin.

[0184] After signing, provider P sends the signed update capsule to the second server via a secure channel. Upon receiving the update capsule, the second server first verifies the validity of the signature using provider P's public key, confirming that the capsule indeed originates from a legitimate provider and its content has not been tampered with. After successful verification, the second server executes the update operations sequentially according to the order of the instructions in the capsule: for addition instructions, a new risk label is inserted into the hash table and an index is built; for deletion instructions, the corresponding entry is located and removed based on the label; for replacement instructions, an atomic deletion followed by addition operation is performed.

[0185] After all updates are completed, the second server calculates the cryptographic digest (such as a hash value) of the updated first tag set and sends this digest, along with an update completion notification, to the first server. Upon receiving the notification, the first server stores the updated digest locally for consistency verification during subsequent queries. Before each execution of the two-party secure computation protocol, the first server can request the second server to provide the digest of the current first tag set for comparison, ensuring that the data versions used by both clouds are consistent during computation and preventing errors in computation results due to data asynchrony. Through this batch update capsule mechanism, the provider (P) can efficiently and securely maintain the real-time nature of the risk list while ensuring data consistency between the two clouds, providing a fundamental guarantee for the accuracy and reliability of civil aviation risk investigation.

[0186] In an alternative embodiment, the method further includes a step of ensuring cross-scenario unlinkability:

[0187] The authorization center's server generates different context index keys and tag mapping keys for different context identifiers; for the same original element, different tokens are generated under different context identifiers through a segmented unintentional pseudo-random function protocol, and the tokens are computationally unlinkable; different tags obtained through pseudo-random function mapping are computationally unlinkable; the cloud cannot associate tags under different contexts with the same original element, blocking cross-flight and cross-scenario trajectory association analysis.

[0188] In an optional embodiment, the method further includes a query frequency budget control step:

[0189] The authorization center sets a query frequency budget under a specified context identifier and query client identity in the issued digital signature ticket; the first server and the second server maintain local counters to record the number of queries executed under the specified context identifier and query client identity; before each execution of the two-party secure computation protocol, the first server and the second server check whether their local counters have reached the upper limit of the query frequency budget; if the local counter of either server has reached the upper limit of the query frequency budget, the query is rejected and an over-budget error is returned to the query client; after the query is successfully executed, the first server and the second server increment their local counters by 1.

[0190] In an optional embodiment, the method further includes a step of verifying the output results:

[0191] The first server adds a zero-knowledge proof to its output of the first computational result share, proving that the first computational result share was correctly calculated based on its input π(W) and the two-party secure computation protocol; the second server adds a zero-knowledge proof to its output of the second computational result share, proving that the second computational result share was correctly calculated based on its input... The zero-knowledge proof is correctly calculated using the secure computation protocol between the two parties; the query end verifies the validity of the zero-knowledge proof to ensure that the server has not maliciously tampered with the calculation result; the query end writes the verified zero-knowledge proof and the result share into the audit ledger.

[0192] In some embodiments, to enforce the principle of least privilege at the protocol level and effectively suppress probe abuse attacks, this application introduces a cryptographic ticket mechanism issued by the authorization center A. Before initiating core computation, the query client Q must apply for and obtain a valid ticket from the authorization center A. This ticket serves as proof of the legitimacy of the query request and participates in all subsequent protocol interactions.

[0193] in, Figure 4 This is a schematic diagram of an anti-probe abuse mechanism based on ticket authorization and element signature according to an embodiment of this application, such as... Figure 4 As shown, for each legitimate investigation task, the authorization center A uses its private key to generate a digitally signed ticket containing mandatory policy constraints, the data structure of which is shown in formula (12):

[0194] (12)

[0195] The meaning and function of each field are as follows:

[0196] ctx: The unique context identifier for the current investigation task, ensuring that the ticket is strongly bound to a specific flight and scenario, and preventing the ticket from being abused across scenarios;

[0197] , The identity identifiers of the party initiating the investigation (query end) and the data provider (provider end) are used to establish the boundaries of data flow and ensure that only authorized parties can participate in this investigation.

[0198] The expiration timestamp and random number of the ticket, through strict lifecycle management and random number mechanism, effectively prevent malicious nodes from carrying out replay attacks;

[0199] policy: A set of mandatory policy constraints, which must include at least the following policy parameters:

[0200] The minimum query set size mandates that the number of real passenger tags submitted by the query client Q must not be less than this threshold, fundamentally preventing attackers from abusing their power to precisely detect whether a specific individual is on the risk list by constructing "small sets" or "single-element sets."

[0201] The fixed upper bound requires the query terminal Q to strictly pad the input set to this length using dummy labels. This eliminates the set size side channel, making it impossible for the dual cloud to infer the actual load factor or other business attributes of the flight from the length of the input data.

[0202] budget: The number of queries or frequency budget allowed under the specified query terminal Q and context identifier ctx. It limits the maximum number of queries for a specific query terminal under a specific context, effectively suppressing the risk of attackers attempting to differentially infer the status of target personnel through high-frequency, fine-tuning adaptive iterative queries of set elements.

[0203] ∈ {card, flag, noisy}: Output mode constraint, which strictly limits the granularity of the final result returned by the cloud. Depending on the business sensitivity, it can be limited to a precise cardinality, a thresholded Boolean flag, or a fuzzy cardinality with added differential privacy noise.

[0204] T: When the output mode is thresholding, this parameter is used to set the alarm threshold;

[0205] ε: When the output mode is noisy cardinality, this set of parameters is used to set the privacy budget and noise distribution type for differential privacy;

[0206] Log levels and auditing strategies specify the requirements for each query to be recorded in the audit ledger, ensuring that there is non-repudiable compliance traceability capability afterward.

[0207] Before the secure computation protocol between the two parties is executed, the first and second servers, acting as the policy execution engines, independently perform public key verification and validity checks on the digitally signed ticket TKT. The dual cloud servers will check whether the length of the input set sent by the query client Q is strictly equal to the upper bound of the fixed length. Simultaneously, it independently maintains and verifies whether the local frequency counter exceeds the budget. Once it detects forged, expired, incorrectly lengthed, or frequency-exceeding tickets, the dual-cloud system will directly block the computing process and reject the unauthorized or overclocking request.

[0208] In some embodiments, a simple ticket authorization mechanism can only limit the scale and frequency of queries. To further constrain the input set of the query terminal Q to strictly come from a genuine flight passenger list, rather than a set of specific target personnel maliciously spliced ​​or forged by attackers, this application introduces an element authorization signature mechanism. The legitimacy of passengers is endorsed by an authoritative list source M, independent of the query terminal Q and the dual cloud servers. This authoritative list source is specifically implemented as a civil aviation departure system or a passenger reservation record system.

[0209] Optionally, after verifying the passenger's genuine ticket purchase and check-in status, the authoritative source M uses its private key to generate a digital signature for the passenger's cryptographic tag under the current context identifier ctx, as shown in formula (13):

[0210]

[0211] The meanings and functions of each field in formula (13) are as follows:

[0212] ctx: Context identifier, used to bind the uniqueness of this assistance task, to prevent attackers from intercepting a passenger's legitimate signature on flight A and replaying it in the query for flight B;

[0213] The cryptographic tag generated after the passenger's identity is tokenized and tagged is the authoritative source M of the list. M only signs the tag form and does not need to know the specific risk comparison logic, which conforms to the principle of least knowledge.

[0214] Optional audit field, which can include auditable information such as flight number, seat number, and passenger type, to enhance the contextual relevance and post-event traceability of signatures.

[0215] Before entering the core two-party secure computation protocol, the first server will perform a one-by-one verification on each tag in the input set: for each input tag t, the first server verifies the signature. Whether the verification passes or fails. Elements that fail the signature verification will be treated as dummy elements, and their indicator bits will be forcibly set to 0, thereby suppressing malicious probing behavior by constructing sets at the protocol level.

[0216] This signature mechanism is symmetrically scalable. For provider P, the risk list elements it holds can also utilize a similar authorized signature system: the risk labels are assigned by provider P's superior regulatory body or internal risk control authority. The signature is issued. This signature can be directly anchored to the update credentials in the cloud-based collection structure, used to verify the legality of risk list update operations, thereby ensuring the purity and auditability of two-way data.

[0217] In some embodiments, to avoid any single cloud server obtaining the intersection cardinality c or the thresholding result independently. This protocol is executed by a first server and a second server under the security assumptions of semi-honesty and no collusion, and satisfies the following security requirements, wherein, Figure 5 This is a flowchart illustrating the execution of a 2PC-based MPCCount share output protocol according to an embodiment of this application, as follows: Figure 5 As shown:

[0218] No single cloud server can obtain a single-element membership result. ;

[0219] No single cloud server obtains the intersection cardinality c or the thresholding result flag;

[0220] The query terminal Q only obtains the final output, which can be the exact cardinality c, the thresholded result flag, or the cardinality with added noise. .

[0221] In some embodiments, a token mapping function is set. Tag mapping function ( ).

[0222] The provider P holds the first set of data for each context identifier ctx. Execute the following formula (14):

[0223] (14)

[0224] The first set of tags generated by the provider P Encoding is a set structure that enables efficient membership determination in two-party secure computation protocols. To facilitate membership testing in two-party secure computation, this embodiment will... Instantiate as a Cuckoo Hash Table or its equivalent array representation, as follows:

[0225] Select d public hash functions , where B is the number of hash table buckets;

[0226] Construct a hash table The cuckoo hashing algorithm is used to place each tag. Stored in a candidate location middle.

[0227] This application establishes the following storage division of labor: Second server Holding hash table Or its encrypted sharing form; First server Do not hold Any information.

[0228] In some embodiments, the query terminal Q holds a second data set. And execute formula (15):

[0229] (15)

[0230] To suppress large-scale side-channel attacks and location correlation analysis, the query endpoint Q follows a fixed-length upper bound as specified in the policy. The specific steps for constructing the extended sequence are as follows:

[0231] generate Random dummy labels The probability of these dummy tags colliding with real tags is negligible;

[0232] Define indicator bit For real label settings For dummy tag settings ;

[0233] Construction length is dual sequences ;

[0234] By the first server or query client Q Apply random scrambling π to obtain the scrambled dual sequence π(W).

[0235] The authorization verification process is as follows:

[0236] The query client Q sends the following to the first server: the scrambled dual sequence π(W) and the element authorization signature corresponding to each real label. And TKT digital signature tickets;

[0237] First Server Verify the authorization signature of each element Is it valid, and verify the digital signature ticket? Is it legal?

[0238] The query client Q sends a request to the second server. Sending: Context identifier (ctx), digitally signed ticket (TKT), and set commitment So that a second server Independently verify the validity of the ticket without exposing any label information;

[0239] For elements that fail signature verification, the first server Force its indicator bit to 0 and treat it as a dummy.

[0240] Define ideal function As in formula (16):

[0241] (16)

[0242] The membership determination function Mem is defined by formula (17):

[0243]

[0244] This function specifies that the output is in the form of an additive secret shared share:

[0245] Select computation ring ,in satisfy This ensures that the calculation results do not overflow;

[0246] Output to the first server Second server The ones are respectively , ,satisfy ;

[0247] The two cloud servers then send their respective shares to the query client Q, which reconstructs the intersection cardinality c.

[0248] It should be noted that this function can be implemented by any two-party secure computation protocol that satisfies the semi-honest security model. Implementations can be achieved, for example, through obfuscated circuit protocols based on unintentional transmission extensions or two-party computation protocols based on secret sharing. This application does not limit the specific instantiation method of the two-party secure computation protocol, but only requires that it satisfy the simulated security definition: for any corrupted single cloud server, there exists a probabilistic multinomial-time simulator that can simulate the generation of interactive transcriptions indistinguishable from its actual execution view computation using only the input and output shares of that cloud.

[0249] In some embodiments, the first server The private input includes: the scrambled dual sequence Second server The private input includes: hash table Or a two-party secure computation representation of its equivalent set structure.

[0250] Two-party secure computation execution includes: the first server Second server Running a two-party secure computation protocol To achieve the desired function and obtain the output share .

[0251] In some embodiments, the first server Send the first calculated share to query client Q and its digital signature ;

[0252] Second server Send the second calculated result share to query terminal Q and its digital signature ;

[0253] Query-side Q reconstructs the intersection cardinality: ;

[0254] The query client Q will and hash value Write it to the audit log for later audit traceability.

[0255] The key security feature of this protocol is that the second server does not directly obtain the intersection cardinality c, and the first server does not directly obtain c either. Any single cloud server only holds the output share and the interactive transcription of the two parties' secure computation protocol, and cannot independently reconstruct the final result.

[0256] In some embodiments, this application provides at least two optional output modes: thresholding and differential privacy noise addition.

[0257] (a) Thresholding output mode:

[0258] Define thresholding results This application supports two implementation methods:

[0259] Method A1: Direct computation within the two-party secure computation protocol and output bit share , ,satisfy The two cloud servers each send their share to the query client Q, which then reconstructs the data using an XOR operation. ;

[0260] Method A2: After the intersection cardinality c is obtained through reconstruction by the query terminal Q, the local calculation is performed. .

[0261] (ii) Noise-increasing output mode:

[0262] If the strategy requires the output noise floor number To reduce the risk of privacy leakage in scenarios with small data sets, where Z represents random noise following a Laplace distribution or a discrete Laplace distribution, this application employs the following share-level noise addition mechanism: the noise Z is sampled by the authorization center A, and the noise shares are secretly shared by adding the samples together. and ,satisfy Authorization Center A will Send to the first server, Send to the second server. The two cloud servers respectively calculate the following formula (18):

[0263] (18)

[0264] The calculation result is sent to the query terminal Q, which then reconstructs the noisy cardinality. During this process, no single cloud server is aware of the original intersection cardinality c, the noise Z, or the final output noisy cardinality. .

[0265] In some embodiments, this application defines update operation types to address the frequent changes to passenger lists and risk lists in civil aviation operations. and incremental set And a differential update capsule mechanism was designed, in which, Figure 6 This is a logic block diagram of an optional differential update mechanism according to an embodiment of this application, such as... Figure 6 As shown, the update process on the query side is as follows:

[0266] When the second data set X held by query client Q changes, query client Q performs the following operations:

[0267] For each element corresponding to the new operation The query endpoint Q re-executes the tokenization process to generate a token for the element under the current context identifier ctx. And the tag t(x), and obtain the corresponding element authorization signature from the authoritative source M of the manifest. ;

[0268] For each element corresponding to the deletion operation The query terminal Q calculates the hash value of the element's token. As a lightweight delete pointer;

[0269] The query client Q encapsulates the identified changes into structured update instructions according to operation type and data item, and sends them to the first server through a secure channel;

[0270] After receiving the update instruction, the first server performs the corresponding add, delete or replace operations on the locally stored dual sequence structure, keeping the unchanged data unchanged, and generates a new dual sequence W based on the updated data in subsequent queries.

[0271] The update process provided on the client side is as follows:

[0272] When the first data set Y held by provider P changes, provider P performs the following operations:

[0273] For each element y∈ corresponding to the new operation The client P re-executes the tokenization process to generate the tag for the element under the current context identifier ctx. ;

[0274] For each element y∈ corresponding to the deletion operation Provides the terminal P to extract the tag of the element. As a deletion marker;

[0275] The provider P sends the update command to the second server;

[0276] After receiving the update instruction, the second server updates its first tag set structure in its storage. Perform the corresponding add, delete, or replace operations.

[0277] The overall complexity of the above update mechanism is: It is only linearly related to the number of changed elements, eliminating the need to recalculate all data, which significantly reduces maintenance costs in high-frequency change scenarios in civil aviation.

[0278] It should be noted that, assuming the identity space is U, under a fixed context identifier ctx, the query client Q and the provider P each hold the original data set X. U and Y U.

[0279] Define token mapping function Used to identify Mapped to an irreversible token bound to the context;

[0280] Define label mapping function This is used to map tokens to tags that are ultimately used for set comparison;

[0281] Define composite mapping This refers to the complete transformation process from the original identity identifier to the final label.

[0282] It should also be noted that provider P maps its first data set Y to a first tag set. and will Encode into a data structure that enables membership determination in a two-party secure computation protocol. Define a membership determination function. as follows:

[0283]

[0284] If a probabilistic data structure such as a Bloom filter or hash table is used, a negligible probability of false positives is allowed, which can be controlled within an acceptable range by adjusting parameters.

[0285] Additionally, the query client Q holds a second set of data. Calculate the label sequence And in accordance with the strategy, the length is padded to the upper limit of the fixed length. Construct dual sequences ,in:

[0286] For real elements : , ;

[0287] For dummy elements: , .

[0288] The query terminal Q applies a random scramble π to W to obtain π(W). Since the scrambling operation does not change the summation result, the subsequent counting process does not depend on the order of the elements.

[0289] Optionally, a counting function as shown in formula (19) can be implemented within the two-party secure computing protocol executed by the two cloud servers:

[0290] (19)

[0291] Since all dummy elements satisfy d=0, the contribution of dummy elements to the counting result is always 0, so we can obtain formula (20):

[0292]

[0293] Furthermore, for any ,when There will always be a time for it. ,thereby ;when hour (Ignoring the extremely low probability of misjudgment). Therefore, we can obtain formula (21):

[0294] (twenty one)

[0295] Two-party secure computation protocol outputs addition secret shared share ,satisfy The cardinality of the intersection is c obtained by reconstructing Q on the query end.

[0296] In some embodiments, if the computation is performed directly within the two-party secure computation protocol... and output bit share satisfy Then the flag obtained after the reconstruction of the query end Q is the same as The threshold judgment results are consistent. If the flag is calculated locally by the query end Q after reconstructing c, the correctness requirement is also met.

[0297] If the output noise floor is And the share of noise Z , and , Add them separately to get , Then the query end Q is reconstructed. satisfy = definition of c + Z.

[0298] If the membership determination function is implemented using probabilistic data structures such as Bloom filters or hash tables, there is a probability of false positives. At a fixed length upper limit The upper bound of the probability that the overall output deviates from the true value is given by formula (22):

[0299]

[0300] in In safety parameters Under the condition that the error is negligible, it can be considered a negligible quantity. Therefore, under the assumption of negligible error, the output of the method in this application satisfies... or .

[0301] In some embodiments, token generation employs a two-cloud split VOPRF. The client sends a blinded value. When given to the cloud, a single cloud can only see the elements of the blinded group and cannot obtain the plaintext. or identity Under standard assumptions such as the discrete logarithm difficulty, Irreversible. Due to Include Rotation and usage code / flight / airport domain separation, different The token cannot be linked, suppressing cross-flight and cross-scenario association inferences.

[0302] In some embodiments, in a two-party secure computing protocol, the two cloud servers obtain the output share only through secure computing. or share No single cloud server can recover the complete intersection cardinality c or thresholded result flag from its single share. According to the simulated security definition of two-party secure computation under the semi-honest security model, there exists a probabilistic multinomial-time simulator that can simulate interactive transcriptions indistinguishable from its actual execution view computation using only the input and output shares of the cloud. Therefore, the additional information gain of a single cloud server on c or flag can be considered negligible.

[0303] In some embodiments, the query terminal Q only obtains the intersection cardinality c, the thresholding result flag, or the noise cardinality of the final output. No element-wise membership result can be obtained. During the execution of the two-party secure computation protocol, the dual sequence W acts as the first server. Private input enters into secure computing, second server Do not directly access W; hash table As the second server Private input enters into secure computing, first server No direct contact Therefore, neither cloud server can obtain the membership determination result of any single element at the plaintext level. The introduction of fixed-length padding mechanism and dummy pointers effectively suppresses large-scale side-channel attacks, while random scrambling eliminates the risk of location correlation analysis.

[0304] In some embodiments, digitally signed tickets Implement context binding, set commitment, and minimum query size. Frequency, budget, and validity period Enforcement constraints; authorization signature via element. The input set of the query terminal Q is limited to a real flight list. For elements that fail visa verification, their indicator bits are forcibly set to 0, treating them as dummy elements. This mechanism effectively suppresses attacks that attempt to infer membership by constructing small sets or using high-frequency adaptive queries at the protocol level.

[0305] In some embodiments,

[0306] The two cloud servers each generate a digital signature for their respective share of the computational results. , The query client Q will and hash value The invoice summary information is written into the audit ledger Log to achieve non-repudiable recording of all query behaviors and output results, meeting the security requirements of post-event compliance audit and traceability.

[0307] According to another aspect of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described method for determining the intersection cardinality of privacy sets for civil aviation risk investigation.

[0308] According to another aspect of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the above-described method for determining the intersection cardinality of privacy sets for civil aviation risk investigation.

[0309] According to another aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the above-described method for determining the intersection cardinality of privacy sets for civil aviation risk investigation.

[0310] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0311] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0312] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0313] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0314] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0315] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0316] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for determining the cardinality of the intersection of privacy sets for civil aviation risk investigation, applied to a system comprising a query terminal, a provider terminal, a first server, and a second server, characterized in that, Includes the following steps: The first and second key shares, bound to the context identifier, are obtained from the authorization center through the first server and the second server, respectively. The provider interacts with each element in the first data set held by the provider based on the context identifier, generates a first tag set, and stores the first tag set on the second server; The query terminal interacts with each element in the second data set held by the query terminal based on the context identifier, generates a second tag set, and sends the second tag set to the first server; The first server and the second server, based on the first key share, the second key share, the first tag set, and the second tag set, collaboratively execute a two-party secure computation protocol to obtain a first computation result share corresponding to the first server and a second computation result share corresponding to the second server. The query terminal obtains the first calculation result share and the second calculation result share from the first server and the second server respectively, and reconstructs the intersection cardinality based on the obtained calculation result shares. The intersection cardinality is used to identify the number of passengers on the flight who overlap with the risk list.

2. The method according to claim 1, characterized in that, The provider interacts with each element in the first data set held by the provider based on the context identifier to generate a first tag set, including: The provider performs normalized encoding on each element in the first data set, and performs a hash operation on the encoded element and the context identifier to obtain a group mapping value. The providing end determines the blinding value based on the group mapping value and the random blinding factor, and sends the blinding value to the first server and the second server respectively; The provider receives a first part of the evaluation result calculated by the first server based on the first key share it holds for the blinded value, and a second part of the evaluation result calculated by the second server based on the second key share it holds for the blinded value. The first tag set is generated based on the evaluation results of the first part and the evaluation results of the second part.

3. The method according to claim 2, characterized in that, Based on the first part of the evaluation result and the second part of the evaluation result, the first tag set is generated, including: The first part of the evaluation result and the second part of the evaluation result are multiplied by the providing end to obtain the aggregated value, and the inverse of the random blinding factor is used to perform a deblinding operation on the aggregated value to obtain the deblinded aggregated value. The provider inputs the deblinded aggregated value and the context identifier into a tag hash function to generate a token bound to the context identifier. The token is input into a pseudo-random function through the providing end to generate a final tag bound to the context identifier; Combine the final tags corresponding to all elements into the first tag set.

4. The method according to claim 1, characterized in that, Before obtaining the calculated result share pair by the first server and the second server collaboratively executing a two-party secure computation protocol based on the first key share, the second key share, the first tag set, and the second tag set, the method further includes: The upper bound of the fixed length is obtained through the query terminal, wherein the upper bound of the fixed length is greater than or equal to the actual size of the second data set; The query terminal generates a target number of dummy tags; wherein the target number is determined by the fixed length upper bound; and the dummy tags are tags that are different from the actual tag indicator bits. The query terminal combines the real label and the dummy label into a dual sequence according to the corresponding indicator bits, and applies random scrambling to the dual sequence to obtain the scrambled dual sequence. The scrambled dual sequence is sent to the first server through the query terminal.

5. The method according to claim 4, characterized in that, The first server and the second server, based on the first key share, the second key share, the first tag set, and the second tag set, collaboratively execute a two-party secure computation protocol to obtain computation result share pairs, including: When the first server takes the scrambled dual sequence it holds as input, and the second server takes the set structure information encoded by the stored first tag set as input, the first server and the second server run a two-party secure computation protocol based on the first key share, the second key share, the first tag set, and the second tag set. The two-party secure computation protocol includes the following steps during its execution: Within the protocol, a membership determination function is executed, wherein the membership determination function is used to determine whether each tag to be queried in the protocol, generated by the query end and input by the first server after scrambling, belongs to the first tag set, and to obtain the determination result of each tag to be queried; The determination result of each query tag is multiplied by the corresponding real indicator bit to obtain the contribution value of the query tag. Finally, the contribution values ​​of all query tags are summed in the encrypted field to obtain the intersection cardinality. The intersection cardinality is output in the form of additive secret sharing, so that the first server obtains the first calculation result share and the second server obtains the second calculation result share.

6. The method according to claim 5, characterized in that, The membership determination function is implemented using a cuckoo hash or Bloom filter structure, and the operation of the membership determination function includes: Select d public hash functions and store each tag in the first tag set in at least one candidate position in the set structure, where d is an integer greater than or equal to 1; If a stored value equal to the query tag exists in one of the d candidate positions of each query tag, the membership determination function outputs 1. If it is detected that there is no stored value equal to the query tag among the d candidate positions of each query tag, the membership determination function outputs 0.

7. The method according to claim 1, characterized in that, Before obtaining the first key share and the second key share bound to the context identifier from the authorization center through the first server and the second server respectively, the method further includes: The authorization center's server generates the context identifier based on the current retrieval task code, time slice, flight number, and airport code. The authorization center's server generates a context index key based on the master key and the context identifier using a key derivation function. The context index key is split by addition using the server of the authorization center to obtain the first key share and the second key share; The first key share is distributed to the first server through the server of the authorization center, and the second key share is distributed to the second server. The server in the authorization center generates a tag mapping key based on the master key and the context identifier, and then distributes the tag mapping key to the controlled components of the provider and the querying end.

8. The method according to claim 1, characterized in that, The method further includes: The authorization center's server generates digital signature tickets that include mandatory policy constraints, wherein the mandatory policy includes at least pre-set constraints on the minimum data size of the query set, the maximum query frequency, and the output pattern. The digitally signed ticket is sent along with the second tag set when the query terminal sends it to the first server. The first server performs a signature verification operation on the digital signature ticket, wherein the signature verification operation includes verifying whether the digital signature ticket is within its validity period, querying whether the input length of the digital signature ticket is equal to the upper bound of a fixed length, and whether the query frequency of the digital signature ticket exceeds the maximum value of the query frequency. If the digitally signed ticket fails the verification operation, the first server and the second server refuse to execute the two-party secure computation protocol.

9. The method according to claim 1, characterized in that, The method further includes: The query terminal submits the second data set to the authoritative source of the list, wherein the authoritative source of the list is the civil aviation departure system or the passenger reservation record system; the authoritative source of the list verifies the authenticity of each element in the second data set submitted by the query terminal, and for the elements that pass the verification, the authoritative source of the list uses a private key to generate a first digital signature for the element based on the context identifier; When the query terminal sends the second tag set to the first server, it also sends the first digital signature of the element verified by the authoritative source of the list to the first server.

10. The method according to claim 1, characterized in that, The method further includes: A second digital signature is generated for each tag in the first tag set by the superior regulatory authority of the provider. While updating the first tag set to the second server, the provider also submits a second digital signature corresponding to each tag in the first tag set to the second server; wherein the second server verifies each received second digital signature and stores and indexes the tags corresponding to the successfully verified second digital signatures.

11. The method according to claim 8, characterized in that, The method further includes: Set a minimum query set size for digitally signed tickets issued by the authorization center; When constructing the label input sequence through the query terminal, the number of real labels in the label input sequence is controlled to be no less than the minimum query set size; If the actual size of the second data set held by the query terminal is less than the minimum query set size, the query terminal expands the second data set with real labels by adding additional virtual elements that do not belong to any real flights, so that the number of real labels in the second data set reaches the minimum query set size.

12. The method according to claim 1, characterized in that, The query terminal obtains the first calculation result share and the second calculation result share from the first server and the second server respectively, and reconstructs the intersection cardinality based on the obtained calculation result shares, including: The first server digitally signs the first calculation result share to generate a first result signature, and sends the first calculation result share and the first result signature to the query terminal. The second server digitally signs the second calculation result share to generate a second result signature, and then sends the second calculation result share and the second result signature to the query terminal. The validity of the first result signature and the second result signature is verified by the query terminal. After successful verification, the intersection cardinality is obtained by performing a modulo operation on the first calculation result share and the second calculation result share.

13. The method according to claim 1, characterized in that, The method further includes: In response to a change event in the second data set, the query terminal identifies the set of changed elements corresponding to the change event, wherein the change event includes an add operation, a delete operation, and a replace operation; For each element corresponding to the new operation, the tag generation process is re-executed through the query terminal to obtain the tag of the new element and the corresponding element authorization signature; For each element corresponding to the deletion operation, the hash value of the token corresponding to the element is calculated by the query end and used as the deletion pointer; For each element corresponding to the replacement operation, an update instruction containing the replacement operation type and the corresponding data item is constructed through the query terminal, and the update instruction is sent to the first server; wherein, according to the received update instruction, the first server performs the corresponding element replacement operation on the sequence structure stored locally, while keeping the unchanged data unchanged.

14. The method according to claim 1, characterized in that, The method further includes: When the provider performs batch updates on the first data set, the provider packages multiple update instructions into update capsules, wherein the update capsules include multiple operation types and corresponding tag data; The provider digitally signs the update capsule and sends the signed update capsule to the second server. The signature of the update capsule is verified by the second server. After successful verification, the tag information in the first tag set is updated sequentially according to the instructions in the update capsule. After the second server completes the update of the first tag set, it sends an update completion notification to the first server, along with a summary of the updated first tag set. The first server records the summary information for consistency verification during subsequent queries.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device containing the computer-readable storage medium performs the method for determining the intersection cardinality of privacy sets for civil aviation risk investigation as described in any one of claims 1 to 14.

16. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the method for determining the intersection cardinality of privacy sets for civil aviation risk investigation as described in any one of claims 1 to 14.

17. A computer program product, characterized in that, Includes a computer program or instructions that, when executed by a processor, implement the method for determining the intersection cardinality of privacy sets for civil aviation risk investigation as described in any one of claims 1 to 14.

Images