Kobi Gurkan 2:02 It's fine. Speaker B 3:17 Folks, we're about to get started here. Kobi Gurkan 3:21 Pass it on to me. 3:22 Thank you very much. 3:25 So, hi, I'm Kobi. 3:27 I work in Bain Capital Crypto. 3:30 And today I want to talk about what I titled as Account Logic in Edge Proto Using Trusted Execution Environments. 3:39 So it's a bunch of things, so let's break them down. Speaker C 3:44 A short disclaimer before I start. Kobi Gurkan 3:47 Bain Capital Crypto is an investor in Turnkey, and BlueSky, both of which I'll mention in the talk. 3:55 So yeah, let's go to the actual stuff. 3:58 So first of all, before we kind of get into what this does, I want to give an overview of how accounts look like in Ad Proto. 4:08 And specifically, I'm a cryptographer, or I guess applied cryptographer, and I want to talk about those aspects of account. 4:17 So accounts in Ad Proto, they have users and users are kind of called decentralized identifiers. Speaker C 4:27 And each decentralized identifier basically has cryptographic keys attached to it. Kobi Gurkan 4:34 And these cryptographic keys control what is authorized by each user to be posted or done in their name. 4:47 There are different kinds of deeds, and we will talk about a couple of them later and what guarantees each of them gives you. 4:55 But what you have to know is just this fact. 4:58 Each user has this decentralized identifier attached to them, and each of them has what's called a Ripple signing key. 5:08 This triple signing key basically authenticates every operation that your dids make. 5:15 So that means posting. 5:17 That means doing likes. 5:19 That means doing everything else that other apps do on your account. 5:25 So it could be anything. 5:28 What is the guarantee that you get? 5:30 This is a signing key. Speaker C 5:31 This is a digital signature. Kobi Gurkan 5:33 So the guarantee that you get is this DID agreed for this record to be published or for this operation to be performed. 5:44 But that's kind of what you get, which is already very powerful. 5:48 You already get end-to-end verifiability. 5:51 So a DID that is published on— that is used in the network has these keys. 5:58 So whenever you want to verify A post is valid. 6:03 You can go to the post. Speaker C 6:04 You can see which DID posted it. Kobi Gurkan 6:06 You can then take what's called the DID document, which then lists what cryptographic keys it has. 6:13 You can get those keys. 6:15 You can verify the signature on something. 6:18 Let's call it verify the signature on the record. 6:21 And pretty much done. 6:22 So this is a very nice property of head proto in general. 6:29 But what if you wanted a bit more from this guarantee? 6:33 So not only this DID authorized is supposed to be published, what if you want more? 6:40 So what if you want to have some logic attached to each operation that is performed in your name? 6:48 An example, like a few examples would be, let's say that each post that is published in your account, you want it to be verified by some LLM that runs some analysis and check that it's like a non-toxic post. 7:04 It runs an LLM that runs on your computer. 7:07 What if we want to get a guarantee that the images that you're posting or that someone else is posting are coming from a trusted source? 7:17 So for example, you have cameras today that have digital signatures on them. 7:21 So you can verify that these are images that have not been tampered with, for example. 7:27 What about a kind of multi-signature account, so an organizational account? 7:32 Each post has to be authorized by 2 out of 3 people so that, you know, if you want some more trust in those posts, you can add that kind of logic. 7:48 Or maybe you want some verified bot accounts. 7:51 So that, for example, could be a bot account that runs with a given system prompt because we don't want just any random bots posting everything. 8:02 Maybe we want to limit them to some things that are more positive. Speaker C 8:08 So generally, what if we attach logic to record authorization? Kobi Gurkan 8:13 If we're talking about signatures, then the limits are that— what I've mentioned, which is you just can say that the DID agreed for something to be published. Speaker C 8:28 But with logic, you can say the DID ran this program before publishing. Kobi Gurkan 8:34 And this is a stronger guarantee that you can get. 8:40 You can do that with signatures if you trust the signer. 8:45 So if you trust the people who run the DID to run this program for you or run this program by themselves, then you can get this guarantee. 8:58 But in a big network with lots of people, sometimes in adversarial scenarios, You want some third-party guarantee that this program ran. 9:08 And this acts as a filter to the operation you perform. 9:13 So now let's talk about what trusted execution environments are. 9:17 It's a bit of a mouthful, at least for me. 9:22 Trusted execution environments, or TEs, are a special kind of hardware that are built in a way that allows you to get a guarantee of what's running inside it. 9:34 Specifically, these machines or these machines with special security chips allow you to measure or get some measurements of what's running inside it. 9:47 So you can get the guarantee of what code is running inside them. 9:51 You can do that really all the way down. 9:54 You can do that to the base OS that's running inside the T. 9:59 You can say what binary is running there. 10:04 And even more, you can even get a more powerful guarantee, which is even what source code is running there in the way that, let's say that you have some source code published on GitHub, Tangle, whatever. 10:18 You can build it in a special way that is called a reproducible build that gets you the same binary each time. 10:26 You can then check that this binary is what's running in the TEE. 10:32 One downside of TEE is that it adds some trust assumption on the TEE provider, or the TEE manufacturer, more correctly. 10:42 Concretely, you need to trust that the TEE manufacturer built the trusted platform in a way that is robust. Speaker C 10:52 That does give you this guarantee that these measurements are correct. Kobi Gurkan 10:55 That's unavoidable, but that's the first assumption that you would have to make. 11:01 Okay, so what we want to talk about is how these two areas connect, how Edproto that has keys connect to TEEs. 11:13 So there is this concept called key encumbrance, and key encumbrance means a public-private key pair for, let's say, digital signatures where the private key is never known to the public. 11:28 It is only generated inside this TEE, and the TEE does not provide a way for you to extract it outside. 11:40 What we can do now, we can think about, okay, we have a TEE that runs a specific program. 11:46 And we have a key that's only locked— that's locked inside it and will never be put outside. 11:54 What if we add specific conditions under which signatures can be done? 12:01 So basically what we can do is we can tie a key to a specific program. 12:07 And the really nice property that you get with this kind of setup is that you can convert logic to digital signatures. 12:16 And what I mean here is the following. Speaker C 12:19 Let's say that you have the guarantee that, okay, there is a TEE provider that you trust. Kobi Gurkan 12:26 You then have a key that is generated inside this TEE. 12:32 Then you have the program that you know what are the conditions it would sign under. Speaker C 12:37 That uses that specific key. Kobi Gurkan 12:41 And you get this kind of chain of verifiability where you only need to verify this attestation or this proof that this key came from a valid TEE once. 12:59 And once you do that, you can just verify signatures. 13:02 You don't have to do anything else anymore. 13:07 So this is the kind of minimal overhead that you can have while still getting a very powerful guarantee. Speaker C 13:19 So this is this verifiability all the way down. Kobi Gurkan 13:23 You usually have from this T manufacturer a root certificate. Speaker C 13:29 That certifies this is the correct hardware, this is valid hardware that is secure. Kobi Gurkan 13:35 You then have proof of what program is running. 13:38 So you know this is the expected logic that runs there. 13:42 And then you know that whenever the TEE produces signatures, the logic agrees with whatever you wanted to run there. 13:54 Now, maybe you can think about, OK, but that means I now have to start verifying these weird TE proofs all the time. 14:04 No, because you can maybe assume that some people verify them. 14:09 As long as enough people in the world go ahead and verify TE proofs about these keys, other people, relays, other actors in the network can just verify signatures. 14:23 Okay. 14:25 Now let's talk about a specific concrete application where here we want to talk about this example of 2 out of 3 people need to authorize each record that is posted on your account. 14:47 One way to do it would be to say, OK, when we launch the TE, one of the arguments of the program would be a set of 3 keys. 14:57 And these 3 keys have to have a quorum of 2 of them signing each time. 15:03 That's one way. 15:05 Another way would be to use the natural elements that we already have in etproto, and specifically deeds. 15:12 So, like Matt showed in his talk, there are multiple kinds of DIDs. 15:18 There is DID web, there is DID PLC. Speaker C 15:21 DID web basically trusts— Kobi Gurkan 15:24 had some trust with the DNS provider and you just go to some specific URL under your domain name and you get the DID document and it has a field which describes the keys. 15:40 Okay, so that's what you can get from DID web. 15:43 And DID PLC has a bit of more, more of a complex structure. 15:50 And concretely, DID PLC is what's used by the main BlueSky network. 15:56 And it works in a way that when an account is created, it's created with some genesis state. 16:05 And then whenever you want to make updates to the state, you have to sign them cryptographically as well. 16:11 And you submit them to PLC. 16:13 And then you create some sort of chain. Speaker C 16:17 Each update in PLC, of course, references the previous state of your DID. Kobi Gurkan 16:31 And we are done. 16:37 Is that me? 16:43 OK. Speaker C 16:46 Oh, it's back. Kobi Gurkan 16:47 It's back? Speaker C 16:47 It's back. Kobi Gurkan 16:48 OK, solved magically. 16:53 So that's what's called in PLC the audit log. 16:55 And it looks something like this. 16:57 You have the genesis state, which has this field called prev to be null because there is no previous state. 17:06 But every time you make an update, you have a reference to the previous state. 17:13 So if you want to know the current state of a DID, you ask to see the audit log And you can verify this audit log up until the current state. 17:30 OK. 17:32 Now you might already guess where I'm going with this. 17:36 And I will say that a lot of these ideas are not new. 17:40 I'm just trying to show how potentially we can apply them in NetProto. 17:44 And even we've seen uses of TEAs in things like privacy-preserving analytics. 17:52 We've seen them in delegating access to online accounts. 17:56 So this is a combination of these ideas here. 18:02 So now you might ask yourself, what key should I encumber? 18:07 One maybe obvious choice would be this Edproto key, or what I call the repo signing key. 18:14 And this head product key controls every operation that you make in your account. 18:19 But that's also its downside. 18:20 And again, I reference Matt's talk because we've seen every time that he made an operation and every time something happened, you need to add a record to your PDS. Speaker C 18:32 So that's a good choice if you want everything to be really, really protected, but it also also adds this, this friction. Kobi Gurkan 18:46 So what we did here is we instead worked with what's called a proof attestation key or like this hashtag sign key that only signs attestations on records that are posts. 19:02 It does introduce the requirement for extra verification infrastructure. Speaker C 19:07 But that verification infrastructure is still only verification of signatures. Kobi Gurkan 19:12 And concretely, we created a proof of concept, and this proof of concept draws on proof and attestation work that Nick Jarakines worked on. 19:25 And this specific work also includes contributions from Nick Jarakines, Andrea Novakovich from my team, and also the Turnkey team. Speaker C 19:39 So concretely what we did here is we created a new app, like a BSET app. Kobi Gurkan 19:44 You can imagine just as any other app that you could be logging into. 19:50 And an author in this app would be creating a post draft. Speaker C 19:56 So, okay. 19:57 There is a post draft. Kobi Gurkan 19:59 Now signers would start adding signatures to this post draft. 20:04 They would say, OK, we are agreeing to sign this post if it is also signed by one of the keys that we know are locked in a TEE. Speaker C 20:15 OK. Kobi Gurkan 20:16 So the signer 1 would do that. 20:19 Signer 2 would do that. 20:21 Signer 3 is offline, but it's fine. Speaker C 20:23 We have 2 out of 3. Kobi Gurkan 20:26 Once we have that, that's where the interesting part gets in. 20:32 We send this collection of signatures with a post-draft to the TEE. Speaker C 20:39 The TEE also gets this audit log from PLC and runs the following logic. 20:49 Is the audit log correct? 20:52 What is the list of 3 keys that the audit log results with? Kobi Gurkan 20:58 And do I have at least 2 signatures that come from these keys? 21:04 If so, only and only then, it signs with its own incumbent key, sends it to the app, and the app publishes it to your PDS. 21:18 And concretely, we even have here— Speaker C 21:20 I'll show you. Kobi Gurkan 21:25 So this is the guarantees that I mentioned. 21:30 And this is a concrete post that was actually signed by a real TE and posted on Bluesky from the author3.tepds.com. 21:44 And what you can see here is that it has a few nice things. Speaker C 21:50 This is the proof of the station work that Nick Jarrickens had. Kobi Gurkan 21:54 It has this signatures field. 21:58 And the interesting part is this one. Speaker C 22:01 These are part of the proof draft— of the post draft. Kobi Gurkan 22:05 But this is where we have a signature that came from an actually encumber TE. 22:12 So whenever someone reads the record that is attached to this post, they can go and verify the signature of this and then they can go and verify that these list of keys here have a TE at the, oh sorry, a root certificate at the station attached to them. 22:35 And therefore, you can get end-to-end verifiability still preserved. 22:40 That's it. 22:46 So yeah, that's the main thing I wanted to talk about. 22:49 Maybe I'll touch on two related concepts. 22:54 One is this concept of reproducible build. 22:57 Because this is something that we're not always thinking about when developing software usually. 23:04 So when we're creating Node.js code, C code, Rust code, whatever, whenever we compile it, we sometimes get a different binary for many reasons. 23:13 Sometimes versions change of our dependencies. 23:16 Sometimes just our compilers add timestamps, which is reasonable, but it changes the binary that we get eventually. Speaker C 23:25 And that is a bit— Kobi Gurkan 23:26 disastrous when you want to get the guarantee that a specific program is running in a TE. Speaker C 23:34 But luckily, a lot of people have thought about that, and it's something that people have worked on for decades, and there is good infrastructure to do that. Kobi Gurkan 23:42 So you can take code in C, you can take code in Rust, or whatever is still reasonable to do it in, and build it, and you can get something that translates source code to binary in a way that you always get the same hash. 23:59 So that means that we don't add trust on whoever deploys the program to the TEE. 24:06 Anyone could go and fetch the source code and rebuild it themselves, which is nice. 24:11 Like, this preserves the decentralized nature of what we're trying to get. 24:18 Yeah, and this is, a whole verifiability chain that I mentioned. Speaker C 24:24 I'll just look at it briefly. 24:26 So we have a published post. Kobi Gurkan 24:29 We have signatures on this post. 24:34 We have a DID that lives on PLC and has TE keys that it allows to sign. 24:46 And we also have attestation that these keys came from the right manufacturer and are actually secure keys, and the verification that this happens, that this whole chain happened correctly. 25:02 So now, because I know I'm still a cryptographer, like I want to kind of give alternatives that maybe some of you would want to utilize instead. 25:15 And two alternatives that might get you to similar concepts would be something called multi-party computation, which is a concept that allows you to split a cryptographic key in a way that whenever it's used, it still seems like a single person's signature, like we know to verify. 25:38 but instead you split it to, let's say, 2 out of 3 people so that they have to run a very complex cryptographic protocol and then produce this signature that looks like any other signature. 25:53 You could do that, but now you don't have the guarantee that some specific program is running. 26:01 You have to trust that an honest majority of people in this committee of signers are running the correct program. 26:09 Reasonable, but that's the trade-off. 26:12 And there is also another complex concept of zero-knowledge proofs, which is, again, allows you to take a program, convert it to some different kind of math, and then get a guarantee that specific logic ran on specific inputs. 26:32 That's nice, but what it produces is not signatures. Speaker C 26:35 What it produces is proofs. Kobi Gurkan 26:38 And these proofs can sometimes be large. 26:41 These proofs can also be slower to verify sometimes. Speaker C 26:48 So also powerful, different trade-offs. Kobi Gurkan 26:53 Another thing that these could give you is the fact that they can also interact with the real world. 26:59 So for example, some of them can also make requests from inside the TE and fetch data, for example. Speaker C 27:08 Which is, let's say, in zkproofs it's not really possible. Kobi Gurkan 27:13 Maybe in some different ways. 27:15 MPC is possible, but then you run into some race conditions. 27:20 Maybe every time you fetch, and different parties would fetch different things, load balancing, whatever. 27:27 Something you can do. 27:29 And yeah, I will say that I used a very specific implementation of TEEs here, but most of these concepts are transferable to other TEE systems as well. 27:42 And yeah, before I wrap up, I'll just also put some glaring open questions that exist in this proof of concept. 27:52 One of them is what about protecting the DID itself? 27:57 So if you remember what I was saying is that we take the list of keys that are authorized to sign from the DID document. 28:05 And that can be updated. 28:07 That can be updated in PLC. 28:08 That can be updated in DID web. 28:11 So maybe we need stronger protections on the DID itself because otherwise it could just put any keys it wants. 28:19 And then maybe the verifiability becomes meaningless. Speaker C 28:24 But that's also OK because in some sense you can say that updates to the deed should be rare. Kobi Gurkan 28:32 It's not something that needs to happen every day. 28:34 So you can think about stronger protections that you can add to deeds. 28:39 And maybe the rotation key, which is what controls updates to the deed in PLC can be under really strong guard or whatever. 28:51 So that's one thing. 28:53 Another thing is if you might remember that I said that in order to know what are the keys that are authorized to sign, we send the whole audit log to the TEE. 29:07 And, but what? 29:09 What if we didn't send the entire audit log? Speaker C 29:12 What if we stopped before the last update? Kobi Gurkan 29:16 So it might not have the most fresh list of keys. Speaker C 29:21 So this is a problem. Kobi Gurkan 29:25 You can think about solving it in different ways, maybe making requests out of the TEE to fetch the audit log. 29:31 And then you don't need to trust the input audit log. 29:36 Maybe there is a solution that can be done on PLC itself. 29:39 Maybe PLC could start signing responses. Speaker C 29:44 That's different ways. Kobi Gurkan 29:47 And yeah, many, many other things that are left open here. 29:50 And when people look at it, they're welcome to discuss this with me or others. 29:58 But yeah, many other things are open in this proof of concept. 30:02 But yeah, I hope that it opened some new notion for at least some of you. 30:10 Thank you. Speaker B 30:12 Thank you so much, Kobi. 30:16 We have time for maybe 2 questions or so. 30:19 Is there any questions? 30:20 I will give you this mic so that they can hear you remotely. Speaker D 30:27 Hi guys, I'm Ethan. 30:28 So my question is, I'd just like to know a little bit more about how the PDS interacts with the TEE at like a process level. 30:37 Like, is it in the same process? 30:39 Is it on the same machine? 30:41 I'm just like really interested in how those two actually connect at a low level. Kobi Gurkan 30:45 That's a great question. 30:46 So in this specific instance, we're using what's called a cloud TEE. 30:53 The PDS is a normal PDS. Speaker C 30:56 It is deployed on my server, but it's still a vanilla PDS that you just installed. Kobi Gurkan 31:02 You don't need to change anything in the PDS itself. Speaker C 31:05 What interacts with the TEE is the new app, which what we call here BSET app, which after it has enough signatures on a post-draft, it sends it to the cloud TEE. Kobi Gurkan 31:18 And once it gets its signatures, it just creates a normal head proto post record and publishes it into the PDS. 31:28 So the PDS can live anywhere, basically. Speaker C 31:30 Nice. Speaker B 31:33 Thank you. 31:34 Any more questions? 31:38 All right. 31:39 Well, thanks everyone. 31:39 We're going to take a break in this room, and I think there's more sessions happening at 4:00 PM. Kobi Gurkan 31:44 Thanks.