Homomorphic Encryption (FHE) & HSM Key Custody
Fully homomorphic encryption, the ISO/IEC 28033 draft schemes, and how an HSM holds the FHE secret key: compute on encrypted data without trusting the hardware.
Why this matters: FHE needs no trusted hardware, but its keys still need a custodian: the secret key is small and precious, the public keys are huge, and an HSM that decrypts on request becomes an oracle that leaks the key.
Start here: Open the first scenario in the FHE + HSM Flows step: the data owner makes its FHE key in an HSM, encrypts locally, lets a third party compute on ciphertexts, then asks the HSM to decrypt under policy.
For your role
- Developer / Engineer
- The CKKS and TFHE single-HSM scenarios show which calls the data owner, the cloud and the HSM each make: key generation, encryption, computing on ciphertexts and decryption under policy.
- Security Architect
- Each workshop scenario shows where the secret key, the public keys and the data sit at every step, and "What can run in the HSM?" says what belongs in the HSM and what belongs on GPUs: the placement decisions an FHE design has to make.
- Researcher / Academic
- The learn sections cover the four ISO/IEC 28033 draft schemes, the lattice basis of FHE against the quantum threat and the decryption attacks that shape HSM policy; the threshold scenarios (OpenFHE and Lattigo) show where no single party holds the key.
- IT Ops / DevOps
- The custody steps cover what an operator has to run: a non-extractable seed in the HSM, decryption under policy with an audit log and rate limits, and an HSM-to-HSM backup so the key survives the loss of a device.
A TEE protects data in use by trusting hardware. Fully homomorphic encryption (FHE) takes the other route: it trusts mathematics. The server computes directly on ciphertexts and returns an encrypted result. It never sees the input or the output, and there is no enclave to attest. The cost is speed: FHE is orders of magnitude slower than computing in the clear.
| TEE | FHE | |
|---|---|---|
| Root of trust | CPU vendor, firmware, attestation chain | Hardness of lattice problems |
| Data inside the server | Plaintext, inside the enclave | Always ciphertext |
| Side channels | Main attack surface | Nothing to leak on the server |
| Speed | Near native | 10³–10⁶× slower; needs GPU/FPGA at scale |
| Integrity of the result | Attested code | Not provided — ciphertexts are malleable |
| Quantum status | Attestation signatures are classical today | Core scheme is lattice-based |
The four schemes in ISO/IEC 28033 (drafts)
Every ciphertext carries a small random error (“noise”). Additions grow it a little and multiplications grow it a lot. Once it is too large, decryption fails. Bootstrapping refreshes the noise by running decryption homomorphically under an encrypted copy of the key. All four schemes are being standardized in ISO/IEC 28033; no part is published yet (parts 2 and 3 are DIS, part 4 is FDIS).
| Scheme | Computes on | Best for | Bootstrapping | Standard |
|---|---|---|---|---|
| BGV (2012) | Exact integers mod t, SIMD-packed | Exact batched arithmetic (counts, matching) | Possible but slow — usually run leveled | ISO/IEC DIS 28033-2 |
| BFV (2012) | Exact integers mod t, SIMD-packed | Same as BGV, scale-invariant variant | Possible but slow — usually run leveled | ISO/IEC DIS 28033-2 |
| CKKS (2017) | Approximate real / complex vectors | Machine learning, statistics, signal processing | Yes (approximate) | ISO/IEC DIS 28033-3 |
| TFHE / CGGI (and FHEW) (2016) | Bits and small integers | Arbitrary functions via lookup tables, comparisons, branching logic | Programmable bootstrapping after every gate (boolean API) or nonlinear operation (integer API) | ISO/IEC FDIS 28033-4 |
Ready to follow the keys?
Step through six encrypt, compute and decrypt scenarios and see where every key and every piece of data sits.
Related Resources
Check off all sections and mark this reading done.
Related modules
- PQC Hardware AccelerationSame track · Hardware Infrastructure · Same migration phase · Shares ML-DSA, ML-KEM, FIPS 203
- ACVP Lab Workflow: From Vector Set to EvidenceSame migration phase · Shares ML-KEM, ML-DSA, FIPS 203
- KMS & PQC Key ManagementSame track · Hardware Infrastructure · Same migration phase · Shares ML-KEM, FIPS 203
- Aerospace PQCShares ML-DSA, ML-KEM, FIPS 203
Check your understanding
14 questions on Homomorphic Encryption (FHE) & HSM Key Custody, each with its answer and the reason.
Take the quizNext step
Produce the artifact: Infrastructure Modernization PlannerThis module belongs to phase 6 (Infrastructure & Performance); Infrastructure Modernization Planner produces a deliverable of that phase in the Command Center.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.