Managing digital assets and data safely, has emerged as a critical issue for both businesses and individuals. One aspect of modern-day business that’s becoming more important is the need to distribute authority between multiple parties; in response, threshold signature schemes (TSS) that leverage multi-party computation (MPC) have emerged as an effective solution [1].
MPC TSS wallets answer a complex question: How can we democratically distribute control over a shared asset — securely, transparently, and efficiently?
These wallets leverage multiple key shares to authorize digital transactions, thus eliminating the risk of single-point failure and guaranteeing widespread approval for every action. In particular, the TSS empowers a group of n parties to share control over a single secret, with a subset of t parties needed to produce a valid signature for a message.
A. So then, what is Proactive Refresh?
Proactively refreshing is a standard aspect of any good security. TSS is slightly different, however, as for a TSS-secured asset, an attacker must be able to form a valid signing group. They must get access to at least t key shares simultaneously, and once updated, fresh shares become incompatible with all the stale past sets. By regularly refreshing key shares, we create a moving target for attackers that becomes much more difficult to hit.
Proactive refresh ensures that the TSS remains secure, making it an essential tool in the toolbox of wallet guardians.
However, having all parties take part in the key rotation security layer is not ideal — everyone will have to regularly be online all at the same time, will all need to remain honest during the rotation, or take part in other such cumbersome protocols [2].
To solve this, we introduce the Offline Proactive Refresh.
Offline Proactive Refresh as an extension represents a significant advancement that amplifies both the security and versatility of any elliptic curve-based threshold signature schemes. The charm of offline proactive refresh is in its flexibility: it enables the continuous renewal of key shares in an MPC-TSS scheme, without requiring all parties to be online every time. Only a valid signature group (i.e. a subset of members that meet the authority threshold to make a decision) must participate, and other parties who were not present are able to catch up later, on their own terms, and after an arbitrary amount of time has passed.
B. Why Offline Proactive Refresh?
Proactive refresh is well-established. But the Offline variant [3] gives Two critical advantages:
B.1 Catching Up at Convenience: The proactive refresh convention allows members who were not online during the refresh process to catch up whenever they can, by receiving a single message. This feature ensures that no party is left behind due to their absence during a key refresh session — even if they miss multiple epochs.
B.2 Avert Denial of Service attacks: In some proactivized refresh TSS implementations, all members of a group are needed. However, a malicious party could simply refuse — blocking an important security layer from getting executed (similar to a DDoS). Offline proactive refresh needs only two parties, so one can simply omit them and retain security.
B.3 Accountable Key Rotations: Each time the keys are proactively refreshed, a record is created identifying the quorum of signers who generated the refresh packet [3].
B.4 Lightweight: The refresh portion of the convention only takes three exchanges between two parties, and is followed by a typical signature session [4].
Let’s take an example case:
I have my own version of 2FA between myself, and a coin exchange. Between us, we have a TSS(2, 3) system in place to sign transactions — the exchange holds one share, and I have one on my laptop and another on my phone — to sign a transaction we need two of these shares to cooperate. We want to proactively refresh once a day to maintain security, but that would require my phone and laptop, both to be online at a specific time, which is not always practical.
With the offline protocol, however, only one of my devices needs to be online when the refresh runs, to cooperate with the exchange. My phone, which is likely always on, can collaborate with the exchange to refresh the key shares in the evening. In the morning, when I turn on my laptop it can fetch the catch-up refresh packet from the exchange and update its own share.
If I don’t turn on my laptop for a few days, perhaps over the weekend, when I open it on Monday the laptop can fetch several refresh packets and simply step through them sequentially, updating to the Saturday state, then Sunday, and finally to the newest Monday state. As long as an offline device has access to the complete chain of refresh packets, an arbitrarily stale share can be caught up to the newest state (P.S: but note that missing any refresh packets would prevent this!).
C. Understanding Offline Proactive Refresh
In TSS, multiple parties collaborate to generate a shared secret, usually denoted as u₀ (though in reality, this is multiplied by an ECDSA curve generator). The shared secret, u₀, is obscured by each party, only actually knowing one portion of the sum value:
Each party creates a polynomial of degree t, represented as fᵢ(x), which satisfies:
They distribute points on their own polynomial to other parties; the values distributed are multiplied by the curve generator also. The group can collectively recover u₀ without exposing individual shares of the secret.
The Offline Proactive Refresh protocol applies to the special case, where t = 2. In this scenario, each party, i, has a degree 1 polynomial:
The goal of refreshing all participant shares is to update each party’s aᵢ values using the same refresh token nonce, Δ, while leaving their bᵢ values unchanged; this means that the public signature verification key remains the same across epochs. This new polynomial will look like this:
The party also knows a point on each of the other participants’ curves, Fⱼ(xᵢ) = fⱼ(xᵢ) G, where G is the curve generator. Each party is able to also update their value of Fⱼ(xᵢ) even without knowing fⱼ(xᵢ).
To summarize, all a party needs to know is the value of Δ, and they are able to update their key share entirely on their own, including their points on polynomials to which they don’t know the underlying curve. This is what enables the offline aspect of the refresh.
So, we can now understand the relative simplicity of the Offline Proactive Refresh convention:
- Two parties generate a nonce together, Δ, and update their shares
- Those same two parties sign a message, confirming the hash of the value of Δ publicly — without revealing Δ itself
- Offline parties are separately told the value of Δ. They can check its authenticity using the public message signature, then update their key share using Δ
As always, progress is a collaborative affair, and we’re open to feedback and conducting joint research. Aiming to open-source the framework, methodology, and results, with all credits attributed, we welcome you to join the discussion by emailing info@silencelaboratories.com, booking a slot to discuss more through Calendly, or writing to us on Twitter @SilentAuth.
ABOUT US:
Silence Laboratories is a deep-tech authentication provider that offers developer-friendly SDKs and libraries for protocols, wallets, and custodians that can be used to embed/build distributed, zero-trust authentication or authorization products alike. We aim to be a defacto MPC and Proofing product suite for others to build on top of. For ease of integration, we are application, protocol, custodian, and stack agnostic, technologically fluid, and future-forward.
References
- “What Is the Threshold Signature Scheme?”: https://cryptoapis.io/blog/78-what-is-the-threshold-signature-scheme
- “UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts”: https://dl.acm.org/doi/abs/10.1145/3372297.3423367
- “Proactive Refresh for Accountable Threshold Signatures”: https://eprint.iacr.org/2022/1656
- “Refresh When You Wake Up: Proactive Refresh Threshold Wallets with Offline Devices”: https://eprint.iacr.org/2019/1328.pdf
- “Threshold Signatures Explained”: https://academy.binance.com/en/articles/threshold-signatures-explained
CEO, Co-Founder
