stub Holding a Private Key Is Not Enough for Digital Asset Security - Securities.io
Connect with us

Thought Leaders

Holding a Private Key Is Not Enough for Digital Asset Security

mm

Published

 on

Multi-party computation (MPC) wallets are the prevailing method for institutions looking to self custody their digital assets. Typically this is a 2-of-2 signature scheme where the customer holds a key share on their device and the vendor holds the other. It is better than trusting a provider with the entire key and swapping your direct ownership claim to an asset for a fractional ownership claim if the provider is not backing their liabilities with assets 1-to-1. However this only scratches the surface of what control and ownership of digital assets means. There are multiple other components in the architecture which determine key use (or abuse) and currently comes in the form of a SaaS blackbox. It’s time to shine a light on MPC wallets and show why simply holding a key share falls far short of any tangible control or any legitimate claim to being self custody.

The role of institutions in digital asset custody evolution

Unsurprisingly, large financial institutions were the first to notice this fallacy after spending the last few years monitoring the digital asset space. When it comes to custody they quickly understood the private key question, the role of hardware and also MPC. However in taking a risk based approach to vendor management, they wanted to understand what other vendor side dependencies exist. It turns out that customers are still heavily reliant on the vendor for many things that would constitute ordinary service or use of the software. Examples can include updating policies and business logic on the wallet, adding new blockchains, soft recovery and hard recovery of the account as well as multiple other fairly routine and expected day to day operations. This manifests itself in the user experience as taking multiple days for a provider to service account level changes or update the rules on the wallet, which ultimately means the customer’s main control against certain identified operational risks is temporarily broken until it is brought back into line. 

Taking this further, security-conscious stakeholders understand that they hold a key share but also want to understand what is the risk in having other logical components in the custody architecture hosted by a SaaS provider, the prevailing method for providing MPC wallet software today. This leads to questions such as:

  1. If a vendor performs the key share generation, what are my assurances that they don't have a cop​​y of my key share?
  2. If a vendor hosts my policies, what stops the vendor from changing them?
  3. If the service is hosted by the vendor, how do I guarantee service availability and business continuity? 
  4. If the vendor is offline, how quickly can I meet my recovery time objective?

The answers to these questions quickly pierce the veil of any trust that the customer has control and ownership of their assets. The keyword there being “trust”, as the answers to all of these questions are elaborate forms of: “Trust us” and as established with recent market events that hasn’t worked so well in the past. Institutions are now looking to move away from that sort of thing as they bolster their operational resilience going into 2024. As such, market participants are starting to think about how these risks and potential operating losses reconcile with their risk appetite, regulatory obligations, or any relevant frameworks that impose regulatory capital requirements for risk weighted assets. Service providers are after all an extension of the firm’s surface area of risk. While an institution can delegate a function to a third party, it can not delegate responsibility for sound risk management or regulatory obligations. The more dependent a company is on a third party, such is the case with an MPC wallet provider, then the greater the required oversight and trust.  

Increase control over digital assets to increase security

One way to reduce third party dependencies is for the institutions to host the software themselves in their own data center or private cloud with the vendor’s responsibility being reduced to tasks such as maintenance and updates to the software. This is preferable for many financial institutions as the servers are on premise for access, maintain data security, and can truly prioritize ownership and control over their custody operations. There are also discussions around a co-hosted model which would allow the customer to run one instance of the custody software while also having the vendor or other third party run their own instances on a connected network. This could be done in a way that ensures consensus between each party (trust but verify) in a manner where the vendor is not a centralized trusted version of the truth as is common today. This distributed deployment model would also strengthen fault tolerances and form a crucial part of business continuity planning which customers have little control over today with their custody provider. These limitations exist since MPC wallets were built at an earlier time and factored in different customer information, SaaS products are highly opinionated which does not bode well in reshaping them for a new reality that puts more power into the hands of the customer. As these needs are becoming increasingly well known and sought after the market is looking for providers to step into the slipstream as the industry turns its next cycle of evolution.

All in all, institutions increasingly want to be the admins for these self custody products and to administer them within their security perimeter while also ensuring high levels of service availability and responsiveness. They need to evidence operational resilience, business continuity, and disaster recovery with clear answers as to how this happens. A blackbox SaaS product or “Trust us” is a non-starter. For these reasons, a shift is underway from vendor side management to customer side management when it comes to self custody technology. It started with the private key shares, and it will continue with the policy engine, servers, and more. Disintermediating the vendor is a good thing for the customer unless the provider needs to fully outsource this function, in which case the company may need a regulated custodian, as it not only allows you to better influence and resolve risk but could even offer up business improvements if the software license allows building on top for exact use cases or blockchain networks of interest. This approach is consistent with an industry-wide effort at maturing in 2024, and customers will increasingly demand this of their custody technology providers or switch to a provider who can facilitate these desirable improvements.

Sebastian Higgs is COO & Co-Founder of Cordial Systems, an all-in-one digital asset key management and policy solution for institutions. Sebastian has been successfully building digital asset custody businesses since 2018, with one acquisition by Genesis Trading. He has also advised and invested in startups through Outlier Ventures and is part of the Playfair Capital angel network. Prior to joining the digital asset industry he worked at Goldman Sachs.