Digital Asset Wallets & Signing Algorithms: A Custodian’s Overview

Digital Asset Wallets & Signing Algorithms: A Custodian’s Overview

July 22, 2020

Digital Asset Wallets — An Overview

Permissionless blockchain networks are typically structured so that digital assets represented on such ledgers are a form of bearer instrument, with private keys controlling the ownership and, therefore, the ability to spend the assets (e.g. the “unspent outputs” in the Bitcoin blockchain). As a consequence, private keys are a single point of failure and their loss would imply the loss of the asset itself. While protecting private keys from unauthorized use protects the assets stored in the digital wallet, private keys are also required in order to perform authorized transactions.

In the past few years, we have seen a number of security solutions aimed at addressing the tradeoff between protecting private keys from unauthorized access while making them readily available to execute transactions. Some solutions developed and adopted by market practitioners have guaranteed an acceptable level of security and availability of assets, keeping into consideration the nature of market participants and the overall size of the market.

In 2020, we are experiencing a new wave of adoption whereby banks and other regulated financial institutions are entering the market to offer digital asset services to their clients. As more institutional investors enter the digital asset ecosystem, the current solutions available will prove insufficient to guarantee the security and scalability of custody and transactional platforms. Central Bank Digital Currencies, and especially the ones which will rely on blockchain technology, will further increase the pace of adoption and, in turn, raise the bar for the entire industry.

Our mission at Hex Trust is to provide banks and other regulated financial institutions with digital asset custody solutions which match their internal and external security, scalability and compliance requirements in the long term.

To fully understand the challenges that custodians and technology companies face when designing wallet solutions and their lifecycle management, it is important to analyse the design options available in the market. In this paper, we will focus on two critical concepts: the temperature of the wallet and the signing algorithm.

Wallet Temperatures

The wallet temperature measures the degree of accessibility to the wallet through the network/servers and, hence, exposure to potential unauthorized access in the case of a breach in the infrastructure to which the wallet is connected. In the past few years, most of the discussion around the security of digital asset wallets has revolved around this topic, because cybersecurity has been regarded as the main threat for wallet providers and holders. Even though other security aspects have emerged, the topic is still relevant and current, especially for its implications with respect to compliance with regulatory requirements, insurance costs and, most importantly, speed and scalability of custody platforms.

A cold wallet is a wallet that is not reachable through the network. It is usually hosted on “air-gapped” platforms or devices to minimize the risk of cyber-attacks and unauthorized access.

While cold wallets have historically been associated with the highest level of security, it is important to analyse their pros and cons from a holistic perspective.

In particular, there are three key factors that should be considered:

  1. The relationship between security, speed and scalability;
  2. The overall security framework, and
  3. The software scalability.

With respect to (a), cold wallets structurally require longer access times given that transactions to be signed must be “manually” transported inside and outside of the air-gapped environment. Typical implementations of cold wallets require anywhere from 1 to 24 hours in order to sign transactions. In addition, the “manuality” side of the signing process makes this type of solution hard to scale when the number of transactions grows beyond a certain threshold.

With respect to (b), it is critical to understand that cybersecurity is only one part of the whole security framework that custody platforms are based on. Two other important layers of the security framework are physical and process security. While cold wallets are structurally stronger from a cybersecurity standpoint, they introduce additional risks from a physical and process security perspective. Firstly, air-gapped devices are kept inside physical vaults, which must be built, monitored 24/7 and whose access must be strictly controlled. Secondly, cold wallets unnecessarily introduce the human factor risk in the operating environment, which is very hard to control at scale.

Hex Trust’s Multi-layer Security Framework

Lastly, with respect to (c), cold wallets are usually more complicated to upgrade and to integrate new protocols. Given cold wallets are usually fully air-gapped, deploying new software involves a quite complicated process which does not fare well with the quickly evolving nature of the blockchain market.

A Hot Wallet is a wallet that is connected to the network and always online so that transactions can be signed and broadcasted directly to the relevant blockchain network.

The main risk with hot wallets is their vulnerability to cybersecurity threats, similarly to the risk of any other IT infrastructure connected to the internet. As a consequence, their level of vulnerability is as high as that of the IT infrastructure and network where they are hosted and access mechanisms to the private keys and signing operations.

Conversely, hot wallets allow quick and automatic access to sign transactions using private keys, minimizing the latency to sign and broadcast transactions to the blockchain. Hot wallets are, therefore, a necessity for those market players who require rapid and frequent access to their assets.

Definitions of Warm Wallets vary across wallet providers. In some instances, warm wallets are designed as hardware wallets or HSM devices which are only connected to the host computer when the signing process. In other implementations, warm wallets are structured similarly to hot wallets but integrate additional layers of security such as whitelisting (warm wallets can only process transactions sent to whitelisted addresses) and transaction policies (e.g. on size or frequency of transactions to reduce the value at risk).

Lastly, some custodians and wallet providers have introduced an additional wallet type, usually called Frozen Wallet or Deep Cold Wallet. Similarly to the warm wallet discussion, there is no single definition for Frozen Wallets. While implementations vary across wallet providers, Frozen Wallets commonly add further security features to cold wallets to enhance their security profile, such as complete air-gapped environments for both private keys and servers, and geographical distribution and sharding of cold wallets.

Most custodians utilize a combination of cold/warm/hot wallets, keeping long-term holdings in cold wallets and funds that are frequently traded in hot wallets. Rebalancing processes are put in place so that only the minimum amount of holdings are kept in hot wallets at all times.

Signing Algorithms — HSM, MS, SSS, MPC

From the previous discussion on the wallet temperature, it is clear that neither cold nor hot wallets can, per se, provide a secure and scalable solution in a market that performs a high number of highly valuable transactions.

For this reason, in the past couple of years, the discussion around how an institutional solution should be designed has expanded to other areas. In particular, the topic of signing algorithms has received rampant attention as it is seen as a possible solution to the ‘single point of failure’ problem.

To understand this problem, we need some basic knowledge of cryptography. Since the 1970s, Internet systems have adopted asymmetric cryptography. Asymmetric cryptography makes use of two keys: the private key is the secret information that gives access to a certain system and the public key which can be published and used by anyone.

The digital signatures used in most blockchains are based on three algorithms:

  1. Key pair generation: when the private key and public key are generated.
  2. The generation of the signature: when the private key is used to sign a transaction and the signature is appended to the transaction itself.
  3. The verification of the signature: when the public key is used to verify the authenticity and correctness of the signature.

In this section, we will discuss four different approaches to signing transactions, and we will analyse the advantages and disadvantages of each of them.

Single Signature

Single signature means that only a single private key is required to create a signature and broadcast a valid transaction to the blockchain network.

While managing single-key signing wallets is easier and faster than any other solution, the main problem is that the private key represents a single point of failure and, if compromised, assets held in the wallet can be lost.

In systems based on single signature, the authorization logic of the system has to be implemented off-chain. This means that, whichever authorization workflow is used by a custodian, it has to be independent from what happens at the blockchain level. Once a transaction is authorized by the system, the single private key will be used to sign transactions.

Multiple Signatures (Multisig)

In multisig wallets, funds are stored on a multisig address and can only be moved if multiple signatures are provided. These multiple signatures are generated by different private keys.

This means that when a multisig wallet is created, it will require a certain combination of private key signatures, which is usually indicated as m/n. M stands for the minimum number of signatures required and N indicates the total number of private keys that can sign transactions for the specific wallet.

Preliminarily, this seems to give custodians and wallet providers more flexibility and a higher level of security. In reality, multisig wallets have some architectural limitations and scalability problems. In terms of architecture, every blockchain has a different implementation of multisig wallets, which condemns wallet providers to a significant integration effort. In addition, certain blockchains do not provide multisig wallets and the ‘multisig’ feature is usually implemented through a smart contract, which can introduce additional security risks. This is the case of Ethereum. In terms of scalability, multisig signatures are more expensive than single signatures and at times, investors might end up paying hefty network fees for this additional security feature. Also, once a wallet has been generated with a certain m/n scheme, it is not possible to change the scheme or the private keys. A new wallet has to be generated and funds must be transferred to the new wallet which is a tedious and expensive process.

Shamir’s Secret Sharing Scheme (SSSS)

The Shamir’s Secret Sharing Scheme (SSSS) is a cryptographic algorithm that allows one to separate a single private key into shards (the secret shares) so that each shard can be stored in different locations or be assigned to different parties.

SSSS, similarly to multisig, allows one to create certain combinations of private key shards (m/n). These shards are used to reconstruct the private key when a transaction is ready to be signed. However, differently from multisig, the transaction is finally signed only by a single private key that has been reconstructed by putting together a certain combination of shards.

It is important to understand that the recombination of shards into a private key is performed off-chain, as opposed to multisig which requires a certain m/n of signatures on-chain. As a consequence, transactions signed through SSSS don’t require different implementations for different blockchains and don’t involve additional transaction costs.

While SSSS is relatively easy to implement, it only partially solves the single point of failure problem. Private keys and shards are generated by a single party in a single location. In addition, in order to sign a transaction, the full private key is required which results in a single point of failure risk every time a transaction signature is needed.

Multi-party Computation (MPC)

Multi-party computation is not a new technology. It originated from the work of Andrew Yao and, more specifically, from the famous Yao’s Millionaires’ problem (1982): wherein Alice and Bob are two millionaires who are interested in knowing which of them is richer without revealing their actual wealth.

In MPC, a set of parties that do not trust each other try to jointly compute a function over their inputs, while keeping those inputs private. MPC can be used to compute signatures for blockchain wallets for a certain number of parties (m/n), without revealing each party’s inputs, or shards, at all times. In addition to keeping the shards private, the computation of the transaction signature will not require the reconstruction of the private key.

If we look at the three algorithms we introduced at the beginning of this section, we will find that:

  1. In MPC, the key generation is done without creating a private key. Conversely, the key generation function will create n different secret shares for the same public key and distribute these secret shares to the n parties.
  2. The generation of the signature is done through another multi-party computation which requires at least m secret share inputs (in the case of m/n) to generate a valid signature. The private key is not generated and the shards are not revealed.
  3. The verification is done through the public key and does not require any multi-party computation.

MPC has attracted a lot of attention in the past few months for a number of reasons. Firstly, it allows you to implement threshold signatures without a single point of failure. Secondly, it is protocol-agnostic and does not require a specific implementation for each blockchain. Thirdly, it produces a single signature, minimizing the blockchain fees. Lastly, it allows a high degree of flexibility in terms of modifying the thresholds or the signing parties without the need for generating new wallets.

With respect to the disadvantages of MPC, I found it interesting to read Mike Belshe’s (CEO of BitGo) post and also listen to his recent discussion with Michael Shaulov (CEO of Fireblocks). While I found Mike’s comments inaccurate with regards to MPC’s lack of flexibility in the threshold schemes, I tend to agree with his three observations:

  • Accountability: With MPC based signatures, it is impossible to distinguish which of the key parts were used to sign the transaction. This is a real problem especially in highly regulated environments but can be solved via additional software.
  • Peer Review: As a relatively new technology, it still has some limitations and concerns. Compared to classic public-key cryptography, TSS protocols can be very complex and are yet to be “battle-tested”.
  • HSM Support: HSMs have been employed for decades by financial institutions to secure private key material; current HSMs do not offer support for the brand-new MPC cryptography.

In addition to the above, I would also add that key shards are still sensitive cryptographic material which needs to be managed and secured, just like any other private keys.

I would like to close this section with a summary and comparison of the algorithms we discussed.

Conclusion

With the blockchain market getting ready to enter its maturity phase, custodians and wallet providers have been working to bring to market solutions that can comply with the requirements of highly regulated financial institutions.

The security of private keys and the signing algorithms employed are a small part of the market infrastructure but a crucially important one. Wallet temperatures and signing algorithms are two examples of the design options that infrastructure providers have in front of them. At this point, no single option can be deemed better than the other ones across all aspects, as solutions should be analysed with a holistic framework that takes into account security, scalability, compliance concerns, as well as the specific target market in which the solution is offered and its participants.

At Hex Trust, we believe that the second wave of adoption will come from financial institutions opening the digital asset markets to their clients. Our mission is to provide bank-grade solutions to enable safekeeping of digital assets and secure and seamless connectivity with service providers within the ecosystem.

To learn more or ask any questions about this article, please feel free to reach out: alessio.quaglini@hextrust.com

About The Author

Alessio Quaglini is the co-founder and CEO of Hex Trust and has over 15 years of professional experience, developed in banking, regulatory bodies and management consulting. Prior to founding Hex Trust, Alessio was the Head of Strategy Asia for BBVA, overseeing the overall business development and geographical footprint in Asia. Among the responsibilities, Alessio helped the Bank set up branches and obtain regulatory approvals in Taiwan, South Korea, Australia, and Japan. Alessio was subsequently Director of Financial Institutions at First Abu Dhabi Bank, where he was responsible for developing the bank’s business with Financial Institutions and Non-Bank Financial Institutions in North Asia. Alessio also worked at the Italian Financial Services Authority (Consob) in Rome, where he was responsible for the supervision of public equity and derivatives markets in the market abuse department. Alessio is an early adopter of cryptocurrency and set up Arepo Capital, a cryptocurrency hedge fund in 2016. Alessio speaks four languages English, Spanish, Italian, Chinese — Mandarin, and earned his bachelor’s and master’s degrees in telecommunication engineering from La Sapienza University in Rome, his MBA from IE Business School. He has also earned a Quantitative Finance diploma from Stanford and is a CFA Charterholder since 2012.

About Hex Trust

Hex Trust is the leading digital asset custodian for the banking sector. The platform, Hex Safe, provides compliance-focused custody infrastructure, deployment flexibility, and seamless integration with third-party service providers in the ecosystem such as exchanges, OTCs, lending and staking platforms. Headquartered in Asia, Hex Trust is fully licensed and has offices in Hong Kong, Singapore, Vietnam and Germany.

Thank you! Your submission has been received!
Download the PDF ⟩
Oops! Something went wrong while submitting the form.
More from Hex Trust
The Evolving Landscape of Finance: The Role of Ethereum ETFs
April 24, 2024
The Evolving Landscape of Finance: The Role of Ethereum ETFs
Ethereum ETFs revolutionize finance by bridging TradFi and digital assets. They offer regulated exposure to Ethereum, enhancing liquidity and investor confidence. This paves the way for wider adoption, innovative products, regulatory challenges, decentralization, and potential global market impact.
Read More ⟩
Important Milestones on the Ethereum Network 2024 Roadmap
January 9, 2024
Important Milestones on the Ethereum Network 2024 Roadmap
Ethereum's 2024 roadmap includes milestones like The Merge (PoW to PoS), The Surge (scalability), The Scourge (security), The Verge (user experience), The Purge (efficiency), and The Splurge (innovation). The upcoming Dencun upgrade aims to enhance functionality, security, and scalability.
Read More ⟩
Unlocking Institutional Interest: The Significance of Bitcoin ETFs in Traditional Finance
January 5, 2024
Unlocking Institutional Interest: The Significance of Bitcoin ETFs in Traditional Finance
Bitcoin ETFs simplify Bitcoin investment, trading on stock exchanges. How the involvement of financial giants may lead to approval. Global adoption signals trust and legitimacy. SEC reassessing. Potential regulatory shift.
Read More ⟩
We use cookies, including third-party cookies, to ensure that we give you the best experience on our website. By continuing to browse, you consent to the use of cookies. Learn more about cookies and how to control whether they are enabled. View our Privacy Policy for more information.
Cookie preferences