I want vetKeys and secure enclaves

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?

7 Likes

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