Encryption at rest, encryption in flight, encryption on disk, encryption, encryption, encryption… even post quantum encryption. If you are not hearing about encryption, you might either be living under a rock, or perhaps leading an idyllic life somewhere in the mountains with a stream and nice walking path and are not the target audience for this article. Instead, allow me to shift to those poor souls who are bombarded by the term encryption from sunup to sundown.
Since forever, encryption of sensitive data has been a must. But as the old adage says: what can be locked/encrypted can also be unlocked/unencrypted (ok maybe that is more of a paraphrase). Each new successive encryption standard is immediately analyzed by the opposition for ways to compromise it, if possible, so that the data protected can be read. This is a tale as old as the need to protect things from theft and is not going to change as encryption methods have become more complex, new tactics like download now, decrypt later (DNDL) become more popular. Even outside of DNDL, there are other areas where sensitive data leaks in unintended ways. One of the more common times sensitive data leaks is during access and processing. A good example is that someone needs access to dataset “A”, they reach out to the owners of that dataset, a connection is established, and the queries begin to fly back and forth. Now we would expect the connection to be over the latest and greatest version of TLS so communication should be secured. Still the queries are not as they are sent and executed, the data typically must be at least unencrypted in memory for processing and the return of data to the requestor also might fly unencrypted over that TLS connection. There are several opportunities for this sensitive data to be leaked (even internally). Enter Fully Homomorphic Encryption (FHE). FHE, according to the IEEE page, is a method of allowing the creation, processing, and transmission of data queries which are always encrypted. The person wanting access to the data generates the query which is then encrypted for transit (even over an encrypted connection), it is processed by the target dataset while encrypted and the output is sent back encrypted. This means that even on the target data server, the request for information and the output is never readable. This reduces the risk of data leakage during the query process. You just knew that there would be a downside though and there is. FHE is, as you might expect, very compute heavy. It requires a lot of cycles to work and requires a middleware layer to function properly on the target data servers. Improvements in software design as well as general efficiencies in CPUs, memory etc. have helped somewhat, but there is still more to be done. We spoke to Duality Technologies co-founder and CTO, Dr Kurt Rohloff about the topic and some interesting use cases around FHE. Duality Technologies, as you might expect, is a provider of an FHE solution so they have a bit of skin in the game when it comes to adoption and usage of this technology. It also means they have an interesting insight into the how, why, where of FHE, so the conversation was a great chance to get more information on this.Since we have already covered a bit of the how and what, let’s dive into the why and where of FHE that came up in our conversation with Dr. Rohloff. One of the first items we talked about was the use of FHE in gathering and working on HIPAA protected data for scientific and medical studies. Being able to request data safely from multiple sources with a reduced chance of leakage and/or compromise is important to protecting privacy and continuing medical studies. The next topic that came up was investigations. These investigations might be law enforcement, government regulators, etc. even incident response and gathering indicators or compromise for intelligence sharing in a more secure manner. As you might expect, my first thought on this was the potential for abuse. Dr. Rohloff indicated that under their current system, this was unlikely since the core of the product tracked all requests (even if it cannot see them). The query, who requested it, where it was going, and other items are required to maintain a chain of custody for any data requests that they (Duality Technologies) process via their solution. This requirement to establish a chain of custody for the data involved (including the request) should make it easier to audit and potentially prevent abuse of the system to gather data without and target’s knowledge. Right now, FHE is still an enterprise level accessory due to the cost of the hardware and software in play, but as the cost to market goes down this type of solution should become available to more people including down to the general end-user level. Making requests for your banking, health, other sensitive data is an interesting thing to think about. What I am not sure of is if anyone would use it if it was not required by the data owners/processors. I do think that FHE is a good move for the handling of personal data by businesses and could be leveraged for use in consumer requests for their own data, once the cost of goods and services make it more sustainable at that scale. If you are like me, you are probably now wondering what the identity and access controls around this type of system are currently, and perhaps what they should be as it scales to a larger client base. After all, there are audit logs a plenty in most systems and attackers still abuse those.FHE and providers like Duality Technologies have a bit of a heavy lift ahead. They are certainly providing a great technology offering, but as it scales there are going to be challenges for them to maintain the same level of service and chain of custody. It is clear they are up to the task of handling the FHE side of things, I like to think they can get ahead of issues at scale as well.
