16.2.3 Homomorphic Encryption

The Core Concept: Computation on Ciphertext

At its heart, homomorphic encryption is a special type of encryption that permits specific mathematical operations to be performed directly on ciphertext. When you decrypt the result of these operations, it is identical to the result you would have obtained by performing the same operations on the original plaintext. This property is the key to secure outsourced computation.

Let’s denote encryption as Enc() and decryption as Dec(), using a key k. A homomorphically additive scheme would have the following property:

Dec(k, Enc(k, data1) + Enc(k, data2)) = data1 + data2

The server only ever handles Enc(k, data1) and Enc(k, data2). It performs the homomorphic addition operation and produces a new piece of ciphertext. It has no access to k, data1, or data2. This fundamental principle is what enables “blind” data processing.

The Spectrum of Homomorphic Encryption

Not all HE schemes are created equal. They exist on a spectrum of capability and performance, which is a critical consideration for any practical application. Understanding these categories helps you assess the feasibility and potential weaknesses of a system.

Partially Homomorphic Encryption (PHE)

PHE schemes support an unlimited number of operations, but only of one type—either addition or multiplication, but not both. For example, the Paillier cryptosystem is additively homomorphic, making it suitable for tasks like securely summing encrypted votes or financial records.

Somewhat (or Leveled) Homomorphic Encryption (SHE/LFHE)

SHE schemes represent a step up, supporting both addition and multiplication. However, there’s a catch: they can only handle a limited number of operations. Each operation adds a small amount of “noise” to the ciphertext. After too many operations, this noise overwhelms the signal, and the data becomes undecryptable. The maximum number of sequential operations (the “circuit depth”) must be defined before encryption.

Fully Homomorphic Encryption (FHE)

FHE is the most powerful and flexible form, supporting an arbitrary number of both additions and multiplications. It overcomes the noise problem of SHE through a revolutionary process called bootstrapping. Periodically, bootstrapping takes a noisy ciphertext and uses a homomorphically-evaluated decryption circuit to “clean” it, effectively resetting the noise budget. This allows for computations of unlimited depth, but it comes at a significant performance cost—bootstrapping is a very slow operation.

Applications of Homomorphic Encryption in AI

In the context of AI and machine learning, HE primarily enables two powerful use cases: private inference and, to a lesser extent, private training.

Private inference is the more mature application. A client encrypts their input (e.g., a medical image), sends it to a server, which homomorphically evaluates its model (e.g., a tumor detection CNN). The server returns an encrypted prediction (e.g., “malignant” or “benign”), which only the client can decrypt. The server learns nothing about the patient’s image or the diagnosis.

Red Teaming Homomorphic Encryption Systems

Attacking the mathematical foundations of modern HE schemes is generally considered infeasible. As a red teamer, your focus should be on the implementation, configuration, and the surrounding ecosystem. The complexity of HE systems provides a rich attack surface.

• Insecure Parameter Selection: HE schemes require careful parameterization (e.g., polynomial degree, coefficient moduli, noise distribution). Incorrect parameters can lead to insufficient security levels (e.g., a smaller-than-claimed 128-bit security) or, more commonly, correctness failures where computation results in undecryptable ciphertext. If an application allows a user to influence these parameters, it may be possible to force errors or probe the system’s limits.
• Side-Channel Attacks: HE operations are not constant-time. The time taken for multiplication or bootstrapping can vary based on the values within the ciphertext. An attacker with precise timing measurement capabilities on the server could potentially infer information about the underlying plaintext. Power analysis and cache-timing attacks are also theoretical vectors.
• Implementation Flaws: The libraries that implement HE (e.g., Microsoft SEAL, OpenFHE, HElib) are highly complex C++ codebases. Vulnerabilities in serialization/deserialization routines, memory management, or random number generation can undermine the entire system’s security. Fuzzing these components is a valid and potentially fruitful approach.
• Malleability Exploitation: If a scheme is malleable, an attacker can transform a ciphertext into another valid ciphertext that decrypts to a related value. For example, an attacker might intercept an encrypted prediction Enc("approved") and modify it to Enc("denied") without ever knowing the content, causing a denial of service or incorrect business logic execution.
• Key Management Failures: This is the most classic and often most practical attack vector. The security of the entire system relies on the secrecy of the private decryption key. If you can compromise the endpoint where the key is stored, or intercept it in transit, the homomorphic properties become irrelevant. Always investigate the key lifecycle: generation, storage, distribution, and rotation.

Conceptual Code Example: The Workflow

You don’t need to understand the complex lattice cryptography to use an HE library. The following conceptual Python example using a library like TenSEAL illustrates the typical developer workflow for performing a simple encrypted vector operation.

# A conceptual example of the HE workflow.
# This code illustrates the API flow, not a production implementation.

import tenseal as ts

# 1. Setup the context: Defines encryption parameters and security level.
# This is a critical step where vulnerabilities can be introduced.
context = ts.context(
    ts.SCHEME_TYPE.CKKS,
    poly_modulus_degree=8192,
    coeff_mod_bit_sizes=[60, 40, 40, 60]
)
context.generate_galois_keys()
context.global_scale = 2**40

# 2. Client-side: Generate keys. The secret key must NEVER be shared.
secret_key = context.secret_key()
# The public context is serialized and sent to the server.
public_context = context.copy()
public_context.make_context_public()

# 3. Client-side: Encrypt the data.
v1 = [1.0, 2.0, 3.0]
v2 = [4.0, 5.0, 6.0]
enc_v1 = ts.ckks_vector(context, v1)
enc_v2 = ts.ckks_vector(context, v2)

# 4. Server-side: Perform computation on encrypted data.
# The server operates on ciphertexts without the secret key.
enc_result = enc_v1 + enc_v2 # Homomorphic addition
enc_result_mult = enc_v1 * 5 # Homomorphic multiplication with a scalar

# 5. Client-side: Decrypt the result.
result_vector = enc_result.decrypt(secret_key)
# result_vector will be approximately [5.0, 7.0, 9.0]

From a red team perspective, every step in this workflow is a point of interest. How is the context chosen? How is the secret_key stored and managed? How are the ciphertexts (enc_v1, enc_v2) serialized and transmitted between the client and server?