zeeghazi
commented
1 month ago Two sets of keys that are being stored right now include node keys and engine keys
there are multiple ways to store these keys using vetkd system api As this is not offical as of now, we have to use system api canister which hard codes the master key, later when this gets merged to the official dfinity sdk we might be able to get this from the management canister and in which case the master key will not be hard coded but the one being shared between nodes with consensus
we considered three options for storing keys
- owner can decrypt ( identity based encryption )
In this case we encrypt the set of keys for the intended user ie the owner's principal and only the owner can decrypt when logged. we didn't encountered any such use case as of now but the same concept is being used to store other keys where we encrypt keys for canister instead of users
- frontend canister can decrypt
engine keys implement this approach where we encrypt the keys for frontend canister when storing
we create a pair of dumy key on the frontend using the ic-vetkd-utils package which is a wasm binary for the equivalent package written in rust customized to be usable with icp environment
get the encryption key from vetkd canister,
encrypt data on the frontend with that encrypted key from vetkd canister and pair of dummy key that is created on frontend.
decryption works the same but for frontend canister only and instead of encryption key we ask the decryption key from the vetkd canister first
3) azle canister can decrypt
encryption works the same but the intended user is azle canister id in this case, for decryption, vetkd canister will check the caller to make sure its form azle canister,
private key is decrypted and signData function is being exposed which takes in the data and node id, creates a signature out of it using specific node's private key
We store up to 2 sets of important keys for each user: (1) Public/Private ETH Keys and (2) Akash/Cloud API keys for Melisearch (and later Qdrant, etc.).
Right now, we only upload low-risk keys, but ideally we encrypt and decrypt them without leaking them in memory or exposing them to the frontend.
Further, it'd be nice, but not strictly necessary, to associate everyone's NFTs/SBTs with a hash of their principal, so to not expose the principals of users.
VetKeys is still an experimental feature but I think it could be used to get the best of both worlds here without changing too much of the existing architecture.
Helpful Implementation: https://safenote.store/#/contact Docs Example: https://internetcomputer.org/docs/current/developer-docs/smart-contracts/encryption/using-vetkeys