Threshold ECDSA Signatures

[dieter.sommer]

Threshold ECDSA System Integration

As promised long time ago, I wanted to give you an overview of the system integration of threshold ECDSA and particularly how we intend to deploy the feature.

New and Updated NNS Proposals for Managing Threshold ECDSA Keys

We needed to define or extend multiple NNS proposals to realize the threshold ECDSA key management functionality required for the intended deployment scenarios.

• do_update_subnet: Updated proposal that allows for defining that a specific subnet should generate a new threshold ECDSA key with a given key id.
• create_subnet: Updated proposal that allows for creating a new subnet with a threshold ECDSA key being re-shared from a specified subnet (actually, multiple keys from different subnets could be re-shared to this subnet in the future, the proposal is already generalized to such scenarios). Re-sharing works by the key source subnet computing initial threshold ECDSA dealings encrypted towards the replicas of the target subnet (Phase 1 of the cryptograpihc re-sharing protocol), which are then stored in the CUP for the to-be-created subnet in the Registry. This is all orchestrated by the NNS canisters when executing the create_subnet proposal. Once the new subnet bootstraps, its replicas pick up the initial dealings from the Registry and compute their threshold ECDSA key shares from those initial dealings (Phase 2 of the cryptographic re-sharing protocol).
• update_ecdsa_signing_subnets: New proposal for enabling / disabling the signing functionality for a subnet for a key id.
• set_recovery_cup: New proposal for setting the recovery cup with the initial threshold ECDSA dealings of the intended key from the given subnet.
• A proposal for deleting a given threshold ECDSA key from a subnet.

Note that key ids are pairs comprising the cryptographic group (as variant) and a key identifier (as byte array). Example: (secp256k1, prod_key_1)

Deployment Architecture

Our intended deployment architecture is as follows:

• We initially want one production threshold ECDSA key (and probably a test key, however, this discussion is about the production key) replicated on two subnets for reasons of key availability.
• The NNS will hold the production threshold ECDSA key passively, i.e., the NNS will not accept signing requests with this key.
• A new 34-node subnet will hold the same production threshold ECDSA key and accept signing requests.

Provisioning Flow

Provisioning flow with abstract API calls (the used key name is an example and not defined yet):

• do_update_subnet(subnet_id=NNS, ... , ECDSA_keys={ (secp256k1, prod_key_1) })
  • The NNS is instructed to create a new threshold ECDSA key with id (secp256k1, prod_key_1) locally.
• do_create_subnet(nodes={X, Y, Z, ...}, ..., ECDSA_key_source={ (NNS, (secp256k1, prod_key_1) }, ...)
  • Computes ECDSA dealings for nodes X, Y, Z, ... from the existing key (secp256k1, prod_key_1) and stores them in the Registry as part of the genesis CUP (Catch Up Package) for the new subnet to be created, then creates a new 34-node subnet with nodes X, Y, Z, ..., the nodes of which pull the ECDSA dealings from the Registry and finalize the re-sharing protocol to obtain the threshold ECDSA key (secp256k1, prod_key_1) in secret-shared form.
• update_ecdsa_signing_subnets(A, true, key_id_1)
  • Enables the new 34-node subnet to accept signing requests for the key (secp256k1, prod_key_1).

In case one of the subnets holding the threshold ECDSA key (secp256k1, prod_key_1) is destroyed such the key cannot be reconstructed from the available shares any more and thus needs recovery, we use the set_recovery_cup proposal to create a recovery CUP (Catch Up Package) with ECDSA dealings of the key from which the key shares are computed.

Further Notes

Currently, each subnet can hold a single threshold ECDSA key, future extensions may lift this constraint, e.g., once we need a key in another group or would want multiple keys in the same group. The further may happen sooner than later in order to be able to realize a decentralized CA, which would require one of the secp256r1 groups.

There will be a talk on May 24th in which we will present more details about this topic.

See the attached figure for an overview of the rollout and related key management process.