Can a hacked canister hardware secretely call sign_with_ecdsa (and receive a valid signature for the hacker’s provided data) without the user instructing it to call sign_with_ecdsa?
That algorithm had a security “leak” (need to check canister behavior post-factum to punish it, rather than preventing to) while using vetKeys. I simplified the algorithm to use tECDSA instead of vetKeys. After this the question arises, whether the simplification also removed this “security leak”.
The Internet Computer implements a novel threshold ECDSA protocol as part of its chain-key signatures suite. In this protocol, the private ECDSA key exists only as secret shares held by nodes. Secret shares are shards of the ECDSA private key. Signatures are computed using those secret shares without the private key ever being reconstructed. Each replica of such subnet holds a key share that provides no information on its own. More than one third of the nodes are required to generate a threshold signature using their respective key shares.
Hi @qwertytrewq I tried to follow the original thread but I have to admit I am a bit confused.
Canisters are SW installed on all the nodes of a subnet. The execution of the canister is replicated on all the nodes of the subnet and what the canister executes is agreed upon using a consensus protocol. This allows them also to agree on the result of the execution of the canister. Some observations:
What do you mean by hacked hardware? If by HW you mean a single node of the subnet (up to less than a third of the nodes) is hacked/corrupt, then they cannot privately compute a signature between themselves. Signatures are computed using a threshold protocol, so you would need to corrupt more than a third of the node to compute signatures.
Canisters cannot compute anything privately, not even with vetKeys. Everything they compute is replicated on all the nodes of the subnet, and the inputs are agreed (and thus visible) to all the nodes.
sign_with_ecdsa is a system API offered to canisters, not to users. So every canister can call this API with arbitrary arguments, according to its source code and the inputs they may receive from external users or other canister. You could say that it is the canister that controls the signing key (although they cannot access it).
That algorithm had a security “leak” while using vetKeys.
Can you expand on this security leak? The confidentiality brought by vetkeys comes from additional encryption keys specified by the users and a new threshold protocol run by the nodes of the subnet. However, vetkeys is also a system API offered to canisters, not users. So the trust assumptions between users and canisters are essentially the same for both functionalities.
I think there may be a misunderstanding on what the vetKeys functionality actually provide. The state of a canister should not be considered private, as node providers can have access to it. This is true also if vetKeys are used. What vetKeys enables is a way for users interacting with a canister they trust (and possibly control) to deterministically derive keys that can be both decrypted and used off-chain.
There are use cases where it does make sense to have a canister perform some secret key operations, like decrypting messages. Time-lock encryption is one such example enabled by vetKeys. However, once the canister has used the private key to perform some decryption, both key and message should be no longer considered confidential.
To summarise, this is not a bug of vetKeys, the example you list is just a use case not enabled by this functionality.
Yes, it is now so. But I propose to make it false:
Add encryption/decryption methods (that don’t expose the SK) to the API and remove the method that exposes SK. I reported it at the MR of vetKeys, so knowledgeable people will take my opinion into account.