The Global Computer and Evolution of Key Management

For thousands of years in free societies, it’s been understood that our world is molded by the infrastructure we create. The resulting conversations have largely centered around the policy decisions and acts of authorities.

In 2013, this changed when Ed Snowden revealed that the internet was under covert global surveillance. In the time since, a focus on computing and privacy technologies has become a larger part of the societal infrastructure conversation.

The impact of computing, data, and privacy continues to grow, so it’s critical to look ahead to the next era – in particular, the emergent global computer, computing with user-owned data, and universal cryptographic adapters. 

From this lens, this article explores the recent past, present, and future of key management and it's role in the Global Computer. We’ll detail why threshold signing, programmable keys and defense in depth security are integral to advancing digital ownership and enabling further development of cyberspace.

Meet the Global Computer

The year 1976 was an important one in this story. In April, Steve Jobs and Steve Wozniak presented the first Apple I at the Homebrew Computer Club. A few months later, Whitfield Diffie and Martin Hellman introduced the concept of public-private key pairs in their paper, "New Directions in Cryptography".

Thirty nine years later, personal computing and cryptography collided in a novel way with Ethereum’s launch. Since then, the focus on applied cryptography has accelerated and expanded with a particular focus on cryptographically secure, decentralized, and leaderless systems designed to provide user sovereignty and control.

Across the wide variety of blockchains types, digital signatures are always used for authorization. This is what lets public blockchains be used by everyone, since anyone can create a key and then a signature. This open ability to write to blockchains establishes them as a foundational component in the Global Computer. Special-purpose co-processors are an example of another component. The missing ability is weaving systems together, a user controlled, smart, universal adapter.

For the open global computer, any universal adapter should have the ability to authenticate with any system, read sensitive data , process data confidentiality, authenticate with another system, and then write an output.

There’s more than one method to build a universal cryptographic adapter, each with various trade-offs in security, scalability, price, and feasibility. Tim Berners-Lee has proposed a universal adapter view where each person runs their own server. In the future, universal adaptors may be created with indistinguishability obfuscation software, as detailed by gubsheep.

Universal adaptors are programmable, like smart contracts. Adaptors can work in concert with databases and blockchains to provide a smart link between systems that doesn’t reveal data to anyone. For application and protocol developers, it’s the capacity to compute that makes universal adapters into a base layer for the next epoch of products. Global computer universal adapters are tools for builders to run private applications and generate proofs, which are verified by other systems.

Today, innovators are using Lit as a key management based universal adapter to build data marketplace infrastructure, chain abstracted liquidity protocols, smart wallets for Bitcoin, as well as private data systems for individuals and organizations.

As AI continues to develop, personal agents working across all user data from a variety of sources (e.g. social, blockchain, medical, traditional finance) can leverage universal adapters as a fundamental platform. This same platform also works for communities who can to create, own, and control collective intelligences.

To explore how it’s possible to provide a user controlled universal adapter today, we’ll need to dive into key management.

From Centralized Keys to Secure Networks

Personal key and server management has no shortage of pitfalls. It’s clear that most edge users opt in to the simplest solution available – centralized custodians. This reality opens up catastrophic landmines of its own. For example, the first major custodial exchange, Mt. Gox, was launched quickly after Bitcoin in 2010 and had lost 850,000 BTC for its customers by the time it collapsed in 2014.

Since Mt. Gox, the tension between personal key management and centralized custody has been persistent and challenging to solve, as both carried significant risks.

In 2018, an alternative to centralized key management for crypto assets finally emerged when Gennaro and Goldfeder proposed a practical MPC TSS method (Multiparty Computation Threshold Secret Sharing) to split a persistent key into multiple parts. This method can be used for both Bitcoin and Ethereum transactions, and showed promise. The industry recognized the potential;  regulated exchanges, wallet apps, and networks like Lit Protocol have since been implementing and innovating on this technological primitive.

While more secure than centralized keys, MPC TSS has one major drawback: collusion. Separate parties, each holding a threshold share of the key, can combine their shares to compose the entire root key. This can happen intentionally, or, as happened a few times (often with bridges), malicious 3rd parties can obtain enough shares to compose the key through various cyber attacks targeting the individual parties.

In a distributed system, there are a few ways to address this collusion risk. One is to ignore it, which should be concerning. Next, there’s economic security (aka staking) where the assets held are limited by the total stake amount. Another is to give the user a mandatory part of the key (aka joint custody). This limits universal adapter functionality, but is useful in some cases. Finally, MPC TSS can be used in combination with another privacy enhancing technology, like secure hardware.

Secure hardware creates isolated execution environments for sensitive operations, including virtual environments. In light of Snowden’s 2013 revelations, the demand on cloud providers (e.g. AWS) to provide privacy via secure hardware picked up. The cloud customers wanted to ensure that only they, the application owner, had access to the data. Not the cloud provider and by extension, various governments. With the implementation of secure hardware, like Intel’s SGX and AMD’s more performant SEV-SNP, cloud service providers moved the number of parties who could access customer data from two, the app owner and cloud provider, to one, just the app owner.

At Lit Protocol, we’ve pioneered the idea of ‘sealing’ secure hardware with network verification to blind node operators who manage threshold key shares. Network sealing moves the number of parties with access to the data in secure hardware from one to zero.

This context brings us to the current state of key management, represented here:

The combination of using MPC TSS with sealed, secure hardware deployed on bare metal has earned Lit Protocol the pole position in this chart. The design choices from the Lit Protocol team have been focused on providing the maximum amount of security, control, and flexibility to developers and end users.

At Lit, the use of a secondary technology to protect threshold keys is a clear and obvious requirement for MPC TSS networks. Services—like Near’s Chain Signatures— that manage user funds using threshold keys without the additional use of secure hardware or other privacy enhancing technologies should be considered with caution.

Secure hardware invites another important consideration, the decision of deploying in the cloud or on bare metal. With the cloud, the application owner has to decide to be either fully dependent on a third party (like AWS) or maintain the ability to access key material from a single security domain. This is why in the graphic above ‘security’ is marked ‘centralized’ for Turnkey and other systems that rely on configuring AWS and don’t use MPC TSS. This accounts for the low marks on fault tolerance. On regulatory status, the latest regulations from the USA and EU (FIT21, MiCA) use the terms ‘safeguarding’ and ‘control’ to define when a company should be licensed as a custodian to hold user keys and conduct KYC.

 At Lit, the decision to innovate directly on the servers in concert with MPC TSS, making nodes ‘authorized signers’, is born from an open and defensive perspective on maximizing users control of their secrets and data. To further understand this, let's unpack the term from earlier: sealing secure hardware. By design, confidential computers like AMD’s SEV-SNP protect the data that is being computed over from snooping by third parties. However, protecting the rules of computation are out of AMD’s design scope.

Consider that in f(x) = y the secure hardware protects x and y but not f. If an attacker can manage to deploy a malicious f' in place of the authentic f, they could tamper with and extract both x and y from the protected environment. Classically, this attack is prevented through strict access control and secrecy (e.g. corporate firewalls, security teams), which places trust in employees and processes. Lit Protocol innovates on this by “sealing the code” where each node provides a trust-minimized integrity guarantee about the operating system running from within their encrypted VM TEE.

For a node to join the network, they need to prove they are running the approved, audited, and attested to open source code by leveraging the hardware guarantees of AMD’s SEV-SNP. Prospective node operators also need to stake tokens to ensure their good stewardship of their threshold key share. This collateral also helps to ensure a graceful exit, should an operator ever want to leave.

With security, regulation, and fault tolerance addressed, let’s finally turn towards programmability, which evolves key management into a universal adapter.

Programmable Signing and Encryption

In addition to managing key shares, sealing secure hardware on bare metal also opens up the opportunity to support execution environments for running arbitrary immutable code (also known as “web3 programmability”). With Lit, these programs are called Lit Actions and they have some unique properties.

Most builders store their Lit Actions on blockchains and storage networks to inherit their immutability. With this functionality, Lit Protocol does for signing and encryption what smart contract blockchains do for tokens. Lit Actions extend across any state and can also be used to read and write from the Web, APIs, and run LLMs.

Since Lit v0’s launch in February of 2024, this functionality has largely been used to enable programmable encryption, fulfilling millions of requests a month to solving a fundamental issue around access control for user-owned data, universal data adaptors, and data marketplaces

With the recent launch of Lit v0.1, a number of ecosystem builders have really understood the power of Lit as a programmable universal adapter. Teams are using keys as orchestration wallets to create crypto asset experiences that go beyond chain abstraction, giving users an account first experience that makes all tokens cross-chain. Looking ahead to Lit v1 and the network’s token economy, the development team is continuing to focus on pushing the boundaries of performance and scale for distributed key management.

In addition to enhancing cross-chain interoperability, the ecosystem teams leveraging Lit Protocol and building from the global computer mindset are exploring private and autonomous AI for trading and data, automated governance, novel consumer data apps, and disruptive data marketplaces, like Fox's Verify.

As the global computer continues to boot up, we can expect to see a new generation of decentralized applications that offer unprecedented levels of security, flexibility, and user empowerment powered by secure key management.

If you’re ready to start building your life’s work and want to leverage the programmable keys running on Lit Protocol, the developer docs are here and you can say hi here.

Stay tuned to this blog post and social media accounts for more information on the upcoming V1 launch and token generation ⭕

Thanks to Chris Cassano, Adam Reif, Alessandro Voto, Derek Edwards, Eli Pearson, Ronan Broadhead, and Arad G for reviewing.