Amid all the news coverage of the Covid-19 pandemic, you might have missed a small but potentially groundbreaking announcement. Back in early June, IBM said that it had successfully completed "field trials" of a "fully homomorphic encryption algorithm."
At this point you might have a few questions. If, like many people, you've just wrapped your brain around public key cryptography, you might be wondering what is homomorphic encryption? Even if you have a vague idea of what IBM is talking about, you might still be curious as to why this is so important.
Fear not. In this article, I'll explain clearly what homomorphic encryption is, why it is useful, and why it might be a game-changer for many organizations looking to work with data safely and securely.
What is Fully Homomorphic Encryption?
Homomorphic encryption is a specific type of encryption among the many various types of cryptographic algorithms. Data which has been encrypted by homomorphic systems exhibits some very special attributes. To put it simply, fully homomorphic encryption (which we'll now call FHE for short) retains the relationship between parts of a dataset, so data points can be worked on by a third party without being decrypted.
Here's an example. Let's take a (very) small dataset with just three data points – say 2, 3, and 7. If you encrypt this corpus with an FHE algorithm, send the three encrypted values to a third party, and ask them to perform processing on them, they will arrive at a value that you can decrypt and that will be correct. For instance, if you ask the third party to add the first and second values, then multiply the result by the third value and return the result to you, you can then decrypt that result – and get 35.
Why is it Important?
At first glance, the value offered by FHE might seem pretty niche. But in reality, the ability to work with third-party data without decrypting it has considerable advantages for many organizations.
At the most basic level, FHE solves the "sysadmin problem." If you are completing your computation on a system managed by a third party, the root-privileged operators at the third party generally have access to the data, and you do not. Encryption at rest prevents access to the data outside the scope of whatever computation is going on at that specific moment – but with root privileges, a system operator can scan or alter the contents of RAM to gain access to whatever data is currently being operated on.
With FHE, you can perform those calculations without the actual data ever being exposed to the remote system at all. Obviously, this solves the sysadmin problem pretty thoroughly. When the machine itself never has access to the decrypted data, neither do its operators.
This is important because of the increasing complexity of the way in which data – and contracts for collecting, storing, and processing it – is handled. We are not far from a world in which the majority of data acquisition and processing tasks are subcontracted to third parties, and in this world ensuring the security of data systems is becoming exponentially more complex.
Before going further, let’s consider the three states of data: data in transit, data at rest, and data in use. For the past few decades, encryption protocols incorporated into low-cost VPNs, HTTPS, and TLS have been able to provide protection for the first two states. Data in use is a different story.
If FHE becomes a feasible, mainstream technology, it will go a long way towards protecting data in this state. It could be passed between and used by dozens – if not hundreds – of contractors without anyone but the original owner having access.
The Limitations
All this said, the FHE system tested by IBM has some significant drawbacks that may limit how widely it can be used, at least for the moment.
Some of these limitations are shared with any FHE system, and arguably any system that aims to allow third parties to work with encrypted data. One of these is that, given access to enough data – even if this remains encrypted – a sufficiently capable contractor could manage to reverse engineer the encryption scheme. This is why security experts recommend encrypting emails instead of the servers.
The second problem, and the one that will be the limiting factor for FHE, at least in the near future, is the sheer amount of processing power that IBM's system requires. Though IBM is keen to stress that their algorithm only increased the required computing resources by a little in relation to individual data, these requirements are additive. In realistic tests, research indicates that roughly 40 to 50 times the computing power and 10 to 20 times the RAM would be required to do the same work as compared to unencrypted models.
This might not be a major problem for firms looking to outsource processing on their customers' buying habits, or on their web analytics. However, one of the major sources of outsourced contracts over the past few years has been in ML and AI training, both of which already require massive processing capability. At the moment, training an AI using FHE data would test the limits of even the most well-resourced firm.
A Final Word
Overall, IBM's announcement hints at what could be an exciting step forward when it comes to ensuring the security of outsourced data processing. The systems that exist to solve the sysadmin problem, such as AMD's Secure Encrypted Virtualization, don't offer the same level of capability that FHE data does. While SEV doesn't suffer from the performance issues that affect FHE, third parties are unable to perform the same kind of advanced data processing on SEV data.
In this context, FHE offers a way to dramatically increase security, but only if some of the current limitations can be sorted out. One area of active research is in improving the efficacy of FHE algorithms. Another is in the policy implications of the enhanced capabilities it offers. If both streams of research bear fruit, we could quickly see the widespread adoption of FHE across many sectors.
Note: This blog article was written by a guest contributor for the purpose of offering a wider variety of content for our readers. The opinions expressed in this guest author article are solely those of the contributor and do not necessarily reflect those of GlobalSign.
