This is the fourth blog in a series aimed at explaining the growing use of MPC and threshold signing to protect cryptocurrencies.
In the first three blog posts in this series (read Shamir Secret Sharing and Quorums, Threshold Signature Schemes, and Additional Properties of Threshold Signing), I described how protection against fraudulent key usage, which is the primary problem for cryptocurrency protection, can be achieved using secret sharing and threshold signing. Beyond the basic ability to achieve cryptographically enforceable quorum authorization so that only an authorized set of parties can generate a signature, 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. In this blog post, I will compare this approach to other existing ones.
Multisig, in the context that it is used in cryptocurrencies, is essentially a composition of multiple signatures that are verified against a given quorum structure. For example, a quorum structure of 2-out-of-3 is defined with 3 public keys, and the verification procedure would verify that it received 2 signatures on the same message that are valid for 2 of the 3 defined public keys. In some sense, technically, multisig is the inverse of threshold signatures. Recall that for threshold signatures, the KeyGen and Sign procedures are modified, but the Verify procedure remains the same (thus, the Sign protocol generates a standard signature which is the same as a locally-generated signature). In contrast, for multisig, the KeyGen and Sign procedures are the same (and each signature is generated locally), but the Verify procedure is changed so that it verifies multiple signatures against a given quorum structure.
When viewed in the above light, multisig and threshold signatures are just different ways of achieving the same goal – no unauthorized subset of parties can generate a (new) valid signature, even given previous signatures. However, there are numerous differences between them:
- Complexity: cryptographically, multisig is much simpler. In particular, the original KeyGen, Sign and Verify algorithms are used, and the only difference is a small amount of code to verify multiple signatures and check the quorum structure. In contrast, threshold signature schemes are advanced cryptographic protocols that require high expertise to design and deploy.
- Platform support: Threshold signing schemes generate standard signatures that are the same as locally generated signatures. As such, they are agnostic to the platform, and no special support is needed. Concretely, the blockchain or specific cryptocurrency need not have any support, or even be aware that the signature is generated in a special way. In contrast, multisig signatures need to be verified in a different way, and thus they must be concretely supported by the platform. Since not all cryptocurrencies support multisig, this can be a problem. In addition, there is a cost associated with multisig (since it’s a type of smart contract), and there can be limitations on the complexity of the quorum structure. Finally, going forward, it is not possible to know what future currencies will or will not support multisig, and to what extent. Thus, multisig is more limited in applicability.
- Structure anonymity: In some cases, the type of quorum structure being used may itself be a secret (e.g., in order to not publicly reveal to the adversary what shares have to be stolen, or since the business process may be confidential). Since threshold signatures generate a standard single signature, the structure can be kept secret. In contrast, in multisig, the structure is publicly known.
- Refresh: As I described in the previous post, threshold signatures support a refresh of the sharing in order to prevent gradual theft of the shares. Multisig does not support this, since each key is held in its entirety and cannot be changed without transferring the funds. Thus, there is no mitigation against an attacker slowly stealing each key over a long time.
- User replacement: Likewise, as described in the previous post, threshold signatures support removing and adding parties who hold key shares and are authorized to be part of a quorum. This is a crucial feature in business settings. In contrast, multisig does not support this. If we wish to modify a quorum from 2-out-of-3 to 2-out-of-4 (since a new employee joined the group), then we would have to transfer the funds to the new structure when using multisig. Likewise, removing an employee and changing the quorum from 2-out-of-4 to 2-out-of-3 would require transferring the funds. Finally, replacing an employee with another would also require changing the key and thus transferring the funds, since otherwise the previous employee would still have authorization (unless the employee’s share is on a secure smartcard, in which case the card itself can just be handed over).
In short, although threshold signing and multisig address the same basic issue, threshold signing has many advantages over multisig. The primary advantage of multisig (and this can be significant) is that it does not require any special cryptographic expertise to build and deploy.
Currently, cryptocurrency exchanges store the vast majority of their currency (actually, the keys that protect that currency) in cold storage – meaning on machines that are disconnected from the network. The cold storage is stored in a physically protected vault that requires a quorum of employees to open. This solution has advantages but is not perfect, even from a security perspective. This is because the transaction information needs to be transferred to the disconnected machine, and the resulting signature transferred back. If this is done via a channel that can carry additional traffic (e.g., via USB), then it can be used to deliver malware. This is a non-trivial attack but one that should nevertheless be considered. Leaving security aside for a moment, the use of cold storage is extremely problematic from a business operations perspective. In order to transfer funds, a number of employees have to be physically present. In order to provide reasonable transfer times, this requires employees to be present at nights, on the weekends, during holidays and so on, resulting in employee dissatisfaction. In addition, due to the need for a physical ceremony, the process is slow. The result is that exchanges can sometimes only guarantee transfer times of days, with the best-case being hours.
HSMs, or Hardware Security Modules, are used to protect cryptographic keys from theft. They do this by allowing keys inside to be used internally only, and never agreeing to export them. Beyond the question of how secure HSMs actually are (see this post for a discussion), as we have discussed, HSMs solve the wrong problem since they focus on key theft and not fraudulent key usage. In particular, if the machine that is authorized to issue cryptographic operations to the HSM is breached, then signatures can be generated to transfer all funds to the attacker. Thus, this still remains a single point of failure, and doesn’t really solve the problem being addressed.
I note also that HSMs don’t always support the exact operation needed for the cryptocurrency platform (e.g., the specific curve for the elliptic curve signature scheme, BIP derivation, and so on). In such a case, some use an HSM to only encrypt the private signing key (like data). Then, in order to carry out an operation, it is decrypted on to a standard server and used. Needless to say, such a method is not very secure.
It is possible to construct a dedicated HSM that will enable quorum definitions, and will carry out the signing operation inside only after receiving authenticated requests from an authorized quorum. Such a dedicated HSM essentially replaces the MPC protocol performed for threshold signing. To the best of my knowledge, such a solution is not currently available on the market. However, it is conceivable that it will be built. If yes, then it could be built well. However, it is important to stress a few important points. First, the authenticated requests to sign a transaction need to be protected by cryptographic keys, and one would want a strong method for protecting these (e.g., including a refresh element, to prevent gradual theft). Second, the hardware needs to be well vetted, and the security by obscurity approach taken by hardware vendors until now is problematic. Third, the speed at which additional functionality can be added (e.g., to support new coins) and at which patches can be issued in the case of vulnerability is important; see this post again for a discussion about the importance of this to security.