IBM and UC Berkeley paper shows how to enable the seamless deployment of multi-party cryptographic systemsSecurity

Existing application deployments typically suffer from a central point of attack: an application provider holding many users' private data is often the target of data breaches. With over 200 million Americans affected by a recent SSN breach, the urgency for secure systems is clear. As computing systems scale, so does the volume of sensitive data online, making it critical to build security infrastructure that can withstand even the most powerful adversaries. As a result, an increasing number of applications are using distributed trust across servers to prevent data breaches. Distributed trust protects users from a central point of attack by distributing sensitive data across several parties in different trust domains, each controlled by distinct entities.

While multi-party computation (MPC) relies on distributed trust, these deployments remain limited due to a core obstacle: establishing distinct trust domains. An application provider, a single trust domain, cannot directly deploy multiple trust domains.

As a result, application providers forge business relationships to enlist third parties as trust domains. There's recently been increased adoption of distributed trust by application providers who aim to protect their users' data, by companies including Signal, Coinbase, Fireblocks, Google, Apple, Meta, and J.P. Morgan. Signal's secure value recovery project aims to enable users to securely back up their private keys through distributed trust. Likewise, MPC wallets, including Coinbase and Fireblocks, secure billions of dollars by distributing their users' private keys and using MPC for signing.

The deployment dilemma

Despite this interest, the adoption of distributed-trust applications remains limited due to a core challenge: the difficulty of deploying distinct trust domains. Indeed, the application provider must find organizations in different trust domains, who are willing to run the provider's workload while restricting access to anyone - including the provider itself. These organizations must offer sufficient availability, security, fault tolerance, logging, swift recovery, and must have a credible reputation in the user community - criteria that have empirically been challenging to satisfy. Hence, business relationships like these are costly and require both time and manual effort to set up. While large organizations can forge such partnerships, this is a barrier to entry for application developers who lack the same resources.

To address this challenge, UC Berkeley and IBM Research have designed the Flock system. Flock provides an on-demand distributed trust architecture, which allows an application provider to deploy distributed trust automatically and immediately without controlling the other trust domains.

The primary insight of on-demand distributed trust is a paradigm shift in the deployment approach. Instead of the application provider deploying the parties to distinct clouds, each user drives the deployment for their own data. At a first glance, this approach appears infeasible when it comes to ease of use and cost because every user has a separate deployment. From a security standpoint, though, it is fitting. Take the following example: A user, let's call her Alice, is the trusted owner of her own sensitive data. She can deploy VMs across n − 1 major clouds, with the application provider as the n-th party. Alice can secret-share her sensitive data - for example, her private key for digital asset custody - across these VMs because no other party can control all of them, not even the application provider. The below figure compares the deployment workflow of traditional and on-demand distributed trust.

Flock: On-demand distributed trust architecture

A careful reader may be concerned about the cost of the on-demand approach. Continuously running one VM per user per cloud would be prohibitively expensive and shutting them off intermittently would introduce significant startup time.

We identify serverless computing as the most fitting paradigm for Flock. Its "pay-as-you-go" model means that we can invoke a serverless instance exclusively when the user runs an operation and incur no cost when the user is idle. For example, in the digital asset custody application, Alice's serverless instances only run when she wants to perform a transaction. Further, executing a serverless instance on-demand is fast, unlike typical VM boot times.

Flock offers a cross-cloud serverless system for secure computation, which runs sophisticated cryptographic libraries across clouds. A challenge is that serverless offerings cannot innately form peer-to-peer connections because they are publicly inaccessible and ephemeral. To enable end-to-end, secure cross-cloud serverless networking, we designed a relay that leverages the application provider to connect the serverless instances without trusting the provider with the contents of the communication.

Flock's automatic deployment mechanism empowers regular users to automatically set up cross-cloud accounts and serverless deployments without being exposed to underlying cloud-level intricacies. First, each user's Flock client automates multi-cloud account creation by filling in the corresponding forms for the user through a webpage automation framework. Then, the Flock client conducts programmatic deployment through cloud-provided APIs. The user experience of a Flock application is comparable a regular application. Users will not have to conduct manual cloud registration or serverless deployment per cloud, and the only difference is that users may need to complete several authentication steps for cloud registration (such as SMS or email verification).

To secure this deployment, Flock contributes a three-tier authentication protocol, which safeguards against the impersonation of our example user Alice, her deployments, and the application provider. Our new setting of user-driven distributed-trust deployment introduced new attack vectors, requiring a novel design for authentication. It led to the question: How can an application provider secure a deployment they do not control?

We first identified the required security "checkpoints" across three tiers - cloud, network, and application - leading us to design a unified protocol spanning these layers. At the cloud level, fine-grained access keys prevent unauthorized users from invoking Alice's serverless instances. At the network level, a secure deployment protocol guards the communication amongst Alice and her "flock." At the application level, Alice's "flock" must authenticate her before conducting operations on her sensitive data. However, it is onerous for each user to authenticate a number of times, once per party. To avoid this, we identify an existing work MPCAuth as particularly well-suited in this scenario. MPCAuth enables a user to perform the usual work of authenticating to a single "logical" server - which is an MPC of the servers - with the same security as authenticating to servers independently.

User-centered deployment introduces a new axis of challenges: Flock should allow the provider to manage billing without controlling users' cloud instances or exposing the provider to resource abuse. We leveraged cloud billing infrastructure to prevent malicious users from draining application provider funds, and cloud access keys to prevent an attacker from wasting serverless compute resources before they are detected by application-level authentication.

Flock has been deployed and evaluated in IBM Code Engine, Amazon Web services, Azure, and Google Cloud Platform. Compared to traditional distributed trust, it has 1.05 times the latency and 0.68-2.27 times the cloud cost. This value does not account for the traditional method's additional cost of business relationships with the third-party organizations (such as employee salaries, or operational costs) - expenses that do not exist in Flock. Moreover, Flock achieves this without the manual and time-consuming process of identifying and setting up other organizations as trust domains. By removing this deployment barrier, we believe that Flock can foster a new wave of adoption for distributed trust.

What's next

The next step is to see through Flock's adoption in real-world applications. We showed that Flock can support eight types of distributed-trust applications, including secret key recovery for end-to-end encrypted systems, password managers, digital asset custody other MPC wallets, certificate authority signing, code signing, two-server private information retrieval, and data rollback protection. These applications demonstrate different aspects of Flock's expressivity: they enable five major cryptographic modules, which showcase protection for data confidentiality, data integrity, data-sharing, or query privacy on a public database.