Guarding against malicious node providers

General DFINITY
1

Hi all,

I’m currently working on an application that works with sensitive user data. It’s not possible to do all the calculations on user side as the canister needs to make sure it’s internal state is correct. From what I understood it’s currently possible for node providers to currently sniff the internal state of a canister. Meaning that when a canister receives an encrypted value then decrypts it with the canisters key, you can assume the node provider can read this decrypted value. So first of all, is this assumption true? If it’s true I have some follow-up questions regarding the capabilities of a node-provider:

  • How easy is it for a node provider to sniff?
  • Do node providers take a risk by sniffing, meaning it can be traced/discovered that a node provider sniffed?
  • To retrieve sensitive data in my application a node provider needs to sniff for a long duration, can a node-provider stay in a subnet indefinitely in case it wants to?
  • Are there already possible guards we can add to a canister to guard against sniffing?
  • Are there any longterm initiatives to tackle this problem that I can already have a look at? For example if there is a solution planned for next year, I can already take this into consideration for the design of my application

Thanks a lot for all the help!

Kind regards,
Thomas

2

Hi there @thomas_vdd

TLDR

I usually tell folks is that data inside canisters should be considered "hard to get, but not cryptographically private" from node providers which means that it is not recommended people use it for privacy.

Summary

from what I understood it’s currently possible for node providers to currently sniff the internal state of a canister.

This is correct.

Long term initiatives to address this

From an R&D POV, there are a few ways one could achieve privacy you are looking for. Many of which are long term initiatives.

  1. Threshold and multi party computation - so even if a malicious node provider inspects the data inside their hardware, it does not reveal enough for malicious actions. This is done for certain things like ECDSA and other private keys, not for all data.

There is an ongoing project called VetKeys that will bring threshold decryption and privacy to canister states.

  1. Secure enclaves - It is an ongoing R&D project to have secure enclaves so the execution environment is opaque even to the people who manage the hardware. This is not live on the IC.

To your questions:

How easy is it for a node provider to sniff?

I think technically they are sniffing because sniffing means inspecting the traffic over a network. the traffic over the network is encrypted. I think you mean inspecting. That being said, the traditional answer is “Hard, but not hard enough, and not cryptographically secure.” Since ICP community is all about cryptography, if something is not cryptographically secure, it is considered not private.

Do node providers take a risk by sniffing, meaning it can be traced/discovered that a node provider sniffed?

There is no obvious way for the network to know if a hardware maintainer inspected the state inside their machine.

To retrieve sensitive data in my application a node provider needs to sniff for a long duration, can a node-provider stay in a subnet indefinitely in case it wants to?

Nodes stay in subnets for a long time. Enough that I would not plan on the length in a subnet as a form deterrent or protection.

Are there already possible guards we can add to a canister to guard against sniffing?

yes, a developer could use threshold encryption where possible. Not all data can threshold encrypted triviall yet. vekKeys will help here.

Are there any longterm initiatives to tackle this problem that I can already have a look at? For example if there is a solution planned for next year, I can already take this into consideration for the design of my application

yup! see above.

3

Hi @diegop ,

Thank you for your clear and in depth explanation! I’ll make sure that all the private data is cryptographically secure! Vetkeys are not possible for me I think as I will be using exponential elgamal encryption system for my encryption. But I can use vetkeys to securely store the keys in my canister I suppose.

Also secure enclaves sounds like a game changer! It would simplify my application which would reduce computation cost and improve performance. I understand that this is still an ongoing R&D and not a simple problem to solve. Are there already some projections on whether it is possible and when we can expect something tangible to test with?

Thanks again for all the help!

Kind regards,
Thomas

1 Like
4

Unfortunately there are no hard dates yet. It is still very much a R&D project in a rapidly changing world. From my understanding (and I could be wrong), part of the complexity of this project is that is not just software engineering and cryptography, but also relies on the hardware manufacturing of secure enclave providers. As far as I understand, providers are hardening their secure enclave technology so it is ongoing. But again, I could be wrong in the details, but the high level answer is: no concrete dates from R&D team.