Privacy retrieval method and system based on end-cloud collaborative architecture

Abstract

The invention discloses a privacy retrieval method and system based on an end-cloud collaborative architecture. The method comprises the following steps: S1, system setting and key generation; s2, generating an available-for-sale database; s3, the client C performs batch query generation; s4, the access edge node AEN executes key unification and sending; s5, the gateway edge node GEN executes security verification, ciphertext packaging, implicit routing and sending; s6, the database cloud server DCS makes a response; and S7, the client unpacks. According to the method, edge nodes are introduced to execute ciphertext conversion and aggregation tasks, lightweight LWE query ciphertexts which are from different clients and are generated in respective cryptographic contexts are firstly converted into LWE query ciphertexts with the same cryptographic context, then aggregation is carried out, and RLWE query ciphertexts suitable for SIMD parallel calculation are obtained. Therefore, multiple independent server retrieval operations are compressed into one time.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of communication, and particularly relates to a privacy retrieval method and system based on an end-cloud collaborative architecture. BACKGROUND

[0002] With the popularity of information protection applications such as anonymous communication, secure browsing and private contact discovery, how to obtain information from a server without revealing the query target of a client has become a key technical requirement. Private information retrieval (PIR) is a cryptographic protocol designed to meet this requirement, which allows a client to obtain a specified data item from a server database while ensuring that the server cannot know which item the client is querying.

[0003] To achieve concealment, the basic requirement of the PIR protocol is that the server must process each data item in the database to respond to a single query, which makes the server throughput a key indicator of the performance of the PIR protocol. Throughput is defined as the number of queries that the system can successfully process per unit of time, which can be obtained by calculating the ratio of the database size to the server computing time. To improve the throughput of the PIR protocol, existing technologies mainly form three different technical routes: state-based schemes based on client preprocessing, batch schemes based on amortization of single-client queries, and schemes focusing on optimizing underlying homomorphic encryption primitives.

[0004] The first technical route is a state-based PIR protocol based on client preprocessing. The design idea of this route is to transfer a large amount of computing tasks to a preprocessing stage that is independent of the query, so that each subsequent online retrieval can be executed on the server at a higher speed.

[0005] The second technical route is a batch PIR protocol based on amortization of single-client queries. This route aims to improve efficiency by amortizing the cost of computation, and is particularly suitable for scenarios where a single client needs to initiate multiple queries simultaneously.

[0006] The third technical route is a PIR protocol based on optimization of underlying homomorphic encryption. This route focuses on improving the homomorphic encryption primitive on which the PIR protocol depends, aiming to reduce the throughput of a single query.

[0007] To improve the throughput of the PIR protocol, existing technologies have developed three main approaches: the first is a stateful scheme based on client preprocessing; the second is a batch scheme based on single-client query amortization; and the third is a scheme that optimizes the underlying homomorphic encryption primitives. While all of these approaches can improve system performance under specific conditions, their respective system architectures exhibit corresponding technical problems that urgently need to be addressed when applied to large-scale, multi-client, and dynamic data environments, particularly regarding client resource constraints, data update mechanisms, and multi-client concurrent processing methods. These technical problems will be elaborated upon below.

[0008] First, the client-preprocessed stateful scheme requires the server to pre-compute and generate a unique set of auxiliary data based on the database content and each client's public key during the offline phase. The client must download and store this data completely before initiating an online query. This workflow presents three technical challenges in practical deployment. First, the size of the auxiliary data is proportional to the database size, reaching hundreds of megabytes, placing extremely high demands on client storage and network bandwidth. This makes it difficult to effectively deploy this technology on mainstream resource-constrained terminals such as mobile phones and IoT nodes. Second, since the auxiliary data is generated based on a snapshot of the database at a specific moment, any change to the database content will cause the previously distributed auxiliary data to all clients to become synchronously invalid. Clients must discard the old data and re-download the newly generated version, making this technology unsuitable for dynamic data service scenarios requiring real-time or near-real-time information. Third, because the server must independently generate, store, and manage a massive set of auxiliary data for each client in the system based on their unique public key, the server's computing and storage resources increase linearly with the number of clients, limiting the feasibility of large-scale deployment of this technology as a low-cost public service.

[0009] Secondly, batch processing schemes based on single-client query amortization exhibit architectural limitations when handling concurrent requests from multiple clients. The core mechanism of this scheme relies on parallel techniques such as Single Instruction Multiple Data (SIMD) to amortize the computational cost of multiple queries from a single client. However, when the server simultaneously receives concurrent requests from different clients, each request is encrypted using its own independent key. The mathematical principles of homomorphic operations dictate that they can only be executed between ciphertexts encrypted with the same key; therefore, the server cannot combine ciphertexts from different cryptographic contexts for a single batch operation. This fundamental limitation forces the server to adopt a serial processing mode, meaning it must completely process one client's request batch before starting the next. The direct consequence is that the response time of any client's query depends on its position in the processing queue and the total computation time of all preceding client batches. This latency model, which accumulates with the number of concurrent clients, cannot provide a stable and predictable low-latency quality of service guarantee for interactive applications.

[0010] Finally, the optimization of underlying homomorphic encryption schemes significantly reduces the computation time required to process a single query. For example, the Spiral protocol reduces the noise growth in homomorphic multiplication from exponential to linear by combining different encryption schemes; the LightPIR protocol uses learning with rounding instead of learning with error, achieving lower initial noise. These improvements allow the protocol to use more efficient cryptographic parameters, thus significantly reducing the computation time for a single query. Although these schemes greatly improve the processing speed of a single query, their optimization scope is still limited to the cryptographic context of a single client. When applied to multi-client concurrent scenarios, the concurrent requests received by the server are still encrypted with their own independent keys. Therefore, the server still cannot perform homomorphic computation across the ciphertexts of different clients and must still process requests from different clients independently and serially. Although the execution time of each task in the queue is shortened, the essential serial processing architecture remains unchanged. This means that this technical approach is also unable to effectively address the challenge of the total system throughput being limited by the number of concurrent clients in high-concurrency service scenarios.

[0011] In summary, the three existing mainstream high-throughput PIR (Programmable Interference Resource) technologies employ different technical solutions to address multi-client, dynamic application scenarios. Stateful solutions require clients to hold auxiliary data strongly correlated with the database state, making them difficult to apply in dynamic data environments and resulting in linear storage growth related to the number of clients. Single-client batch processing solutions and underlying encryption optimization solutions, while improving processing efficiency within a single cryptographic context, do not provide a mechanism for parallel computation across different client encryption contexts, thus requiring serial processing of concurrent requests. A common problem faced by these technical solutions is the lack of a parallel processing model compatible with different client cryptographic contexts. Therefore, there is an urgent need in this field to develop a technical solution that does not require clients to hold a large amount of state and can perform parallel batch processing of encryption requests from different clients. Summary of the Invention

[0012] The purpose of this invention is to solve the problem of balancing system throughput, scalability, and query privacy in distributed information retrieval systems when multiple clients concurrently request sparse data. Existing batch PIR protocols rely on a central server that needs to process each client request independently and serially, causing its computational overhead to increase linearly with the number of concurrent clients, constituting a serious computational bottleneck. This makes it impossible to merge requests across clients, greatly limiting the system's throughput and scalability.

[0013] To address the aforementioned issues, this invention proposes an Adaptive Hierarchical Edge Privacy Retrieval Protocol (AHEPIR) based on an edge-cloud collaborative architecture. The core idea of ​​this scheme is to extend the batch PIR protocol, originally designed for single clients, to scenarios with concurrent retrieval by multiple clients, under conditions of limited client resources. This extends the existing batch PIR protocol, originally designed for single clients, to scenarios with concurrent retrieval by multiple clients, thereby improving the throughput of the central server. To achieve this goal, this invention introduces edge nodes to perform ciphertext transformation and aggregation tasks. Lightweight LWE query ciphertexts generated from different clients in their respective cryptographic contexts are first transformed into LWE query ciphertexts with the same cryptographic context, and then aggregated to obtain RLWE query ciphertexts suitable for SIMD parallel computation, thus compressing multiple independent server retrieval operations into a single operation.

[0014] To achieve the above objectives, the present invention adopts the following technical solution:

[0015] The privacy retrieval method based on an edge-cloud collaborative architecture has the following specific steps:

[0016] S1, System Setup and Key Generation: The Key Generation Center (KGC) generates publicly shared parameters and a unified system computing key. KGC assists each registered client in generating a unique private key and a key conversion key for ciphertext conversion via the OPRF protocol. KGC is responsible for responding to client C's OPRF request to derive a secret seed for implicit routing.

[0017] S2, Amortizable Database Generation: Database Cloud Server DCS generates the original database. A one-time preprocessing step is performed to reorganize the data into a database suitable for batch retrieval. ;

[0018] S3, Client C Batch Query Generation: Each client encodes the indexes corresponding to the multiple data items it wants to retrieve into a content matrix containing query index information; simultaneously, the client calculates a permutation based on the initial and target positions of its content in the final aggregated ciphertext, and derives a routing secret seed based on the permutation through the OPRF protocol, and calculates two plaintext mask shares locally; finally, the content matrix is ​​encrypted using the seed-based LWE encryption method, and the encrypted content matrix and the derived seed of the first mask share are sent to the access edge node AEN, and the derived seed corresponding to the second mask share is sent to the mask cloud server MCS;

[0019] S4, Access Edge Node (AEN) performs key unification and transmission: Access Edge Node (AEN) collects encrypted query packets from multiple clients. Its task is to perform key unification, that is, to use the key conversion key submitted by each client with the packet to convert all LWE query ciphertexts encrypted under the client's independent key into LWE ciphertexts encrypted under the unified system computing key. After the conversion is completed, AEN forwards the key-unified query to Gateway Edge Node (GEN). After the conversion is completed, AEN performs a service quality prediction and uses an intelligent scheduling algorithm to determine the best time to send the query, and finally forwards the key-unified query to Gateway Edge Node (GEN).

[0020] In step S5, the gateway edge node (GEN) sequentially performs security verification, ciphertext packaging and format conversion, zero-depth implicit routing, and aggregate query forwarding, ultimately forwarding the aggregate query to the database cloud server (DCS). The GEN aggregates queries from multiple AENs with unified keys. It first performs a security verification based on homomorphic arithmetic. Then, the GEN performs ciphertext packaging and conversion, encapsulating and converting the massive LWE ciphertext under the unified key into a single, unordered RLWE aggregate query. Next, the GEN coordinates with independent mask cloud servers (MCS) to execute a secure two-party computation protocol. The GEN uses its local first mask share to calculate the first intermediate result. Simultaneously, the GEN sends the aggregate ciphertext to the MCS, which uses its second mask share to calculate the second intermediate result. The GEN finally adds the first and second intermediate results and, through zero-multiplication-depth homomorphic computation, rearranges the data slots within the RLWE aggregate query to obtain the correctly ordered aggregate query. Finally, the GEN forwards the aggregate query to the database cloud server (DCS) via a key encapsulation protocol.

[0021] S6, Database Cloud Server DCS Response: The Database Cloud Server DCS processes the aggregated query submitted by the Gateway Edge Node GEN. It calculates the data required by all clients by performing homomorphic multiplication operations and packages all results into an encrypted response for broadcast.

[0022] S7, Client Unpacking: After receiving the encrypted response broadcast by the server, each client decrypts it using its own private key.

[0023] This invention also discloses a privacy retrieval system based on an edge-cloud collaborative architecture for performing the above method, which includes the following modules:

[0024] Key Generation Center (KGC): Responsible for the cryptographic settings of the system. It generates public parameters, a unified system computing key for use by cloud servers, and assists each client in generating its own private key and distributing the corresponding key conversion key by executing the OPRF protocol with the client. KGC is also responsible for responding to the client's OPRF request to derive the secret seed for implicit routing.

[0025] Client C: First, it initiates a registration process with KGC and obtains a key through the OPRF protocol. When it wants to retrieve a set of sparse data items, the client constructs an encrypted batch query packet containing an encrypted batch query LWE content matrix. Based on the OPRF routing seed obtained from KGC, it calculates the plaintext mask share for implicit routing locally and sends its corresponding derived seed to AEN and MCS respectively.

[0026] Access Edge Node (AEN): Used for the preprocessing stage of high-concurrency queries, handling computationally parallelizable tasks; it receives query packets from multiple clients, each encrypted with its own independent key, and uses the conversion key provided by the client to securely convert these query packets into ciphertext encrypted with a unified system computing key, and then forwards the converted ciphertext to the designated Gateway Edge Node (GEN).

[0027] Gateway edge node (GEN): Performs ciphertext packaging and coordinates implicit routing; it receives LWE ciphertexts with unified keys from multiple AENs, first packages all ciphertexts and converts them into a single RLWE aggregate ciphertext that supports SIMD operations, then uses the first mask share derived from the client and collaborates with the mask cloud server (MCS) to perform a secure two-party computation protocol. Through a series of zero-multiplication-depth homomorphic computations, it performs privacy-preserving rearrangement of the data slots inside the aggregate ciphertext, finally generating a unified and correctly ordered RLWE query request and forwarding it to the database cloud server (DCS).

[0028] Mask Cloud Server (MCS): Receives and stores the derived seeds corresponding to the mask shares from the client, and uses these seeds to reconstruct the shares; it works with GEN to complete implicit route calculations. Specifically, the MCS receives aggregated ciphertext from GEN. The second mask share of the local reconstruction is used to perform homomorphic plaintext multiplication, and the result is returned to GEN.

[0029] Database Cloud Server (DCS): Processes single batch PIR queries that are implicitly routed by the gateway edge node (GEN) and broadcasts the encrypted query results to each client.

[0030] The key technical challenges in this invention are mainly solved through the following innovative designs:

[0031] 1. To protect the privacy of users' query targets during the aggregation process, this invention designs an implicit routing mechanism based on secret sharing. Extending the PBC technology in the batch PIR protocol to scenarios with concurrent retrieval by multiple clients requires that the ciphertexts of queries from different clients be arranged according to their independently calculated PBC scheduling order to form ordered ciphertexts. However, existing technologies lack privacy protection for this rearrangement process. Edge nodes executing the aggregation task must keep the target location information of each query hidden, that is, accurately sort the ciphertexts of queries from multiple clients without obtaining specific replacement instructions.

[0032] The implicit routing mechanism of this invention solves the problem of failing to correctly route LWE ciphertext to the ciphertext arrangement position required by PBC technology in resource-constrained multi-party concurrent retrieval scenarios. In this invention, the client interacts with the key center through an Oblivious Pseudo-Random Function (OPRF) to derive a unique secret seed. The client uses this seed to generate two mask shares locally and sends their seeds to the gateway edge node GEN and the cloud server, respectively. During the process of packaging all client LWE ciphertexts into a single RLWE ciphertext, GEN, through a single interaction with the cloud server, completes the routing selection homomorphically at zero multiplication depth without any knowledge of the permutation rules, thereby generating a structurally correct ordered RLWE ciphertext.

[0033] 2. To reduce the computational and communication burden on client devices, this invention employs an asymmetric ciphertext system. In traditional batch PIR protocols, to accommodate SIMD parallel computation on the server side, the client is forced to generate and transmit massive polynomial ciphertexts based on the RLWE encryption scheme, which is unacceptable for resource-constrained devices.

[0034] In this invention, the ciphertext conversion task is performed by edge nodes, allowing clients to employ a lightweight LWE encryption scheme with extremely low communication overhead. Under this scheme, each client only needs to transmit a compact seed and a portion of the query ciphertext, rather than the complete ciphertext, to the edge node, thus minimizing uplink communication. The edge node receives queries from multiple clients and uniformly converts them into a single RLWE aggregated ciphertext request that the server can efficiently process, thereby enabling the protocol to simultaneously satisfy both extremely low communication overhead for clients and high computational throughput for servers.

[0035] 3. To eliminate the security risks associated with reliance on a single trusted key center in traditional solutions, this invention integrates a key blinding generation mechanism based on an unintentional pseudo-random function. Traditional solutions require the key center to generate and know the private keys of all clients, which constitutes a serious security and privacy risk. This centralized key escrow model makes the key center a high-value target for attackers; once compromised, all user keys in the entire system will be leaked, leading to catastrophic consequences. Simultaneously, this also means that the key center itself becomes an omniscient entity, possessing the potential to track and correlate user behavior even without external attacks, which contradicts the original intention of privacy protection.

[0036] The OPRF algorithm introduced in this invention enables clients to generate private keys with the key center without revealing their secret seed, achieving blind key generation and eliminating this trust bottleneck at its source. This mechanism completely returns the ultimate ownership and control of the key to the client. During the interaction, the client's secret seed is blinded locally before being sent, and the key center can only perform its encryption function on this unreadable blinded data. After receiving the return result, the client deblinds locally, thereby independently deriving a private key that is only held by itself. This means that the client's private key is never transmitted over the network or stored on any central server, greatly enhancing the user's key sovereignty and the overall system security.

[0037] 4. To improve the overall scalability and robustness of the system, this invention designs a layered collaborative architecture consisting of access edge nodes (AEN) and gateway edge nodes (GEN). Simply introducing a single edge node would make it a new performance and reliability bottleneck, and would also cause disordered concurrent requests to overwhelm the central node. A single edge computing node has limited computing resources, memory, and network bandwidth. When the number of concurrent clients increases sharply, the node will quickly reach saturation, becoming the performance bottleneck of the entire system, causing a surge in request latency for all users. More seriously, this also creates a single point of failure risk; if this node fails, the entire privacy query service will be completely interrupted.

[0038] This invention's layered architecture decomposes complex edge computing tasks. The AEN (Access Entity) focuses on handling client-related, large-scale parallel key unification tasks, while the GEN (Generation Entity) focuses on implicit routing and ciphertext aggregation tasks requiring the collection of all information and based on multi-party coordination. Specifically, the AEN intelligently schedules query forwarding and proactively shapes traffic to avoid network congestion through service quality prediction and adaptive congestion control algorithms. The AEN is no longer a simple request forwarder; instead, it predicts the GEN's load in real time and employs a jittered, truncated exponential backoff algorithm to smooth the disordered and bursty request traffic generated by clients into a more stable and predictable workload flow for the GEN, thus preventing impact on the central node at the source. Before aggregation, the GEN performs security checks on requests using homomorphic collision detection technology to defend against malicious conflicts. After aggregation, a key encapsulation protocol with forward security reliably forwards the aggregated query to the cloud server, solving the link security problem.

[0039] Typical application scenarios of this protocol in distributed information systems include: 1) Privacy-preserving Database as a Service (DBaaS) scenarios, where multiple tenants of a cloud platform can concurrently query their hosted data without worrying about service providers snooping on the query content. 2) IoT data query scenarios, where numerous sensor nodes can simultaneously query specific historical data or instructions in a central database with privacy. 3) Multi-party privacy data sharing scenarios, where multiple organizations can efficiently retrieve encrypted information from consortium blockchains or shared databases without revealing their query intent. Taking privacy-preserving cloud database services as an example, when multiple enterprise tenants need to concurrently retrieve a small number of different sensitive business records from their cloud-hosted databases, this invention allows edge servers deployed at network access points to aggregate these numerous queries from different enterprises into a single encrypted request to the cloud database. The cloud service provider cannot know the specific query content of any enterprise, thus protecting its trade secrets, and also avoids service delays or resource exhaustion due to handling high-concurrency requests. Attached Figure Description

[0040] Figure 1 This is a block diagram of the privacy retrieval system based on the edge-cloud collaborative architecture of the present invention. Detailed Implementation

[0041] The preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0042] like Figure 1 This embodiment illustrates a privacy retrieval system model architecture based on an edge-cloud collaborative architecture.

[0043] The Adaptive Hierarchical EdgePIR (AHEPIR) protocol proposed in this embodiment consists of six core entities: a Key Generation Center (KGC) responsible for cryptographic setup and key distribution; a Database Cloud Server (DCS) hosting the complete database and responding to final queries; a Masking Cloud Server (MCS) responsible for storing and calculating mask shares and not colluding with the GEN; an Access Edge Node (AEN) and a Gateway Edge Node (GEN) acting as computational intermediaries between clients and the cloud servers; and multiple clients (C) initiating data retrieval requests. Details of each entity are as follows:

[0044] Key Generation Center (KGC): The Key Generation Center (KGC) is a fully trusted entity responsible for initializing and defining all components and parameters required for the entire protocol. It generates public parameters, a unified system computing key for use by the cloud server, and assists each client in generating its own private key and distributing corresponding key conversion keys by executing the OPRF protocol with the client. Simultaneously, the KGC is also responsible for responding to client OPRF requests to derive secret seeds for implicit routing.

[0045] Client C: Client C refers to the end-user device that initiates the PIR request, such as a mobile phone or IoT node. In the technical solution of this invention, the client first initiates a registration process with KGC and obtains a key through the OPRF protocol. When it is necessary to retrieve a set of sparse data items, the client's task is to construct an encrypted batch query packet, which contains an encrypted batch query LWE content matrix, and calculates the plaintext mask share for implicit routing locally based on the OPRF routing seed obtained from KGC, and sends its corresponding derived seeds to AEN and MCS respectively, while ensuring that its own access mode privacy is protected.

[0046] Access Edge Node (AEN): An Access Edge Node (AEN) is a computing agent deployed at the network access layer, geographically close to the client. The AEN is used for the preprocessing stage of high-concurrency queries and is specifically designed to handle massively parallel computing tasks. It does not store any persistent data. Its task is to receive query packets from multiple clients, each encrypted with its own independent key, and securely convert these query packets into ciphertext encrypted with a unified system computing key using a conversion key provided by the client. The converted ciphertext is then forwarded to the designated Gateway Edge Node (GEN).

[0047] Gateway Edge Node (GEN): This is a computing agent deployed in the core network with enhanced computing capabilities. Its core task is to perform ciphertext packaging and coordinate implicit routes. It receives LWE ciphertexts with unified keys from multiple AENs, first packaging all ciphertexts and converting them into a single RLWE aggregate ciphertext that supports SIMD operations. Then, the GEN uses the first mask share derived from the client and collaborates with the Mask Cloud Server (MCS) to execute a secure two-party computation protocol. Through a series of zero-multiplication-depth homomorphic computations, it performs privacy-preserving rearrangement of the data slots within the aggregate ciphertext, ultimately generating a unified, correctly ordered RLWE query request and forwarding it to the Database Cloud Server (DCS).

[0048] Masked Cloud Server (MCS): The Masked Cloud Server (MCS) is an independent, non-colluding computing entity. Its core task is to receive and store the derived seeds corresponding to the mask shares from the client, and to reconstruct the shares using these seeds. It works in conjunction with the Generator (GEN) to perform implicit route computation. Specifically, the MCS receives the aggregated ciphertext from the GEN. It performs homomorphic plaintext multiplication using the second mask share reconstructed locally and returns the result to GEN, but it cannot know the first mask share held by GEN, thus cryptographically guaranteeing the privacy of the routing.

[0049] Database Cloud Server (DCS): The Database Cloud Server (DCS) is the central entity that hosts the complete PIR database. In the technical solution of this invention, its core task is to process single batch PIR queries that are implicitly routed by the gateway edge node (GEN) and broadcast the encrypted query results to each client.

[0050] This embodiment presents a privacy retrieval method based on an edge-cloud collaborative architecture, comprising seven steps:

[0051] The first step is system setup and key generation. In this step, the Key Generation Center (KGC) is responsible for generating globally shared public parameters and a unified system computation key. Simultaneously, the KGC assists each registered client in generating a unique private key and a key conversion key for subsequent ciphertext conversion via the OPRF protocol. Furthermore, the KGC is also responsible for responding to client C's OPRF requests to derive a secret seed for implicit routing.

[0052] The second step is the generation of the amortizable database. In this step, the database cloud server (DCS) generates the original database. A one-time preprocessing step is performed. This process uses PBC technology to reorganize the data into a database (DB) suitable for batch retrieval, enabling a one-time, computationally cost-amortizable retrieval of multiple encrypted queries.

[0053] The third step is batch query generation by client C. In this step, each client encodes the indexes corresponding to the multiple data items it wants to retrieve into a content matrix containing query index information. Simultaneously, based on the query indexes in the content matrix, the client calculates a permutation at the initial and target positions in the final aggregated ciphertext, derives a routing secret seed based on this permutation using the OPRF protocol, and locally calculates two plaintext mask shares. Finally, the content matrix is ​​encrypted using seed-based LWE encryption, and the encrypted content matrix, the derived seed of the first mask share, is sent to the access edge node AEN, while the derived seed corresponding to the second mask share is sent to the mask cloud server MCS.

[0054] The fourth step is for the Access Edge Node (AEN) to perform key unification and intelligent transmission. In this step, the AEN collects encrypted query packets from multiple clients. Its task is to perform key unification, that is, using the key conversion key submitted by each client with the packet, to convert each LWE query ciphertext encrypted under its own client key into LWE ciphertext encrypted under a unified system computation key. After the conversion is completed, The query with the unified key is forwarded to the gateway edge node (GEN). After the conversion is completed, AEN does not forward the query immediately, but performs a quality of service prediction and uses an intelligent scheduling algorithm to determine the best time to send the query to avoid network congestion. Finally, the query with the unified key is forwarded to the gateway edge node (GEN).

[0055] The fifth step involves the gateway edge node (GEN) performing security verification, ciphertext packaging and implicit routing, and reliable transmission. In this step, the GEN aggregates queries from multiple AENs with unified keys. It first performs a security verification based on homomorphic arithmetic to ensure the legitimacy and conflict-free nature of batch requests. Then, the GEN performs ciphertext packaging and transformation, encapsulating and converting the massive LWE ciphertext under the unified key into a single, unordered RLWE aggregate query. Next, the GEN coordinates with independent masked cloud servers (MCS) to execute a secure two-party computation protocol. The GEN uses its local first mask share to calculate the first intermediate result. Simultaneously, the GEN sends the aggregated ciphertext to the MCS, which uses its second mask share to calculate the second intermediate result. Finally, the GEN adds the first and second intermediate results and, through zero-multiplication-depth homomorphic computation, rearranges the data slots within the RLWE aggregate query to obtain the final correctly ordered aggregate query. Finally, GEN will securely forward the aggregate query to the database cloud server DCS through a key encapsulation protocol (i.e., a hybrid encryption protocol) and ensure forward security of the aggregate query forwarding.

[0056] The sixth step is the database cloud server (DCS) response. In this step, the DCS only needs to process the single aggregate query submitted by the gateway edge node (GEN). The server can simultaneously calculate the data required by all clients by performing a single efficient homomorphic multiplication operation and then package all the results into an encrypted response for broadcast.

[0057] The seventh step is client-side unpacking. In this step, each client receives the encrypted response broadcast by the server and decrypts it using its own private key. Since the client knows the preset slot information when it made the query, it can accurately extract its own portion of the result from the decrypted plaintext data.

[0058] The specific steps of the above method embodiments will now be described in detail:

[0059] Step 1: System Setup and Key Generation

[0060] This is the one-time initialization phase of the protocol, as detailed below:

[0061] Step 1.1: System Initialization. KGC runs a system initialization algorithm that receives a security parameter that determines the overall security strength of the system. As input, the algorithm's output consists of two parts: one is the system's publicly available parameters. This is a set of common configurations shared by all participants, such as the dimensions of the cryptographic scheme. Modulus The first is to ensure compatibility of subsequent cryptographic operations; the second is to provide a unified system for calculating key pairs. This key pair defines a unified cryptographic context for homomorphic operations between edge nodes and cloud servers, but it is not exposed to DCS, MCS, or GEN. Furthermore, KGC acts as the server for the OPRF protocol, responding to two types of OPRF requests from clients: one for deriving the client's LWE private key, and the other for deriving the secret seed for implicit routes.

[0062] Step 1.2: Client Registration. For each client C in the system... i The generation and registration of its LWE key vector is an interactive derivation process. This process no longer generates a single secret value, but rather a client-side private key vector. Each component undergoes independent privacy derivation. (Client) First, generate a master secret seed independently on your local machine. Then, it prepares for the upcoming generation. Each dimension of the key vector This derives an independent input. ,in," " indicates a splicing operation.

[0063] Next, the client and KGC execute the OPRF protocol. In the OPRF protocol, It is the master OPRF key held by KGC. It is a hash function responsible for mapping any input string to a group. One of the elements. It is a cyclic group, and all core OPRF cryptographic operations are performed on this group. It is a group The order. This determines the blinding factor. The range of values . This represents the number of inputs / outputs requested by the client in this interaction request. It is the modulus, used to convert the final unblinding result. Convert to an integer within a specific range .

[0064] The client's original input list, which contains A client wants to calculate the raw value of OPRF. . yes The first in the list One original input. yes go through The group elements obtained after hashing. Is the client local for A randomly generated blinding factor. It is blind input. The client calculates... This value is obtained. It is sent to the KGC, which cannot deduce it from the KGC. or . It's a blinded output. KGC received... Then, use its master key. calculate This value is obtained and returned to the client by KGC. These are the unblinded group elements. The client received... Then, use the locally saved... inverse Unblind it and calculate get. This is the final integer output. The client will output the group elements obtained after deblinding. By using the HashToInteger function and taking the modulo of p, we obtain the final integer that can be used in the protocol. ;

[0065] 2) KKGC evaluates Evalute. KGC receives data sent from the client. A blind input KGC uses master keys For each blinded input The key steps in executing the server-side Evaluate computation of the OPRF protocol are: ;

[0066] KGC will calculate Each corresponding blinded output Compiled into a list and will Returned to the client in one go;

[0067] 3) Client-side unblinding. The client unblinds the received data. Blinded output To unblind, obtain A unique pseudo-random output The client receives Blinded output Using the corresponding blinding factor stored locally in step 1), To perform unblinding.

[0068] The unblinding process is as follows: First, calculate... inverse Then calculate the final pseudo-random group elements. ;

[0069] The client will this A pseudo-random output Small integer range required for conversion to LWE key This directly constructs the final LWE private key vector. This key is only used by client C. i The KGC holds the data to encrypt its initial query request, ensuring the privacy of the query content when submitted to the access edge node (AEN). During this process, the KGC cannot obtain the client's... and the final key vector Any component information;

[0070] Subsequently, the client will publish the corresponding public information. Submitted to KGC, KGC calculates the key based on this public information and the system key generated in the previous step. and common parameters Generate a corresponding key conversion key for the client. This key allows the access edge node AEN to securely transfer a data entry device without knowing any private key. Encrypted ciphertext is converted to... The encrypted ciphertext.

[0071] Step 2: Amortizable Database Generation

[0072] This step is performed by the database cloud server (DCS) and aims to perform structured preprocessing on the original database to meet the efficiency requirements of subsequent cross-client batch queries. The specific steps are as follows:

[0073] Step 2.1: Database Preprocessing. The database cloud server DCS runs the PBC.Encode algorithm, which uses a PBC construction based on a 3-way reverse cuckoo hash. Specifically, it preprocesses the original database... For each data item, three different hash functions are used to calculate... 1 candidate bucket, and copy and store the data item to all of them. In each bucket. The core advantage of this encoding structure lies in providing a crucial guarantee: the client can access any... Retrieving individual data can be transformed into retrieving... Each bucket performs a simpler single-point query. Since the server ultimately only needs to perform one query on each bucket... Each codeword is used for calculation, and under normal circumstances This greatly reduces the total computing overhead on the server side.

[0074] Step 3: Client C i Multiple query generation

[0075] When client C i This step is performed when a set of data needs to be retrieved. The input at this stage is the data the client wants to retrieve. The original index set of data items and the system assigns to this client, A set of target slot indexes used to uniquely locate the target slot in subsequent aggregation queries. The core objective of this step is to generate an encrypted query package containing a matrix of content queries and mask shares for privacy rearrangement at edge nodes.

[0076] Step 3.1: Content Matrix Generation. The client first generates the original index set. The input is fed into the PBC scheduling algorithm PBC.GenSchedule. Its specific implementation is as follows: the client locally simulates the 3-way reverse cuckoo hash allocation process used in step 2.1. This simulation uses the same... A hash function, extracted via Cuckoo Hash, is used for its... The algorithm calculates a collision-free optimal query solution using each index. Based on the database's logical bucketing structure, the original index is mapped to a set of... Scheduling index Subsequently, the client generates a file of length [length missing] for each scheduling index. The weight of Hamming is The constant-repetition binary codeword. Ultimately, this Each codeword is stacked as a row vector to form a vector of size . binary content matrix .

[0077] Step 3.2: Implicit Route Mask Share Generation. To ensure that the client's query content is placed accurately and discreetly in the correct location during edge node aggregation, the client needs to generate a set of plaintext mask shares for implicit routing. First, client C... i A unique routing secret seed is derived by performing an OPRF protocol with the KGC. The client then uses this seed locally based on its target slot index set. Using this secret seed, two plaintext mask shares are deterministically generated. and These two masks are constructed to mathematically satisfy... Equivalent to a pointer The selection vector for the target slot is used to hide routing instructions in the secretly shared computation between the two parties.

[0078] Step 3.3: Seed-based LWE encryption. After generating the content matrix... After setting the implicit route mask share, the client employs a seed-based LWE encryption scheme for efficient communication of the content matrix. Perform element-by-element encryption to obtain In this scheme, the large-dimensional random vector required for encryption... Instead of requiring complete generation and transmission, it consists of a compact, public seed. Through a pseudo-random function Deterministically generated when needed. For any plaintext bit. Its encryption calculation is defined by equations (1) and (2): ; ;

[0079] in, It is the ciphertext pattern of the LWE encryption algorithm. It is the client's private key. It is a small noise term. The client only needs to compress it. For messages sent as part of ciphertext, edge nodes can, according to the publicly available... Automatically recover the complete vector The LWE-based ciphertext consists of two parts, in the form of (a, b). (a, b) together form an LWE ciphertext pair; a is a high-dimensional random vector, and b is the scalar component of the ciphertext. This method significantly compresses the amount of uplink communication data on the client side, making it highly suitable for resource-constrained terminal devices.

[0080] Finally, the client will send the encrypted content matrix The key conversion key obtained during the system initialization phase and plaintext mask share The derived seeds are combined into a query packet. This query packet is then sent to the designated access edge node (AEN). Simultaneously, the client sends another plaintext mask share. The corresponding derived seed is sent to the specified masked cloud server MCS.

[0081] Step 4: Unify AEN keys at access edge nodes

[0082] This step is processed in parallel by multiple Access Edge Nodes (AENs) deployed at the network front-end and geographically close to the clients. AENs possess environmental awareness and dynamic decision-making capabilities. To ensure that the ciphertext of queries from various clients is encrypted using the same key before the server performs batch retrieval, AENs use the key conversion key submitted by each client along with the query packet. For each received encrypted query packet, the content matrix implement Algorithm (key conversion algorithm of LWE encryption algorithm).

[0083] The core idea of ​​this algorithm is to cleverly utilize the key exchange of RLWE to efficiently achieve the key exchange of LWE through a three-step process of "embedding-transformation-extraction":

[0084] 1. Embedding: AEN first embeds the input LWE ciphertext Polynomial ring embedded in RLWE This is achieved by using LWE vectors. Transform into a polynomial And construct a temporary RLWE ciphertext. This is achieved through [the means].

[0085] 2. Ring-based key exchange: Subsequently, the algorithm processes this temporary RLWE ciphertext. Perform a standard RLWE.KeySwitch operation to convert the key using the key. Take it from the client key Convert to system computing key .

[0086] 3. Extraction: Finally, the algorithm extracts the new RLWE ciphertext output by RLWE.KeySwitch. 18. Convert back to LWE encrypted format. This is done by converting the polynomial... Convert back to vector and extract only constant term This is what was done. The final result is... That is, calculating the key in the system. The new LWE ciphertext, which maintains the same plaintext, is then generated. After this stage, AEN holds a set of keys computed within the system. The query is encrypted and the key has been unified.

[0087] This algorithm, as a key conversion protocol, can securely transfer the encryption key of ciphertext from the client. Replace with the system computing key issued by KGC. Meanwhile, the plaintext message content remains unchanged during this process. After completing this phase, AEN holds a set of computation keys within the system. The encrypted query with a unified key is the encrypted content matrix. Plaintext mask share submitted by the client Derivative seeds.

[0088] AEN will then execute an intelligent scheduling algorithm, namely an adaptive congestion control algorithm based on the service level protocol, to determine the best time to forward the query, rather than immediately forwarding the query to the single gateway edge node GEN.

[0089] Its decision-making logic consists of two steps:

[0090] 1. Service Quality Prediction: AEN first uses a mathematical model based on the Service Level Agreement (SLA) to calculate and predict the current queuing latency of the gateway edge node (GEN) in real time. Its core function is to calculate the estimated service completion time. The calculation formula is shown in equation (3): ;

[0091] in, and It is the real-time latency and bandwidth obtained from the network status monitoring service. It is the final calculated estimated completion timestamp, which is AEN. j The main basis for decision-making. It is the current timestamp, i.e., AEN j The moment when this decision-making algorithm is activated. It is the network transmission time, i.e., AEN. j The time required to completely transfer the data to GEN. This refers to the new task computation time, specifically the time it takes for GEN to process AEN. j The computation time required for these new tasks themselves.

[0092] The calculation formula is shown in equation (4): ;

[0093] in, It is AENj The size of the data batch to be forwarded this time, and , These data were obtained from the network status monitoring service and from AEN, respectively. j Real-time network latency and available bandwidth to GEN.

[0094] AEN's intelligent scheduling algorithm is based on formula (3). AEN first calculates the current estimated queuing time of GEN. As shown in equation (5): ; ;

[0095] in, This represents the total size of all pending query data in the task queue of the gateway edge node at a given moment. This refers to the speed or throughput of data processing at the gateway edge node.

[0096] 2. Intelligent scheduling decision: AEN will then calculate the... Service Level Agreement thresholds set by the system A comparison is made. This decision-making logic is defined in detail in Algorithm 3. If... If the data is normal, it indicates that the GEN is under normal load, and the AEN will immediately forward its data. Otherwise, it indicates that the GEN is congested, and the AEN will temporarily suspend transmission and use the designed jittered truncation exponential backoff algorithm.

[0097] In the truncated exponential backoff algorithm: This is the batch of data that AEN is preparing to send to GEN. This is a handle to the network coordinator. This is an auxiliary service; AEN obtains the real-time state of the GEN by calling its .GetGENState() method. This is the Service Level Agreement (SLA) threshold. This is the maximum queuing delay that AEN can accept from GEN, if... If this value is exceeded, AEN will initiate backoff. This is the maximum number of retries allowed. This is the base waiting time. It is the basic unit for calculating backoff time. This is the current retry counter. It starts at 0 and increments by 1 each time the algorithm backs off. From the coordinator The total amount of data to be processed in the current queue of GEN. From the coordinator The data processing rate of the acquired GEN. It is the estimated queue waiting time of GEN calculated by AEN, through The calculation yielded the result. : The window size used to calculate the random backoff interval. It is based on the number of retries. Calculations show that . This is the final calculated random backoff time. The above algorithm in the [number]th [period / phase]... On the second retry, AEN will... Choose a random backoff time within the interval to wait, where, This is the basic unit of waiting time. The upper limit of the waiting time increases with the number of retries. Exponential growth allows congested GEN nodes ample time to recover; while random jitter ensures that multiple waiting AENs do not attempt to send again at the same time, thus achieving smooth traffic scheduling. AENs will repeat this check-wait loop until the GEN load falls back to normal. Send again if the threshold is not met, or if the maximum number of retries is reached.

[0098] Step 5: Gateway Edge Node GEN Aggregation and Implicit Routing

[0099] This step is led by the gateway edge node GEN, which is the core of the edge computing layer and is responsible for security verification, ciphertext aggregation, coordinating implicit routing, and reliable forwarding. The specific steps are as follows:

[0100] Step 5.1: Security Verification. Before executing routing, to prevent query conflicts caused by malicious or misconfigured clients (i.e., multiple queries routing to the same aggregation slot), GEN first performs a collision detection based on homomorphic arithmetic. First, GEN requires clients to include an encrypted vector containing their target slot index set P_i in their query packets. GEN then homomorphically adds these encrypted vectors (with a unified key) from all clients to obtain an encrypted aggregation routing vector. .at this time, In each encrypted slot, the plaintext value is equal to the total number of times that slot has been requested; then, GEN leverages the RLWE encryption scheme's strength in arithmetic operations to... Each encrypted element in Homomorphically compute polynomial functions Because only when the plaintext value hour, The result is non-zero, and this operation can effectively identify the slots where collisions have occurred; finally, GEN will... The calculation results are homomorphically summed to obtain a final, single check ciphertext. After generating the checksum, GEN can send it to the trusted entity KGC for decryption verification. If the result is 0, it proves that there is no collision; if the result is not 0, it proves that there is a collision, and GEN will reject this batch processing request and issue an alarm, which greatly enhances the robustness of the protocol.

[0101] Step 5.2: Encrypted Packaging and Format Conversion. After security verification passes, The core task is to prepare for subsequent implicit routing. First, GEN collects all LWE content ciphertexts received from AEN that have undergone key unification. Subsequently, GEN invokes the LWEs-to-RLWE algorithm (an algorithm for converting multiple LWE ciphertexts to RLWE ciphertexts).

[0102] The input to the LWEs-to-RLWE algorithm is a List of LWE ciphertexts The output is a single, packaged RLWE ciphertext. . It includes A list of LWE ciphertext inputs. It is an input list The number of LWE ciphertexts in the text. :list The first in LWE ciphertext (of which) ). The final output of the algorithm is a single, packaged RLWE ciphertext. It is a temporary empty list used to store the ciphertext after format conversion. PACKLWEs is a sub-algorithm responsible for... Multiple ciphertexts in the list are packaged into a single RLWE ciphertext. Homomorphic Trace Evaluation is the computation of homomorphic traces. This is one of the core steps of the algorithm, used to remove the ciphertext after packing. The useless data is discarded, and only the useful data is retained. Plaintext of the original LWE ciphertext. The ring dimension of the target RLWE ciphertext. EvalAuto is a homomorphic automorphism that applies to the ciphertext. Perform a specific slot rotation or replacement operation. It is a homomorphic addition operation. In each iteration, the algorithm will change the current ciphertext Add it to the version transformed by EvalAuto and store the result back. This iterative summation process ultimately achieves the computation of the homomorphic trace.

[0103] The LWE ciphertext packing algorithm recursively packs a string of characters into a single string. The list of individual RLWE ciphertexts is merged into a single RLWE ciphertext. This represents the total number of input ciphertexts. It is the depth of recursion. The final output of the algorithm is a single, merged RLWE ciphertext. : Intermediate result of recursive calls to the even-numbered parts of the list. : Intermediate results of recursive calls to the odd-numbered parts of the list. It is a plaintext polynomial.

[0104] Packing all these LWE content ciphertexts into a single RLWE aggregation query that supports SIMD operations but whose content order is not yet sorted is called... At the same time, GEN also collects all plaintext mask shares submitted by clients. Derived seeds, and used them to reconstruct aggregate mask shares. .

[0105] Step 5.3: Perform zero-depth implicit routing. This step is a secure two-party computation protocol led by GEN and coordinated with MCS. GEN uses packaged aggregate ciphertext... Aggregate mask share of local reconstruction For input. GEN computes the first part of the result locally: GEN uses what it holds. Plaintext polynomials for aggregated ciphertext Perform homomorphic plaintext multiplication (the basic operation of the BFV algorithm, which is the multiplication of plaintext and ciphertext) to obtain the first intermediate ciphertext (i.e., the intermediate result). GEN will aggregate the ciphertext. The result is sent to the Mask Cloud Server (MCS). The MCS computes the second part of the result locally: the MCS uses its reconstructed aggregate mask share. Regarding the received ciphertext Performing homomorphic plaintext multiplication (multiplication between homomorphic ciphertexts, which does not involve ciphertext relinearization and does not consume multiplication depth, i.e., zero multiplication) yields a second intermediate ciphertext. MCS will calculate the results. Securely sent back to GEN. GEN completes the final aggregation locally: GEN will perform the locally computed aggregation. and received from MCS Perform homomorphic addition to obtain the final aggregate query. .

[0106] Because GEN was never informed during this process. MCS was never aware of this. The protocol's non-collusion assumption is strictly guaranteed. Furthermore, the entire computation process involves only homomorphic plaintext multiplication and homomorphic addition, resulting in significantly lower computational overhead and noise growth compared to multi-layer homomorphic multiplication, thus resolving the routing performance bottleneck in high-concurrency PIR.

[0107] Step 5.4: Reliable forwarding of aggregated queries. After the meticulous processing in the above two stages, the data from... Clients, total Each independent LWE query was successfully converted into a single RLWE ciphertext. This final aggregation query, with its internal SIMD slots already handling all client requests, can be efficiently processed in parallel by the cloud server. Finally, the gateway edge node GEN will process this aggregation query... Send to database cloud server It completed its computational proxy task.

[0108] In the aforementioned transmission process, to ensure the security of this critical link, GEN no longer simply relies on a standard TLS channel with the cloud server, but instead implements a hybrid encryption protocol to achieve forward security and stricter trust separation.

[0109] 1) One-time session key generation. GEN first generates a high-strength, one-time-use symmetric session key locally. , It can be obtained from the AES-256 key.

[0110] 2) Session key encapsulation. GEN obtains the BFV unified public key issued by KGC during the initialization phase. GEN uses this public key. For the newly generated one-time session key Perform homomorphic encryption, calculate .

[0111] 3) Encrypt the query payload: Using plaintext As a key, it is used in an efficient, authenticated symmetric encryption algorithm. For that massive aggregate query Encryption is performed to obtain the encrypted payload. .

[0112] 4) Sending and decapsulating security packets: GEN will... and The package is sent to the database cloud server DCS. Upon receiving this package, DCS does not have the private key. It cannot decrypt CS must Forwarded to the Key Generation Center (KGC). KGC is... The sole holder, it uses Decryption To obtain plaintext Then, through an internal secure channel between them, Send to DCS.

[0113] DCS ultimately used the received Decryption Thus, to obtain safely For subsequent calculations. Due to the transmission of each... All of these are random and one-time events, even if the server's long-term master key is lost someday. Even if the data is leaked, the historical communication data intercepted by the attacker cannot be decrypted, thus ensuring the persistent security of past queries, which in turn ensures forward security.

[0114] Step Six: Database Cloud Server (DCS) Response

[0115] When a database cloud server (DCS) performs this step, its computing tasks are greatly simplified.

[0116] DCS received a single aggregate query from the edge node. It preprocesses its database. Perform a homomorphic multiplication operation (RLWE algorithm) on the query. .

[0117] The result of the above operation is an encrypted response vector. All of them have been packaged in their different slots. Each client requests its own data item. DCS then sends this single encrypted response. Broadcast to all clients participating in this round of queries.

[0118] Step 7: Unpack the client

[0119] Each client C i Perform this final step independently to obtain its data.

[0120] Client C i Received encrypted response to broadcast It uses its own unique private key. Execute on the RLWE ciphertext The operation is used to decrypt.

[0121] Decryption yields a plaintext vector. Since the client knows the target slot index set in step three... It can directly extract all the requested data from the corresponding position in the plaintext vector. Count the data items to obtain the final result. .

[0122] The following experiment was conducted to verify that the present invention has significant technical advantages.

[0123] To verify the effectiveness and performance advantages of the AHEPIR scheme in the edge-cloud collaborative architecture of this invention, the following four sets of experiments were designed and executed. The experimental environment was based on the SEAL 4.0 homomorphic encryption library, with the polynomial degree uniformly set. The plaintext modulus is 188417.

[0124] 1. Verification of lightweight client mechanism and communication advantages

[0125] This experiment aims to demonstrate that the client key generation mechanism of this invention is lightweight and that its LWE query scheme has significant uplink communication advantages compared to the baseline PIRANA scheme.

[0126] 1.1 Client Key Generation Overhead

[0127] First, the performance of the OPRF-based client key generation mechanism described in Invention Point 1 was tested. Experimental results show that the local pure computational overhead of OPRF, including both the client and the key center (KGC), is only 0.1960ms. After simulating a 15ms network round-trip latency, the total time for the client to complete key generation was 15.1960ms. This proves that the key generation mechanism is lightweight and efficient, and will not impose a computational burden on resource-constrained clients.

[0128] 1.2 Uplink communication overhead

[0129] Furthermore, the uplink communication overhead of the baseline PIRANA scheme and the AHEPIR scheme of this invention was compared. The baseline PIRANA scheme requires the client to upload the complete RLWE ciphertext query, while the AHEPIR scheme of this invention only requires the client to upload the LWE seed and send it to AEN. Derived seeds of shares and those sent to MCS Derivative seeds of shares.

[0130] As shown in Table 1, the LWE lightweight query mechanism of this invention greatly reduces the uplink communication burden on the client. Depending on the query batch size, the communication overhead compression ratio can reach 91.2% to 99.7%, thus verifying the lightweight client design of Invention Point 1.

[0131] Table 1. Comparison of uplink communication overhead between AHEPIR and the baseline PIRANA scheme.

[0132] 2. Verification of the End-to-Cloud Collaborative Architecture and Implicit Routing Scheme

[0133] This experiment aims to verify that the implicit routing scheme of Invention Point 2 is functionally correct and feasible, and that the edge-cloud collaborative architecture has high throughput and scalability in terms of performance.

[0134] 2.1 Architectural Functionality Correctness

[0135] First, the core functionality of the implicit routing scheme was verified. The privacy of this scheme relies on the non-collusion assumption between GEN and the masked cloud server MCS. This experiment aims to verify whether the homomorphic computation part of the scheme functions correctly and the noise is controllable under this security premise.

[0136] This experiment simulates a client generating a mask seed via OPRF, and using this seed, the client derives two plaintext mask shares locally. ,in The share of derived seeds is sent to GEN, while The derived seed of the share is sent to the masked cloud server MCS. Both GEN and MCS use this seed to reconstruct. and The plaintext polynomial.

[0137] Subsequently, GEN and MCS performed a simulated secure two-party computation: GEN locally processed the encrypted raw data vector with an initial noise level of 55 bits. Perform one plaintext multiplication and you will get Meanwhile, MCS simulations... Performing plaintext multiplication yields GEN ultimately won. And perform a ciphertext addition. Complete the routing.

[0138] Decryption Subsequently, the results were completely consistent with expectations, with only target slots 5, 120, 1024, and 3000 being retained. More importantly, after two plaintext multiplications and one addition, the final ciphertext still retained a 33-bit noise budget. This result proves that the implicit routing scheme of this invention is cryptographically secure and feasible, and has good noise control, sufficient to support subsequent PIR aggregation operations.

[0139] 2.2 Architecture Performance and Throughput

[0140] This invention simulates a In a scenario with concurrent requests from multiple clients, each client requests 32 queries at a time, for a total of [number missing] queries. The performance was compared with the PIRANA baseline for a single client. As shown in Table 2, the architecture of this invention is on par with the baseline in total computation time, but demonstrates a significant throughput advantage in amortized cost.

[0141] Table 2 AHEPIR Architecture and Baseline PIRANA Performance comparison data table

[0142] Experimental results strongly demonstrate the high throughput advantage of the architecture of this invention. The baseline solution takes 290.42 ms to process one client. The architecture of this invention takes 353.55 ms to process 32 concurrent clients, almost the same as the baseline solution. This means that the amortized cost of the architecture of this invention is only 11.05 ms / client, compared with the baseline of 290.42 ms / client, achieving a throughput improvement of more than 26 times, perfectly verifying the scalability of invention point two.

[0143] 3. Verification of AEN Adaptive Congestion Control

[0144] This experiment aims to demonstrate that, in the face of concurrent surges, the congestion control algorithm of AEN can effectively protect the gateway edge node GEN, smooth traffic, and optimize the overall system performance. As shown in Table 3, a scenario of 10 concurrent AEN requests impacting a single GEN was simulated, and the system performance with the congestion control algorithm disabled and enabled was compared.

[0145] Table 3 Comparison of AEN Adaptive Congestion Control Effects

[0146] Experimental data clearly demonstrates that enabling Invention Point 3 congestion control significantly reduces: GEN load: the maximum queue size decreases from 9 to 3. System stability improves: the number of task rejections decreases from 1 to 0. User experience is optimized: the average client latency decreases by approximately 31.5%. This perfectly proves that the Invention Point 3 congestion control mechanism is efficient and necessary.

[0147] 4. GEN security mechanism verification

[0148] This experiment aims to demonstrate that invention point four: GEN's homomorphic collision detection and KEM's reliable forwarding are not only functionally correct, but also have extremely low performance overhead.

[0149] 4.1 Collision detection function correctness

[0150] First, the correctness of the homomorphic collision detection function was verified. The verification method is as follows:

[0151] In test case 1, two clients are simulated requesting the same slot (slot 5). GEN performs a homomorphic summation on the client's encrypted slot vector to obtain... Then execute Operation; In test case 2, simulate two clients requesting different slots (slots 5 and 123) and perform the same homomorphic operation.

[0152] Experimental results show that in test case 1, the decryption result is a non-zero value 2 at slot 5, successfully detecting a collision. In test case 2, the decryption result is 0 in all 4096 slots, confirming no collision. This experiment demonstrates that the mechanism can accurately identify query conflicts in the ciphertext.

[0153] 4.2 Security Mechanism Performance Overhead

[0154] Furthermore, the additional computational latency introduced by Invention Point 4 was measured, as shown in Table 4. The complete security mechanism of Invention Point 4 introduces only 3.5360 milliseconds of computational latency in total. Compared to the total computational time of 353.55 milliseconds for the AHEPIR architecture in Table 2, this security overhead accounts for only about 1.0%.

[0155] Table 4 Performance overhead of security mechanisms

[0156] These two experiments together demonstrate that the mechanism of Invention Point 4 is functionally correct and has negligible performance overhead, significantly enhancing the system's security without reducing performance.

[0157] In summary, the inventive points of this invention are four in total:

[0158] First, an innovation of this invention lies in a key blinding generation mechanism based on an unintentional pseudo-random function. This mechanism solves the security and privacy risks associated with the reliance on a single trusted key center in traditional schemes. The client interacts with the key center without revealing the master secret seed, deriving an LWE private key that is exclusively held by the client through the OPRF protocol. This method eliminates centralized key escrow at its source, ensuring that the key is held solely by the user, avoiding potential risks of key leakage and behavioral tracking, and greatly enhancing the user's key sovereignty and the overall system security.

[0159] Secondly, another innovation of this invention lies in its unique edge computing architecture with end-to-end cloud collaboration, and an efficient, secret-sharing-based "implicit routing" scheme. This architecture achieves high scalability through task decomposition. The architecture consists of a client (C), an access edge node (AEN), a gateway edge node (GEN), a database cloud server (DCS), and a mask cloud server (MCS). AEN is responsible for receiving lightweight LWE queries from the client and performing key unification. GEN focuses on performing cross-client ciphertext aggregation and privacy routing. To address the high multiplication depth and performance bottleneck of traditional homomorphic permutation schemes, this invention innovatively introduces implicit routing: the client derives a routing seed through the OPRF protocol and locally calculates two plaintext mask shares, making their sum mathematically equivalent to a target slot selection vector. After aggregating all LWE ciphertexts into a single RLWE ciphertext, GEN coordinates the mask cloud server (MCS) to efficiently complete the privacy rearrangement of the aggregated data through a single homomorphic computation with zero multiplication depth, using these two mask shares without decryption. This design completely solves the permutation performance bottleneck in high-concurrency PIR, reducing the computational complexity from expensive multi-layer homomorphic multiplication to a single lightweight homomorphic addition and plaintext multiplication.

[0160] Third, the third inventive aspect of this invention lies in the adaptive congestion control capability of the Access Edge Node (AEN). This method aims to avoid overload of the central GEN node through intelligent scheduling. After completing key unification, the AEN does not immediately forward queries. Instead, it performs a Quality of Service (QoS) prediction, using a mathematical model based on the Service Level Agreement (SSA) to calculate and predict the current queuing latency of the GEN in real time. The AEN only forwards queries when the predicted latency is below a threshold; when the latency is too high, the AEN initiates a jittered truncation exponential backoff algorithm to postpone transmission and wait for a suitable opportunity. This method transforms the AEN's task from simple calculation to intelligent traffic scheduling, ensuring the stable operation of the entire system under high load.

[0161] Fourth, the fourth inventive point of this invention lies in the request verification and secure communication mechanism integrated into the gateway edge node (GEN). This method adds two key security features to the protocol: request verification and reliable forwarding. Firstly, regarding security verification, GEN performs a homomorphic collision detection before data rearrangement. By performing homomorphic summation and arithmetic evaluation on the encrypted target slot vectors provided by all clients for verification purposes, it can verify whether two or more queries have been incorrectly assigned to the same aggregation slot without decryption, thus preventing malicious or accidental request conflicts. Based on this, to ensure the final secure delivery of the aggregation query, the method also defines a reliable forwarding mechanism: after aggregation and implicit routing are completed, GEN securely forwards the aggregation query to the database cloud server (DCS) through a key encapsulation protocol with forward security, ensuring that even if GEN's long-term key is leaked, the communication content of a single query remains confidential.

[0162] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the technical solutions of the present invention have been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the present invention, and all such modifications or substitutions should be covered within the protection scope of the present invention.

Claims

1. A privacy search method based on an end-cloud collaborative architecture, characterized in that, The specific steps are as follows: S1, the key generation center KGC generates the public parameters shared by the system and the unified system calculation key; KGC assists each registered client to generate a unique private key and a key conversion key for ciphertext conversion through the OPRF protocol; KGC is responsible for responding to the OPRF request of the client C to derive a secret seed for implicit routing; S2, the database cloud server DCS preprocesses the original database D and reorganizes the data into a database DB suitable for batch retrieval; S3, each client encodes the index corresponding to the multiple data items to be retrieved into a content matrix containing query index information; at the same time, the client calculates a permutation according to the initial position and the target position of the content in the final aggregated ciphertext, and derives a routing secret seed through the OPRF protocol according to the permutation, and locally calculates two plaintext mask shares; finally, the content matrix is encrypted using the LWE encryption method based on the seed, and the encrypted content matrix and the derived seed of the first mask share are sent to the access edge node AEN, and the derived seed corresponding to the second mask share is sent to the mask cloud server MCS; S4, the access edge node AEN uses the key conversion key submitted by each client to convert all LWE query ciphertexts encrypted under the independent key of the client into LWE ciphertexts encrypted under the unified system calculation key one by one; After the conversion is completed, the AEN forwards the query with unified keys to the gateway edge node GEN, and the AEN performs a quality of service prediction at the same time to determine the best transmission opportunity through an intelligent scheduling algorithm, and finally forwards the query with unified keys to the gateway edge node GEN; S5, the gateway edge node GEN sequentially performs security check, ciphertext packaging and format conversion, zero-depth implicit routing, and aggregated query forwarding process, and forwards the finally obtained aggregated query to the database cloud server DCS; S6, the database cloud server DCS processes the aggregated query submitted by the gateway edge node GEN, and calculates the data required by all clients by performing homomorphic multiplication operation, and packages all results in an encrypted response for broadcast; S7, each client receives the encrypted response broadcast by the server and decrypts it using its own private key.

2. The privacy search method based on the end-cloud collaboration architecture of claim 1, characterized in that, Step S1 is specifically as follows: Step 1.1: System initialization; KGC runs An algorithm that receives a security parameter that determines the overall security strength of the system As input, the output of the algorithm contains two parts: one is the public parameter of the system , the second is a unified system calculation key ; Responsible for the server as the OPRF protocol, responding to two kinds of OPRF requests of the client, including: for deriving the LWE private key of the client, and for deriving the secret seed of implicit routing; Step 1.2: Client registration; for each client The generation and registration of its LWE key vector is an interactive derivation process, providing the client with a private key vector. Each component undergoes independent privacy derivation; client First, generate a master secret seed independently on your local machine. Subsequently, the client For the generation to be Each dimension of the key vector This derives an independent input. ,in," This indicates a concatenation operation; next, the client and KGC execute an OPRF protocol once: 1) Client to Input Perform independent blinding processing, and then... A blinded input is submitted to KGC in one go; 2) KGC uses its master key On this Blinded input is computed and a corresponding blinded output is returned to the client once. Blinded input is computed and a corresponding blinded output is returned to the client once. 3) the client de-blinds the received blinded output to obtain an independent pseudo-random output ; The client converts this pseudo-random output into the required integer range for the LWE key, thus directly constructing the final LWE private key vector ; Subsequently, the client will send the corresponding public information to the KGC, which, on the basis of the public information, the system calculation key and the public parameter generated in the previous step, generates a corresponding key conversion key for the client, which allows the access edge node AEN to convert a ciphertext encrypted by into a ciphertext encrypted by without knowing any private key.

3. The privacy search method based on the end-cloud collaboration architecture according to claim 2, characterized in that, In step S2, the database preprocessing is specifically as follows: the database cloud server DCS runs an algorithm that adopts a probability batch coding PBC technology to reorganize the original database. algorithm that adopts a probability batch coding PBC technology to reorganize the original database.

4. The privacy search method based on the end-cloud collaboration architecture of claim 3, characterized in that, Step S3 is specifically as follows: Step 3.1, Content Matrix Generation: The client first inputs the original index set to the scheduling algorithm of PBC, which maps the original index to a set of scheduling indices according to the logical bucketing structure of the database; Subsequently, the client generates a constant weight code binary codeword of length and Hamming weight for each scheduling index. Finally, The code words are stacked as row vectors, jointly forming a binary content matrix of size ; and ; Step 3.2, Implicit Routing Mask Share Generation: The client needs to generate a set of plaintext mask shares for implicit routing; first, the client C i derives a unique routing secret seed by performing an OPRF protocol with the KGC; then, the client locally determines two plaintext mask shares and from the secret seed according to its target slot index set ; the two mask shares are constructed to satisfy mathematically, which is equivalent to a selection vector pointing to the target slot in , thus hiding the routing instruction in the two-party computation of secret sharing; Step 3.3, Seed-based LWE encryption: The client employs a seed-based LWE encryption scheme to encrypt the content matrix element-wise, resulting in ; in this LWE encryption scheme, the large-dimension random vector needed for encryption is deterministically generated from a compact public seed by a pseudo-random function when needed. Finally, the client combines the encrypted content matrix , the key conversion key obtained during the system initialization phase , and the plaintext mask share of the derived seed into a query package, which is then sent to the designated access edge node AEN; At the same time, the client sends another plaintext mask share The corresponding derived seed is sent to the designated mask cloud server MCS.

5. The privacy search method based on the end-cloud collaboration architecture according to claim 4, characterized in that, Step S4 is specifically as follows: AEN uses the key conversion key submitted by each client with the query package , for each received encrypted query package , performs an algorithm that acts as a key conversion protocol, which can securely change the encryption key of the ciphertext from the client's to the system calculation key issued by the KGC , while the plaintext message content remains unchanged during this process; Upon completion of this phase, the AEN holds a set of system- computed keys encrypted, key-unified queries, i.e., encrypted content matrices and client-submitted plaintext mask shares of the derived seed; Subsequently, the AEN determines the best forwarding opportunity based on the adaptive congestion control algorithm of the service level agreement, which dynamically adjusts the sending strategy by predicting the load of the GEN. Computing estimated service completion time ; AEN recalculates GEN's current estimated queue wait time ; Will Service Level Agreement thresholds set by the system Compare; if If this is true, it indicates that the GEN load is normal and the AEN will immediately forward its data. On the contrary, it means that the GEN is in a congested state, and the AEN will suspend sending and use a truncated exponential backoff algorithm with jitter.

6. The privacy search method based on the end-cloud collaboration architecture of claim 5, wherein, Step S5 is specifically as follows: Step 5.1, security check: first, GEN requires the client to additionally include a set of target slot indices in the query package encrypted vector; GEN homomorphically adds all the encrypted vectors of the clients with the same key to obtain an encrypted aggregated routing vector At this time, , the plaintext value of each encrypted slot is equal to the total number of times the slot is requested; then, GEN homomorphically calculates a polynomial function for each encrypted element in ; finally, GEN homomorphically sums up the calculation results of all to obtain a final, single check ciphertext ; after generating the check sum, GEN sends to the trusted entity KGC for decryption verification; if the result is 0, it proves that there is no collision; if the result is not 0, it proves that there is a collision, and GEN will reject this batch request and issue an alarm; Step 5.2, Ciphertext Packing and Format Conversion: First, GEN collects all the LWE ciphertexts of the contents received from AENs, which have been homogenized by the key ; Then, GEN invokes the LWEs-to-RLWE algorithm to pack all these LWE ciphertexts of the contents into a single RLWE ciphertext of the contents, which is SIMD-enabled but not yet arranged in the order of the contents ; Meanwhile, GEN collects all the client-submitted shares of the plaintext mask , which are derived from the seed, and reconstructs the aggregated share of the plaintext mask ; Step 5.3, Execute zero-depth implicit routing: GEN uses the packaged aggregate ciphertext Aggregate mask share of local reconstruction For input; GEN computes the first part of the result locally: GEN uses what it holds. Plaintext polynomials for aggregated ciphertext Performing homomorphic plaintext multiplication yields the first intermediate ciphertext. GEN will aggregate the ciphertext. Send to the mask cloud server MCS; MCS computes the second part of the result locally: MCS uses its reconstructed aggregate mask share. Regarding the received ciphertext Perform homomorphic plaintext multiplication to obtain the second intermediate ciphertext. MCS will calculate the results. Securely sent back to GEN; GEN completes the final aggregation locally: GEN will compute locally. and received from MCS Perform homomorphic addition to obtain the final aggregate query. ; Step 5.4, aggregated query forwarding: the gateway edge node GEN forwards this aggregated query to the database cloud server DCS.

7. The privacy search method based on the end-cloud collaboration architecture of claim 6, characterized in that, During the sending process of step 5.4, a hybrid encryption protocol is executed, which is specifically as follows: 1) One-time session key generation; GEN first locally generates a symmetric session key that is used only once ; 2) Session key encapsulation; GEN obtains the RLWE uniform public key issued by KGC in the initialization phase ; GEN uses this public key to homomorphically encrypt the just generated one-time session key , computing ; 3) Query payload encryption: GEN uses plaintext As the key, a symmetric encryption algorithm with authentication , is used to encrypt the aggregated query , resulting in an encrypted payload ; 4) Sending and decapsulating of security package: GEN sends and packaged to database cloud server DCS; DCS forwards to key generation center KGC; KGC is The sole holder, using Decryption To obtain plaintext Then through an internal secure channel Send to DCS; DCS receives decrypts and thereby securely obtains .

8. The privacy search method based on the end-cloud collaboration architecture of claim 7, characterized in that, Step S6 is specifically as follows: The database cloud server DCS receives the single aggregated query sent by the edge node , the DCS performs a homomorphic multiplication operation on the pre-processed database and the query , the result of the operation is an encrypted answer vector , which has packed in its different slots all the data items requested by the clients respectively; The DCS will send this single encrypted response Broadcast to all clients participating in this round of query.

9. The privacy search method based on the end-cloud collaboration architecture of claim 8, characterized in that, Step S7 is specifically as follows: Client C i Receiving the broadcasted encrypted response , using its own private key Performing decryption on the RLWE ciphertext Operation, after decryption, obtains a plaintext vector, extracts all requested data items from the corresponding positions of the plaintext vector, and obtains the final result .

10. A privacy search system based on end-cloud collaborative architecture, configured to perform the method according to any one of claims 1-9, characterized in that, Specifically includes the following modules: Key Generation Center KGC: responsible for the system's cryptographic settings, generating public parameters, a unified system computing key for cloud servers, assisting each client in generating its independent private key and distributing the corresponding key conversion key by executing the OPRF protocol with the client; KGC is also responsible for responding to the client's OPRF request to derive the secret seed for implicit routing; Client C: first initiates the registration process to KGC, and obtains the key through the OPRF protocol; when retrieving a set of sparse data items, the client constructs an encrypted batch query package, which contains an encrypted batch query LWE content matrix, and based on the OPRF routing seed obtained from KGC, calculates the plaintext mask share for implicit routing locally, and sends its corresponding derived seed to AEN and MCS respectively; Access Edge Node AEN: used for preprocessing stage of high concurrency query, processing large-scale parallel computing tasks; it receives encrypted query packages from multiple clients under their independent keys, and uses the key conversion key provided by the client to securely convert these query packages into ciphertext encrypted under the unified system computing key, and then forwards the converted ciphertext to the designated Gateway Edge Node GEN; Gateway Edge Node GEN: performs ciphertext packaging and coordinates implicit routing; it receives LWE ciphertexts with unified keys from multiple AENs, first packages all content ciphertexts into a single RLWE aggregate ciphertext supporting SIMD operation, then GEN uses the first mask share derived by the client and cooperates with the Mask Cloud Server MCS to execute a secure two-party computation protocol, performs a series of zero-multiplication depth homomorphic calculations to privately rearrange the data slots inside the aggregate ciphertext, finally generates a unified and correctly ordered RLWE query request, and forwards it to the Database Cloud Server DCS; Mask Cloud Server MCS: receives and stores the derived seed corresponding to the mask share from the client, and uses the seed to reconstruct the share; cooperates with GEN to complete implicit routing calculation, specifically, MCS receives the aggregate ciphertext V from GEN, executes homomorphic plaintext multiplication using the locally reconstructed second mask share, and returns the calculation result to GEN; Database Cloud Server DCS: processes the single batch PIR query rearranged by the Gateway Edge Node GEN, and broadcasts the encrypted query result to each client.

Images