[Feature]: ☂️ Stable aggregate public keys using PSS/VSS (share refresh/reshare) and repairable shares (RTS)

[cylewitruk]

Feature - Stable (and repairable) aggregate public keys using PSS/VSS (share refresh)

1. Description

1.1 Context & Purpose

Today, the sBTC signer set generates secp256k1 keys via an on-demand DKG process, for example in the following cases:

• The signer set has changed (added/removed/swapped a signer),
• The signature threshold has changed,
• A decision to refresh the keys has been made and the signers have aligned their configurations accordingly (e.g. if the key has been deemed to have been compromised).

This approach has a couple of limitations, however:

1. Unstable Aggregate Keys. When DKG is re-run (likely due to one of the above reasons), the resulting aggregate public key changes, forcing the bridge contract and off-chain participants to update to a new aggregate key each time, which can lead to drift (i.e. differing views of the current group public key).

2. Fragile Secret Shares. If a signer loses its secret share (e.g. disk failure, operator error), there's currently no way to recover it. The only option is to rerun the entire DKG, which changes the group public key. This threatens liveness and increases operational overhead. Some work has been done to attempt to mitigate this by using a participant-specific deterministic generation of poly commitments, however the full solution for recovering shares in practice is not yet implemented.

To address the above, we can use Verifiable Secret Sharing (VSS) and Proactive Secret Sharing (PSS) protocols to enable periodic share refresh and share recovery using a protocol akin to Repairable Threshold Scheme (RTS), while maintaining a stable aggregate public key across "key epochs".

In addition to refresh and repair, a re-sharing protocol could be used to add, remove, or swap signers in the set without requiring a new DKG. Re-sharing redistributes the same underlying group secret among a new participant set (with the same threshold policy).

This allows:

• Long-lived signer groups with fixed aggregate public keys,
• Resilience against individual signer failures (share loss or compromise),
• Periodic share rotation to mitigate key exposure without changing the aggregate key (old shares are invalidated by a refresh, assuming n - t + 1 honest signers delete their old shares) -- a periodic refresh reduces the potential attack window for compromised shares),
• Repair of lost shares by a threshold of honest peers, without requiring a full DKG rerun.
• Incremental signer set changes without changing the aggregate public key.

2. Technical Details

2.1 Sub-Issues

(To be refined and then created as sub-issues)

1. (WSTS) Implement VSS/PSS share refresh protocol

• Implement and provide an API for proactive refresh of each signer's share without changing the group public key (this is probably most intuitive as an instance method on a loaded state machine).
  • Some past work has been done regarding this in the PR Keep polynomial constant parameters during DKG xoloki/wsts#92.
  • Otherwise, some inspiration may be found in https://github.com/ZcashFoundation/frost/blob/main/frost-secp256k1/src/keys/refresh.rs and https://github.com/ZcashFoundation/frost/blob/main/frost-core/src/keys/refresh.rs.
• Based on standard Feldman/Pedersen VSS with additive share refresh (new polynomial with zero constant term). Trusted dealer/centralized approaches should not be used. @xoloki please confirm
• Investigate if this can be done non-interactively for potentially offline signers, or if we have a 100% liveness requirement for refresh.

2. (WSTS) Implement share repair / RTS (Recoverable Threshold Shares) protocol

• Allow a signer who has lost its share to request a recovery from the signer set, using a threshold of its peers, by broadcasting a recovery request.
• Peers provide encrypted fragments that can be combined to reconstruct the original share (via a secure direct channel between peers).
• https://eprint.iacr.org/2017/1155.pdf (as referenced by ZCash's frost crate).

3. (WSTS) Implement a re-sharing protocol for membership changes

• Allow the signer set to add, remove, or swap signers without running a new DKG using distributed resharing of the existing group secret with the same constant term, generating shares for the new participant set.
• Removed signers are simply excluded from the new polynomial distribution, and their shares become invalid.
• The aggregate public key remains unchanged.
• Likely very similar to the refresh machinery, but with support for changed participant lists.

4. (sBTC) Implement & expose LibP2P's request/response protocol

• The above protocols require secure direct communication between signer peers (i.e. non-broadcast). LibP2P provides the mechanisms for this (request/response protocol), but it is not currently integrated into the signer.

5. (sBTC) Implement share refresh in the sBTC signer

• Implement support for share refresh and accompanying integration tests.
• Introduce a hidden configuration flag which will prefer refresh over DKG when DKG shares are present, or full DKG when no shares are present.

6. (sBTC) Implement signer set re-sharing in the sBTC signer

• Add support for safely resharing to reflect signer set changes without full DKG, including integration tests covering add/remove/swap scenarios.

7. (sBTC) Define policy for share refresh vs. re-sharing vs. re-DKG

• Clearly define when each mechanism is used, e.g.:
  • Refresh for routine key hardening and sub-threshold compromises.
  • Re-sharing for incremental membership changes.
  • Re-DKG for >= t compromise, major churn (large set change), or threshold/policy changes.

2.2 Acceptance Criteria

• Signers' aggregate public key remains stable across multiple share refresh cycles.
• A signer can successfully recover its lost share with the help of >= t peers without triggering a new DKG.
• Membership changes via re-sharing do not change the aggregate public key and do not require on-chain contract updates.
• All VSS/PSS refresh , re-sharing and RTS recovery steps are cryptographically verifiable by other signers.
• Integration tests which demonstrate that signer sets with any of refreshed, repaired and re-shared shares can still correctly sign/spend in all relevant flows (sweep deposits/donations, spend signers' UTXO, etc.).
• No single signer learns another signer's share during refresh, re-share or recovery.

3. Related Issues and Pull Requests (optional)

• Keep polynomial constant parameters during DKG xoloki/wsts#92
• feat: generate recoverable private shares during dkg #1746

[xoloki]

1.1.1: "which can lead to drift"

What is drift here?

[xoloki]

1.1.2: "If a signer loses its secret share (e.g. disk failure, operator error), there's currently no way to recover it without rerunning the entire DKG, which changes the group public key."

This doesn't exactly recover the share. A better way to phrase this would be:

"If a signer loses its secret share (e.g. disk failure, operator error), there's currently no way to recover it. The only option is to rerun the entire DKG, which changes the group public key."

[xoloki]

"Recoverable Threshold Shares" should be "Recoverable Threshold Scheme"

[xoloki]

When you say:

"Based on standard Feldman/Pedersen VSS with additive share refresh (new polynomial with zero constant term)."

Do you mean that each user adds a zero constant polynomial to their existing polynomial?

[xoloki]

"Investigate if this can be done non-interactively for potentially offline signers, or if we have a 100% liveness requirement for refresh."

Unless I'm missing something, after generating a new polynomial, each signer still needs to send DkgPrivateShares, with their new polynomial evaluated at every signer ID. If a signer doesn't send these shares then the sum of the private shares will no longer be a point on the group polynomial.

[xoloki]

"Periodic share rotation to mitigate key exposure without changing the aggregate key (old shares are inherently invalidated by a refresh -- a periodic refresh reduces the potential attack window for compromised shares)"

Old shares aren't exactly invalidated by the refresh, since the aggregate key doesn't change. A threshold of signers who keep their old shares can still sign with them. But as long as (n - t + 1) signers delete their old shares, then there will no longer be such a threshold of old shares extant.

[djordon]

Thanks for putting this all together, this is great. Some quibbles:

4. (sBTC) Implement & expose LibP2P's request/response protocol

I don't think we need this. Right now during DKG, we do a Diffie-Hellman key exchange (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) so that only the intended party to decrypt secrets between signers when messages are broadcast.

13. (sBTC) Define policy for share refresh vs. re-sharing vs. re-DKG

• Clearly define when each mechanism is used, e.g.:

  • Refresh for routine key hardening and sub-threshold compromises.

I don't think we need proactive resharing. Maybe we should add it, but I think doing so would depend on the specific kinds of threats that we are trying to thwart and whether proactive sharing makes sense that model. So, if you think that we should add it, we should spell out why and then we can hash it out.

[xoloki]

4. (sBTC) Implement & expose LibP2P's request/response protocol

I don't think we need this. Right now during DKG, we do a Diffie-Hellman key exchange (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) so that only the intended party to decrypt secrets between signers when messages are broadcast.

With ephemeral DKG keys, this will require a bit of work. So any signer who needs recovery/etc will need to broadcast a public key in that request, and anyone communicating with that signer will need to include their public key in the response.

It also raises the issue of the DkgPrivateShares from the previous dkg round. The ephemeral private key will need to be stored so these can be decrypted at a later date for recovery. Or else they will need to be stored encrypted symmetrically with that signer's long lived private key.

[xoloki]

"Allow the signer set to add, remove, or swap signers without running a new DKG using distributed resharing of the existing group secret with the same constant term, generating shares for the new participant set."

We can certainly use the recovery protocol to swap signers, i.e. if a signer drops out a threshold of the remaining signers can send private share data that will allow a new signer to interpolate the old signer's polynomial. However, all signers must send the swapped signer public and private shares for the new signer to create signing shares. So it's not exactly running a new DKG, but it effectively is for the new signer.