Fully Homomorphic Encryption Use Cases and Gap Analysis for Network Services

Introduction and Background Artificial intelligence (AI) services, network sensing, and remote lookups process sensitive information outside the user's trusted environment. Encryption in transit and at rest protects communication and storage, but an ordinary processing endpoint still accesses plaintext. The privacy question is what that endpoint and the eventual result recipient need to learn to provide the service. In IETF/IRTF, some earlier work on homomorphic encryption (HE) for measurement collection and subsequent fully homomorphic encryption (FHE) presentations describe advances in protected computation . The ciphertext-inference contribution for the Model Context Protocol (MCP) explored an agent invoking a remote tool with local encryption and decryption . IETF 126 discussion identified privacy analysis and FHE evaluation as distinct from MCP protocol integration . This document examines when FHE is useful for general AI inference, integrated sensing and communication (ISAC), and private information retrieval (PIR). For each use case, it identifies the intended privacy outcome, explains where existing non-HE solutions fall short under the stated conditions, and derives requirements that encrypted computation can support. The examples describe high-level processing rather than a protocol. Local processing or other techniques remain suitable where they already meet the requirements.

Terminology This document uses the following terms.

Fully Homomorphic Encryption (FHE):: An encryption scheme that allows computation to be performed directly on ciphertexts, producing an encrypted result that decrypts to the result of the corresponding computation on the plaintext.
Evaluator:: The remote party that performs computation over ciphertexts without holding the decryption secret.
Private Information Retrieval (PIR):: A protocol that allows a client to retrieve an item from a server database without revealing which item was requested.
Keyword PIR (KPIR):: A form of PIR in which the client retrieves the value associated with a keyword without revealing the keyword to the server.
Searchable Symmetric Encryption (SSE):: A symmetric-key construction that supports keyword lookup over an encrypted database using an encrypted index and search tokens.
Integrated Sensing and Communication (ISAC):: A system in which radio signals serve both communication and sensing, for example to detect the presence or movement of objects.

Summary of Potential Gaps Homomorphic encryption (HE) is the general family of encryption methods that can permit computation or evaluation on ciphertexts. Some support only restricted operations; fully homomorphic encryption (FHE) supports general computation. Leveled FHE is configured for a chosen computation depth, while bootstrapping can extend the supported computation . FHE applications can use leveled evaluation for bounded workloads without invoking bootstrapping. This document focuses on applications and uses FHE when referring to the broader family or a documented homomorphic construction . In a general architecture with FHE capability, the evaluator is the remote computing party; the trusted party such as user itself holds protected plaintext and decryption secrets. The listed gaps below motivate encrypted computation under an honest-but-curious evaluator model; they identify where current practice may fall short of the proposed requirements, and are not claims that every non-HE method is insecure. Their mapping appears in . Source anonymity, traffic analysis, and application authorization require complementary controls discussed in .

G1: Plaintext Exposure at the Processing Endpoint Traditional security protocols such as Transport Layer Security (TLS) protect information in transit between endpoints . It does not prevent an application from learning the inference inputs and features, individual ISAC reports, or lookup selection that it processes. Where that application is outside the plaintext trust boundary, the service needs useful computation without disclosing those values. FHE directly addresses this gap for compatible functions.

G2: Coupling of Computation Authority and Plaintext Access Ordinary remote processing requires the computing party to access the inputs and computed results. It therefore cannot enforce a separation between permission to compute and permission to read those values: a party authorized only to evaluate a model or combine reports also gains plaintext access. FHE addresses this gap by enabling evaluation without the decryption secret and returning an encrypted result to an authorized decryptor. Computation authority can thus be granted independently of decryption authority. Deciding who may receive a final result, or limiting its granularity, still requires application policy and appropriate enforcement.

Gx: More Gaps TODO: more privacy-related gaps and their use-case mappings are for further study (FFS).

Use Cases and Requirements

Summary of Use Cases Privacy Gaps and Corresponding Use Cases

Gaps description	Use case(s)
G1: a remote processor learns inference inputs or features, sensing reports, or a lookup selection.	UC1, UC2, UC3
G2: ordinary plaintext processing cannot separate permission to compute from access to the inputs and results.	UC1, UC2
Gx: Other gaps (FFS).	UCx (FFS; mapping to be determined).

Use Cases Each scenario is followed by four parts: example flows, post-conditions, existing non-HE solutions, and potential new requirements. The flows illustrate high-level processing and trust boundaries. Post-conditions are the intended functional and privacy outcomes; they are not guarantees of every existing solution. The requirements are analysis objectives to use FHE.

UC1: General AI Inference Scenario: A user or an agent acting on the user's behalf invokes an externally hosted AI model. Tasks can include image classification, document analysis, or processing conversation-derived features. The service needs remote computation, but its inputs may contain personal or business information. The user wants an agreed inference result without giving the remote model provider access to protected inputs or intermediates. This is the general trusted-side/remote-tool pattern of the earlier MCP contribution . (1) Example Flows: Alice, as a product inspector of the company, uses AI Agent to classify and detect data containing business product privacy, and prevents remote models from obtaining product images and specifications in plaintext:

Alice or her trusted agent prepares the image representation required for the selected inference task and determines the allowed output, for example, product defect detection.
Alice encrypts the image that requires product detection and retains the decryption key. Only the public material required for ciphertext evaluation is configured to the remote network agent.
The network ciphertext inference tool is used for encrypted input without reading original product images or forwarding original data to any third parties.
The tool performs evaluation based on the ciphertext inference model and returns encrypted evaluation results.
Alice or her trusted Agent decrypts the results to obtain the actual product inspection outcomes.

Call summarization is another instance: local speech recognition and segmentation prepare conversation features. The remote tool is responsible for extracting or summarizing the ciphertext call data. It then sends the summary to the participants of the call. The required output is a useful summary rather than an image label; the same input, computation, and release boundaries apply. (2) Post-conditions: The user obtains the agreed inference output at the required quality and timeliness. The remote tool provider has not obtained protected input values or intermediate features (G1). Decryption remains in the trusted domain, and any result supplied to the agent or another recipient is an authorized disclosure (G2). (3) Existing Non-HE Solutions Covering the Use-Case Functionality: Ordinary cloud inference executes the model and returns predictions over TLS, with access and retention policies governing the service. Redaction or feature minimization can reduce what is uploaded. On-device inference keeps processing local. A trusted execution environment (TEE) can isolate remote plaintext inference , with remote attestation supporting a decision to trust that environment . (4) Potential New Requirements Needed to Support the Use Case:

UC1-R1 (G1): Protected inference. Support the agreed remote model function without exposing protected input values or intermediates to the evaluator, while preserving the task's required output quality.
UC1-R2 (G2): Controlled decryption and release. Retain the decryption secret in the trusted domain and return encrypted inference results for authorized decryption. Apply recipient authorization and failure handling that avoids unintended plaintext disclosure.

FHE allows the remote tool to evaluate the selected compatible model and return encrypted results without holding the decryption secret. The earlier demonstration used a convolutional neural network (CNN) to illustrate this pattern . It does not establish feasibility for every AI task. Full generative summarization needs separate evidence; LG U+'s planned HE integration into communication services provides application context for that specialization .

UC2: Privacy-Preserving ISAC Scenario: A facility wants to know the occupancy of an authorized area — basically, "roughly how many people are in this zone right now." The future telecom system uses bistatic sensing: one radio node transmits while another node or a User Equipment (UE) receives the echo, so transmitter and receiver are separated and work together. (1) Example Flows: The facility's application function (AF) requests an occupancy estimate for a defined zone and reporting period. A candidate protected flow is:

The AF specifies the area, the period, and the needed result granularity; the sensing service then decides which contributors and measurements are authorized for that request.
Radio nodes or the UE prepares the selected measurements locally, and then encrypt them on the spot under a compatible computation and key arrangement — the data stays in ciphertext all the way through.
A sensing processing function receives the encrypted reports and performs the agreed fusion or regional aggregation directly without decrypting any individual input; the network function never needs to obtain private information such as the location information.
A trusted result-release authority receives the encrypted result, decrypts it inside its trusted domain, and applies the permitted output policy before releasing the occupancy estimate.
The AF uses the regional estimate for the facility service, without receiving individual reports and without holding decryption authority over them.

(2) Post-conditions: The AF obtains the authorized regional result at the required accuracy and timeliness. The evaluator has not learned protected reports or contributor locations from its inputs (G1). The AF receives only the permitted result and granularity (G2). Observations already available to a sensor before encryption remain outside this protection boundary. (3) Existing Non-HE Solutions Covering the Use-Case Functionality: Academic physical-layer techniques combine transmit beamforming with artificial noise to reduce an unauthorized receiver's ability to infer location from radio observations . At the measurement-reporting stage, local differential privacy can instead perturb each contributor's measurements before collection, allowing aggregation with a quantified privacy and accuracy trade-off . The former protects against radio sensing under its channel and attacker assumptions; it does not hide reports from a processor that receives them in plaintext. The latter can protect contributors from the collector, but its added noise may affect the required occupancy accuracy. These methods do not provide confidential computation on unperturbed reports at an untrusted fusion processor (G1). FHE can support that computation; protection against physical observation and controls on released results remain separate concerns. (4) Potential New Requirements Needed to Support the Use Case:

UC2-R1 (G1): Protected multi-source computation. Support the agreed aggregation over encrypted reports from multiple contributors, with a compatible key arrangement.
UC2-R2 (G2): Restricted result release. Keep report-decryption authority separate from the evaluator and the AF, and return encrypted computation results to a trusted release authority. Apply purpose, area, period, and granularity controls at release.

UC3: Private Retrieval (PIR) for Caller Identification Scenario: An incoming call prompts a device to fetch the current caller-identity or blocking record from a provider's database. The queried number can itself reveal a communication relationship, so the device needs the matching record without telling the provider which number it asked about — and without storing or continuously updating the provider's entire dataset on the device. (1) Example Flows: Bob's phone rings with a number he doesn't recognize. His phone needs the matching record, but the very act of asking "what is number X?" would tell the lookup service who is calling Bob. Here are the detailed steps:

Bob's phone rings with an unknown number. The phone needs the caller record, but it must not send that number in plaintext, since the number itself would expose who is reaching out to whom.
Bob's phone seals number inside an encrypted query — like handing a librarian a closed envelope and saying "please look this up for me," instead of announcing the title out loud. The phone keeps the one key that can open the reply, and the query goes out only under the service's access policy.
The service takes that sealed query and runs it against its entire phonebook in a single pass — imagine feeding an encrypted question through every record at once — without ever opening the envelope. The phonebook itself can stay in plaintext on the provider's side; the one thing the provider never learns is what was asked.
The provider returns an encrypted answer, rather than the entire dataset.
Bob's phone recovers the matching record locally and uses it for display or a blocking decision. The provider never learned which number was queried, and the phone never had to download the full database.

(2) Post-conditions: Bob's device obtains the correct, current record within the application's response budget. The database service has not learned the queried number (G1), and the device has not needed a full local copy of the dataset. These conditions concern selection confidentiality; they do not establish source anonymity or unlinkability. (3) Existing Non-HE Solutions Covering the Use-Case Functionality: Searchable symmetric encryption (SSE) supports keyword lookup over an encrypted database using an encrypted index and search tokens issued under an appropriate key arrangement . It can retrieve matching records without downloading the full database. Common efficient constructions nevertheless reveal a specified leakage profile, such as whether queries repeat and which records match; an evaluator can combine this leakage with auxiliary information to infer queried keywords . Encrypting the records and search tokens therefore does not by itself meet this use case's requirement to conceal the selected number from the evaluator (G1). SSE also assumes an encrypted database and authorized token generation, whereas the caller-information provider may retain its database in plaintext. HE-backed PIR provides a different way to protect selection under the stated deployment conditions. (4) Potential New Requirements Needed to Support the Use Case:

UC3-R1 (G1): Private selection. Support keyword retrieval without exposing the selected number to the database evaluator.
UC3-R2 (G1): Provider-side private retrieval. Meet selection confidentiality while allowing computation at one provider, without full client-side database replication or reliance on non-colluding database replicas.

HE-backed keyword PIR (KPIR) supports these requirements by computing a protected answer to a concealed query. Apple's Live Caller ID Lookup provides a concrete application example , and its library implements the FHE-based Brakerski-Fan-Vercauteren (BFV) scheme . The required homomorphic operations and selected parameters determine whether a lookup workload can run within its service budget, which is the known first FHE application in this use case.

UCx: Other Use Cases TODO: Additional use cases are for further study (FFS).

Evaluation Evaluation checks each use case's post-conditions and potential requirements against its non-HE baseline. State cryptographic parameters and trust assumptions , and distinguish setup from recurring cost.

UC1: assess task-specific inference quality and end-to-end latency; check protected inference (UC1-R1) and authorized result release (UC1-R2).
UC2: assess occupancy accuracy and fusion delay; check report confidentiality (UC2-R1) and permitted output granularity (UC2-R2).
UC3: assess lookup correctness, freshness, and latency; check private selection (UC3-R1) and provider/client deployment costs (UC3-R2).

Report client computation and communication overhead for each flow. TODO: Further evaluation evidence is to be added.

Security and Privacy Considerations G1 confidentiality does not provide execution integrity or availability. Active modification, replay, and denial of service require protection beyond the baseline model. Authentication, protected transport, and appropriate result validation remain necessary. Decrypted values and secret-dependent diagnostics are kept from an untrusted evaluator to avoid decryption oracles . G2 protection depends on key custody and output authority. A sensing release authority that can decrypt raw reports is trusted to enforce the release policy; FHE alone does not enforce aggregate-only access. Sending decrypted inputs or call passages to an additional cloud model exposes them, and repeated sensing results can reveal trajectories. Source and identity linkage are complementary privacy concerns, rather than core gaps solved by FHE. Network origin, timing, size, signaling, and stable identifiers can reveal associations even when the query is encrypted . Source protection and unlinkable credentials require additional mechanisms and stated provider, relay, and issuer collusion assumptions. Key compromise, plaintext logs, and downstream sharing affect all use cases. Query confidentiality also does not establish database secrecy, response correctness, or per-record access restrictions.

IANA Considerations This document has no IANA actions.