The side channel attack by the node operator’s direct memory access could be the biggest security vulnerability in IC. It’s also inherently unreliable for other public cloud vendors, but if we add node operators without a legal contract in the future, things are even worse for IC.
I know there are some studies going on for this; such as MPC, AMD-SEV. However, as far as I know, there is no (active) research on Fully Homomorphic Encryption(FHE).
There are two breakthroughs in the practical use of FHE. Advances in algorithms and advances in hardware. Algorithms are clearly improving rapidly, but I think we should pay more attention to hardware acceleration caused by new hardware components. E.g. High Bandwidth Memory(HBM), In-memory processing(PIM), FPGA, and the SoC structure that integrates them with CPU can dramatically reduce the performance overhead of FHE.
Despite these possibilities, has Dfinity researched and concluded that FHE has no future? Obviously it will take a long time for the dissemination of new hardware, but since new technologies are applied to servers first, IC has a chance to try to adopt such hardware sooner than expected. (around 5 years?)
Not all data and operations on IC need to be encrypted with FHE. However, Dfinity should provide guidelines for FHE in the future, and be prepared to provide hardware acceleration for programs using FHE.
Why doesn’t a roadmap exist for FHE? The roadmap doesn’t have to be in the near future, but I think there should be a mention of it similar to Post-Quantum security.
I don’t know what the current state of the art is in FHE, but I know we have people at the foundation that are very interested in the topic. So I’m sure it has been discussed before and will be discussed every so often for sure.
Also, the roadmap page itself is for things that are in the near future, with concrete goals set that can be accomplished now-ish. As there are no immediate plans for FHE I don’t think it should be on the roadmap (for now).
Thanks for bringing this up, @Murphy. First of all, when it comes to privacy, there will be no one-size-fits-all solution. As you indicated, we are already looking into privacy based on TEEs – such as AMD-SEV – which is clearly an improvement over the current state but relies on a single point of trust for privacy (namely: AMD’s technology) and TEEs for general computation have proven … let me say … “leaky” in the past, at least under hardware-level attacks. So we would not want to put all of our eggs into that basket. In particular, our research team has already started looking into solutions based on FHE, which would add full cryptographic security (of course at the cost of efficiency).
Just incorporating an existing FHE-scheme into the IC, while possible, wouldn’t really fit the IC’s trust model: In plain FHE schemes, each ciphertext is encrypted toward a single private key; whoever holds that private key will be able to decrypt all the ciphertexts. This is of course entirely appropriate if you consider the most common use case motivating FHE: outsourcing computation on private data to the cloud – there’s one entity owning the data, and that entity will hold the private key. In a smart-contract use case, however, there is no natural, single holder of that cryptographic key. So we need more than that.
So where does that leave us? I’d say that we have a pretty good grasp of what we need in order to make FHE useful for the IC, at least at the level of protocol research, and we’re now planning how we can get there. I think it would be a bit premature to put it on the roadmap at this point, but I am optimistic that it will appear there …
@Murphy If you have an FHE scheme that is efficient enough for your application then you can deploy it in canister code already today. No support from the IC is needed to do that. It can be done today.
If you are asking for hardware support then it should be noted that all smart contract (canisters) on the IC run inside a Wasm VM. They can’t really make use of any hardware support. If the nodes have such hardware then smart contracts have no way to access it. Creating such access is a long shot. There are probably a number of other use cases that are easier than HFE but even they are not on the roadmap. Such as, for example, giving canisters access to special hardware such as GPUs or neural network chips. Hence, waiting for hardware support for FHE will definitely take long.
I am not aware of an FHE scheme that would allow to run the entire Wasm VM encrypted. I think for that approach, to run the entire VM encrypted, SEV is the more suitable way.
I’ve been feeling there should be a topic to discuss the FHE in the forum. FHE is theoretically possible, but still in development and “too” slow for widespread adoption. So it’s unlikely to be a universal solution right now, despite its great potential.
Can FHE help to improve the protocol of IC? If it can, it would be cool; well, I don’t know if it is. But there will be other ways to utilize it; such as for applications running on the IC rather than IC.
It is difficult to predict the pace of advances in hardware and software(algorithms). However, as more and more efficient solutions are developed, there could be widespread adoption though it will begin with a small number of limited use cases.
If there is an environment where FHE can be freely used only by software method, there will be no problem. However if hardware support is required, it may be difficult to use for developers.
Right. It doesn’t have to be included in the roadmap now. I had to express it as a long term R&D rather than a roadmap. Anyway it would be nice if it can be a place to share ideas; there are many ways to use it and it is unclear when, where, and how to utilize it.