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

Abstract

The application discloses a privacy retrieval method and system based on an end-cloud cooperative architecture, and the method comprises the following steps: S1, system setting and key generation; S2, a database generation; S3, a client C batch query generation; S4, an access edge node AEN performs key unification and sending; S5, a gateway edge node GEN performs security check, ciphertext packaging, implicit routing and sending; S6, a database cloud server DCS responds; and S7, a client unpacks. The application introduces an edge node to perform a ciphertext conversion and aggregation task, converts lightweight LWE query ciphertexts generated in respective cryptographic contexts from different clients into LWE query ciphertexts of the same cryptographic context, then performs aggregation, obtains RLWE query ciphertexts suitable for SIMD parallelization calculation, and thus compresses multiple independent server retrieval operations into one.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, specifically relating to a privacy retrieval method and system based on an edge-cloud collaborative architecture. Background Technology

[0002] With the widespread adoption of information protection applications such as anonymous communication, secure browsing, and private contact discovery, retrieving information from a server without revealing the client's query target has become a critical technical requirement. Private Information Retrieval (PIR) is a cryptographic protocol designed to meet this need. It allows clients to retrieve specified data items from a server's database while ensuring that the server cannot know which specific item the client is querying.

[0003] To achieve concealment, the PIR protocol fundamentally requires that the server must process every data item in the database in response to a single query. This requirement makes server throughput a key performance indicator for the PIR protocol. Throughput is defined as the number of queries that the system can successfully process per unit of time, and can be obtained by calculating the ratio of database size to server computation time. To improve the throughput of the PIR protocol, existing technologies have mainly developed three different approaches: stateful schemes based on client preprocessing, batch schemes based on single-client query amortization, and schemes focusing on optimizing underlying homomorphic encryption primitives.

[0004] The first technical approach is a stateful PIR protocol based on client-side preprocessing. The design philosophy of this approach is to offload a large amount of computational work to a query-independent preprocessing stage, allowing subsequent online searches to be executed at high speed on the server.

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

[0006] The third technical approach is the PIR protocol, which is based on underlying homomorphic encryption optimization. This approach focuses on improving the homomorphic encryption primitives on which the PIR protocol relies, 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... The retrieval of individual data can be transformed into the retrieval of individual data... 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] ;

[0080] ;

[0081] 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.

[0082] 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.

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

[0084] 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).

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

[0086] 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].

[0087] 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 .

[0088] 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.

[0089] 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.

[0090] 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.

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

[0092] 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):

[0093] ;

[0094] 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.

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

[0096] ;

[0097] in, It is AEN j 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.

[0098] 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):

[0099] ;

[0100] ;

[0101] 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.

[0102] 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.

[0103] 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. Sending will resume if the threshold is not met, or if the maximum number of retries is reached.

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

[0105] 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 routes, and reliable forwarding. The specific steps are as follows:

[0106] 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.

[0107] 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).

[0108] 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.

[0109] 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.

[0110] 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. .

[0111] 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. .

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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 .

[0117] 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. .

[0118] 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.

[0119] 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.

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

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

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

[0123] 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.

[0124] Step 7: Unpack the client

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

[0126] 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.

[0127] 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. .

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

[0129] 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.

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

[0131] 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.

[0132] 1.1 Client Key Generation Overhead

[0133] 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.

[0134] 1.2 Uplink communication overhead

[0135] 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.

[0136] 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.

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

[0138]

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

[0140] 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.

[0141] 2.1 Architectural Functionality Correctness

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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.

[0146] 2.2 Architecture Performance and Throughput

[0147] 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.

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

[0149]

[0150] 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.

[0151] 3. Verification of AEN Adaptive Congestion Control

[0152] 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.

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

[0154]

[0155] 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.

[0156] 4. GEN security mechanism verification

[0157] 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.

[0158] 4.1 Collision detection function correctness

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

[0160] 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.

[0161] 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.

[0162] 4.2 Security Mechanism Performance Overhead

[0163] 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%.

[0164] Table 4 Performance overhead of security mechanisms

[0165]

[0166] 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.

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

[0168] 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.

[0169] 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.

[0170] 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.

[0171] 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.

[0172] 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 retrieval method based on an edge-cloud collaborative architecture, characterized by: The specific steps are as follows: S1, 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. S2, the database cloud server DCS preprocesses the original database D, reorganizing the data into a database DB suitable for batch retrieval; S3, each client encodes the indexes corresponding to the multiple data items it wants to retrieve into a content matrix containing query index information; at the same time, 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; S4, the access edge node AEN uses 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 query with unified key to the gateway edge node GEN. At the same time, AEN performs a service quality prediction and uses an intelligent scheduling algorithm to determine the best time to send the query with unified key to the gateway edge node GEN. S5, the gateway edge node GEN sequentially performs security verification, encrypted packaging and format conversion, zero-depth implicit routing and aggregation query forwarding process, and forwards the final obtained aggregation query to the database cloud server DCS; S6, the database cloud server DCS, processes aggregate queries 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. In S7, each client decrypts the encrypted response broadcast by the server using its own private key.

2. The privacy retrieval method based on an edge-cloud collaborative architecture as described in claim 1, characterized in that, Step S1 is as follows: Step 1.1: System initialization; KGC running An 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 publicly available system parameters. Secondly, a unified system computing key. ; It is responsible for acting as the server of the OPRF protocol, responding to two types of OPRF requests from the client, including: the LWE private key used to derive the client's secret key, and the secret seed used to derive the implicit route; 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 Regarding this Perform computation on a blinded input, and... Each corresponding blinded output is returned to the client at once; 3) The client receives Deblind the blinded output to obtain A unique pseudo-random output ; The client will this Each pseudo-random output is converted into an integer range required by the LWE key, thereby directly constructing the final LWE private key vector. ; 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 send a data packet containing a key without knowing any private key. Encrypted ciphertext is converted to... The encrypted ciphertext.

3. The privacy retrieval method based on an edge-cloud collaborative architecture as described in claim 2, characterized in that, In step S2, the database preprocessing is as follows: The database cloud server DCS runs... The algorithm uses Probabilistic Batch Coding (PBC) technology to reorganize the original database.

4. The privacy retrieval method based on an edge-cloud collaborative architecture as described in claim 3, characterized in that, Step S3 is as follows: Step 3.1, Content Matrix Generation: The client first generates the original index set. The data is input into the PBC scheduling algorithm, which maps the original index to a set of bins based on the logical bucketing structure of the database. Scheduling index ; Subsequently, the client generates a length of [length missing] for each scheduling index. The weight of Hamming is constant-repetition binary codeword; final, Each codeword is stacked as a row vector to form a vector of size . binary content matrix ; Step 3.2, Implicit Route Mask Share Generation: 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 KGC; subsequently, the client locally determines the 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 within a secret shared computation between the two parties. Step 3.3, Seed-based LWE encryption: The client uses a seed-based LWE encryption scheme to encrypt the content matrix. Perform element-by-element encryption to obtain In this LWE encryption scheme, the large-dimensional random vector required for encryption... From a compact public seed Through a pseudo-random function Generate deterministically when needed; 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, which is then sent to the designated access edge node (AEN). At the same time, the client will send another plaintext mask share. The corresponding derived seed is sent to the specified masked cloud server MCS.

5. The privacy retrieval method based on an edge-cloud collaborative architecture as described in claim 4, characterized in that, Step S4 is as follows: AEN uses the key conversion key submitted by each client along with the query packet. For each received encrypted query packet, the content matrix implement The algorithm, which serves as a key conversion protocol, securely transfers the encryption key of ciphertext from the client's... Replace with the system computing key issued by KGC. Meanwhile, the plaintext message content remains unchanged during this process; Upon completion of this phase, AEN holds a set of in-system computation keys. The encrypted query with a unified key is the encrypted content matrix. Plaintext mask share submitted by the client Derivative seeds; Subsequently, AEN uses the Service Level Protocol's adaptive congestion control algorithm to determine the optimal forwarding timing. This algorithm dynamically adjusts the transmission strategy by predicting the load on GEN. Calculate the estimated service completion time ; AEN then calculated GEN's current estimated queuing time. ; Will Service Level Agreement thresholds set by the system Compare; if This indicates that the GEN load is normal, and the AEN will immediately forward its data; Conversely, if GEN is congested, AEN will temporarily suspend transmission and use a jittered truncation exponential backoff algorithm.

6. The privacy retrieval method based on an edge-cloud collaborative architecture as described in claim 5, characterized in that, Step S5 is as follows: Step 5.1, Security Verification: First, GEN requires the client to include an additional set of indexes for its target slot in the query packet. The encrypted vector; GEN performs homomorphic addition on this encrypted vector from all clients, whose keys have been unified, to obtain an encrypted aggregated 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... Each encrypted element in Homomorphically compute polynomial functions Finally, GEN will put all of them together. The calculation results are homomorphically summed to obtain a final, single check ciphertext. After generating the checksum, GEN will Send the request 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 conflict, and GEN will reject this batch processing request and issue an alarm. Step 5.2, Ciphertext Packaging and Format Conversion: First, GEN collects all LWE content ciphertexts received from AEN that have been key-unified. Subsequently, GEN invokes the LWEs-to-RLWE algorithm to package all these LWE content ciphertexts into a single, SIMD-enabled, but unordered RLWE ciphertext. Meanwhile, GEN collects all plaintext mask shares submitted by clients. The derived seeds are used to reconstruct the aggregate mask shares. ; 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, Aggregate Query Forwarding: The gateway edge node GEN forwards this aggregate query. Send to the database cloud server DCS.

7. The privacy retrieval method based on an edge-cloud collaborative architecture as described in claim 6, characterized in that, During the transmission process in step 5.4, a hybrid encryption protocol is executed, as follows: 1) One-time session key generation; GEN first generates a symmetric session key locally that can only be used once. ; 2) Session key encapsulation; GEN obtains the RLWE 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 ; 3) Query payload encryption: GEN uses plaintext. As a key, it is used in a certified symmetric encryption algorithm. For aggregate queries Encryption is performed to obtain the encrypted payload. ; 4) Sending and decapsulating security packets: GEN will and Package and send to the database cloud server DCS; DCS will Forwarded to the Key Generation Center (KGC); KGC is The sole holder, using Decryption To obtain plaintext Then, through an internal secure channel... Send to DCS; DCS uses the received Decryption Thus, to obtain safely .

8. The privacy retrieval method based on an edge-cloud collaborative architecture as described in claim 7, characterized in that, Step S6 is as follows: The database cloud server DCS received a single aggregate query from the edge node. DCS processes the pre-processed database Perform a homomorphic multiplication operation with the query. The result of the operation is an encrypted response vector. All of them have been packaged in their different slots. Each client requests its own data items; DCS will use this single encrypted response Broadcast to all clients participating in this round of queries.

9. The privacy retrieval method based on an edge-cloud collaborative architecture as described in claim 8, characterized in that, Step S7 is as follows: Client C i Received encrypted response to broadcast Use your own private key Execute on the RLWE ciphertext The operation decrypts the data, resulting in a plaintext vector. The requested data is then extracted from the corresponding positions within this plaintext vector. Count the data items to obtain the final result. .

10. A privacy retrieval system based on an edge-cloud collaborative architecture, used to perform the method as described in any one of claims 1-9, characterized in that, Specifically, it 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, and assisting 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 requests to derive secret seeds for implicit routing. 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. 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). Gateway edge node (GEN): Performs ciphertext packaging and coordinates implicit routing; 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). 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; works with GEN to complete implicit route calculation. Specifically, MCS receives the aggregated ciphertext V from GEN, performs homomorphic plaintext multiplication using the locally reconstructed second mask share, and returns the calculation result to GEN. 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.

Images