I want vetKeys and secure enclaves

Developers
1

I have a very specific use case for vetKeys and secure enclaves that I would like to share.

TL;DR

I want to deploy to npm or PyPI using deploy tokens. I need to do this securely and in compliance with npm and PyPI terms. I am thinking that a combination of secure enclaves, vetKeys, and node operator legal agreements could allow this to happen securely and in compliance with terms. What do you think? Is there any other way to achieve this?

Longer Explanation

At Demergent Labs we are considering the long-term futures of Azle and Kybra, and we are considering how we might be able to decentralize the projects. One key part of this decentralization might be giving control of the npm and PyPI packages to a DAO-like group.

Essentially we would like a DAO-like group to be able to vote to push a new version to npm or PyPI. This would allow development to take place anywhere, but final deployment of the package that developers will download to be strictly controlled by the DAO-like group.

The problem right now is keeping the deployment token secret and complying with the terms of npm and PyPI. For a canister to control the deployment process it would need to have the token. But to get the token into the canister it would have to pass through the boundary nodes unencrypted and live in the canister unencrypted.

I’m hoping that vetKeys combined with secure enclaves would provide a compelling solution that might be good enough. The deployment token would always be encrypted at rest with vetKeys, in addition to being secured by the secure enclave. Even if the enclave were successfully attacked, the token would be encrypted.

Then when the HTTPS Outcall is to be performed to push a new version to the npm or PyPI registry, the vetKey shares would be collected ephemerally into the canister inside of the secure enclave. This would be a central point of failure but it would only be temporary. The token would be unencrypted and an HTTPS Outcall performed. I hope that the HTTPS Outcalls are also performed inside of the secure enclaves, the unencrypted token must not be exposed outside of the enclave.

Does this all make sense? Is there another way to do this? Do you think it would provide sufficient security and also comply with the terms of npm and PyPI?

9 Likes
2

This would be cool, but there would still need to be an operator of the npm or PyPI account. That account would probably sign up and verify itself with a combination of email and maybe text message or some other 2FA.

Another basic prerequisite to truly decentralizing this kind of account ownership might be for ICP to support SMTP.

See here for some discussion on email/SMTP support: Email/ smtp support to canisters - #2 by w3tester

1 Like
3

I would love to see this feature as well.

After 3 years of canister development, the foundations have been established for large canister states, identity management, canister maintenace, frontend integrations, standards like ICRC3 etc.

A lot of the on-chain data belongs to the users. I hope the next 3 years we will see the emergence of e2e encrypted on-chain apps.

2 Likes
4

I hope we can get to general-purpose private computation in addition to end-to-end encryption, as end-to-end encryption usually means (in my experience) that the data can never be computed on in an encrypted state and must be decrypted and used at the ends.

3 Likes
5

I wonder how far away that is. Its called homomorphic encryption, correct? That’s all I cureently understand about that and can’t judge how much of an effort it would be to implement it on IC

1 Like
6

That would be one way to do it, maybe the most promising, but IMO still has a couple drawbacks I haven’t been able to see a way out of in my conversations.

Some kind of performant general purpose MPC would be the other way, I believe.

1 Like