A financial sensitive data sharing method based on privacy computing technology

Abstract

The application discloses a financial sensitive data sharing method based on privacy computing technology and relates to the technical field of data security, and solves the technical problems that the existing anonymous query scheme cannot support multiple institutions to share data with a center node, query behavior lacks constraints, and the writing and reading processes are split. The application comprises the following steps: a first client generates a query key and an encryption key according to an identity identifier and a real name attribute, uploads encrypted plaintext data to a center server, the center server stores and distributes unique slot identifiers in buckets, and establishes a corresponding relationship among the three; a second client generates a target query key according to a target identity identifier and a real name attribute and requests bucket metadata; the center server returns bucket parameters, an elliptic curve coordinate list and a mask ciphertext; and the second client calculates a target slot identifier. The application has the advantages of supporting multiple institutions to securely share data, supporting query behavior to be constrained, supporting two-way privacy protection and supporting high query performance.

Description

Technical Field

[0001] This invention belongs to the field of data security technology, specifically relating to a method for sharing sensitive financial data based on privacy computing technology. Background Technology

[0002] In the data circulation scenarios of the financial industry, traditional plaintext data sharing methods are difficult to apply directly due to multiple constraints such as customer privacy protection, data security compliance, and the lack of complete trust between institutions. Existing technologies mainly focus on scenarios where "the querying party initiates a privacy query against the data holder," and their core objective is to return matching results while hiding the query conditions.

[0003] Existing technical solutions mainly fall into three categories: The first category is keyword anonymity query schemes based on homomorphic encryption. Represented by Chinese invention patent CN115269938B, the basic idea is that the responder first bins the data, and the requester constructs a corresponding vector based on the bin containing the keyword to be queried and performs homomorphic encryption. The responder then uses this vector to complete the bin-based index location and data extraction. This type of scheme relies on homomorphic encryption computation in both the bin-based location and data retrieval stages, and requires multiple rounds of ciphertext interaction. When the amount of data within a bin is large, the computational and communication overhead is high, making it difficult to meet the high-performance query requirements of large-scale data scenarios. Furthermore, patent application CN118586025A further proposes a multi-party sequential computation scheme based on homomorphic encryption. The query end broadcasts the encrypted query conditions to all data providers, and each provider sequentially performs polynomial computation on the ciphertext and then transmits the aggregation result. Ultimately, the query end can only know whether the target data exists, but cannot obtain the specific data content, and the query latency increases linearly with the number of participating parties.

[0004] The second category comprises large-scale anonymous query schemes based on bucketing and encrypted location vectors. Represented by Chinese invention patent CN117077209B, this approach first narrows down the candidate data range, then the querying party constructs encrypted location vectors to complete the query. This type of scheme offers some efficiency improvement over traditional schemes, but the location vectors are sparse one-hot encoded, which significantly increases vector length and communication message size when the anonymity space is large. Furthermore, excessively fine bucketing reduces anonymity, creating an inherent contradiction between security and efficiency.

[0005] The third category: Updatable anonymous query solutions for data updates. Represented by Chinese invention patent CN117521152B, these solutions separate query data from update data and employ preprocessing methods such as sharding, bucketing, OPRF processing, and polynomial computation to support partial updates or overall data reconstruction. This type of solution still belongs to a one-way model of "data provider holding data, queryer initiating query," serving scenarios where a single data provider needs to provide anonymous query capabilities to an external party.

[0006] Furthermore, Chinese invention patent CN115730338A proposes a cross-domain data sharing scheme based on a Trusted Execution Environment (TEE). The data provider exports all sensitive data to the data user's TEE environment. The user's application obtains account information through remote authentication and then logs into the database to read the data. While this type of scheme utilizes hardware isolation technology to ensure data security during transmission and storage, its query privacy protection depends on the trustworthiness of the TEE hardware. The data user's database (server) can know which specific data the application reads; the query intent is transparent to the server. Moreover, deployment requires a specific hardware environment, limiting its versatility.

[0007] The common shortcomings of the aforementioned existing technical solutions are:

[0008] (i) Insufficient Scenario Adaptability. Existing solutions primarily address the issue of "clients initiating anonymous queries to servers," which presupposes that the data is originally held solely by the server. They fail to address the problem of "multiple institutions continuously sharing their sensitive data to a central node" in real-world financial scenarios. In homomorphic encryption multi-party sequential computation schemes, such as CN118586025A, each data provider retains its own data, participating only in homomorphic computation upon receiving a query request. They do not continuously upload sensitive data from each institution to a central node for unified sharing and storage. In financial industry consortium sharing scenarios, while the central node handles data aggregation and query services, consortium members typically do not accept the central node directly accessing the plaintext content of data uploaded by each institution, nor do they accept the central node possessing knowledge of each member's specific query information.

[0009] (ii) Limited Query Result Types. Multi-party sequential computation schemes, such as homomorphic encryption, only allow the querying end to determine if the target data exists, but not to obtain the complete data content. This makes it difficult to meet the query needs of financial businesses for detailed customer risk information, overdue records, and other specific data. If the querying end requires complete data content, an additional data acquisition channel must be established, increasing system complexity and security risks.

[0010] (III) Incomplete Privacy Protection. In TEE-based solutions, although encryption is applied throughout the entire upload and storage chain, the database server still knows which data records the querying party has read, and the query intent is transparent to the server. While homomorphic encryption-based solutions hide the query conditions, all data providers must participate in the ciphertext computation. The querying party ultimately learns the existence result, and the intermediaries involved in the computation may also infer the query intent from the information obtained during the computation process. Furthermore, existing solutions lack effective constraints on the querying party's behavior, making it difficult to prevent the querying party from forging query conditions for arbitrary or batch probing queries, posing a risk of misuse of sensitive information.

[0011] (iv) Insufficient dynamic update and large-scale data query capabilities. Existing solutions do not adequately support dynamic updates and high-frequency incremental uploads; homomorphic encryption solutions experience a sharp increase in computational overhead as the data volume increases, and TEE solutions are limited by hardware memory capacity and cannot handle large-scale data. Under large-scale data conditions, the query performance is difficult to meet the low-latency requirements of financial services.

[0012] For the reasons mentioned above, existing technologies are unable to simultaneously meet the comprehensive requirements of security, anonymity, query controllability, update efficiency, and query timeliness in the scenario of sharing sensitive data among multiple institutions in the financial industry. Summary of the Invention

[0013] This invention aims to provide a method for sharing sensitive financial data based on privacy computing technology, which solves the problem that existing technologies cannot simultaneously meet the comprehensive requirements of security, anonymity, query controllability, update efficiency, and query timeliness in scenarios involving the sharing of sensitive data among multiple financial institutions.

[0014] To solve the aforementioned technical problems, the present invention adopts the following technical solution:

[0015] A method for sharing sensitive financial data based on privacy-preserving computation technology, applied in a system architecture consisting of multiple clients and a central server, includes:

[0016] The original data to be shared is obtained through the first client among the multiple clients. The original data includes identity credentials and plaintext data D. A query key Key is generated by performing a hash operation on the identity credentials. The plaintext data D is encrypted to generate ciphertext data EncryptD. The query key Key and the ciphertext data EncryptD are then uploaded to the central server.

[0017] After receiving the query key Key and the encrypted data EncryptD, the central server generates a bucket number based on the query key Key, stores the query key Key and the encrypted data EncryptD in the bucket corresponding to the bucket number, assigns a unique slot identifier Slot to the query key Key, and stores the correspondence between the query key Key, the slot identifier Slot and the encrypted data EncryptD.

[0018] The second client among the plurality of clients performs a hash operation on the target credential to generate a target query key Key', generates a target bucket number based on the target query key Key', and sends a metadata request carrying the target bucket number to the central server;

[0019] In response to the metadata request, the central server reads the bucket parameters corresponding to the target bucket number, constructs subkey seeds for each slot based on the binary code of each slot in the bucket parameters, generates a mask stream using the subkey seeds, performs masking processing on the ciphertext data corresponding to each slot to generate masked ciphertext, generates an elliptic curve coordinate list A, and returns the bucket parameters, the elliptic curve coordinate list A, and the masked ciphertext to the second client.

[0020] The second client calculates the target slot identifier Slot' based on the target query key Key' and the bucket parameter, generates an elliptic curve coordinate list B based on the binary code of the target slot identifier Slot', and sends the elliptic curve coordinate list B to the central server;

[0021] The central server generates an encrypted seed list based on the elliptic curve coordinate list B and the elliptic curve coordinate list A, and returns it to the second client.

[0022] The second client recovers the corresponding mask stream from the encryption seed list based on the binary code of the target slot identifier Slot', and uses the mask stream to perform a demasking operation on the masked ciphertext to obtain the target ciphertext data EncryptD';

[0023] The second client performs a hash operation based on the target credential to generate a decryption key AES_Key', and uses the decryption key AES_Key' to decrypt the target ciphertext data EncryptD' to obtain the target plaintext data D';

[0024] Specifically, when the target credential matches the identity credential, the target plaintext data D' is equal to the plaintext data D; when the target credential does not match the identity credential, the target ciphertext data EncryptD' cannot be correctly decrypted by the decryption key AES_Key'.

[0025] Furthermore, an encryption key AES_Key is generated by performing a SHA-256 hash operation based on the identity credential and the public encrypted salt value e_salt; the decryption key AES_Key' is generated by performing a SHA-256 hash operation based on the target credential and the public encrypted salt value e_salt.

[0026] The encryption of the plaintext data D includes: encrypting the plaintext data D using the encryption key AES_Key and the AES encryption algorithm, as shown in the formula:

[0027] .

[0028] Furthermore, the query key Key is generated by SHA-256 hashing based on the identity credential and the public desensitized salt value h_salt; the target query key Key' is generated by SHA-256 hashing based on the target credential and the public desensitized salt value h_salt.

[0029] Furthermore, the central server assigns a unique slot identifier (Slot) to the query key (Key), including:

[0030] The slot identifier (Slot) is calculated using a slot calculation function, and the formula is as follows:

[0031] ,

[0032] Where Hash is the murmur hash function, r is a random number, and m is the maximum number of slots configured in the bucket;

[0033] Adjust the value of r so that any two query keys Key_i and Key_j within the same bucket satisfy:

[0034] .

[0035] Furthermore, the second client calculates the target slot identifier Slot' based on the target query key Key' and the bucket parameters, including:

[0036] Obtain the maximum number of slots m and a random number r from the bucket parameters;

[0037] The target slot identifier Slot' is calculated using the slot calculation function, and the formula is as follows:

[0038] ,

[0039] Where Hash is the murmur hash function, r is a random number, and m is the maximum number of slots configured in the bucket.

[0040] Furthermore, the maximum number of slots m satisfies m≥n, where n is the number of elements already in the bucket, and m is calculated as follows:

[0041] ,

[0042] Where E is the expected number of times to find a conflict-free r in random trials, and E is a real number greater than 1.

[0043] Furthermore, the bucket number is generated by extracting the first N bits of the query key, where N is 20.

[0044] Furthermore, the central server constructs a subkey seed for each slot based on the binary code of each slot in the bucket parameters, including:

[0045] Calculate the binary length bit_len of the maximum number of slots m in the bucket parameters;

[0046] Generate two sets of random seed lists, {seed0} and {seed1}, with each set having a length of bit_len;

[0047] For each slot, the slot is converted into a binary code of length bit_len. Based on each bit of the binary code, a corresponding random seed is selected from the random seed list {seed0} and the random seed list {seed1} and concatenated. The concatenation result is then hashed to obtain the subkey seed for that slot.

[0048] Furthermore, the central server uses the subkey seed to generate a mask stream and performs masking processing on the ciphertext data corresponding to each slot to generate masked ciphertext, including:

[0049] For each existing slot, obtain the length of the ciphertext data EncryptD corresponding to that slot, generate a mask stream with the same length as the ciphertext data EncryptD using the HKDF algorithm for the subkey seed of that slot, and perform an XOR operation between the mask stream and the ciphertext data EncryptD to generate the mask ciphertext for that slot.

[0050] Furthermore, the method also includes incremental data updates:

[0051] If the central server has already stored the corresponding relationship, when new original data is added, any one of the multiple clients generates a new query key and new encrypted data based on the identity information and real-name attribute in the new original data, and uploads the new query key and the new encrypted data to the central server.

[0052] The central server determines the target bucket number based on the first N bits of the new query key, and stores the new query key and the new encrypted data into the corresponding bucket;

[0053] The central server re-executes the slot allocation operation for the corresponding bucket, reassigning a unique slot identifier to all query keys within the bucket, including newly added data, and updating the corresponding relationship.

[0054] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0055] This invention constructs a unified query key derived from identity identifiers and real-name attributes, and establishes a three-level storage structure of "bucket number - slot identifier - encrypted data" on the central server. This enables multiple institutions to securely share sensitive data with the central node, overcoming the limitations of existing technologies that only support existence judgments and cannot obtain complete data content. It allows the querying party to obtain the complete plaintext of the target data through an anonymous query method, meeting the query needs of financial businesses for specific data content such as detailed customer risk information and overdue records.

[0056] This invention enables the client to independently calculate the target slot identifier and, in conjunction with an elliptic curve coordinate list interaction and mask transmission recovery mechanism, completes data extraction. This ensures that the central server remains unaware of the target slot identifier throughout the query process and cannot determine which specific data record the querying party has read, thus achieving complete anonymity of the query intent to the server. Compared to solutions relying on TEE hardware, this invention does not depend on any specific hardware, is a purely software cryptographic solution, has wider deployment applicability, and offers a higher level of privacy protection.

[0057] This invention designs the query location credential and the data decryption credential to be of the same origin, ensuring that the querying party can only complete location and decryption when they simultaneously possess the correct identity identifier and real-name attributes. When the query credential and identity credential do not match, the decryption key is different from the encryption key, and AES decryption fails due to authentication tag verification failure, resulting in invalid plaintext. This mechanism directly constrains query behavior at the cryptographic level, effectively preventing forged query conditions and mass probing attacks. Compared to existing solutions that lack constraints (homogeneous encryption) or rely solely on indirect constraints through application auditing (TEE), this method offers stronger security and reliability.

[0058] This invention employs a bucketing and slot mechanism, mapping query keys to unique slots. During a query, only a small amount of data needs to be processed within the target bucket, eliminating the need to traverse the entire dataset. Real-world testing shows that the response latency for queries involving tens of millions of data points is within 50 milliseconds, and the query latency does not increase linearly with the total data volume. This overcomes the shortcomings of homomorphic encryption schemes, where computational complexity increases dramatically with data volume, and TEE schemes, which are limited by hardware memory capacity. Furthermore, this invention supports dynamic updates of incremental data and slot reallocation without requiring a full data reconstruction, thus balancing the comprehensive needs of large-scale dynamic data updates and high-performance queries in financial scenarios. Attached Figure Description

[0059] The present invention will be described by way of example and with reference to the accompanying drawings, wherein:

[0060] Figure 1 A schematic diagram illustrating a method for sharing sensitive financial data based on privacy computing technology provided by the present invention;

[0061] Figure 2The graph shows the test results for a single query response latency of 43ms in this invention.

[0062] Figure 3 The graph shows the test results for a single query response latency of 46ms in this invention. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the embodiments and accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. The components of the embodiments of this application described and marked in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0064] In the description of the embodiments of this application, it should be noted that the terms "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product of the invention is in use. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. In addition, the terms "first," "second," and "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0065] In the actual deployment of sensitive data sharing among multiple institutions in the financial industry, directly adopting traditional anonymous query solutions will face the following technical problems:

[0066] First, there's the issue of concealed location and complete data retrieval during data writing. In scenarios where multiple institutions continuously upload data to a central node, each data entry is independently generated by the uploader, and the central node cannot know the total amount and distribution of data in advance. If sequential storage is used, subsequent queries need to traverse the entire dataset or rely on plaintext field indexes, which compromises privacy and reduces performance. If existence-based encoding methods such as Bloom filters are used, the storage location of individual data entries cannot be accurately located, and dynamic deletion and updates are difficult to support. Furthermore, while multi-party sequential computation schemes based on homomorphic encryption (such as CN118586025A) can achieve existence-based queries, the querying end can only know whether the target data exists, not the complete data content. If the querying end needs to obtain specific data such as detailed customer risk information or overdue records, an additional data acquisition channel must be established, increasing system complexity and security risks. Therefore, a bucketing and slot allocation mechanism is needed that can uniquely and deterministically map any uploaded data to the server storage structure without revealing the original identification information, while also supporting the querying end in retrieving the complete data content.

[0067] Second, there is the issue of target location concealment and the thoroughness of privacy protection during the query process. During the client-side query phase, if the client directly informs the server of the target slot, query privacy cannot be protected. Existing solutions based on homomorphic encryption or fully anonymous retrieval still have room for optimization in terms of computational load or number of interaction rounds. On the other hand, while cross-domain sharing solutions based on trusted execution environments (such as CN115730338A) utilize hardware isolation technology to ensure the security of data transmission and storage, the database server of the data user still knows which specific data records the application has read. The query intent is transparent to the server, resulting in insufficient privacy protection. Furthermore, deployment depends on specific hardware environments, limiting versatility. Therefore, a query mechanism is needed that, within a limited number of interaction rounds, allows the client to obtain only the encrypted data of the target slot, while the server cannot distinguish the target slot, and is not dependent on specific hardware.

[0068] Third, there is the issue of unified binding of query credentials and decryption credentials, and constraints on query behavior. In financial scenarios, clients may use batch-generated mobile phone numbers or ID card numbers to conduct probing queries. In existing solutions, the construction of the query key and the generation of the decryption key are independent of each other. Even if a client forges query conditions and obtains ciphertext, it may still attempt to decrypt it through other means. Homomorphic encryption schemes lack any constraints on the identity of the querying party, and any querying party can initiate a query. Although TEE-based schemes indirectly constrain application behavior through application auditing and metric binding, they cannot directly constrain malicious human behavior by the querying party. Therefore, it is necessary to design a mechanism that binds query location credentials and data decryption credentials to the same source, so that the credentials used by the queryer to locate data and the keys used to decrypt data have mathematical homology, and the credentials contain real-name attribute information, directly constraining query behavior from a cryptographic level.

[0069] To address this, this invention provides a method for sharing sensitive financial data based on privacy-preserving computing technology. It establishes a closed-loop privacy protection mechanism encompassing "bucket writing—conflict-free slot mapping—inadvertent transmission extraction—decryption using a shared key" by constructing a unified query key derived from identity information (phone number / ID number and name). The core design idea is as follows: During the data sharing phase, the query key is used to anonymize the data through bucketing and unique slot allocation, laying the foundation for subsequent queries; during the stealth query phase, the client reuses the same query key to locate the slot and recovers the mask stream without informing the server of the target slot through elliptic curve coordinate list interaction and mask transmission recovery mechanisms, thereby decrypting the ciphertext; finally, decryption is completed using an AES key of the same origin as the query key. The entire scheme is a pure software cryptography scheme that does not rely on any specific hardware. The server only stores the ciphertext and irreversible slot indexes. It is impossible to associate the plaintext with the queryer throughout the process, and it is impossible to know which specific data the client has read. If the client does not have complete identity information (including name), it cannot accurately locate or decrypt the data, thus achieving effective constraints on query behavior at the cryptographic level.

[0070] The technical solution of this application will be described in detail below with reference to the accompanying drawings and multiple embodiments. Embodiment 1 provides a complete implementation process of the invention, describing the entire process from data writing to anonymous querying in steps, and detailing the cryptographic operations in each step; Embodiment 2 verifies the anti-forgery query security effect of the invention; Embodiment 3 provides performance test data for the invention.

[0071] Example 1

[0072] This embodiment demonstrates the complete implementation process of the present invention through a complete end-to-end application scenario, following the step-by-step sequence. This scenario involves two parties: the uploader holding the original data (first client), and the queryer needing to retrieve the data (second client). Both parties are alliance members and share the same set of publicly available system parameters: the public encrypted salt value e_salt and the public de-identified salt value h_salt.

[0073] Step 1: The first client encrypts the data to be shared and uploads the data to the central server.

[0074] First, the data to be shared is collected using the first client. Each piece of data to be shared has three fields: customer identity information x (such as mobile phone number, ID card number, or bank card number); the customer's real-name attribute y (usually the name); and the customer's plaintext data D. The identity information x and the real-name attribute y serve as identity credentials, which are used for queries.

[0075] Next, based on the identity information x, real-name attribute y, and public desensitized salt value h_salt, a query key Key is generated using SHA-256 hashing, with the formula as follows:

[0076] ,

[0077] Here, ‖ represents the string concatenation operation.

[0078] Simultaneously, based on the identity information x, real-name attribute y, and public encrypted salt value e_salt, the encryption key AES_Key is generated through SHA-256 hash operation, with the formula as follows:

[0079] ,

[0080] Next, the plaintext data D is encrypted using the AES algorithm and the encryption key AES_Key to generate the ciphertext data EnceyptD, as shown in the formula:

[0081] .

[0082] For example, suppose the original data obtained is: x = "135xxx", y = "Zhang San", D = "This is a test message", e_salt = "encryption_salt_2023", h_salt = "hashing_salt_2023". Then the following data can be obtained through the above steps:

[0083] ,

[0084] ,

[0085] .

[0086] Finally, the query key (Key) and the encrypted data (EncryptD) are uploaded to the central server.

[0087] Step 2: The received data is stored in buckets by the central server.

[0088] After receiving the query key (Key) and encrypted data (EncryptD), the central server extracts the first N bits of the query key (Key) as the bucket number (Bucket_ID), using the following formula:

[0089] ,

[0090] Here, head(Key,N) represents extracting the first N bits of the binary representation of the Key and converting them into an integer. In this embodiment, N=20, and the total number of buckets is 2. 20 .

[0091] Next, the central server stores the query key Key and the encrypted data EncryptD into the bucket corresponding to the bucket number Bucket_ID.

[0092] For example, the first 20 digits of Key="d08d77..." are converted to an integer to obtain the bucket number Bucket_ID=854231, and the Key and EncryptD are stored in bucket 854231.

[0093] Then, the central server assigns a unique slot identifier (Slot) to the query key within the bucket, including:

[0094] The slot identifier (Slot) is calculated using a slot calculation function, and the formula is as follows:

[0095] ,

[0096] Where Hash is the murmur hash function, r is a non-negative integer, and m is the maximum number of slots configured in the bucket.

[0097] It is worth noting that the value of r needs to be adjusted so that any two query keys Key_i and Key_j within the same bucket satisfy the following relationship, thereby ensuring that each query key corresponds to a unique slot identifier:

[0098] ,

[0099] The calculation result for each query key is the slot identifier for that query key.

[0100] Finally, the central server stores the correspondence between the query key (Key), the slot identifier (Slot), and the encrypted data (EncryptD), which is stored in the corresponding bucket in the form of a triple (Key, Slot, EncryptD).

[0101] It should be noted that, regarding the estimation method for the maximum number of slots m, this embodiment provides the following preferred scheme: Assuming that the number of elements already in the bucket is n, and the expected number of attempts is E (E is a real number greater than 1, representing the expected number of times to find a conflict-free r in random attempts), then the maximum number of slots m can be estimated as follows:

[0102] ,

[0103] When the actual number of attempts exceeds the preset threshold, the value of m is adjusted (e.g., by doubling) to ensure that the actual number of attempts does not exceed the preset threshold.

[0104] This method allows for rapid estimation of m within constant time. Furthermore, if the number of attempts exceeds 2 to 3 times m, the program can force m to be multiplied, thus finding a reasonable number of bucket slots even faster. While m may be a large number, each communication between the server and client is in binary format, with the first 20 bits used as the bucket ID. This means there are approximately 1 million buckets in total. Even with 10 million data entries, each bucket contains only 10 entries, so the binary length of m is usually less than 10. This is crucial for ensuring high-performance queries; for anonymous queries on tens of millions of data entries, the interface response latency is generally within 50ms.

[0105] For example, bucket 854231 already contains some data. After adding new data, the total number of elements n=10. Assuming the expected number of attempts E=5, the maximum number of slots m can be calculated using the following formula:

[0106] ,

[0107] The central server sets m=32 (rounded up to the power of 2 for easier bitwise operations). By trying different values ​​of r, it was found that when r=37, all data slots do not conflict, and the slot for this data is 9. In this embodiment, the maximum number of slots m is set to 16.

[0108] To better understand this invention, the above-mentioned bucket single hash collision-free slot allocation mechanism will be described in detail below.

[0109] The single-hash slot allocation mechanism in this invention references perfect hashing methods such as CHD (Compress-Hash-Displace) and minimal perfect hashing. This involves finding suitable hash parameters for a set of query keys to map each query key to a non-conflicting slot. However, this invention does not directly adopt the compact global hash construction of CHD. Instead, it focuses on local single-hash collision-free slot allocation for bucketing scenarios: first, the bucket number is determined based on the query key prefix, and the entire data is split into numerous smaller buckets; for each bucket, only a random parameter r needs to be found for a small number of elements within the bucket, ensuring that after Slot = Hash(Key‖r), the slots for all query keys within the bucket are non-conflicting.

[0110] The main difference between this invention and conventional double hashing schemes (such as Cuckoo Hash) is that:

[0111] The number of candidate slots differs. Conventional double hashing calculates two candidate positions (e.g., h1(Key), h2(Key)) for each query key. Insertion may involve eviction, relocation, reconstruction, or stashing mechanisms, and queries require consideration of the two candidate slots or additional records of the actual landing point. In this solution, each query key corresponds to only one definite slot. After obtaining the bucket metadata (maximum number of slots m, random number r), the query end directly calculates the unique slot, without trying two positions or maintaining tableNo, stashing, or relocation paths.

[0112] Unlike the subsequent covert query process, in the subsequent covert query process of this invention (i.e., steps 33 to 35), the second client needs to construct an elliptic curve coordinate list B based on the binary code of the target slot identifier Slot', and obtain the ciphertext seed list returned by the server. and The system accurately extracts the random seed corresponding to the target slot identifier Slot' and ultimately recovers the target ciphertext. This process requires the query client to explicitly know the unique slot location of the target data. If a double-hash scheme is used, the target data may fall in one of two candidate slots, and the query client will face the following problems: First, it is necessary to perform coordinate list construction and seed extraction for both candidate slots separately, doubling the communication and computation workload; second, if the actual data location information is maintained by the server, the server will know the target location of the query client, compromising query anonymity; third, if the location information is maintained by the client, it is necessary to store and transmit this information additionally, increasing system complexity. This solution ensures that each query key corresponds to a unique slot, allowing the query client to execute subsequent processes only around a single, determined slot, thus reducing communication and implementation complexity while maintaining query anonymity.

[0113] The trade-offs between compactness and engineering feasibility differ. This invention does not pursue the extremely compact static hash structure of the CHD scheme, but intentionally retains a certain number of redundant slots (maximum number of slots m) in exchange for lower construction complexity, higher construction success rate, and better incremental update capabilities. In financial data sharing scenarios, query performance, update efficiency, and engineering feasibility are more important than the ultimate compression rate.

[0114] This invention provides a quantitative estimation method for the number of slots. A formula is given to estimate the maximum number of slots m based on the number of elements n in a bucket and the expected number of attempts E, thus enabling each bucket to complete conflict-free slot allocation within a controllable number of attempts.

[0115] In summary, the "single hash" in this invention is not a theoretical basis for hashing proposed out of thin air, but rather an engineering modification based on the idea of ​​perfect hashing and combined with the scenario of "bucketing + hidden query + incremental update + central node ciphertext sharing". Its core effects are: reducing the number of candidate slots and ensuring unique slot location paths, direct query processing flow, no need to maintain additional landing point information, and support for bucket-level local reconstruction, thereby improving engineering efficiency in large-scale data sharing query scenarios.

[0116] Step 3: Query the shared data through the second client, including:

[0117] Step 31: Perform a hash operation on the target credential to generate the target query key Key', generate the target bucket number based on the target query key Key', and send a metadata request carrying the target bucket number to the central server.

[0118] The second client obtains the target identity information x' and target real-name attribute y' to be queried, and generates the target query key Key' using SHA-256 hash operation based on the target identity information x', target real-name attribute y', and common desensitized salt value h_salt. The formula is as follows:

[0119] ,

[0120] Next, the first N bits of the target query key Key' are extracted as the target bucket number, and a metadata request carrying the target bucket number is sent to the central server.

[0121] For example, if the second client obtains x'="135xxx" and y'="Zhang San", then Key' can be calculated using the following formula:

[0122] .

[0123] Since the same hash function and the same input are used, Key' = Key.

[0124] The target bucket number is also obtained as follows: .

[0125] Step 32: The central server responds to the metadata request, obtains the bucket parameters corresponding to the target bucket number, constructs the subkey seed for each slot based on the binary code of each slot in the bucket parameters, generates a mask stream using the subkey seed, performs masking processing on the ciphertext data corresponding to each slot to generate masked ciphertext, generates an elliptic curve coordinate list A, and returns the bucket parameters, elliptic curve coordinate list A, and masked ciphertext to the second client.

[0126] In response to the metadata request, the central server randomly generates a unique string of numbers to represent the current session ID (session_id). Next, it obtains the bucket parameters corresponding to the target bucket number. The bucket parameters include the maximum number of slots m and a random number r.

[0127] Next, the central server performs the following operations based on the bucket parameters:

[0128] (1) Calculate the binary length of the maximum number of slots m:

[0129] ,

[0130] Where bin(m) represents a binary string with a maximum number of slots m, and |·| represents the string length.

[0131] (2) Based on the binary length of the maximum number of slots m, generate two sets of random seed lists {seed0} and {seed1}, each with a length of bit_len, and each seed is a 256-bit random number:

[0132] ,

[0133] .

[0134] For example, assuming the metadata for bucket_id=854231 is read, m=16 (binary 10000), r=37, then the binary length of the maximum number of slots m can be calculated as: bit_len=5. The randomly generated seed list is as follows:

[0135] ,

[0136] .

[0137] (3) For each slot, convert the slot into a binary code of length bit_len. Select the corresponding random seed from {seed0} and {seed1} according to each bit of the binary code and concatenate them. Perform SHA-256 hash operation on the concatenation result to generate the subkey seed of the slot.

[0138] For example, if the 0th bit is 0, then extract the first element of {seed0} and concatenate it; if the 0th bit is 1, then extract the first element of {seed1} and concatenate it. Finally, use SHA256 to generate the complete key seed. Specifically, this can be expressed as follows:

[0139] ,

[0140] Here, select(bit_t) means selecting the corresponding random seed from {seed0} and {seed1} based on the t-th bit of the slot binary code.

[0141] (4) For each existing slot, read the ciphertext data EncryptD corresponding to each slot, and calculate the length of the ciphertext data EncryptD. The subkey seed for this slot is generated using the HKDF algorithm, with a length equal to the length of the ciphertext data EncryptD. Using the same mask stream, and XORing the ciphertext data EncryptD twice with the mask stream, the masked ciphertext for that slot is generated:

[0142] .

[0143] For example, assuming the ciphertext data in the 9th slot of the bucket is EncryptD=3d417e899346a02cc...., and the resulting subkey seed is aafe..., then the mask stream of length |encryptD| generated by the HKDF algorithm is: Then, the ciphertext data is encrypted twice using the mask stream mask, resulting in the final masked ciphertext maskD: .

[0144] (5) Select the elliptic curve secp256r1, set its order to N, and its generator to G. Generate a large integer list a (a∈[0,N-1]) of the same length as bit_len using the elliptic curve secp256r1. Calculate the elliptic curve coordinate list A, and obtain the elliptic curve coordinate list A as follows: .

[0145] For example, suppose the generated list of large integers a is: The list A of elliptic curve coordinates calculated using generators is as follows: .

[0146] (6) Return the current session ID (session_id), bucket parameters (m and r), elliptic curve coordinate list A, and mask ciphertext (maskD) to the second client.

[0147] For example, the returned data is: {"session_id":"ef10b23","A":[ppp1...,ppp2...,ppp3...,ppp4...,ppp5...],"m":16,"r":37,"maskD":[{"0":"mask1","2":"mask2"....}]}.

[0148] Step 33: The second client calculates the target slot identifier Slot' based on the target query key Key' and bucket parameters, generates an elliptic curve coordinate list B based on the binary code of the target slot identifier Slot', and finally sends the elliptic curve coordinate list B to the central server.

[0149] After receiving the data returned by the central server, the second client first uses the maximum number of slots m and the random number r in the bucket parameters to calculate the target slot identifier Slot' using the same slot calculation function as the central server when allocating slot identifiers. It then calculates the binary code (length bit_len) of the target slot identifier Slot', using the following formula:

[0150] .

[0151] It should be noted that the target slot identifier Slot' obtained here is the same as the slot identifier Slot assigned by the central server to the target query key Key'. Without knowing the details within the bucket, the client can calculate the precise slot of the query key on the server using only the publicly available data m and r, which is the basis for stealth queries.

[0152] Next, the second client uses the elliptic curve secp256r1 to generate bit_len random large integers b (b∈[0,N-1], where N is the order of secp256r1), and generates an elliptic curve coordinate list B based on the binary code of the target slot identifier Slot', specifically including:

[0153] Detecting whether each bit of a binary code is 0 or 1:

[0154] If the current bit is 0, then pass calculate;

[0155] If the current bit is 1, then pass calculate;

[0156] Where G is the generator of the elliptic function, * represents elliptic curve multiplication, and A is the list of elliptic curve coordinates.

[0157] Finally, we obtain an elliptic curve coordinate list B, which is the same length as elliptic curve coordinate list A:

[0158] The list of elliptic curve coordinates B is sent to the central server.

[0159] For example, assuming the target slot identifier Slot' calculated by the second client is: Slot' = Hash(Key'∥37) mod 32 = 9, its binary code is 001001, then the generated random large integer list b is: The elliptic curve coordinate list B constructed based on the binary code 001001 is as follows:

[0160] .

[0161] Step 34: The central server generates an encrypted seed list based on elliptic curve coordinate list B and elliptic curve coordinate list A, and returns it to the second client.

[0162] After receiving the elliptic curve coordinate list B, the central server generates an encryption seed list based on elliptic curve coordinate list B and elliptic curve coordinate list A, including:

[0163] For each bit of the binary mask, it is calculated using the following formula:

[0164] ,

[0165] ,

[0166] Then, respectively using and Using the hash value as the key, the corresponding elements in the random seed lists {seed0} and {seed1} are encrypted, which can be expressed by the following formula:

[0167] ,

[0168] ,

[0169] Finally, the ciphertext seed list is obtained. and List of ciphertext seeds and ciphertext seed list Return to the second client. (via the ciphertext seed list) and ciphertext seed list This setting allows the client to retrieve the corresponding ciphertext based on the binary code of the slot.

[0170] For example, the central server receives a list of elliptic curve coordinates. Post-calculation and We obtain K0:

[0171]

[0172] And K1:

[0173] ,

[0174] Then, K0 and K1 are used to encrypt the corresponding elements in the random seed list {seed0} and the random seed list {seed1} respectively, to obtain... and Finally and Return to the second client.

[0175] Step 35: The second client recovers the corresponding mask stream from the encryption seed list based on the binary code of the target slot identifier Slot', and uses the mask stream to perform a demasking operation on the masked ciphertext to obtain the target ciphertext data EncryptD'.

[0176] First, the second client recovers the corresponding random seed from the ciphertext seed list based on the binary code of the target slot identifier Slot'. Specifically, the following operations are performed for each bit of the binary code of the target slot identifier:

[0177] If the current digit is 0, then use the formula. Decryption ,

[0178] If the current digit is 1, then use the formula. Decryption ,

[0179] The resulting list of random seeds is as follows: );

[0180] Next, all the recovered random seeds are concatenated bit by bit to calculate the SHA-256 hash, and the mask stream mask corresponding to the target slot identifier Slot' is generated using the HKDF extended algorithm.

[0181] Finally, the second client uses the mask stream mask' to perform an XOR demasking on the corresponding masked ciphertext in the masked ciphertext, obtaining the target ciphertext data EncryptD', which can be expressed by the following formula:

[0182] .

[0183] Step 36: The second client performs a hash operation on the target credential to generate a decryption key AES_Key', and uses the decryption key AES_Key' to decrypt the target ciphertext data EncryptD' to obtain the target plaintext data D'.

[0184] The second client generates a decryption key using SHA-256 hashing based on the target identity information x', the target real-name attribute y', and the public encrypted salt value e_salt. Finally, it decrypts the target ciphertext data EncryptD' using this key to obtain the final target plaintext data D', which can be expressed as follows:

[0185] ,

[0186] .

[0187] For example, AES_Key'=SHA256("encryption_salt_2023"‖"135xxx"‖"Zhang San"), which is the same as AES_Key in step 1, and decryption yields D'="This is a test message".

[0188] The decryption verification conditions of this embodiment are explained below.

[0189] When the target identity information x' is consistent with the identity information x and the target real name attribute y' is consistent with the real name attribute y (i.e., x'=x and y'=y), Key'=Key, AES_Key'=AES_Key, and the target plaintext data D' is equal to the plaintext data D.

[0190] When the target identity information x' does not match the target identity information x, or the target real-name attribute y' does not match the target real-name attribute y, i.e., AES_Key' ≠ AES_Key, the target encrypted data EncryptD' cannot be correctly decrypted by the decryption key AES_Key'. Decryption fails due to authentication tag verification failure and cannot yield valid plaintext. This ensures that only the querying party possessing both the correct identity information and real-name attribute can successfully decrypt the data, effectively preventing forged queries and mass probing attacks.

[0191] Example 2

[0192] This embodiment further verifies the security effect of the present invention in preventing forged query conditions.

[0193] Suppose a malicious party (second client) attempts to initiate a query using the known mobile phone number "135xxx" and the arbitrarily fabricated name "Wang Wu". This party performs the following operations:

[0194] Calculate the forged query key:

[0195] Key_fake=SHA256(h_salt||"135xxx"||"Wang Wu");

[0196] Due to the collision resistance of the hash function, Key_fake is completely different from Key_true (based on "Zhang San") calculated when writing real data. Key_fake may fall into a completely different bucket, and even if it falls into the same bucket, the slot calculation function will output a different slot value.

[0197] Assuming that the party still obtains the ciphertext data EncryptD_fake of a certain slot through the oblivious transfer protocol, in the final decryption stage, it calculates:

[0198] AES_Keyfake=SHA256(e_salt||"135xxx"||"Wang Wu");

[0199] And the key actually used for encrypting this ciphertext is:

[0200] AES_Keytrue=SHA256(e_salt||"135xxx"||"Zhang San");

[0201] The two are completely different, and AES-GCM decryption will directly throw an exception due to the authentication tag verification failure, making it impossible to obtain any valid plaintext data.

[0202] This mechanism ensures that even if a malicious party can obtain ciphertext fragments at the protocol level, it cannot complete the final decryption without simultaneously holding the complete (identity information + real-name attribute) credentials. Batch trial query attacks are thus effectively blocked.

[0203] Third Embodiment

[0204] This embodiment describes the specific implementation of the present invention in the scenario of data incremental update.

[0205] Under the condition that the central server has stored the above correspondence, when new original data is added, any one of the multiple clients generates a new query key and new ciphertext data according to the identity information and real-name attribute in the new original data, and uploads the new query key and the new ciphertext data to the central server.

[0206] The central server determines the target bucket number according to the first N bits of the new query key, and stores the new query key and the new ciphertext data into the corresponding bucket.

[0207] The central server re-executes the slot allocation operation on the corresponding bucket (that is, repeats the operation of step 1 in the first embodiment), re-allocates a unique slot identifier for all query keys in the bucket including the new data, and updates the correspondence.

[0208] This eliminates the need to re-upload existing data within the bucket, and slot redistribution can be completed solely on the server side. The process of uploading new data and redistributing slots is transparent to the client, thereby enhancing dynamic scalability.

[0209] Example 4

[0210] This embodiment provides performance test data of the present invention in a real deployment environment.

[0211] The test environment was as follows: the central server was configured with a 64-core CPU, 256GB of memory, and a 10 Gigabit network card. The server was developed using Java, the database was MySQL, and the network latency between the client and the server was approximately 5ms.

[0212] The core business table finance_fraud.org_share_data contains more than 10 million records.

[0213] The aforementioned data scale of tens of millions constitutes the test benchmark for subsequent performance verification.

[0214] Figure 2 and Figure 3 The figure shows the response result and time log returned after executing a single query request based on the technical solution of the present invention. As shown in the figure, under the condition that the database contains more than 10 million records, the end-to-end response latency of this query request is 43 milliseconds and 46 milliseconds, respectively.

[0215] The results demonstrate that the technical solution of this invention maintains a single query response latency consistently below 50ms even with tens of millions of data points. Furthermore, given the additional overhead of serialization / deserialization and log output in the load testing program, there is room for further optimization of the pure server-side processing latency in a real production environment. The test results verify the high-performance query capabilities of this solution in large-scale data scenarios; the query latency does not increase linearly with the total data volume but remains stably below 50 milliseconds. This effect stems from the bucketing and slotting mechanism of this solution, where queries only need to process a small amount of data within the target bucket to achieve accurate location and data extraction.

[0216] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for sharing sensitive financial data based on privacy computing technology, applied in a system architecture consisting of multiple clients and a central server, characterized in that: include: The original data to be shared is obtained through the first client among the multiple clients. The original data includes identity credentials and plaintext data D. A query key Key is generated by performing a hash operation on the identity credentials. The plaintext data D is encrypted to generate ciphertext data EncryptD. The query key Key and the ciphertext data EncryptD are then uploaded to the central server. After receiving the query key Key and the encrypted data EncryptD, the central server generates a bucket number based on the query key Key, stores the query key Key and the encrypted data EncryptD in the bucket corresponding to the bucket number, assigns a unique slot identifier Slot to the query key Key, and stores the correspondence between the query key Key, the slot identifier Slot and the encrypted data EncryptD. The second client among the plurality of clients performs a hash operation on the target credential to generate a target query key Key', generates a target bucket number based on the target query key Key', and sends a metadata request carrying the target bucket number to the central server; In response to the metadata request, the central server reads the bucket parameters corresponding to the target bucket number, constructs subkey seeds for each slot based on the binary code of each slot in the bucket parameters, generates a mask stream using the subkey seeds, performs masking processing on the ciphertext data corresponding to each slot to generate masked ciphertext, generates an elliptic curve coordinate list A, and returns the bucket parameters, the elliptic curve coordinate list A, and the masked ciphertext to the second client. The second client calculates the target slot identifier Slot' based on the target query key Key' and the bucket parameter, generates an elliptic curve coordinate list B based on the binary code of the target slot identifier Slot', and sends the elliptic curve coordinate list B to the central server; The central server generates an encrypted seed list based on the elliptic curve coordinate list B and the elliptic curve coordinate list A, and returns it to the second client. The second client recovers the corresponding mask stream from the encryption seed list based on the binary code of the target slot identifier Slot', and uses the mask stream to perform a demasking operation on the masked ciphertext to obtain the target ciphertext data EncryptD'; The second client performs a hash operation based on the target credential to generate a decryption key AES_Key', and uses the decryption key AES_Key' to decrypt the target ciphertext data EncryptD' to obtain the target plaintext data D'; Specifically, when the target credential matches the identity credential, the target plaintext data D' is equal to the plaintext data D; when the target credential does not match the identity credential, the target ciphertext data EncryptD' cannot be correctly decrypted by the decryption key AES_Key'.

2. The method for sharing sensitive financial data based on privacy computing technology according to claim 1, characterized in that: An encryption key AES_Key is generated by performing a SHA-256 hash operation based on the identity credential and the public encrypted salt value e_salt; the decryption key AES_Key' is generated by performing a SHA-256 hash operation based on the target credential and the public encrypted salt value e_salt. The encryption of the plaintext data D includes: encrypting the plaintext data D using the encryption key AES_Key and the AES encryption algorithm, as shown in the formula: 。 3. The method for sharing sensitive financial data based on privacy computing technology according to claim 1, characterized in that: The query key Key is generated by SHA-256 hashing based on the identity credential and the public desensitized salt value h_salt; the target query key Key' is generated by SHA-256 hashing based on the target credential and the public desensitized salt value h_salt.

4. A method for sharing sensitive financial data based on privacy computing technology according to claim 1, characterized in that: The central server assigns a unique slot identifier (Slot) to the query key (Key), including: The slot identifier (Slot) is calculated using a slot calculation function, and the formula is as follows: ， Where Hash is the murmur hash function, r is a random number, and m is the maximum number of slots configured in the bucket; Adjust the value of r so that any two query keys Key_i and Key_j within the same bucket satisfy: 。 5. A method for sharing sensitive financial data based on privacy computing technology according to claim 4, characterized in that: The second client calculates the target slot identifier Slot' based on the target query key Key' and the bucket parameters, including: Obtain the maximum number of slots m and a random number r from the bucket parameters; The target slot identifier Slot' is calculated using the slot calculation function, and the formula is as follows: ， Where Hash is the murmur hash function, r is a random number, and m is the maximum number of slots configured in the bucket.

6. A method for sharing sensitive financial data based on privacy computing technology according to claim 4, characterized in that: The maximum number of slots m satisfies m≥n, where n is the number of elements already in the bucket, and m is calculated as follows: ， Where E is the expected number of times to find a conflict-free r in random trials, and E is a real number greater than 1.

7. A method for sharing sensitive financial data based on privacy computing technology according to claim 1, characterized in that: The bucket number is generated by extracting the first N bits of the query key, where N is 20.

8. A method for sharing sensitive financial data based on privacy computing technology according to claim 1, characterized in that: The central server constructs a subkey seed for each slot based on the binary code of each slot in the bucket parameters, including: Calculate the binary length bit_len of the maximum number of slots m in the bucket parameters; Generate two sets of random seed lists, {seed0} and {seed1}, with each set having a length of bit_len; For each slot, the slot is converted into a binary code of length bit_len. Based on each bit of the binary code, a corresponding random seed is selected from the random seed list {seed0} and the random seed list {seed1} and concatenated. The concatenation result is then hashed to obtain the subkey seed for that slot.

9. A method for sharing sensitive financial data based on privacy computing technology according to claim 8, characterized in that: The central server uses the subkey seed to generate a mask stream and performs masking processing on the ciphertext data corresponding to each slot to generate masked ciphertext, including: For each existing slot, obtain the length of the ciphertext data EncryptD corresponding to that slot, generate a mask stream with the same length as the ciphertext data EncryptD using the HKDF algorithm for the subkey seed of that slot, and perform an XOR operation between the mask stream and the ciphertext data EncryptD to generate the mask ciphertext for that slot.

10. A method for sharing sensitive financial data based on privacy computing technology according to claim 1, characterized in that: The method also includes incremental data updates: If the central server has already stored the corresponding relationship, when new original data is added, any one of the multiple clients generates a new query key and new encrypted data based on the identity information and real-name attribute in the new original data, and uploads the new query key and the new encrypted data to the central server. The central server determines the target bucket number based on the first N bits of the new query key, and stores the new query key and the new encrypted data into the corresponding bucket; The central server re-executes the slot allocation operation for the corresponding bucket, reassigning a unique slot identifier to all query keys within the bucket, including newly added data, and updating the corresponding relationship.

Images