listen to this article:
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 present different common approaches to use to protect cryptocurrency. A more detailed assessment of which method should be opted for by financial institutions for crypto services and blockchain data protection can be found here.
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 that 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.
Related Article: Comparing Multisig vs MPC
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, 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 onto 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. Moreover, 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.
More blog posts in this series: