Decentralizing Programmable Keys For Signing and Encryption by David Sneider

and signing. And so just for some light participation, does anybody know who this is? Yes. Some indications. So from the perspective of how we're thinking about keys, this is a centralized trusted custodian.

And spoiler alert, if you've ever seen this movie, the custodian gets compromised and Neo gets into the Matrix. Um, and so from the perspective of the machines, it was a centralized custodian that was uh what was able to have the system be corrupted and compromised. And so that's just a kind of a like a fun metaphor to start thinking about keys. And we over here at LIT have a pretty interesting question that we ask oursel all the time, which is where are keys stored? This is a really fundamental question about secret management.

And as you're like looking at uh things in this space, this is a really key question. And so another way to think about this question in the context of doing this in a distributed way as a network and this is our take is to say can the internet keep a secret and so what I'm going to talk to you about in the next several minutes is us saying yes we believe that is possible take you through the architecture of how that works and then talk about some of the use cases that are enabled when the internet can in fact keep a secret through a distributed key management network. So, let's talk about what LIT is. As you can see, a decentralized key management network for conditional encryption and digital signatures. And so, there's a couple components that make it up, as you can see with these initialisms on the page.

And we'll go through each of those. The first one is a DKG. That is a distributed key generation. So 30 nodes coming together and creating a new shared key where none of those individual nodes have the whole secret. But as a result of performing the DKG, each of the nodes has a key share.

And with that key share, they can authorize some action like an encryption, like a digital signature. And it's only when a threshold of those uh nodes have signed off on that and this is sometimes referred to as threshold cryptography or TSS threshold secret schemes can that underlying distributed key be used. So it's an X ofn scheme. So that's really great. Now we have distributed keys.

Okay. But if we want to make a network that's going to persist for a hundred years, a thousand years, 10,000 years, and that's what we're really trying to do here is build the long-term public infrastructure for the new self-s sovereign web as nodes join and leave the network over time, how do you maintain the underlying secret? And so the other primitive that's used here is something called proactive secret sharing, PSS. And so proactive secret sharing is a method quite similar to the DKG um but instead of generating a new key it's generating new shares. So in epoch one you may have 30 nodes with the 20 of 30 signers five nodes leave five node new nodes join this um this method of proactive secret sharing is performed and in that second epoch they have different shares that are incompatible with the first epoch and so it's a method for persisting the same underlying secret um without the same operators over time and then so this brings up the question but what about those old shares what happens there.

Um, can't those nodes just take those and recombine the key to collude and then the network is broken? And so the way to prevent that attack is something called secure encrypted virtualization. For the purpose of this network today, we've started with initially with AMD, SEV, SNP and all of the nodes operations are functionally taking place in a black box where that node operator is cryptographically attesting to the code that is being run in there. So that's that's what we're up to. That's kind of the systems design and then we'll take a few moments to talk uh through some use cases.

And so in the context of public key cryptography in general, even outside of what we're doing around distributed key management, functionally an asymmetric key pair, a public private key pair has two features, signing and encryption. So when you use MetaMask, you're signing a transaction. When you text your friends on signal, you are encrypting that message to them. And these are the two fundamental features in the context of public key cryptography. And naturally as a key management network, these are the two fundamental features of of lit.

And so we'll start with the decryption side. And so there's a process. Let's just say Alice is a creator and Alice wants to encrypt some data and say only people who hold my creator NFT can decrypt this. The process here is for Alice to encrypt that data client side and generate a symmetric key. That key is in turn encrypted to lit this distributed key and associated with a set of rules.

For example, you must hold my creator NFT. When Bob shows up later on, Bob sends a message to all of the nodes and says, "Hey, I own Alice's NFT. I'm signing from my wallet to prove that." The nodes validate that against the blockchain. And then this is where it gets really cool and this is what makes it distributed.

Each of those underlying nodes, they create something called a decryption share. You could think about as an authorization. And each of these nodes is doing this independently. And in a 30 node network for example with a 2/3 threshold um Bob needs to collect 20 of these decryption shares or authorizations in order to in turn decrypt the symmetric key that uh Alice created client side and then grab that encrypted blob of whatever it is the content and decrypt that. And so what's really cool about this is it's not an exact definitional match but this is basically what they call identity based encryption.

And as you can see definitionally, at least according to Wikipedia, identity based encryption does in fact require a central authority today. But with the lit method, what we just walked through with this conditional decryption, there is no central authority thanks to the fact that it isn't just one party that is saying Bob can now decrypt this, but a threshold twothirds of the network that is signing off on that inside of that SEV blackbox that we discussed earlier. And so with that, let's talk about some use cases for this conditional decryption product. For those of you who are familiar with Lens Protocol, Lens Protocol is a system that lets you, it's essentially a social graph on chain where interactions, social interactions are functionally NFTs. So if you follow somebody, hold their NFT.

If you like or collect their post, there's an NFT associated with that. And so Lens Protocol has integrated lit for the purpose of doing token gated content. So Alice can say you must follow me on Lens in order to decrypt this content content to have a patreon like model. Um we're also seeing some really cool stuff working with live pier doing this around video as well. Another use case for this is token gated chat.

Uh this is a group called orbit.club that has in integrated the lit SDK for the purpose of uh doing token gated chat. And the cool thing is here, you know, if you think about the way that signal works in the context of encrypted chat, every time somebody joins and leaves, you need to do new handshakes. But with this key provisioning method, that isn't required. And so the data, the underlying data for the chat can be stored on the open web in the context of Orbit, uh, it's stored on ceramic and and encrypted with lip.

And then we'll see if these videos will play. Hopefully, we have good luck with the internet. So this is a really cool example. Uh this is from a group called Krebbit. And what you're going to see unfold in this video is somebody doing a KYC process.

A third party is validating that KYC and then that proof of that KYC is being encrypted client side and in this case again being stored um I believe to ceramic. Uh there's other teams that are exploring this with Arweave. And then with this conditional decryption process that we talked about this user can then say who can decrypt that data, who can see the KYC data. And what we really start to get to here and why this is kind of labeled in the context of user own data. The same kind of flow that you may be used to in the context of Google when you go login with Google and you see the consent screen that says hey this app wants access to your contacts and calendar.

This is functionally that same process but as a user to application firstparty relationship and not using Google as the intermediary of this personal data. And then one other use case to look at on encryption and then we'll talk a little bit about signing. This is also applicable to data marketplaces. Uh we've been working really closely with the streamer team. That's their logo.

So somebody generates some data. They may go offline but they want to be able to sell that data passively. So an NFT is purchased the key is provisioned. The purchaser of that data um can then access it there. So now we're going to talk oh excuse me.

Yes. And um there's one feature uh and this will make more sense when I talk more about lit actions but basically for the past year we've had to do the conditions based on onchain data and then very recently we've released the ability to kind of call any data across the web any HTTP request that can return true or false and perform decryption. So if you want to say somebody must follow me on Twitter to decrypt this data that is stored on IPFS in an as an encrypted blob that's now possible. This is uh this is a brand new feature essentially conditional encryption for for off-chain data and this is currently live. Now let's talk a little bit about signing.

Um so the name of the product that we have is a programmable key pair a PKP as we call them. And so as you can see it's the same kind of underlying pattern but it looks a little bit different. And so in this case in order to program signing essentially like if you think about a web two analogy this is functionally like a lambda function combined with a KMS a key management store but that's distributed and fault tolerant. And so the way that it works is an application developer can write a program and we'll look through a couple examples here in a second that says when these conditions are true, I want this distributed custody wallet to sign on behalf of the user or sign for some specific use case. And um so the the code itself is is the application logic is encoded in JavaScript.

We have a JavaScript runtime on the nodes. That JavaScript lives at an immutable CID on IPFS. Let's just say for the sake of example, it's like um a DeFi product, a structured financial product for dollar cost averaging. And you want to say, I'm going to send USDC to this and every week between buy between5 and $500 of ETH depending on the sentiment from Twitter as the application that you would build with this. That would all be encoded in the JavaScript.

And on that weekly basis, as the nodes are triggered, they pull down that sentiment data from Twitter, whatever API it's hooked up to. And the result of that is each of these nodes represented by these hexagons here again creates one of these authorization shares. But in this case it's an authorization to sign not to decrypt as we talked about earlier. And once those signing shares are combined the output of that is some signed data such as a signed transaction which can then make it way make its way to um your state machine of of choice. And so we'll talk about a couple use cases now.

Um so what we're seeing here is using this method for user onboarding. This has been quite popular. Uh the current supported off methods are ooth as you can see here. Um web ain which is Apple pass keys part of the pho alliance fast ID online between Microsoft Apple and Google around getting rid of passwords online. That's already hooked up.

The next step for us is to get um email and SMS off into the nodes and and that's underway there. And functionally this is a method to onboard users into web 3 without them having to hold on to a seed phrase which for some is a massive privilege but for many other it's a burden and so it's not against self- custody by any means um but for the set of people that don't want to do that perhaps they don't speak English and they have to save these 12 foreign words um this is a method for somebody to essentially have one self-s sovereign like user credential driven login for the entire internet that meets web to UX parody as we can start to kind of bring in the next 10 100 million and then 1 billion users into into web 3. Another thing that you can use these for, as I mentioned earlier, is D5 automation. So what we're seeing in this example is a swap. This PKP, this programmable key pair has been encoded to functionally act like an immutable escrow agent.

So this these two screens represent two different counterparties. Party A sends money from Optimism to this PKP. Party B sends money from Polygon. Once they both sent them in and approved, the the swap is is automated based on that JavaScript logic that was associated with the PKP. And this kind of use case is really cool because it's a wallet as utility.

The wallet doesn't represent a user in this case, but it is serving a function. Um, thinking about again like you can think about it as like a a serverless function that's immutable and and can sign and it's just kind of sending them in approving so on and so forth. And then just in the interest of time, we'll also talk about this in the context again of user own data. So what we're looking at here is a method where a user is connecting their Discord and then that Discord is being logged into this user's data backpack as an encrypted verifiable credential. But verifiable credentials is functionally just like signed JSON LD linked data.

And so it's like who signs this? Is Discord going to sign this? No, they're not. They don't have keys. They're like a web two company.

Should the user sign it? Well, how do you trust the user's key? This is really interesting in the context of verifiable credentials because what we're looking at here is a method for having the network 20 of these 30 nodes sign to say yes, this is this user's Discord name. And then that is encrypted and stored on ceramic or arweave or IPFS or whatever the storage network of choice is there. And so it's basically like automated verifiable credential issuance or like an issuance bot maybe you could think about it in that way.

And then um I'll close with this final question of where are the keys stored coming back to this fundamental question. And so the state of the project right now is the developer preview is live for all of the products that we've just looked at. Uh we have a grants program and that's been really exciting as well and we are in the midst of rolling out this uh initial mainet things are in test net right now and if this type of stuff is appealing to you and you operate nodes uh please do reach out you can find the contact form on on our website and if you want to operate a node as one of kind of the founding node operators in this network now would be a really excellent time to get in touch and with that I will close it out and we have uh two minutes for questions if anybody has any. Thank you so much for your time. [Applause] Any questions?

Yes. For the actions uh that use a web 2 API, is it possible for the lit nodes to like man in the middle of that request or can they all verify that it's signed by the same SSL certificate? Yeah, they are signing and then that is also they're also the communication between that API is happening inside of SEV as well. Um but uh the interesting thing here is there's a little bit of an Oracle problem. So if you have like 30 nodes all contacting a different API, how do you kind of unify that data?

And there's been some like the security sides sound but then like from a practical side there's some interesting implementations there. Chris, do you have anything to add on that? Okay, that's Chris. He's my co-founder. Um, any other questions right there?

Hey, uh, how do you solve the problem of nothing at stake for the, uh, participants that were participating in the old epochs? For example, if there is like a million dollar worth of data stored like a year ago, but uh the keys didn't really change for that wa of the NFT or something like that, how do you make sure that the old validators on the network that may still have the shares of the keys like will not use them to unlock the vault? Excellent. So the question was as the node switches from one epoch to the next, what keeps the old epoch from stealing the key? Is that right?

And that's why we're using AMD SEV S&P. So none of the node operators, it's secure encrypted virtualization. It's a direct integration with the processor. The node operator is functionally running a black box. It's a TE.

It's trusted execution environment. And so the node operator, even when they leave the network, even while they're operating the network, they never get access to any of the private key material. Huh? How they didn't get the key or the key share? They'd have to break SEV to get the key share.

They they never have access to it. They delete the key. Oh, how do they delete the key? Oh, yeah. Proactive secret sharing.

Like you mean in terms of like like do they just like keep it in the cache? They have to pay to store it if they want to store it in perpetuity. Yeah, we can connect afterwards. I want to make sure I understand your question. All right.

Well, uh, looks like I'm out of time. Thanks so much. Uh, some of our team is around here. Um, we have glowy cubes. If you see those around, please come talk to us.

And thanks again.