How to secure digital assets with multi-party computation and Confidential Space

In a previous blog post, we introduced how multi-party computation (MPC) can help reduce risk from single points of compromise and can facilitate instant, policy-compliant digital asset transactions. One of the quickest and easiest ways companies can implement MPC solutions is with Google Cloud's Confidential Space. This solution offers the benefit of being able to hold the assets online for real-time transactions, and allows multiple parties to collaborate in the transaction in a privacy-preserving and policy-compliant manner.

Today, we describe a reference architecture for implementing MPC-compliant blockchain signing using Confidential Space. To illustrate the architecture, let’s imagine Company A, which wants to transfer digital assets to Company B. Since they are leveraging an MPC-compliant model, instead of individual private keys, they use distributed key shares where key shareholders collaborate to sign a transaction. This gives Company A the benefits of simplifying the user experience, and creating operational efficiencies, while retaining control over their private keys.

“Wells Fargo is always looking at new fintech opportunities and emerging trends to redefine future customer experiences,” said Vitaliy Dorum, senior vice-president of Advanced Technology for Wells Fargo’s Blockchain Platform. “As Web3 technology, for example, becomes more mainstream, Wells Fargo is exploring solutions that provide safe and secure access to a new generation of digital products. Working with the Google Cloud Digital Asset team allows Wells Fargo to experiment with Google Cloud services including Confidential Space paired with multi-party computation, which we believe is a fundamental building block for secure solutions in the Web3 environment.” Dorum said. 

To describe the critical components that make this possible, we will walk through the technical setup, and outline the approval and signing process that triggers the transfer of digital assets from Company A to Company B. 

The architecture is shown in Figure 1.

The architecture is distributed as follows:

• 1 MPC operator environment (right side of the diagram): This is the environment used to run the confidential workload that orchestrates the signing process to create a signed blockchain transaction. The workload can be operated by a custody infrastructure provider (or in our case by Company A directly). At no point does the operator have access to secret material in plain text (nor can the operator influence the signing process).

• N co-signer environments (left side of the diagram): Co-signers use these environments to collaborate during the approval and transaction signing steps. We show all co-signers running in Google Cloud but other environments are possible as well (for example: a mobile device, on-prem systems and other clouds).

The MPC operator environment is realized using the following components:

• Confidential Space - This is where the sensitive workload runs on a Confidential Space virtual machine (VM). Confidential Space has two core components:

• 1 - A hardened base image that runs the sensitive containerized workload with minimized risk surface in the Confidential Computing Trusted Execution Environment (TEE).

• 2 - An attestation service that certifies the operating environment, validates the integrity of the workload, and enables these assurances (claims) to be used in the MPC policy logic.

• Artifact Registry

• Secure storage for the sensitive workload image (that signs blockchain transactions) with built-in vulnerability analysis.

• Node hosting - This is used to host the Ethereum (or other) blockchain node. This can be done in GCP or by using Blockchain Node Engine

The co-signer environment can take multiple formats. In our reference architecture, we use:

• Cloud KMS/HSM to issue a partial signature.

• Cloud KMS and Cloud HSM are used to generate signatures using different algorithms (including ECDSA). All of this is done with a simple, unified API that does not require custom code nor HSM appliance management.

• For use cases where the signer doesn’t use signatures generated by the Cloud KMS or Cloud HSM services, these services would be used to wrap secret material generated elsewhere.

• Cloud IAM (Workload Identity Pool)

• A Workload Identity pool ensures attribute conditions (provided by the Confidential Space Attestation Service) are met before granting access to the identity authorized to access keys in Cloud KMS/HSM.

Now that we have described the architecture at a high level, we can walk through the steps required to execute the MPC signature, starting with the setup steps:

• We start with a workload image. This contains the MPC signing application and the associated policy logic required to trigger the transaction signing process.

• The application image is hosted in Google Artifact Registry (other remote registries could be used as long as a Confidential Space VM can connect to them).

• We then create keys in Cloud KMS/HSM, and build Cloud IAM policies to grant the workload access to those keys when authorized.

• Finally, we deploy the workload image onto a Confidential Space VM.

Now that we’ve completed the setup, it’s time to transact. The transaction steps are as follows (Figure 2, repeated for each signature request)

1. An unsigned transaction request comes into the MPC signing application.

2. The attestation service verifies the Confidential Space operating environment and the workload image integrity. Once satisfied, it generates claims (based on these verifications) used by the MPC signing application when accessing the keys created above.

3. Once the MPC signing application (the workload) receives the required number of approvals, it reaches out to the co-signer’s KMS and asks for their (partial) signatures to create the signed transaction.

4. Once all co-signatures are collected, the workload signs the blockchain transaction and submits it to a local blockchain node. 
   *Note: We over-simplified this step because we understand that each implementation is going to have its own mechanism here.

“Google Cloud's Confidential Computing allows us to seamlessly integrate AMD's SEV into our TEE runtime for multi-party computation (MPC) with minimal code changes,” said Jason Li, CEO of MPCVault. “This will further enhance the security of our solution, enabling us to protect institutional crypto assets with greater confidence at scale.”

Alternatives and complementary approaches exist – including using non-Google Cloud services for producing co-signatures, or having co-signers take turns to build the blockchain signature in their own environments (which is a more decentralized architecture). Our hope is that this post inspires different approaches to MPC on Google Cloud. 

If you want to go deeper into the components of Confidential Space, including ways we prevent threats against the TEE, please refer to our post describing the security control validation, check out our How-To document, and learn more about Google Cloud’s other Web3 products and solutions.