Protecting the crypto-stash with Multi-Signature, MPC, and HSMs: Part III

This is the third in a series of posts exploring the various approaches to safeguarding crypto assets. Previously, we introduced the typical attack vectors and examined different approaches to protecting custodians against them. This post is about the most vital aspect of security – transaction approvals. They’ve gained importance with the rise of cryptocurrencies, especially considering the damage that a single misuse of a key can cause.

We compared Multi-Signature, Multi-Party Computation, and Hardware Security Modules in their ability to protect cryptocurrencies and assets and in meeting operational, business, and regulatory requirements.

Transaction approvals

Preventing unauthorized access to the key material is, arguably, less than half the job when it comes to protecting crypto assets. The real challenge is controlling the use of the keys. This differs from legacy applications. When a private cryptocurrency key is compromised, the damage is severe. Even if it only happens once, it can cause a loss of millions, if not hundreds of millions of dollars. It’s also practically irreversible. The attacker might not even have physical access to the keys – they merely need to exploit an application that’s been given permission to use the keys locally or remotely.

• Not all cryptocurrencies support it.
• The implementation varies across different cryptocurrencies, adding to the complexity of transaction-processing architecture.
• The larger bytesize of the multi-signature transactions increases the transaction fees
• It doesn’t allow for more complex groups and quorums.
• It isn’t possible to change the rules without moving the asset to a different address. (Some might argue that this is a feature, but as long as it isn’t up to the custodian to define if they want to change these rules or not we see it as a shortcoming).
• The quorum requirements are exposed to the blockchain and thus subject to the same level of blockchain analysis as the asset itself.
• It doesn’t allow for more sophisticated rules based on time, frequency, or volumes.

Multi-party computation addresses most of these issues. Since it’s performed on a single key, which is also required for the approved transaction, it is:

• Blockchain agnostic;
• As inexpensive as any other crypto transaction on a particular ledger;
• Allows for larger groups, quorums, and combinations thereof;
• Flexible on rule change;
• Private.

However, where it falls short is in two main areas:

• Its software-based implementation makes it vulnerable to traditional attacks, such as malware, unsigned code execution, remote system access, keylogging, etc. While these attacks are complicated in linear proportion to the size of the quorum, they are still far from infeasible.
• It doesn’t introduce time restrictions

Legacy HSMs are pretty “dumb” machines: they sign whatever they are requested to sign with an appropriate API authentication key. This is sufficient for legacy PKI applications, where a compromised key can be simply revoked and reissued. However, it’s unacceptable behavior for cryptocurrency applications.

This is the main reason why HSMs have gotten a pretty lukewarm reception from the cryptocurrency industry itself. CISOs know that the protection typically provided by HSMs, which focuses on physical and cryptographic vulnerabilities, is insufficient.

It’s also the reason why Securosys introduced several regulatory mechanisms that allow developers and security administrators to maintain oversight over private key operations. These controls include:

• Multi-party authorization, which allows for the flexible use of groups, quorums and combinations thereof
• Timelocks
• Timeout requests
• Dedicated rules for key blocking, unblocking and even changing the rules themselves

Combined with the right design and operating procedures, such rules practically eliminate the possibility of any outsider or insider attack:

• Multi-party authorization with timeouts might require n out of m financial officers to confirm a transaction within a certain time frame. The combination of quorums might, for example, allow for a smaller group of assenting board members to do the same.
• Timelocks could enforce a delay on any transaction before it’s signed to let an anti-fraud system, or a monitoring team kick in and raise the alarm
• Dedicated key blocking rules allow compliance and risk officers to block any keys immediately if they suspect fraudulent behavior. Additionally, unblocking rules might require a large quorum of risk, security, and financial officers to allow the transactions to continue.

These rules are enforced within the Securosys HSM’s secure container, which physically protects the key material itself. It’s impossible to sneak in an unsigned code or break the protection with a man-in-the-middle attack.

Continued

In the final post of the series, we’ll look at business, contractual, and regulatory considerations, as well as the tradeoffs involved in the various approaches, and finally their respective developer experiences.

You can find more information on the safeguarding of crypto assets here.