This is the fifth blog in a series aimed at explaining the growing use of MPC and threshold signing to protect cryptocurrencies.
In the first four blog posts in this series (Shamir Secret Sharing and Quorums, Threshold Signature Schemes, Additional Properties of Threshold Signing, and MPC Compared to Other Approaches) I described how MPC and threshold signing can be used to protect against fraudulent key usage, which is the primary problem for cryptocurrency protection. Beyond the basic ability to achieve cryptographically enforceable quorum authorization, I described additional properties like “refresh” to prevent gradual theft of shares, and the ability to replace users in threshold signature schemes as is required in business uses. Finally, in the previous post, I compared this approach to other existing ones. In this post, I will discuss an important feature – asynchronous approval.
Simultaneous interaction and MPC
Most protocols for secure multiparty computation require all participants to interact in multiple rounds, and thus be online at the same time. This is true also of the threshold signing protocols known for ECDSA, EdDSA, Schnorr and so on, which require multiple messages to be sent between parties.
In the context of cryptocurrency protection, simultaneous interaction is not a problem if all of the participants are servers, and no human involvement is needed (e.g., the participants are “bots”). Likewise, if at most one human needs to be involved, then it can interact with the servers. However, in many cases, approval from multiple humans is desired or required, and these humans must inspect the request and manually approve it. If the devices held by the humans also participate in the actual MPC (threshold signing) protocol, then this would require all of them to be online at the same time. This is a significant impediment to the ultimate goal of fast transaction time (e.g., consider people in different time zones, or someone being on a train or plane). In addition, in some cases, it is desired to have some cryptographic material in a cold device (i.e., disconnected and truly offline). This is not possible – or at least becomes extremely impractical – if multiple messages are needed to be received and sent by the cold device (since manual transfer of each message is needed).
We therefore conclude that although threshold signing with arbitrary quorums is a very strong tool, it falls short in providing a practical solution in some important real use cases.
Threshold signing with asynchronous approval
In order to solve the aforementioned problem, we can add a step called “asynchronous approval” to the threshold signing MPC protocol. In this case, the participating parties are divided into two types:
- Online parties who run the actual MPC threshold signing protocol, and can interact all with each other simultaneously, and
- Offline parties who provide approval, or authorization, of the transaction, but don’t actually participate in the MPC threshold signing protocol itself. The offline parties should be able to work “asynchronously” which means that each party can send its approval independently of the others (as is needed for humans that provide manual verification of the transaction). In addition, in order to enable this approval step to be practically carried out by a cold device, it should involve a single message to the approver and a single reply back.
We stress that the term “offline parties” can be misleading, since it does not necessarily mean offline in the sense of disconnected. Such parties can be physically offline, but typically refer to devices that are not required to be simultaneously online and send their responses asynchronously.
Naively, the approval step by the offline parties could involve each human approver (or cold device) authenticating to all the online parties running the actual MPC protocol by sending a password. Needless to say, this is very weak since there is no binding between the password and the transaction to be signed, and since the password can be reused in the future even if the approver does not approve. A better solution would be to have each human approver (or cold device) sign on the transaction details (with any secure digital signature scheme), and have the online parties verify that a full quorum of asynchronous approval parties has approved. However, this is still too weak, since an attacker who breaches all of the online parties can just bypass this approval process and generate a signature. (This is possible since the approval parties do not hold any cryptographic material related to the threshold signing. Thus, an attacker can just have the online MPC parties run the protocol as if a quorum of signatures was received.)
The solution used by Unbound is to have the offline parties hold cryptographic material related to the threshold signing MPC protocol, so that without a quorum of the offline parties the online parties themselves cannot generate a signature. Furthermore, the operation carried out by the offline parties is cryptographically bound to the transaction and MPC threshold signing protocol so that the messages sent cannot be reused for different transactions. The security property achieved is therefore that in order to break the scheme, the attacker has to simultaneously corrupt a full quorum of the online parties and have a full quorum of the offline parties approve a transaction.
The details of how the above is achieved is too technical for a blog post, but the above property can be achieved (and is indeed incorporated in Unbound’s CASP product).
It is possible to achieve asynchronous approval for offline parties together with threshold signing. This enables extending security beyond the online parties alone to a set of human approvers and/or disconnected devices, whose participation is cryptographically enforced. This feature can significantly increase security, without significantly slowing down transaction time.