Yes - this is the reason (is this 20 characters).
Once decentralized node onboarding becomes possible, should we expect a bunch of malicious node providers to join the network and make private data public as a way to undermine the IC? Or is there a way to counter this?
3 Likes
Because the wasm code is part of ingress messages to the ic and function calls are ingress messages and intercanister calls are part of the subnet message log, you reallly should not consider any data private on the IC. Theoretically, with access to the logs, you could reconstruct anyones datastate from the logs. Dfinity hasnāt made these public yet, but I know there have been talks to do so.
If you want your data to be private you should encrypt it before sending it to the IC.
Hopefully there is a future where we can send encrypted transactions to enclaves that have a much higher security level. Likely you would want a higher level of kyh (know your host) for this kind of subnet that could drastically reduce the risk of having the data be exposed.
7 Likes
Great info (plus 20 characters).
Thanks for your post! KYH.
White bordering a PoC and MVP Use Case, the eIDAS2 EU mandate on eID schemes offers a potential public-private partnership. A Subnet of 31 EU-Digital Single Market member states interfaced boundary-nodes interoperable with EBSI distributed nodes.
If feasible, could it then be possible to offer a higher LoA (end-to-end encryption) privacy-preserving DID channel?
Has anyone been able to store data encrypted on the IC? Without needing to encrypt it first, or store the key in browsers?
This seems like it should be high priority as b2b users need to know their data is not viewable.
1 Like
Not yet. DFINITY has been talking about enclaves since 2018 so itās on the roadmap. There may be cool crypto schemes in the horizon as well. Everyone wants to get there.
1 Like
Can threshold ECDSA be used to encrypt canister data?
(Ignoring concerns around potential node provider collusion, etc. for now)
3 Likes
No, it can only be used to sign data.
1 Like
Threshold encryption is now on the roadmap, under Upcoming: Roadmap
āEnable threshold encryption on the IC by allowing canisters to call a threshold decryption interface. The interface would enable canisters or individual users to encrypt messages under the public key of the subnet, and decrypt the ciphertexts under the corresponding decryption key that is secret-shared among the replicas. Threshold encryption will enable canisters to store end-to-end encrypted user data (e.g., storage, messaging, social networks) without having to rely on browser storage for user-side secrets, as well as enabling transaction privacy within canisters (e.g., closed-bid auctions, front-running prevention).ā
10 Likes
@skilesare, @lastmjs, & @domwoe,
I could really use your help with this regarding ntagle.
The entire usage of ntagle rests on being able to securely store symmetric encryption keys.
Users will need to login, so I can have them sign messages before sending them to the canister.
What I need to know is:
-
If the secrets are plaintext while the logic is actively running internally within the canister, would this still basically be public and viewable by a bad node provider? If so this really means nothing about data can be secret with the network, which is hugely disappointing.
-
Could I use the ECDSA feature to encrypt keys with the public key before storing them to state, then then decrypt the keys when needed for the authentication logic? I assume only the canister can call the usage of the secret key? Would I be able to safely store any data Iād need for generating these calls to the ECDSA functions (like, could a node provider replicate my canisterās ECDSA calls and get back the original data)?
-
@skilesare basically said inter-canister calls can all be revealed from the logs. I guess this includes the ECDSA calls too?
@domwoe when we talked you mentioned there may be some advantage to splitting up sensitive data across multiple subnets. Do you think this is the best approach to pursue? If so, how could I help make the necessary inter-canister calls secure?
3 Likes
Are you asking about signing or encrypting? These are two distinct cryptographic operations, and you might be conflating the two. I assume youāre most interested in encrypting data.
- The safest assumption is that any data you store in a canister is viewable by the node provider. The nodes seem pretty locked down from what Iāve learned, but a motivated node provider I believe would be able to get all data stored in all canisters on its subnet. This is hugely disappointing. But, you can client-side encrypt data before sending it to the IC. This would help because node operators wouldnāt have the decryption keys. But the problem is, where would the user store these keys? Itās a hard UX problem. Thatās where threshold encryption comes into place. I think it might be exactly what youāre looking for. This allows you to store the encryption/decryption key on the IC distributed across multiple nodes. A user can then request the key, I assume based on regular IC authentication, and encrypt and decrypt data on their own devices.
- ECDSA is only for signing data, not for encrypting or decrypting data.
- I donāt know about this
2 Likes
Thanks for this! Who would have thought to look at the roadmap 
Should I be concerned that it is all blacked out?
@domwoe This might mean it was in planning but no longer?
I am thinking of ways to onboard companies to certain features in the IC. Privacy is always a rebuttal for data storage; and we need to be able to tell the truth about current state.
It is in the process of launching.
That one is a different feature
1 Like
Looks like it is being explored, but Iād imagine threshold encryption is a way off. I have some ICDevs bounties that need it. They are in the freezer for now.
2 Likes
Do your tags have an encryption feature or just a signing feature? If the tag can sign then the tag probably has an enclave.
What you want is an enclave in the dfinity nodes. We donāt have those yet, but research is being done.
Signing should be enough in your tag to prove the presence of the tag. The signing algo likely reports a public key which isnāt secret and sends a signature of a payload back(random number, time stamp) that only having the private key would possibly be able to produce.
1 Like
The tags generate unique URLs with a CMAC parameter based on the scan count using AES-128.
Unfortunately, since itās all symmetric encryption this typically means the Secure Dynamic Messaging server (in this case an SDM canister) must hold the secret keys for each tag.
One option would be for the encoder to generate a huge list of valid CMAC messages (perhaps the first 100,000 scans), hash the values, and then upload that data to the canister. We donāt have a CMAC library for Motoko yet, so thatās already similar to what Iām currently doing.
The transfer code will change between each tag owner (itās a random string encoded statically to the tag in plaintext by the current owner when they "unlock"the tag for transfer), so even the original encoder wonāt have all the necessary information to transfer ownership of the digital assets associated with the tag.
For the transfer code, Iām going to need a creative solution to make sure that information is stored, transmitted, and validated securely.
1 Like
Iām not enough of a crypto expert to know if this is viable, but nu-cypher has some tech that lets a node re-encrypt without knowing the actual code and a few other multi party compute schemes. Iād love to see if any of these could be put inside of canisters to create a multi canister encryption scheme. It would be āslowā but might dove some problems.
3 Likes
Interesting parts ā rust-umbral/umbral-pre-wasm at master Ā· nucypher/rust-umbral Ā· GitHub
GitHub - nucypher/rust-umbral: Umbral implementation in Rust
It seems that Alice would need to use her secret key and Bobās public key to generate the re-Encryption for the capsuleā¦ 
jargon aside - a canister would need to store a secret key to do this.
1 Like