This is the eighth and last blog in a series aimed at explaining the growing use of MPC and threshold signing to protect cryptocurrencies.
Check out the rest of the blog posts in this series:
- Shamir Secret Sharing and Quorums
- Threshold Signature Schemes
- Additional Properties of Threshold Signing
- MPC Compared to Other Approaches
- Asynchronous Approval in Threshold Signing
- The Importance of Proofs of Security
- Publicly Verifiable Backup of Signing Keys
In the previous blog posts in this series, I described the use of MPC and threshold signing for protecting cryptocurrencies, along with its main features and properties. In this post, I conclude the series with a discussion regarding the difference between a cryptographic MPC protocol and a full-blown security solution.
MPC Protocols vs. Security Solution
The MPC protocols for threshold signing that are at the core of a solution to protect cryptocurrencies (or anything else for that matter) are without a doubt crucial to the security achieved. These protocols must be designed correctly, must achieve the required level of security (e.g., security for malicious adversaries), and must be implemented with great care. If all of this is done correctly, then – in the context of what we are discussing here – one is guaranteed that only an authorized quorum of parties is able to carry out a transaction. This is the primary property we are looking for, and so one may think that everything else beyond this is just packaging (which are also non-trivial, but not related necessarily to security). However, the truth is that a full solution needs to take many other security issues into account:
- How is the system securely installed?
- How are parties identified and keys issued to them?
- How are keys generated and securely backed up? How can we ensure that the backup is correct?
- How are the sharings of the signing keys refreshed to achieve proactive security?
- How are shares revoked from participants leaving the quorum and how are new participants added to a quorum?
- How is the system administered in a secure way?
- How are policies mandating what operations are allowed and under what conditions distributed in a secure manner amongst all participants?
- How is the UI designed to encourage proper usage with high security?
- How does the vendor help in implementation to achieve high security?
All of the above, and more, are needed in a full-blown solution, and a lot of these aspects are non-trivial to achieve.
We have discussed secure backups, proactive security, party administration (adding and removing parties) in previous posts in this series. These all require cryptographic expertise and care to design, and to be integrated with the MPC threshold signing protocol. This is even more challenging when different signing algorithms (e.g., ECDSA, EdDSA, Schnorr, over different curves) and standards (e.g., BIP 032/044 derivation) need to be supported. The level of complexity in this case becomes much greater, and one is no longer analyzing and reasoning about a single isolated execution of “key generation” and signing” of a single protocol, but an entire dynamic system.
We have not discussed other aspects mentioned, like installation, issuing keys to parties, and so on, and indeed this is out of the scope of this blog series (which focuses on pure cryptographic aspects). However, I stress that ignoring these aspects can render an excellent cryptographic core completely insecure in practice.
- If an attacker can add malicious participants to the quorum, until it controls a full quorum, then all security is lost
- If an attacker can steal key shares as they are sent to parties during installation or when parties are added (e.g., via a man-in-the-middle attack), then over time it can steal enough shares to obtain the key.
- If an attacker can modify policies that mandate what operations are allowed, then it can undermine an important part of the security infrastructure.
The above are just a few examples of many things that can go wrong. As such, it is strongly recommended to discuss these issues with any vendor offering a security solution in this space. Needless to say, it is important to also verify that the vendor has the cryptographic expertise to build such a solution and is willing to tell you what protocols they are using and what level of security they achieve.
MPC/threshold signing as a technology is extremely well-suited to the problem of cryptocurrency protection. We have discussed the major aspects required from such a solution in this series and hope that it was beneficial. A lot of the principles discussed here are relevant to other settings where signing is extremely sensitive, and manual verification is possible. For example, these principles could also be applied to a CA issuing certificates, signing code to be pushed out to users, and more.