Assessing the Security of FHE Solutions

Written by Joseph Wilson and the CSA FHE Working Group.
 

Questions of privacy and security are at the forefront of every deployment of Fully Homomorphic Encryption (FHE). In this blog post, we provide insight that will help you to evaluate FHE solutions when answering the following questions:

• Is this solution secure? Who says so, why are they correct, and how do I know the difference?
• What is the core “advantage” of FHE relative to existing solutions?
• Is this solution authorized for use in my domain? How can I tell, and what guidance is there?

 

FHE In Context

There are many overlapping trust concerns that must be addressed when transmitting or storing data, such as trust in the security of your connection, in any intermediaries that might handle your data when in transit, or whether your data storage system might be exposed to adversaries. These complex trust issues can all be mitigated by the use of cryptography. This means that we replace a myriad of different problems with some simpler cryptographic trust assumptions, namely

• Can we trust the mathematics which underpins the cryptography;
• Can we trust our key management system to control access to the cryptographic keys;
• Can we trust that the software or hardware implementing the cryptography is free from bugs.

FHE aims to extend this simplification of trust assumptions from data-in-transit and data-at-rest problems to one of data-in-use. In doing so, this allows the security model of encryption to cover issues of trust that could not be addressed by conventional means, such as:

• Is the party that I send my data to going to use it in a way that is harmful or outside of a previously approved scope?
• Do I trust the data security practices of a counterparty that I wish to collaborate with?
• Does my organization implement a unified security solution for sensitive data workflows across the full data lifecycle?
• Can I combine my data with another party's data to obtain increased insight without giving up the confidentiality of my own data to the other party?

By extending the protections of cryptography to data outside of an organization overall points in the data lifecycle, FHE enables a new paradigm of data collaboration.

 

Mathematical Security Guarantees

FHE extends the traditional advantages of encryption to data in use. But is this solution secure? Evaluating the security of an FHE solution follows the same process as evaluating existing encryption schemes that offer strong security for data-in-transit and data-at-rest. 

In existing cryptographic schemes (RSA, AES, Diffie-Helman, and so on), mathematical processes are applied to information to render it unreadable and unusable unless

1. You possess the information required to reverse the mathematical process (the “key”)
2. You need to expend significant computational effort in attempting to determine any information about the encrypted data without access to the key.

It is typically the case that the parameters involved in the mathematics are selected such that the amount of computational effort required to determine any information about the encrypted data is infeasible, even if an attacker leverages computing resources at an implausible scale.

This approach - estimation of the computational difficulty of breaking a given instance of a cryptosystem based on the defining mathematical parameters - is known as a “concrete security” approach and forms the security basis for many practical cryptosystems in use today, including FHE. This concrete security approach measures the amount of computational resources needed (with the current best algorithms) to break the underlying security of the cryptographic system. This analysis is usually done via means of a mathematical “security proof.”

How is trust in the mathematics of FHE established? As we are working in the same mathematics-driven framework as prior instances of encryption, the groundwork for evaluating the security of FHE follows the same pattern:

• Proposed FHE schemes are defined mathematically and subjected to open peer review and cryptanalysis. 
• Schemes need to come with a rigorous security proof, in a well defined mathematical model of security that is accepted by the community.
• Practical implementations (e.g cryptographic libraries) of FHE that implement security-critical processes such as key generation, encryption and decryption should be open source to allow for scrutiny.
• Development of cryptographic standards should be done with oversight and engagement from relevant standards bodies such as the ISO and NIST.

These steps help to ensure that:

• There are no readily identifiable shortcomings or vulnerabilities in the mathematical implementations, and that the cryptographic primitives are secured against both conventional and quantum computing attacks.
• That practical implementations implement the mathematical principles faithfully and correctly, and eliminate or mitigate potential vulnerabilities (such as “side-channels”) that arise during the physical process of computing sensitive material such as keys. 
• That established best practices and parameters are always applied when implementing a cryptographically secure workflow. 

In particular, a well-posed cryptosystem should be secure even if the underlying algorithms are public knowledge. This is Kerckhoff’s principle. Avoid solutions that avoid open scrutiny on the basis that the solution in question is proprietary, sensitive, or closed source.

Depending on the intended application of FHE, key management can be made more secure. A guiding principle of FHE is that sensitive key material never needs to leave an organization, as no inputs to computation are ever decrypted outside of the organization’s trust boundary.

However, at some point, data needs to be decrypted, and that is where the secret key comes into play. Different applications of FHE require different means to secure this secret key; some applications can utilize storage of the key on a single computer (much like one store signing or decryption keys for email), some may require storage of the key in a hardened computing device (such as a Trusted Execution Environment (TEE) or a Hardware Security Module (HSM)), others may require splitting the key between different parties in a process known as threshold decryption. 

 

Questions To Ask Yourself

For a cloud practitioner or responsible data protection officer seeking to evaluate an FHE solution, the principles outlined above drive the following questions to ask of any solution that implements FHE.

• Does the solution leverage an FHE scheme that is subject to open cryptanalysis? For reference, schemes that are definitively known to have been subjected to extensive and open cryptanalysis include the following:
  • BGV
  • BFV
  • CKKS
  • TFHE
• Is there a relevant reference to a mathematical description of the scheme and the associated security proof, such as an academic paper published in a reputable conference or journal, such as those of the  IACR?
• Are the cryptographic components of the solution implemented using an open-source cryptographic library, or do you need to trust the vendor has implemented it correctly? Being able to inspect the implementing library is key. Note that it is typical for an open-source cryptographic library to reference the mathematical description of the cryptosystem(s) that it implements. Inspecting hardware implementations that secure the cryptographic keys can, however be more difficult, in which case does the vendor have suitable certifications of the said hardware?
• Is there an existing standard set of parameters for any specific data workflows that the solution implements? If not, can you tell us the parameters or parameter ranges that are used in the solution? If the solution dynamically generates parameters for a given encrypted computation, does the solution provide an estimate of the security level?

With affirmative answers to the first four questions, practitioners can be assured that an FHE-based solution is adhering to best practices in the deployment of cryptography. 

The main current issue with FHE at the moment is that it is a new technology, and hence standards bodies are very much in a catch-up mode. Work will continue throughout 2025 in establishing standards for FHE with bodies such as the ISO and NIST. Work produced by the Homomorphic Encryption Standardisation body (homomorphicencryption.org) in 2024 in support of ISO/IEC standardization represents the most contemporary set of expert-led standards, with the next standards meeting taking place on March 23rd-24th 2025 in Istanbul, Turkey. 

In the absence of specific standards and where deeper inspection of a solution is required, consider also using the open-source lattice estimator tool - this is a Sage module that provides functions for estimating the concrete security of cryptosystems based on lattice cryptography, including the Learning With Errors problem to which all contemporary instances of FHE are reducible. 

 

Is The Solution Authorized For Use In My Domain?

Generally speaking, unless working in sectors where the use and implementation of cryptographic solutions is explicitly governed by statutory or other relevant standards, FHE and other PETs are usable as long as relevant practices for information protection are followed. For example, if working under the EU GDPR, you may need to carry out a Data Protection Impact Assessment. An analogous process under the Californian CPRA would be a Privacy Risk Assessment. For locales where no specific guidance on privacy protection rules is enforced, you may need to seek dedicated legal guidance.

Different regulatory bodies may also influence the adoption of PETs. For example, in the United Kingdom, guidance from the Information Commissioners Office (the ICO) explicitly and broadly encourages the adoption of Privacy Enhancing Technologies (including FHE). PET guidance for data protection officers in the UK can be found here. 

 

Summary Of Privacy And Security Considerations

In summary, FHE extends the practical security advantages of conventional encryption (which traditionally secures data-in-transit and data-at-rest security) to the case of data-in-use. 

The advantage and utility of FHE lies in reducing a broad spectrum of considerations for protecting data-in-use (including “unknown-unknown” considerations that cannot be identified ahead of time, such as potential future attacks on microcode architectures) to a question of key management, allowing greater scope for sensitive data processing across conventional trust and security boundaries. 

Assessing FHE as a secure solution invokes the same best practices as applied in the evaluation of other forms of cryptography, and relies heavily on open peer review. 

Authorities in the US, the EU, and the UK are generally open to responsible use of PETs (including FHE) as a valid and permissible method of augmenting data security.

 

---

Note: As an illustrative example of a sector where amateur, unsupervised implementations of cryptography are a) common and b) frequently fail miserably, the authors can wholeheartedly recommend the “Great Crypto Failures” whitepaper from the Check Point Blog.