NOAH’s Multi-Party Computation

In the previous blog post in this series, we looked at the Ephemeral Key Cryptography NOAH uses to implement our Non-Custodial wallet. In this blog, we look at how NOAH utilizes another cryptographic technology, namely Multi-Party Computation (MPC), to split a single private key into multiple key shards, which are then shared between separate entities for on-chain transaction signing operations.

The use of MPC significantly improves NOAH security and operations, namely through unshared shards independently and geographically dispersed among different people or devices. Sharing only the zero-knowledge proofs of private key shards ensures there is no risk of leaking cryptographic material (the private key shard itself) and, thus, additional security when signing on-chain transactions.

While MPC algorithms have been around since the 80s, the advent of Bitcoin renewed interest in this field of cryptography. In a general sense, MPC enables multiple parties — each holding their private data — to evaluate a computation without ever revealing any personal data.

The two fundamental properties that an MPC protocol must ensure are:

• Privacy: The private information (in NOAH's case, the private key shard) held by the parties cannot be inferred from the execution of the protocol.

• Accuracy: If several parties within the group decide to share information or deviate from the instructions during the protocol execution, the MPC will not allow them to force the honest parties to output an incorrect result or leak an honest party's secret information.

With MPC, private keys (as well as other sensitive information, such as authentication credentials) no longer need to be stored in one location. The risk involved with keeping private keys in one single place is referred to as a "single point of compromise." With MPC, the private key is broken into shards, encrypted, and shared among multiple parties.

These parties will independently compute their part of the private key share they hold to produce a signature — without revealing the encryption to the other parties. The private key is never in one place; it exists only in "liquid" form, as encrypted data.

Ordinarily, when a single private key is stored in one place, a wallet's owner would need to trust that a single device or party that holds that private key is entirely secure. MPC does away with this problem, as any party no longer holds the private key at any time. Instead, it is decentralized and held across multiple parties (i.e., devices), each blind to the other. To gain control over a user's wallet, a hacker now needs to attack multiple parties simultaneously.

Because the key no longer resides in one single place, the entire private key is completely secure.

In choosing an MPC implementation, the governance layer — how the ownership rights over assets are honored, managed, and maintained is a critical factor. The governance layer orchestrates MPC among the participants when an asset transfer is requested on-chain.

This governance layer will generally be a database for custodial wallet service providers that acts as a ledger. As a result, such organizations will typically need to regulate and implement a wide range of security controls to ensure a hacker or malicious insider cannot simply compromise the vulnerable database or perform other operations without permission.

Non-custodial wallet implementations ultimately need a validation/reconciliation method between the parties involved in signing transactions. The validation/reconciliation implementations can vary considerably. For example, some may use blockchains (distributed ledgers) to validate transactions using native consensus to add immutable transaction data to the ledger, while others may rely on more traditional forms of reconciliation.

At NOAH, in our current beta, we split the private key into multiple different MPC shards. At least one of these shards is held by NOAH, and the digital asset service provider holds at least one other shard. This sets the stage for us in a subsequent roll-out to add additional shards, making our implementation more robust, not only by having more resilient MPC infrastructure but also by adding new entities to the MPC signing process.

For instance, in the future, we plan to let our customers choose to install a key shard directly onto their devices. This option gives customers the ability directly manage their assets themselves in the event of a disaster as an alternative to NOAH disaster recovery service (more about that in our final blog). It is effectively a self-custodial option for our customers.

As we have discussed in previous blogs about NOAH's MPC implementation, three participants are involved with signing on-chain asset transfers. These are:

• NOAH
• Digital Asset Service Provider
• Customer (Not in beta, but customer instructions are still cryptographically verified)

To learn about the roles of these entities, please refer to the first blog post in this series. Suffice it to say that each entity operates one or more cosigners, and all three are involved in validating asset transfer requests. It is essential to understand that in NOAH's current implementation of MPC, customers' devices do not store a private key shard.

While the burden of key management may be less than holding a complete private key, it will still require the customer to make contingencies if their device is lost, stolen, or compromised.

At NOAH, we decided that customers should be able to make an informed decision between these options.

As described above, in our current beta wallet, no cryptographic material is stored on end-user devices. Instead, we store the private key shards under the following principles:

Secure Geographic Distribution

Cosigners, software, and hardware that store private key shards must be geographically distributed in secure cloud environments. Typically each party involved with MPC will have multiple cosigners in their isolated cloud infrastructure distributed in different availability zones. Such an architecture ensures that if any single cosigner suffers service disruption, MPC can continue to validate and sign on-chain transfers.

All security aspects must be considered, not simply the storage of cryptographic material in specialized hardware but the physical security of the data centers housing the hardware. Surveillance equipment, monitoring, alerting, and security controls must be to the same standard or higher than those found in traditional financial institutions.

Operational Integrity

There are limited benefits in implementing MPC technology if a single entity controls all the key shards. As we have explained previously, having no single point of failure by splitting the key between multiple entities means that you strike the right balance remaining in control of your assets and retaining the ability to recover in case of loss. One of the biggest challenges remains the loss of keys. Arguably 20% of all crypto is lost and not recoverable.

Encryption and Information Leakage

The generation and storage of the private key shards must be achieved using strong cryptographic techniques with specialized hardware. Furthermore, private key shards should never leave their secure hardware; instead, zero-knowledge proofs are utilized to sign on-chain transactions.

In this blog, we have explained the rationale for choosing server-side MPC and how multiple entities will ultimately be involved in signing on-chain transactions that have been authorized by you, the asset owner. In addition, we explained why we initially chose server-side MPC over client-side MPC to reduce the security surface and burden on customers, but that we will offer the client-side MPC for those customers that want it.

Finally, we discussed the organizational and operational security controls we have implemented to prevent bad actors from compromising our wallet and digital asset management platform.

In the final blog of this series, we will describe in detail how disaster recovery has been implemented at NOAH and how we will disburse assets into self-custody in the event of service discontinuation caused by natural or man-made disasters.

About the author: Hussein Badakhchani is a Distinguished Technologist and CTO of Noah. Hussein has 30 years of professional experience in financial services technology. Having worked for institutions such as the Bankers Automated Clearing System (BACS), Deutsche Bank, VocaLink - MasterCard, YouTrip, Wave Money, and Ziglu; Hussein has a proven track record of delivering innovative banking and financial services platforms in some of the most competitive markets in the world.