Can threshold ECDSA signatures be used maliciously by rogue node operators?

General
1

Hi, I’ve been trying to get my head around the threshold ECDSA implementation, and a concern came to mind about rogue node operators potentially creating fake signed messages that could be submitted to e.g. an ECDSA-enabled blockchain.

When canisters send requests for message hashes to be signed, when that signature is returned, is it always identical on each canister and node?

If it’s not necessarily identical for each request, in order for the signed message_hash to be sent off with a message for another purpose (e.g. to make a transaction on an ECDSA-compatible blockchain like Ethereum), is a single signed message sufficient, or do you need to combine the signatures from multiple nodes?

Note: I’m assuming here that the same parameters (canister_id, message_hash, derivation_path, curve and key_id) are used.

I ask because if the signatures returned to each node are identical - or at least if they are sufficient to fully sign messages to another blockchain - it appears that this would be a potential security risk.

For example, a rogue node operator could create an arbitrary message (e.g. to send ETH from a canister-controlled address on Ethereum to the node operators wallet address), send the hash of that message on behalf of a canister it hosted to the signature canister/subnet, get a signed message back, which it could then submit to the Ethereum network.

This would require the node operator knowing that its canister controlled an Ethereum wallet that had ETH (or whatever) in it, but that wouldn’t be hard to find out.

Is there some other mechanism in place to prevent this kind of abuse?

Any clarification on this would be appreciated.

Thanks.

2

Having thought about this a little further, I’m wondering if there are checks on which nodes requested specific hashes when the they are sent via XNet?

More specifically, if the ECDSA key-generating / signing canisters verify that at least 2/3 of the ECDSA-enabled source canisters all requested signatures for the same hash, then based on the standard rules for the IC, that’s enough to assume that the signing request itself is valid, and can be responded to.

Otherwise, if not enough nodes request the signature of a particular message_hash, then a signature shouldn’t be returned.

Is there already some kind of check like this in place?

1 Like
3

The scheme is resilient towards up to a third of the nodes on the ECDSA subnet being corrupt, so no single rogue node can do anything bad. Signing requests go through consensus, so there is agreement among the nodes on the unique messages to sign; likewise Xnet works such that the nodes on the sending subnet agree on messages sent.

3 Likes
4

@JensGroth - Thanks for your response.

When the signing requests go through consensus on the sending subnet, does that also require 2/3 nodes to be in agreement before the signing requests are sent to the ECDSA subnet for signing?

5

Yes, 2/3’s of nodes being in agreement is needed to certify the output of the sending canister on the sending subnet.

2 Likes
6

Thanks for the clarification. Much appreciated.