A privacy set intersection system, method, and apparatus

Abstract

The present specification provides a privacy set intersection system, method and device, the system comprises: a blockchain node, a sending end and a receiving end, the sending end maintains a sending end data set composed of data corresponding to different objects, and the receiving end maintains a receiving end data set composed of data corresponding to different objects, wherein: the blockchain node is used to call an object registration contract deployed on a chain according to a received object registration transaction, so as to generate a corresponding global object identifier for an object indicated by the object registration transaction; the sending end is used to obtain a first function result corresponding to data to be intersected; and compare the first function result with a second function result from the receiving end; the receiving end is used to obtain the function seed in response to an intersection request, and process data in the receiving end data set based on an inadvertent pseudo-random function and the function seed to obtain a corresponding second function result.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a privacy set intersection system, method and apparatus. Background Technology

[0002] Private Set Intersection, a cryptographic technique in Secure Multi-Party Computation (MPC), allows participating parties to compute the intersection of their data without obtaining additional information about each other (i.e., information other than the intersection itself). Currently, this technique is widely used in collaborative computation scenarios involving privacy data of overlapping user groups across various industries. However, since this privacy data is typically maintained independently by each organization, inconsistencies may exist between them, leading to a decrease in the accuracy of the calculated intersection. Furthermore, the privacy data provided by each organization is difficult to trace and verify, further increasing the difficulty of data oversight during collaborative computation. Summary of the Invention

[0003] In view of this, this specification provides a privacy set intersection system, method and apparatus to address the shortcomings of related technologies.

[0004] Specifically, this specification is implemented through the following technical solution:

[0005] According to a first aspect of the embodiments of this specification, a privacy set intersection system is provided, comprising: a blockchain node, a sender, and a receiver, wherein the sender maintains a sender dataset consisting of data corresponding to different objects, and the receiver maintains a receiver dataset consisting of data corresponding to different objects, wherein:

[0006] The blockchain node is configured to invoke the on-chain deployed object registration contract according to the received object registration transaction, so as to generate a corresponding global object identifier for the object indicated by the object registration transaction; and to store the global object identifier on the blockchain.

[0007] The sending end is configured to initiate an intersection request to the receiving end, the intersection request carrying data to be intersected from the sending end's dataset; obtain a first function result corresponding to the data to be intersected, the first function result being obtained by processing the data to be intersected based on an unintentional pseudo-random function predetermined by the receiving end and a function seed corresponding to the receiving end; and compare the first function result with a second function result from the receiving end, if the two correspond to the same global object identifier, then determine that the data to be intersected belongs to the intersection data between the sending end's dataset and the receiving end's dataset;

[0008] The receiving end is configured to obtain the function seed in response to the intersection request, process the data in the receiving end's dataset based on the unintentional pseudo-random function and the function seed to obtain the corresponding second function result, and return the second function result to the sending end.

[0009] According to a second aspect of the embodiments of this specification, a privacy set intersection method is provided, applied at a sending end, wherein the sending end maintains a sending end dataset consisting of data corresponding to different objects; the method includes:

[0010] Initiate a cross-intersection request to the receiving end, which maintains a receiving end dataset consisting of data belonging to different objects, and the cross-intersection request carries data to be cross-intersected from the sending end dataset;

[0011] Obtain the first function result corresponding to the data to be intersected. The first function result is obtained by processing the data to be intersected based on an unintentional pseudo-random function predetermined by the receiving end and the function seed corresponding to the receiving end.

[0012] Comparing the result of the first function with the result of the second function from the receiving end, if they correspond to the same global object identifier, it is determined that the data to be intersected belongs to the intersection data between the sending end dataset and the receiving end dataset; the second function result is obtained by the receiving end processing the data in the receiving end dataset based on the unintentional pseudo-random function and the function seed; the global object identifier is generated by the blockchain node calling the on-chain deployed object registration contract according to the received object registration transaction to target the object indicated by the object registration transaction; and the global object identifier is stored on-chain by the blockchain node.

[0013] According to a third aspect of the embodiments of this specification, a privacy set intersection apparatus is provided, applied at a sending end, wherein the sending end maintains a sending end dataset consisting of data corresponding to different objects; the apparatus includes:

[0014] The request initiating unit is used to initiate a cross-interaction request to the receiving end, wherein the receiving end maintains a receiving end dataset consisting of data corresponding to different objects, and the cross-interaction request carries data to be cross-interacted from the sending end dataset;

[0015] The function result acquisition unit is used to acquire the first function result corresponding to the data to be intersected. The first function result is obtained by processing the data to be intersected based on an unintentional pseudo-random function predetermined by the receiving end and the function seed corresponding to the receiving end.

[0016] The function result comparison unit is used to compare the first function result with the second function result from the receiving end. If the two correspond to the same global object identifier, it is determined that the data to be intersected belongs to the intersection data between the sending end dataset and the receiving end dataset. The second function result is obtained by the receiving end processing the data in the receiving end dataset based on the unintentional pseudo-random function and the function seed. The global object identifier is generated by the blockchain node calling the on-chain deployed object registration contract according to the received object registration transaction to target the object indicated by the object registration transaction. The global object identifier is stored on-chain by the blockchain node.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the second aspect.

[0018] According to a fifth aspect of the embodiments of this specification, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described in the second aspect.

[0019] In the technical solution provided in this specification, by calling the object registration contract deployed on the blockchain through a blockchain node, a corresponding global object identifier can be generated for the object indicated by the aforementioned object registration transaction, and this identifier can be stored on the blockchain. This enables the traceability and verification of privacy data and multi-party computation data corresponding to the global object identifier, thereby preventing the impact of counterfeit data on the intersection data. Furthermore, the sending and receiving ends can determine whether the data to be intersected intersects based on the results of a first function and a second function obtained through an unintentional pseudo-random function, effectively improving the efficiency of data privacy intersection determination.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings.

[0022] Figure 1 This is a schematic diagram illustrating the architecture of a blockchain-based privacy set intersection system, as shown in an exemplary embodiment of this specification.

[0023] Figure 2 This is a schematic diagram illustrating a multi-party interaction of a privacy set intersection system, as shown in an exemplary embodiment of this specification.

[0024] Figure 3a This is a schematic diagram illustrating an exemplary embodiment of the creation of a blockchain smart contract as described in this specification;

[0025] Figure 3b This is a schematic diagram illustrating an exemplary embodiment of this specification, showing a method for invoking a blockchain smart contract;

[0026] Figure 4 This is a schematic diagram illustrating a privacy set intersection protocol as shown in an exemplary embodiment of this specification;

[0027] Figure 5 This is a schematic diagram illustrating an exemplary embodiment of the present specification, showing a comparison between a sending end dataset and a receiving end dataset;

[0028] Figure 6 This is a flowchart illustrating an exemplary embodiment of a privacy set intersection method as shown in this specification;

[0029] Figure 7 This is a schematic structural diagram of an electronic device shown in an exemplary embodiment of this specification;

[0030] Figure 8 This is a schematic diagram of a privacy set intersection device illustrated in an exemplary embodiment of this specification. Detailed Implementation

[0031] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification.

[0032] It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the methods may include more or fewer steps than those described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments. It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0033] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0034] Figure 1 This is a schematic diagram illustrating the architecture of a blockchain-based privacy set intersection system, as shown in an exemplary embodiment of this specification. Figure 1 As shown, it may include a blockchain system 11, a sender 12, and a receiver 13.

[0035] Blockchain system 11 can maintain one or more blockchains (e.g., public blockchain, private blockchain, consortium blockchain, etc.) and includes multiple blockchain nodes for carrying the aforementioned one or more blockchains; for example, blockchain node 1, blockchain node 2, blockchain node 3, blockchain node 4, blockchain node i, etc., can jointly carry one or more blockchains. Cross-chain data access is possible between the blockchain nodes included in the aforementioned blockchain system. Furthermore, the aforementioned blockchain system can be a physical host in a server cluster, or a virtual machine created by virtualizing the hardware resources of a server or server cluster based on virtualization technology. Each blockchain node can be connected together to form a network through various types of communication methods (e.g., TCP / IP) to carry one or more blockchains. One or more embodiments in this specification do not limit this. During the operation of the aforementioned privacy set intersection system, blockchain nodes in the blockchain system can invoke the on-chain deployed object registration contract according to the received object registration transaction and generate a corresponding global object identifier; and, by storing the global object identifier on the chain, the credibility of the data involved in the privacy set intersection calculation is determined, thereby realizing the tracking and supervision of privacy calculations between the sending and receiving ends.

[0036] The sending end 12 is a network device that supports data storage, transmission, and processing functions. During the operation of the aforementioned privacy set intersection system, the sending end can maintain a sending end dataset consisting of data corresponding to different objects. By comparing the first function result corresponding to the sending end dataset with the second function result corresponding to the receiving end dataset, the intersection data between the sending end dataset and the receiving end dataset can be determined without leaking other privacy data. The sending end can be a separate physical server or a virtual server hosted in a host cluster; this specification does not impose any restrictions on this.

[0037] The receiver 13 is a separate network device from the sender. During the operation of the privacy set intersection system, the receiver can maintain a receiver dataset consisting of data corresponding to different objects. After responding to an intersection request initiated by the sender and obtaining the second function result corresponding to the receiver dataset, the receiver can return it to the sender. The receiver can be a physical server on a separate host or a virtual server hosted in a host cluster; this specification does not impose any restrictions on this.

[0038] It is important to note that Figure 1This is a schematic diagram illustrating the architecture of a blockchain-based privacy set intersection system as an exemplary embodiment. It represents only one implementation of the system. Taking the object registration transaction as an example, the sending or receiving end (or other connected device terminal) can generate an object registration transaction and send it to any node in the blockchain system. Upon receiving the data query request, any node in the blockchain system can perform any of the following operations: synchronize the object registration transaction to other nodes in the blockchain system; if consensus is reached between the object registration transaction and the other nodes, the node can directly execute the object registration transaction locally, while the transaction initiator listens to and obtains the generated registration result.

[0039] The aforementioned privacy set intersection system can also be implemented in other ways, such as in blockchain systems. Figure 1 The above describes a BaaS platform (also known as a BaaS cloud) that incorporates Blockchain as a Service (BaaS). The BaaS platform provides pre-written software for activities occurring on the blockchain system (such as subscriptions and notifications, user authentication, database management, and remote updates), offering simple and efficient blockchain services to transaction initiators connected to the BaaS platform. This accelerates the development, testing, and deployment of blockchain-related applications, facilitating the implementation of corresponding blockchain business applications. Taking the object registration transaction as an example, the transaction initiator can send an object registration request to the BaaS platform. Upon receiving this data query request, the BaaS platform generates a corresponding object registration transaction and sends it to any node in the blockchain system. Any node in the blockchain system receiving the object registration transaction can perform one of the following operations: synchronize the object registration transaction to other nodes in the blockchain system; or, if consensus is reached between the node and the other nodes, the node can directly execute the object registration transaction locally and return the generated registration result to the transaction initiator via the BaaS platform.

[0040] Figure 2 This is a schematic diagram illustrating a multi-party interaction of a privacy set intersection system, as shown in an exemplary embodiment of this specification. Figure 2 As shown, the system can include blockchain nodes, a sender, and a receiver. The sender maintains a sender dataset consisting of data belonging to different objects, and the receiver maintains a receiver dataset consisting of data belonging to different objects. The system can include the following steps:

[0041] S201, the sending end initiates an object registration transaction for the data in the sending end's dataset to the blockchain node.

[0042] S202, the receiving end initiates an object registration transaction for the data in the receiving end's dataset to the blockchain node.

[0043] Before a user attempts to determine the intersection between the sending and receiving datasets, the objects to which data belongs in both datasets can be uniformly managed through blockchain nodes. This prevents discrepancies in the definitions of the objects to which the same data belongs between the sending and receiving ends from being deemed as intersecting data. Therefore, both the sending and receiving ends need to initiate corresponding object registration transactions with the blockchain nodes in advance so that the nodes can invoke the on-chain object registration contract as described below. These object registration transactions can carry the identity information of the corresponding objects, which may include the object's public key, identity credentials (e.g., name, gender, validity period, registration time), and the signature corresponding to the identity credentials.

[0044] Those skilled in the art will understand that the above-mentioned object registration transactions are not time-sequential; that is, S202 can be executed before S201, or S202 can be executed after S201. Furthermore, the so-called object can also be pre-registered in a non-blockchain node. For example, institution A, as the sender, and institution B, as the receiver, respectively store user A's registration information. However, due to objective differences in the registration rules of each institution (e.g., institution A generates a unique identifier for user A in institution A based on a preset random seed, while institution B generates a unique identifier for user A in institution B based on the registration time sequence), their registration information usually does not necessarily overlap. If the aforementioned blockchain node is introduced, the different registration information of user A in institutions A and B can be mapped to the same unified global object identifier in the blockchain node (e.g., institution A uses the global object identifier mentioned below as the unique identifier for user A in institution A, and institution B also uses the global object identifier as the unique identifier for user A in institution B). This specification does not restrict the process of registering data for the object in the sender or receiver.

[0045] Furthermore, the aforementioned blockchain nodes can be subdivided into three categories based on their specific functions: user light nodes, off-chain data nodes, and full blockchain nodes. User light nodes possess ownership and encryption keys of the data in the sending or receiving datasets. They are characterized by limited storage space and computing resources, and a high priority for protecting their own privacy data. Therefore, decentralized applications (DApps) can be considered to assist user light nodes in completing functions such as blockchain identity registration. The specific principles and usage of these DApps are largely disclosed in relevant technologies and will not be elaborated upon here. Off-chain data nodes can be deployed and managed by various institutions acting as sending and / or receiving ends, and are used to store their local privacy data while performing data verification, computation, and zero-knowledge proof generation in multi-party computation. Full blockchain nodes can store and maintain all on-chain data and respond to requests for on-chain data storage and data record queries.

[0046] S203, the blockchain node invokes the on-chain object registration contract based on the received object registration transaction to generate a corresponding global object identifier for the object indicated by the object registration transaction; and, the global object identifier is stored on-chain.

[0047] After receiving the aforementioned object registration transaction, the blockchain node can invoke the pre-deployed object registration contract on the blockchain to generate a corresponding global object identifier. The generated global object identifier is then recorded in the blockchain to provide proof of the legality of the privacy data of each party during the subsequent privacy set intersection process between the sender and receiver.

[0048] The aforementioned object registration contract can also verify the authenticity of the data before it is officially stored, in order to prevent illegal third parties impersonating the sender or receiver from maliciously registering abnormal objects.

[0049] In one embodiment, the blockchain node receiving the object registration transaction can verify the identity information carried in the transaction. If the verification is successful, it signs the identity credential information using the private key corresponding to the blockchain node to form a digital certificate. The identity information and the digital certificate are then organized and stored together in a predefined object data structure. As mentioned earlier, the identity information may include: the public key of the corresponding object, the identity credential information, and the signature corresponding to the identity credential information. Therefore, the verification process can be as follows: verify the signature of the identity credential information corresponding to the public key. If the signature verification is successful, it indicates that the identity credential information indeed comes from a device (e.g., a sender or receiver) that uniquely possesses the object's private key; otherwise, it indicates that the source of the identity information is illegitimate, and no further digital certificate generation and storage is required. Furthermore, the aforementioned digital certificate is formed by the blockchain node signing the hash value of the aforementioned information using its private key (different from the private key of the aforementioned object). Therefore, the serial number of the digital certificate, the hash value, and the certificate status can all be packaged into a block and recorded and maintained by all blockchain nodes in the blockchain system through the blockchain's consensus process. At this point, the user essentially possesses a unique identity identifier (i.e., the aforementioned global object identifier) ​​on the blockchain. Of course, this unique identity identifier can be obtained and recorded by the sending or receiving end through the aforementioned registration result.

[0050] For the blocks packaged above, their block structure can use an MPT (Merkle Patricia Tree) to store on-chain data and related information. The block header stores the root node's hash value, blockchain version information, and block generation time, while the block body stores the identity information of the data owner (i.e., the registered object). All child nodes in the MPT structure can have the same prefix and use a key-value (KV) data structure to store node data. Each node's key is formed by concatenating the key values ​​of all nodes along the path from the root node to that node.

[0051] The aforementioned object registration contract is a type of smart contract, and its creation and invocation methods can be referenced as follows: Figure 3a , 3b As shown in the diagram. Figure 3a This is a schematic diagram illustrating an exemplary embodiment of the method for creating a blockchain smart contract, as shown in this specification. Figure 3b This is a schematic diagram illustrating an exemplary embodiment of this specification, showing a method for invoking a blockchain smart contract.

[0052] like Figure 3aAs shown, Bob can send a transaction containing smart contract creation information (including contract code) to the blockchain system, and each node device can then execute this transaction within its virtual machine. Specifically, Figure 3a The `From` field of a transaction records the address of the account that initiated the creation of the smart contract. The `Data` field stores the contract code, which can be the bytecode mentioned above. The `To` field is a null (empty) account value. Once nodes reach a consensus through the consensus mechanism, the smart contract is successfully created, and users can subsequently call it. After the smart contract is created, a contract account corresponding to that smart contract appears on the blockchain, possessing a specific address; for example, Figure 3a In each node, "0x68e12cf284…" represents the address of the contract account that was created; the contract code and storage will be stored in the contract account's storage. The behavior of a smart contract is controlled by the contract code, while the smart contract's storage stores the contract's state. Simultaneously, the Data field of the transaction that created the smart contract can store the smart contract's bytecode. Bytecode consists of a series of bytes, each byte representing an operation. For reasons of development efficiency and readability, developers can choose to write smart contract code in a high-level language instead of directly writing bytecode. For example, high-level languages ​​such as Solidity, Serpent, and LLL can be used. Smart contract code written in a high-level language can be compiled by a compiler to generate bytecode that can be deployed to the blockchain. Taking Solidity as an example, contract code written in it is very similar to classes in object-oriented programming languages; a contract can declare various members, including state variables, functions, function modifiers, and events. Among them, the state variable is a value that is permanently stored in the account storage field of the smart contract and is used to save the state of the contract.

[0053] like Figure 3b As shown, after Bob sends a transaction containing information about invoking a smart contract to the blockchain system, each node device can execute this transaction within its virtual machine. Specifically, Figure 3b The `From` field of a transaction records the address of the account initiating the smart contract call, the `To` field records the address of the smart contract being called, and the `Data` field records the method and parameters used to call the smart contract. After the smart contract is called, the account state of the contract may change. Subsequently, a client can access the blockchain through a connected node (e.g.,...). Figure 3bNode 1) View the account status of the contract account. Smart contracts can be executed independently on each node of the blockchain network in a prescribed manner. All execution records and data are stored on the blockchain. Therefore, once such a transaction is completed, an immutable and unlost transaction certificate is stored on the blockchain. Through the above data storage transaction, the aforementioned global object identifier can be stored as the account status in the corresponding contract account.

[0054] By combining the block structure and smart contracts described above, the technical solution in this specification can automate the successful execution of identity registration and data verification, making the process of user identity management and multi-party (between the sender and one or more receivers) computational data management transparent.

[0055] At this point, the aforementioned privacy set intersection system has completed the data registration and on-chain phase, providing a technical foundation for the implementation of the subsequent privacy set intersection phase.

[0056] S204, the sending end initiates a request to the receiving end to request the data to be requested.

[0057] When a user needs to obtain the intersection data between the sending end's dataset and the receiving end's dataset, the sending end can manually or automatically initiate an intersection request to the receiving end, carrying the data to be intersected. This data to be intersected can be considered as data corresponding to one or more objects in the sending end.

[0058] It should be noted that before the formal multi-party computation of the intersection of privacy sets, the sender and receiver can upload their respective digest values ​​of their privacy data (i.e., the data in the sender's dataset and the data in the receiver's dataset) and provide zero-knowledge proofs to enhance the credibility of the data. Specifically, when either the receiver or the sender uploads the data digest to a blockchain node, the corresponding blockchain node can trigger a smart contract to execute the zero-knowledge verification, thereby verifying the input data and computation process of the aforementioned digest value.

[0059] S205, the sending end processes the data to be intersected based on a pre-determined random pseudo-random function and the corresponding function seed to obtain the first function result.

[0060] Most existing set intersection protocols typically only support calculating the intersection of sets. However, in many scenarios, participants may prefer to compute certain functions about the intersection (such as the intersection size, the sum of intersection weights, etc.) without revealing the intersection. Therefore, this document introduces a privacy-preserving intersection method based on the Oblivious Transfer protocol. Oblivious Transfer is a secure two-party communication protocol frequently used in cryptography and is a fundamental protocol in cryptography. This protocol specifies the communication method between the sender and receiver, ensuring that after the protocol execution, the receiver can obtain the information it wants, but cannot obtain any other information from the sender. The sender is unaware of which message the receiver has received. In other words, the core requirement for Oblivious Transfer for both parties is that the receiver does not want the sender to know the data it needs, while the sender wants the receiver to only obtain the data it needs, and not other data. At the same time, compared with traditional privacy intersection techniques based on public-key encryption, obfuscated circuits, homomorphic encryption, and polynomial evaluation, this method has lower computational complexity and a wider range of applicable scenarios.

[0061] The aforementioned sending and receiving ends can establish an unintentional transmission protocol based on the correct execution of the intersection request, and obtain the first function result according to the unintentional pseudo-random function and function seed corresponding to the unintentional transmission protocol. The first function result corresponding to the data to be intersected is combined with the second function result described below to calculate the intersection data between the sending end's dataset and the receiving end's dataset. The following section combines... Figure 4 Further explanation of the results of the first function, such as... Figure 4As shown, assuming that a random function seed K is assigned to the receiver during the creation of the privacy intersection protocol, this seed can be different depending on the selected bit i. From the sender's perspective, the subsequent privacy data comparison process is equivalent to the sender inputting the data to be intersected and obtaining a first function result consisting of a random string. This first function result is determined by the random seed held by the receiver and the aforementioned data to be intersected, while the receiver is unaware of the sender's data to be intersected. This process can be seen as an implementation of an Oblivious Pseudorandom Function (OPRF). Furthermore, as a cryptographic protocol, the OPRF allows the receiver to choose a random seed Ki, and the receiver can choose an input data x1 to be intersected and obtain the output of a pseudorandom function F(Ki, x1), while the receiver is unaware of the data x1 to be intersected. In the privacy comparison, the sending end actually executes an unintentional pseudo-random function, while the receiving end can execute a regular pseudo-random function on its own dataset (therefore, the receiving end must hold the function seed locally). By comparing the function outputs of the sending and receiving ends, the privacy comparison can be achieved.

[0062] Those skilled in the art will understand that the aforementioned sender and receiver refer to the initiator and receiver of the intersection request in the privacy set intersection scenario, respectively. In the actual unintentional transmission protocol, the receiver is the sender who selects the random seed, and the sender is the receiver who obtains the result of the first function. However, for the sake of easy reading and understanding of the context, the concepts of sender and receiver in the unintentional transmission protocol will not be emphasized in this specification.

[0063] S206, the receiving end obtains the function seed and processes the data in the receiving end dataset based on the unintentional pseudo-random function and the function seed to obtain the second function result.

[0064] As mentioned earlier, the data result obtained by the receiver performing an unintentional pseudo-random function on the data in the receiver's dataset (which can be regarded as an ordinary pseudo-random function in form, but whose function content is completely consistent with the unintentional pseudo-random function executed by the sender) can be called the second function result.

[0065] S207, the receiving end returns the result of the second function to the sending end.

[0066] S208, the sending end compares the result of the first function with the result of the second function based on the global object identifier.

[0067] In one embodiment, the sending end can compare the result of the first function with the result of the second function returned by the receiving end in sequence. If the data of the two correspond to the same global object identifier, it can be determined that the data to be intersected belongs to the intersection data between the sending end dataset and the receiving end dataset.

[0068] In another embodiment, considering that the comparison method in the previous embodiment, while intuitive, is very expensive (increasing with the size of the sending and receiving datasets), an alternative comparison method based on hash buckets is introduced. Specifically, the sending end can map the data of its dataset to different first hash buckets according to multiple hash functions predetermined by the receiving end. If multiple first hash buckets contain unmapped data, the corresponding data is randomly inserted into any one of them; if one first hash bucket contains unmapped data, the corresponding data is directly inserted into that first hash bucket; if no first hash bucket contains unmapped data, the corresponding data is stored in the corresponding cache. The receiving end can map the data of its dataset to different second hash buckets according to multiple hash functions, and the storage space of the hash tables corresponding to the second hash buckets and the first data buckets is the same. Then, the sending end can compare the result of the first function with the result of the second function corresponding to the data mapped to the target hash bucket in the receiving end, where the position of the target hash bucket in the corresponding hash table is the same as the hash bucket containing the data to be intersected.

[0069] The following is combined with Figure 5 To explain the comparison method of the previous embodiment, first assume there is a financial institution A and an e-commerce platform B. Financial institution A maintains financial information such as credit ratings for different users, while e-commerce platform B maintains shopping information for different users. Institution A wants to infer the spending power of users A, B, and C (assuming their global object identifiers stored in the blockchain nodes are x1, x2, and x3, respectively) based on their shopping information, and then determine whether to raise the user's credit rating to encourage the user to make more financial investments, thereby increasing the institution's profits, or lower the user's credit rating to restrict the user's financial investment behavior, thereby reducing the institution's risk probability. In this scenario, institution A can send a request carrying the data to be submitted to institution B as the receiving end to determine whether institution B stores shopping information corresponding to the same user (i.e., users A, B, and C), and after determining this, initiate subsequent function requests for the shopping information to institution B.

[0070] The sending end can select two hash functions and initialize a hash table with a capacity of L. Organization A can map its three global object identifiers corresponding to users A, B, and C to this table. The specific steps are as follows:

[0071] 1. Organization A and Organization B negotiate two hash functions respectively and initialize the capacity to L (e.g., Figure 5 A hash table (where L is 7) (e.g., for example) Figure 5 (Left side);

[0072] 2. For global object identifiers x1, x2 and x3 in sequence, mechanism A calculates the HASH values ​​of the corresponding two HASH functions, assuming they are h(x1_1) and h(x1_2);

[0073] 3. Organization A checks the hash buckets corresponding to the two calculated hash values. If there are two vacant positions, it randomly selects one vacant position to insert the hash value.

[0074] 4. If there is a vacancy, insert directly;

[0075] 5. If there are no vacant positions, that is, both positions already have elements, then randomly select one of the two existing elements, remove that element, and insert the current element.

[0076] 6. The removed element will repeat steps (3) to (5) until a vacancy is found for insertion (corresponding to...). Figure 5 The x1 on the left is only placed into the first hash bucket of the hash table on the right; if the number of iterations reaches a preset threshold, the element will be placed in a pre-set cache.

[0077] For the receiving end, it only needs to push the privacy data into the bucket using a regular hash table. The specific steps are as follows:

[0078] 1. Organization B uses two hash functions pre-negotiated with Organization A to initialize a hash table of capacity L (e.g., ...). Figure 5 (Right side part);

[0079] 2. Organization B calculates the HASH values ​​corresponding to the private data, assuming they are h(x_1) and h(x_3);

[0080] 3. Organization B places the two hash values ​​into their corresponding hash buckets, therefore each bucket may contain multiple elements (corresponding to...). Figure 5 x1 on the right is placed into the first and second hash buckets of the hash table on the right.

[0081] 4. To better protect the privacy of Organization B's data, Organization B can fill the bucket with random numbers (corresponding to...). Figure 5 The "*" elements in each hash bucket of the hash table on the right.

[0082] Simultaneously, a privacy-preserving intersection protocol is executed bucket-by-bucket on both parties' hash tables (i.e., Figure 4The corresponding operation compares the function output corresponding to the HASH value in the bucket to find the global object identifier of the intersection user of organization A and organization B. Among multiple organizations, the task initiator can perform a privacy intersection protocol with the other organizations to ultimately obtain the global object identifier among multiple organizations.

[0083] S209, the sending end determines whether the data to be intersected belongs to the intersection data between the sending end dataset and the receiving end dataset based on the comparison result.

[0084] like Figure 5 As shown, if the comparison results indicate that the first function result and the second function result in the same hash bucket at the sending and receiving ends correspond to the same global object identifier, then it means that the user corresponding to that global object identifier (users A, B, and C) has corresponding financial / shopping information in both institution A and institution B. In other words, based on the comparison results, it can be determined that x1, x2, and x3 are intersection data between the sending and receiving datasets.

[0085] The following is combined with Figure 6 A flowchart illustrating the intersection method for privacy sets is provided, wherein the method is applied at the sending end, which maintains a sending end dataset consisting of data corresponding to different objects; the method includes:

[0086] S601, initiate a cross-interaction request for the receiving end. The receiving end maintains a receiving end dataset consisting of data corresponding to different objects. The cross-interaction request carries data to be cross-interacted from the sending end dataset.

[0087] S602, obtain the first function result corresponding to the data to be intersected, wherein the first function result is obtained by processing the data to be intersected based on an unintentional pseudo-random function predetermined by the receiving end and the function seed corresponding to the receiving end.

[0088] S603, compare the first function result with the second function result from the receiving end. If they correspond to the same global object identifier, then determine that the data to be intersected belongs to the intersection data between the sending end dataset and the receiving end dataset. The second function result is obtained by the receiving end processing the data in the receiving end dataset based on the unintentional pseudo-random function and the function seed. The global object identifier is generated by the blockchain node calling the on-chain deployed object registration contract according to the received object registration transaction to target the object indicated by the object registration transaction. The global object identifier is stored on-chain by the blockchain node.

[0089] As mentioned above, the object registration transaction carries the identity information of the corresponding object; the object registration contract is used to implement the following steps:

[0090] Verification is performed based on the stated identity information;

[0091] If the verification is successful, the identity credential information is signed using the private key corresponding to the blockchain node to form a digital certificate;

[0092] The identity information and the digital certificate information are organized and stored in the form of a predefined object data structure.

[0093] As mentioned above, the identity information records include: the public key corresponding to the object, the identity credential information, and the signature corresponding to the identity credential information;

[0094] The verification based on the identity information includes:

[0095] Verification is performed based on the signature of the identity credential information corresponding to the public key.

[0096] As mentioned above, the blockchain node is also used to: store the digest values ​​and signatures of each data in the sending end dataset and the receiving end dataset.

[0097] As mentioned above, the sending end is also used for:

[0098] The data in the sending end dataset is mapped to different first hash buckets according to multiple hash functions predetermined by the receiving end. If there are multiple first hash buckets with unmapped data, the corresponding data is randomly inserted into any first hash bucket. If there is one first hash bucket with unmapped data, the corresponding data is directly inserted into the corresponding first hash bucket. If there is no first hash bucket with unmapped data, the corresponding data is stored in the corresponding cache area.

[0099] The receiving end is also used for:

[0100] The data in the receiving dataset is mapped to different second hash buckets according to the multiple hash functions. The storage space of the hash tables corresponding to the second hash buckets is the same as that of the first data buckets.

[0101] The comparison of the first function result with the second function result from the receiving end includes:

[0102] The sending end compares the result of the first function with the result of the second function corresponding to the data mapped to the target hash bucket in the receiving end. The position of the target hash bucket in the corresponding hash table is the same as the hash bucket where the data to be intersected is located.

[0103] As demonstrated by the above embodiments, the technical solution in this specification combines blockchain technology and privacy intersection technology to achieve unified identity management for the same user across different institutions and privacy intersection of data to be intersected. This ensures consistency of user data in multi-party computations, exhibiting good adaptability and applicability to various task computations. Specifically, the application of blockchain technology protects the confidentiality and integrity of privacy data, giving the multi-party computation process strong resistance to attacks, while the Unintentional Transfer Extension Protocol and data intersection methods improve the efficiency of privacy intersection.

[0104] Figure 7 This is a schematic structural diagram of an electronic device according to an exemplary embodiment. Please refer to... Figure 7 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other necessary hardware. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it, forming a privacy set intersection device at the logical level. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0105] Corresponding to the embodiments of the aforementioned privacy set intersection method, this specification also provides embodiments of the privacy set intersection apparatus.

[0106] Please refer to Figure 8 , Figure 8 This is a schematic diagram illustrating the structure of a privacy set intersection device in an exemplary embodiment. Figure 8 As shown, in a software implementation, the device is applied to a sending end, which maintains a sending end dataset consisting of data corresponding to different objects; the device may include:

[0107] The request initiating unit 801 is used to initiate a cross-interaction request to the receiving end, wherein the receiving end maintains a receiving end dataset consisting of data corresponding to different objects, and the cross-interaction request carries data to be cross-interacted from the sending end dataset.

[0108] The function result acquisition unit 802 is used to acquire the first function result corresponding to the data to be intersected. The first function result is obtained by processing the data to be intersected based on an unintentional pseudo-random function predetermined by the receiving end and the function seed corresponding to the receiving end.

[0109] The function result comparison unit 803 is used to compare the first function result with the second function result from the receiving end. If the two correspond to the same global object identifier, it is determined that the data to be intersected belongs to the intersection data between the sending end dataset and the receiving end dataset. The second function result is obtained by the receiving end processing the data in the receiving end dataset based on the unintentional pseudo-random function and the function seed. The global object identifier is generated by the blockchain node calling the on-chain deployed object registration contract according to the received object registration transaction to target the object indicated by the object registration transaction. The global object identifier is stored on-chain by the blockchain node.

[0110] Optionally, the object registration transaction carries the identity information of the corresponding object; the object registration contract is used to implement the following steps:

[0111] Verification is performed based on the stated identity information;

[0112] If the verification is successful, the identity credential information is signed using the private key corresponding to the blockchain node to form a digital certificate;

[0113] The identity information and the digital certificate information are organized and stored in the form of a predefined object data structure.

[0114] Optionally, the identity information record includes: the public key corresponding to the object, identity credential information, and the signature corresponding to the identity credential information; the device further includes:

[0115] The authentication unit 804 is used to verify the signature of the identity credential information corresponding to the public key.

[0116] Optionally, the blockchain node is also used to: store the digest value and signature of each data in the sending end dataset and the receiving end dataset.

[0117] Optionally, the sending end is further configured to:

[0118] The data in the sending end dataset is mapped to different first hash buckets according to multiple hash functions predetermined by the receiving end. If there are multiple first hash buckets with unmapped data, the corresponding data is randomly inserted into any first hash bucket. If there is one first hash bucket with unmapped data, the corresponding data is directly inserted into the corresponding first hash bucket. If there is no first hash bucket with unmapped data, the corresponding data is stored in the corresponding cache area.

[0119] The receiving end is also used for:

[0120] The data in the receiving dataset is mapped to different second hash buckets according to the multiple hash functions. The storage space of the hash tables corresponding to the second hash buckets is the same as that of the first data buckets.

[0121] The function result comparison unit 803 is specifically used for:

[0122] The sending end compares the result of the first function with the result of the second function corresponding to the data mapped to the target hash bucket in the receiving end. The position of the target hash bucket in the corresponding hash table is the same as the hash bucket where the data to be intersected is located.

[0123] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0124] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 network units. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0125] The embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0126] The processing and logic flow described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flow can also be executed by dedicated logic circuitry—such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and the device can also be implemented as dedicated logic circuitry.

[0127] Computers suitable for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of processing unit. Typically, the processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0128] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0129] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0130] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0131] Therefore, specific embodiments of the subject matter have been described. Furthermore, the processes depicted in the figures are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0132] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A private set intersection system, comprising: The blockchain consists of a node, a sender, and a receiver. The sender maintains a sender dataset containing data belonging to different objects, and the receiver maintains a receiver dataset containing data belonging to different objects. The blockchain node is configured to invoke the on-chain deployed object registration contract according to the received object registration transaction, so as to generate a corresponding global object identifier for the object indicated by the object registration transaction; and to store the global object identifier on the blockchain. The sending end is configured to initiate an intersection request to the receiving end, the intersection request carrying data to be intersected from the sending end's dataset; obtain a first function result corresponding to the data to be intersected, the first function result being obtained by processing the data to be intersected based on an unintentional pseudo-random function predetermined by the receiving end and a function seed corresponding to the receiving end; and compare the first function result with a second function result from the receiving end, if the two correspond to the same global object identifier, then determine that the data to be intersected belongs to the intersection data between the sending end's dataset and the receiving end's dataset; The receiving end is configured to obtain the function seed in response to the intersection request, process the data in the receiving end's dataset based on the unintentional pseudo-random function and the function seed to obtain the corresponding second function result, and return the second function result to the sending end.

2. In the system according to claim 1, the object registration transaction carries the identity information of the corresponding object; the object registration contract is used to implement the following steps: Verification is performed based on the stated identity information; If the verification is successful, the identity information is signed using the private key corresponding to the blockchain node to form a digital certificate; The identity information and the digital certificate information are organized and stored in the form of a predefined object data structure.

3. The system according to claim 2, wherein the identity information record includes: the public key corresponding to the corresponding object, identity credential information, and the signature corresponding to the identity credential information; The verification based on the identity information includes: The signature of the identity credential information is verified based on the public key.

4. In the system according to claim 1, the blockchain node is further configured to: store the digest value and signature of each data in the sending end dataset and the receiving end dataset.

5. The system according to claim 1, The transmitting end is also used for: mapping data of the sending end data set into different first hash buckets according to a plurality of hash functions predetermined by the receiving end, and if there are a plurality of first hash buckets with unmapped data, randomly inserting the corresponding data into any first hash bucket; If there is a first hash bucket with unmapped data, the corresponding data is directly inserted into the corresponding first hash bucket; if there is no first hash bucket with unmapped data, the corresponding data is stored in the corresponding cache area. The receiving end is also used for: The data in the receiving dataset is mapped to different second hash buckets according to the multiple hash functions. The storage space of the hash tables corresponding to the second hash buckets is the same as that of the first hash buckets. The comparison of the first function result with the second function result from the receiving end includes: The sending end compares the result of the first function with the result of the second function corresponding to the data mapped to the target hash bucket in the receiving end. The position of the target hash bucket in the corresponding hash table is the same as the hash bucket where the data to be intersected is located.

6. A privacy set intersection method, applied at a sending end, wherein the sending end maintains a sending end dataset consisting of data corresponding to different objects; the method includes: Initiate a cross-intersection request to the receiving end, which maintains a receiving end dataset consisting of data belonging to different objects, and the cross-intersection request carries data to be cross-intersected from the sending end dataset; Obtain the first function result corresponding to the data to be intersected. The first function result is obtained by processing the data to be intersected based on an unintentional pseudo-random function predetermined by the receiving end and the function seed corresponding to the receiving end. Compare the result of the first function with the result of the second function from the receiving end. If they correspond to the same global object identifier, then it is determined that the data to be intersected belongs to the intersection data between the sending end dataset and the receiving end dataset. The result of the second function is obtained by the receiving end processing the data in the receiving end dataset based on the unintentional pseudo-random function and the function seed. The global object identifier is generated by the blockchain node invoking the on-chain object registration contract based on the received object registration transaction to target the object indicated by the object registration transaction; and the global object identifier is stored on-chain by the blockchain node.

7. The method according to claim 6, wherein the object registration transaction carries the identity information of the corresponding object; the object registration contract is used to implement the following steps: Verification is performed based on the stated identity information; If the verification is successful, the identity information is signed using the private key corresponding to the blockchain node to form a digital certificate; The identity information and the digital certificate information are organized and stored in the form of a predefined object data structure.

8. The method according to claim 7, wherein the identity information record includes: the public key corresponding to the corresponding object, identity credential information, and the signature corresponding to the identity credential information; The verification based on the identity information includes: The signature of the identity credential information is verified based on the public key.

9. The method according to claim 6, wherein the blockchain node is further configured to: store the digest value and signature of each data in the sending end dataset and the receiving end dataset.

10. The method according to claim 6, wherein the transmitting end is further configured to: mapping data of the sending end data set into different first hash buckets according to a plurality of hash functions predetermined by the receiving end, and if there are a plurality of first hash buckets with unmapped data, randomly inserting the corresponding data into any first hash bucket; If there is a first hash bucket with unmapped data, the corresponding data is directly inserted into the corresponding first hash bucket; if there is no first hash bucket with unmapped data, the corresponding data is stored in the corresponding cache area. The receiving end is also used for: The data in the receiving dataset is mapped to different second hash buckets according to the multiple hash functions. The storage space of the hash tables corresponding to the second hash buckets is the same as that of the first hash buckets. The comparison of the first function result with the second function result from the receiving end includes: The sending end compares the result of the first function with the result of the second function corresponding to the data mapped to the target hash bucket in the receiving end. The position of the target hash bucket in the corresponding hash table is the same as the hash bucket where the data to be intersected is located.

11. A privacy set intersection device, applied at a sending end, wherein the sending end maintains a sending end dataset consisting of data corresponding to different objects; the device comprises: The request initiating unit is used to initiate a cross-interaction request to the receiving end, wherein the receiving end maintains a receiving end dataset consisting of data corresponding to different objects, and the cross-interaction request carries data to be cross-interacted from the sending end dataset; The function result acquisition unit is used to acquire the first function result corresponding to the data to be intersected. The first function result is obtained by processing the data to be intersected based on an unintentional pseudo-random function predetermined by the receiving end and the function seed corresponding to the receiving end. The function result comparison unit is used to compare the first function result with the second function result from the receiving end. If the two correspond to the same global object identifier, it is determined that the data to be intersected belongs to the intersection data between the sending end dataset and the receiving end dataset. The second function result is obtained by the receiving end processing the data in the receiving end dataset based on the unintentional pseudo-random function and the function seed. The global object identifier is generated by the blockchain node invoking the on-chain object registration contract based on the received object registration transaction to target the object indicated by the object registration transaction; and the global object identifier is stored on-chain by the blockchain node.

12. A computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the steps of the method as claimed in any one of claims 6 to 10.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described in any one of claims 6 to 10.

Images