listen to this article:

Cryptocurrency Protection: Using HSM, Multi-Sig, and MPC

Hardware Security Modules (HSM) have been the financial sector’s go-to key protection strategy for the past two decades. Multi-Sig has become the default choice for crypto-native institutions that want to secure cryptocurrencies and blockchain transactions. Both are well-known and well-documented – but have many disadvantages, especially when compared to Multi-Party Computation (MPC).

Today, we’ll break down what each of these technologies is and is not – and why MPC is a better choice for financial institutions considering a long-term investment in cryptocurrency services and blockchain data protection.

See how Unbound CORE addresses cryptoasset security challenges in this technical whitepaper

But first, a brief reminder of why key protection for blockchain data is different than traditional key protection and management.

Securing Cryptocurrency vs Securing Other Assets

Fiat currencies are protected by private keys and credentials: a password to gain access to a bank account is a classic example of this (and physical keys to access a physical vault). Cryptocurrency and blockchain data, however, are keys by their very nature. With crypto, the keys are the asset.

This means, in practice:

  • Due to the immutability principle that is inherent in the blockchain design, once a transaction is recorded there are no do-overs. This presents unique issues relating to fraud and anti-money-laundering (AML) protection.
  • One misuse of a key is enough to lose it all; the malicious actor does not even need to have the key in his/her physical possession in order to gain ownership of the asset. This presents unique challenges in terms of protecting data and user privacy, considering that the decentralized ledger is available for the public to view (in the case of traditional cryptocurrencies).

HSM for Cryptocurrency Protection

An HSM is a physical computing device purpose-built for secure key storage and cryptoprocessing. In short, HSMs are designed to protect key confidentiality. Operations can be made with keys while the keys reside within the secure hardware environment.

For cryptocurrency purposes, HSMs are used to store blockchain keys that are used for signing and validating transactions. While HSM can be connected to a network, they can also be used in offline mode to protect wallets that are completely disconnected from the Internet, also known as “cold storage.”

HSMs have become an industry standard after roughly 3 decades of use and development, and have well-established standards and certifications such as FIPS 140-2. For cryptocurrency enthusiasts, HSM wallets are the security method of choice for those who swear by “cold storage” over “hot storage.”

HSM Limitations

HSM’s primary shortcomings are related to accessibility and usability, but there are a few security shortcomings as well.

  • Do not address the threat of key misuse – as stated, one key misuse is enough to lose the asset when it comes to cryptocurrency and/or blockchain data. HSMs do not typically provide mechanisms for detection of key misuse and have no quorum authorization structures for key usage in place (quorum authorization structures do exist in HSM, however they’re typically applicable only to sensitive administrative operations and not for key usage). If an attacker compromises a system or application that has permissions to use keys in the HSM, or if a rogue insider abuses such permissions, they can sign fraudulent cryptocurrency transactions. One such signature is enough to empty all cryptocurrency in a specific address.
  • Not crypto-agile – Due to the nature of hardware, updating HSMs to counter newfound vulnerabilities is both time-consuming and costly. In practice, upgrading an HSM may not only involve a firmware upgrade — but, in some cases, replacing the physical appliance itself; upgrades can take months to years, particularly for production systems.
  • Difficulties supporting new ledgers — HSMs are built to support cryptographic curves (not ledgers, per se) – and in order to support a given ledger, the HSM must support the specific curve used by that ledger (e.g. Bitcoin and curve secp256k1). In the event a ledger is introduced with a curve not supported by the HSM system or in the event a hard fork of a cryptocurrency introduces cryptographic curve changes, upgrading HSM systems becomes a serious problem. Exchanges, in particular, would face difficulties upgrading their systems to keep up with the market and offer competitive services that cover the latest popular currencies.
  • Slower transaction times and lack of automation – Cold storage HSMs require manual input and have limited capacity for automating verification and signing transactions. This means both inefficient use of manpower and long transaction times, limiting the level of service that cryptocurrency service providers could provide to their customers.

MultiSig for Cryptocurrency Protection

Multi-sig is something else entirely: an online address built directly into the decentralized ledger system which allows linkage to more than one private key. In simple terms, a multi-signature address is (usually a Bitcoin) address which is linked to more than one private key.

Multi-signature addresses emerged in early 2012 when Bitcoin had presented an alternative to single key addresses. Around that time, a new type of address called pay-­to-­script-­hash (P2SH) was defined and standardized. P2SH addresses can be recognized by the fact that they begin with a “3” instead of a “1.” Among the functionality supported by P2SH addresses is the ability to require multiple private keys to transact, known as multi­signature, or more commonly, multi­sig.

Practically speaking, signing a multi-sig transaction involves a quorum of m-of-n (typically 2 out of 3) dedicated signatories adding their signature to a proposed blockchain transaction; added signatories should, in theory, prevent fraud by providing additional verification for any given transaction – whether those added signatories are joint account holders (e.g. a client and his/her spouse), or a verified wallet, security service, or bank employee (e.g. a client and a company employee or bot). Some ledgers support bigger quorum sizes, for example, 3 out of 5, but this is relatively rare, and adds significant complexity and processing requirements.

Multi-Sig Limitations

Ultimately, multi-sig’s problems are largely due to the high TCO for institutions looking for a long-term security solution; most multi-sig solutions require lots of customization over a long period of time.

  • Limited support for multiple ledgers – Multi-sig was originally built for Bitcoin, and overall are ledger-dependent. Multi-sig solutions require significant development for supporting any new asset, as they are custom to every ledger. In addition, multi-sig addresses are preset. Any change must be custom coded, which requires time and money, and means dependence on the IT or solution vendor for daily operations
  • Difficulty supporting more than 2 of 3 approvers – Multi-sig has limited flexibility in supporting advanced quorum authorization policies. Banks and other large institutions often require more complex quorums to meet compliance requirements and/or provide a high standard of security for their top-level customers.
  • Difficulties with flexible approval policies – again, a problem of custom coding. Changing approvers can require more development work and stall deployment and upgrade times. Furthermore, there is no flexibility to modify approvers based on factors such as time of day, amount, etc. The vendor may mitigate this challenge with custom code that is application-based — but that is much less secure than cryptographic mechanisms and hence exposed to various attacks.
  • Higher transaction fees – In a quorum situation, multi-signature scripts entail more data to accommodate metadata about each signer. The result is a higher cost for block processing, which may be reflected in higher costs for the end user.
  • Lower transaction times – More data = more time to process a new block – on top of the block processing limitations per ledger (e.g. Bitcoin – 10 minutes per block; Ethereum – 10-15 seconds per block).
  • Incomplete signatory privacy – While the possibility of a real breach is small, the risk of an experienced hacker being able to track down the signers and compromise them is there.

MPC for Cryptocurrency Protection

Multi-party computation (MPC) enables a distributed model of trust based on splitting secrets into multiple shares distributed across multiple entities, with a strong yet elastic and agile pure-software platform. In the case of blockchain transactions, MPC is used for securing the blockchain private keys and executing the sign operation using key shares held by multiple signers. Because keys always remain split into multiple shares throughout their lifetime – starting from key generation and even while in use – it is possible to protect the keys without requiring dedicated hardware like an HSM, and to establish advanced approval quorums without the complexity and cost of multi-sig.

Unbound’s Core Crypto Asset Security leverages MPC to eliminate the single point of compromise in a transaction. Here’s how:

  • A key is generated as multiple random key shares. The key-shares are created and stored separately in different locations and each random share alone reveals no information whatsoever about the actual key.
  • The key shares are stored in different servers and/or end points that are strongly segregated, for example between different clouds, in a hybrid-cloud constellation or between endpoint devices and one or more servers, to ensure the utmost security. The key shares are never combined at any point in time: all operations are carried out without ever uniting the key shares, including key generation and key usage (i.e. signing).
  • Key shares are refreshed at frequent intervals, creating a conundrum for any malicious actor who may gain access to one share. In order to compromise the key, an actor would have to access multiple key shares in a very short window of time, before the shares are randomized again. This requirement to compromise multiple key shares simultaneously in order to compromise the key is guaranteed mathematically– and it’s been confirmed by the world’s foremost cryptographic experts.

How does Unbound CORE for Crypto Asset Security deliver blockchain security?

Unbound’s CORE for Crypto Asset Security is a blockchain security platform built on our core MPC-based technology. It has been designed with tier-1 banks to meet their highest security requirements for cryptocurrency protection.

It’s secure: Key share data refreshes at set intervals across all entities, further reducing the risk of vulnerability should a hacker manage to see multiple shares. The key shares can communicate without revealing the data contained within; in practice, it means the entire key is never in the clear.

The single signature is easy to process – not only does it not reveal any metadata about signatories on the block, but the lack of extra metadata keeps transaction time short and transaction fees low. CORE for Crypto Asset Security supports all cryptographic curves which require ECDSA/EdDSA signing; wallet providers may be interested to know that it includes BIP32/BIP44 protocols as well.

It’s flexible: Multi-group quorums not only add an added layer of cryptocurrency protection, but also rich approval policy support for banks and other large-scale custody solutions. CORE for Crypto Asset Security supports unlimited quorum sizes – don’t settle for 2-out-of-3, go for 8-out-of-10 schemes – and can include multiple quorums for transactions. And risk-based policies are available based on amount, account status, location, time, or asset type.

CORE for Crypto Asset Security is software-only; it can be deployed across any platform (mobile, desktop, server); and changes to policies, opening/closing vaults, etc. can be made in a few clicks of a button.

It’s agile and efficient: as a software-only solution, MPC also allows for quick, easy, code-only updates with immediate deployment. That includes support for any ledger; due to the platform’s ledger-agnostic design, adding new ledger support is achieved in days. Any institution can offer new services to their clients in record time.  Updates to approval policies can be handled by authorized operations staff – no need for additional development work – and can be made with a few clicks or taps.