Mental Models for Real-World Cryptography and Trusted Execution Environments

Transcript

All right, welcome everyone to today's A16Z crypto research seminar. Very pleased to introduce Itai Abraham. It has been working in the intersection of distributed computing, cryptography, and game theory since way before it was cool, even maybe before blockchain protocols even existed, I would say. So he's obviously perfectly positioned to do lots of great research in the blockchain area which is what he done over the past decade plus and today he'll talk us about mental models for TEEES. >> Thank you Tim uh for inviting me and uh thank you everyone for coming for my talk. Uh very excited uh to spend time here and uh work with such a strong team of researchers, interns and and visitors. Uh in particular this is a great opportunity for me to actually work in person with Kartik and Ling something that I haven't done since

2016. So yeah very exciting. Okay, so I'll talk to you today about uh trusted execution environments and uh you know there's not going to be a lot of math so don't worry it's going to be more of a kind of overview of of this topic and I hope you'll get uh uh something that you want from so I'm going to talk about multiple different topics a little bit about kind of in general how I view uh security and and the friction around that we'll talk about cryptography and and uh the real world or or the physical world and then kind of go into uh these trust execution environments and at at at the very least I want to talk about uh you know how they relate to consensus how they relate to integrity proofs and how they relate to to this notion of accountable privacy that I'll be talking

about. Okay. So, um so let's talk about kind of a you know this this notion of security versus friction which I find in many of the uh dilemmas that that I look at in the real world is kind of a driving trade-off. So in some sense you know you ask yourself why do we want security? So if you're more of a Beijian thinker, it's because you're kind of risk averse and you want to reduce uh the probability of of having bad events, maybe reduce your variance. Or if you're kind of worried about the worst case, then you kind of want to prepare for the worst case. And really the question is kind of at what cost? And and sometimes there's this kind of inherent trade-off, right? If you spend a lot of effort trying to protect yourself, then at some point it becomes too costly. So you

really want to find something that makes sense in terms of this trade-off between uh uh you know, security and uh and and friction. And so, you know, at least for me, traditionally, uh, most systems kind of, uh, uh, don't go for this kind of high security, uh, uh, trade-off. They usually provide relatively low, uh, security because they want to basically get as low friction that they can because, you know, high friction is kind of a, uh, stopping, uh, usually value created. And at least in some places, this kind of creates an illusion of security uh, and and in some case even kind of not a real uh, value for for users. And at least to me kind of one of the biggest disruptions in this trade-off is uh this appearance of of Bitcoin uh which is kind of one of the extreme

examples of something that provides very high uh uh uh security and also provides you know relatively high friction. It's pretty there's multiple reasons why it it's not uh it's not easy to use or or to maintain and so on. And maybe the next uh kind of evolution for that is is you know these uh blockchain disruption which is kind of more generally trying to get uh at a point where it still provides high security uh but kind of lower friction I would say you know global computer right so this kind of the the high level goal of this this whole topic and uh and and uh I would say the overarching goal uh uh in in this space is to kind of get high security but get low friction because we know that anything that has you know high friction or or even medium friction

will just not be adopted and used. And so this is really the kind of important trade-off. And uh you know I I personally think that uh one of the ways we're going to get through this is through through a kind of major disruption that's happening upon us. And so you know what what will be the way to kind of get high high uh security and low low friction. Yeah. So I I actually think the you know this AI is going to make a huge difference here. This is one of my big predictions um that you know these dramatic productivity gains that we're seeing will actually be translated um to the ability to dramatically reduce friction. So we're already seeing this by basically being able to build way more complicated systems. But I believe that over time we'll be actually be able to get even better reductions in

friction and that will allow us new points in the trade-off. So things that we didn't believe were were feasible or or efficient uh will actually now become much more efficient. And I'll talk a little bit about that. But I want to focus kind of today on uh cryptography and hardware. And I'll kind of ask you this uh this kind of question. You know, we all believe in in in cryptography. So you know, do we need to trust the physical world? Is there any hardware that we need to trust? If we kind of just have, you know, cryptography and cryptography works and is is wonderful. So anybody uh anybody think we uh we don't need any secure hardware?

>> So what's the question? We do we need secure hardware or not? >> Yeah. >> It depends on the application, right? >> Yeah. Good. Great. Yeah. So what application you don't need anything? >> Sorry, what what's the question? I >> Yeah. So so I think I think Elaine's answer is actually quite good. So what I want to say is that for many things that we take for granted, we'll see that uh uh we do need uh some sort of secure hardware. But for others, for example, uh let's say uh the fact that we can use hash functions and we believe that they're unbreakable, right? I don't think we need a a secure hardware for doing that. I mean, so so here's what I here's the thought experiment that I wanted to kind of go over. I want you to kind of think about a world where uh um

there's what I'll call, you know, no physical security. So in that sense, you know, the adversary can always kind of reach into any secret that you have, right? If you have a USB key that has a secret, it can reach and look at it. If you have a, you know, secret note with your uh uh passphrase or or or you know uh password or whatever, it can look at that. Right? So, this is kind of a very uh daunting world where basically there's no there's no physical way to kind of isolate and keep a secret. And I guess my point is that this kind of world is is uh is very hard like there's nothing we can do in this world. There's so you know as Ela kind of observed there are things that you can do, right?

So for example, you can do uh some sort of integrity proofs, right? So so there's a little bit you can do and and maybe even you know if you're kind of if you assume that there's some randomness then maybe adversary can't predict randomness and so you can do randomized algorithms. So there's a little bit of things you can do uh in some you know area of cryptography but kind of most of the things that you would like to do public key cryptography having secrets being able to sign being able to encrypt in such a way that some people can decrypt but others cannot all these things be kind of uh impossible. So I guess my point here is that whenever we think about cryptography as kind of solving all our problems, we're actually assuming some root of trust of physical assumptions. There's essentially you cannot do anything or there's very very

little you can do with with cryptography without having any uh physical trust. Okay, so that's kind of the main point here and and yeah, that's kind of the the the the essence is that uh you want to or you know if you don't have a way to guarantee that there are secrets that will not leak that the adversary cannot look at then there's very little we can do right if you want to maintain assets if you want to have some some uh cryptocurrency or any sort of access to your bank and so on then you need to have some sort of secrets some sort of biometric secrets some sort of uh passphrases some sort of uh digital uh secrets that cannot be accessed by others, right? If you if that is not the case, then I don't know what to do. And

so I guess the the thesis here is that if we already have to trust uh hardware, then I guess the question is, you know, why should we trust it or or you know, which which hardware should we trust? And the other thing that I'm going to try to ask is okay if we need to trust hardware a little bit then you know maybe why not should we use that little bit of trust to actually build hardware that we trusted even more to allow it to do more things than just say keep our secrets. And in particular, you know, there's kind of this uh meta question that if we have time, we'll we'll go over at the end, which is, you know, what is the minimal trusted hardware that we would need? Uh and and how would we even guarantee that it is trusted, right? Maybe today you buy a I don't

know a secure wallet or a ledger or something that that you can kind of keep your your your your cryptocurrency. So, how do you trust that that thing is actually um you know, doing that and doesn't have some sort of back door, for example. Okay. Okay. So I guess the main thing I wanted to kind of convey here is that uh in a sense uh you can think of cryptography as a reduction as a way of taking a small amount of physical trust and using crypto poverty to create a lot of trust. >> Yes. >> Can I ask question? I have a question about the TCB. So I wonder is like and does Intel believe that ST TDX is more secure than SGX because I think the trust model we'll talk about TDX at the end and uh and I'm not representing

Intel in terms of their beliefs but I will I will discuss that. Thank you. Yeah, I want to go into trying to define uh uh so formally how we can talk about uh physical trust. So we have some something that we believe is uh physic you know we can trust it physically and so what does that mean? So we want to kind of define an adversary and say hey this type of adversary cannot access this type of uh physical machine. And so for that I want to kind of uh separate different types of adversaries. So I'm going to go through this hierarchy. You know maybe the easiest one is a remote adversary or network adversary. So again imagine this is like somebody who can access your uh your laptop or your phone remotely right which is kind of uh what what may happen once your machine is

connected to the internet. The other is maybe it's running uh local software. So maybe you know if if you're keeping secrets on your laptop then maybe there's another application running on your laptop or maybe if you have a a USB device but you connect it to your laptop or your phone then you know then something can run on your phone and so on. So that would be kind of the uh a software adversary. It's still an adversary that can only just run software but it's running close to this secure hardware. And the third thing is kind of a physical adversary. So this is the adversary where you know you you you give it your your secure hardware and they go to their lab and they have all the lasers and things that they need and all the measurements to kind of uh try to figure out what to do and there are

going to be different types of technologies and in different ones we'll see we get different type of guarantees against these different types of adversaries. So, so this is kind of you know I guess the I won't say the beginning but it's the beginning that I want to start with with uh uh you know what are uh these uh secure hardware uh uh entities and and this is kind of a TPM this is a a a chip a piece of hardware uh which you know sometimes it's actually virtualized uh so so it's not necessarily a piece of hardware but uh the idea of of this uh piece of hardware is that it can kind of do these uh three things it can store secrets inside of it so in that sense you know again can keep secrets that people from the outside cannot see. Um, it has a

monotonic counter by the way. So, for the consensus people here, that kind of allows you to do all these fun things. Um, but I'm not going to talk a lot about that. And the third thing which is interesting about these uh these uh u uh systems is that we believe that they can trust trustedly measure other parts of the system. So in particular, for example, if I want to see what's running on my CPU, I believe that these TPMs have a hardware trusted way of looking at that and measuring that. So measuring kind of will be the the noun that we're going to use for for saying I'm kind of looking at what is running on on a CPU.

And again, if any any one of these things uh break, right, then uh it's going to be hard to use these things, right? So even if I trust it, if it's kind of looking externally and reading things that don't exist, then it doesn't help me. or if I trust it but it leaks its secrets it doesn't help me right or you know if you depend on this monotonic counter and it's not really monotonic then also kind of horrible things happen yes >> first two assumptions make a lot of sense to me but why is the last one a reasonable assumption >> oh this is physical trust of hardware this is how it's uh it's how it's built I mean I would say you think this is reasonable um so it really depends on your your attack model right like uh um but I would say I I'm saying it

differently I'm saying you need these three things in order to make it you need to to trust these three things. Um whether it's a you know whether you believe it is trusted or not is kind of a yeah make sense. >> Why why do you think it's not reasonable? >> Can measure other parts you mean you can measure what's in the memory. >> Yeah. in particular is I can I can design a malicious uh >> RAM when you try to measure I give you a different set of >> yes so so so definitely you have to assume that the that there's more to the design of the system than just the the just the TPM but also kind of the thing that it can measure it can measure in a trusted way absolutely I mean that's I think that's part of the mental model

that you should have right so I'm glad that you uh yeah >> this meant to be a silly question but it feels There should be something more here because like for these three conditions >> isn't the human mind trusted hardware. >> I can keep a secret I can count and I can see things you know and if you you need to tr trust me but you know there are some laws saying I'm not allowed to do things. >> That's a very good observation and I would say uh yeah humans also have this property and I think against a physical adversary with a wrench >> um it you know you could argue whether you have this property or not. So it really depends on the the physical adversary but for a software adversary like somebody just talking to you could also imagine some

risk right so so but but you're you're absolutely right like you should think about this is a a good mental model not just for TPMS for any type of secure hardware let's say uh a piece of paper that has a so on right um yeah okay so so kind of this is what a TPN are and by the way all all your you know all your servers and and laptops have these things and uh I'll talk a little bit more about this but yeah but but anyways what is good at this is that basically this allows you this notion of an attistation um so basically what is an attestation it's basically taking the first uh the the the the first thing and the third thing together right so I'm measuring something in the external world and then I use the secret that I have to sign it okay and then basically

by having a signing of a measurement this is kind of what can be called a an an attistation and I can even do something more sophisticated which is I can keep secrets. I can release these secrets only if this signed measurement matches a previous signed measurement. This basically allows me to kind of uh put a secret into a very specific piece of code and then make sure that the same piece of code is running again. I can kind of put again I can release the secret just for this type of code. Um I you know there's a monotonic counter here. there's like this nice literature from the uh 90s and 200s about uh BFD systems with monotonic counters. I'm not going to talk about a lot for for many

reasons. Um this is not not very efficient and let's just put it there and not talk a lot too much about monotonic counters even though I like them a lot in terms of the security model. So I would say you know definitely people believe that TPMs are secure against a network adversary and even even um um a software adversary again even though there were challenges there were there are virtual TPMs are implemented uh in in firmware onto you know larger co-processors and there might be risks there as well. Uh and in terms of uh um uh physical security you know people say it has a relatively good physical security. Um so you know I'm not an expert in these things but my guess here is that uh um there are there are um

uh yeah maybe agencies or or or groups that if they have physical access uh can spend can spend effort to actually break into these things physically. So no I'll say differently nobody's claiming that this is physically unbreakable at least not that I know of. Um and okay that's kind of one problem. The other problem is that obviously like these things need to be upgraded and updated. That's another story which I won't go into too much. Um but I will tell you kind of you know what really went wrong with this type of paradigm. So the paradigm basically was that you have this small co-processor that you really trust and then you basically load the bias and the TPM would measure the bias and kind of sign it and then check that this is the right bias and then load the operating system and measure that and then load

the application. So you kind of get a sequence of trusted boot and basically this trusted boot would be kind of verified from the bias of the operating system to your applications. And typically the problem is that uh what the TPM would end up verifying is you know in in in in a in a in a ZK language a huge enormous circuit right of all the applications running on your machine. Uh and so if you're kind of you know yes you verify that that is what's running. Um but that huge thing might have so many problems in it. Um so this is this kind of large TCB problem. Uh trusted compute base right this is the the thing that I need to trust right. So I think that's kind of what uh somewhat failed with this paradigm. And what this kind of led to is is systems that that don't

kind of verify your whole system, but to verify smaller parts of it. So for example, your phones uh have kind of something similar to a TPM. Uh you know, wallets definitely have that uh and and you know, HSM are kind of dedicated servers that are kind of focused on minimal functionality just for maintaining managing secrets. I think you can use TPM to verify only the piece of code you care about, but it's just it's not fast. I think it's inefficient. >> It's not necessarily I don't think the problem is I don't Yeah, I'm not sure the problem is inefficiency. I would say the problem is that usually like a a platform runs a lot of code and I mean if you wanted to this goes back to the security versus friction. So you could have a very very dedicated system that just just does one thing. That's

essentially kind of what an HSM is. But uh this is maybe going to be in the next slide which is kind of the the way compute evolved is by basically packing a lot of work into one server. And so once you pack a lot of work into a into one server then okay you can verify that a lot of things are running on this server right but uh but it's not clear that that gives you a lot of uh security value >> but what I'm saying is like there are works that show how to use TPM to verify only a small piece of code that you care about. I think I have a paper called bind and then Brian Panel has a bunch of papers on that topic.

>> Great. Yeah. >> Uh so it's just like when you do that you have to go through a heavy context switch. >> Yes. Yes. Yeah. That's a great comment. Yeah. Yeah. Yeah. That's that's a good point. So you can use this. I'm not saying you cannot. Yeah. Yeah. That that's a really good comment. Thank you. Okay. So yeah. So I want to say that the next thing that happened is kind of uh uh this you know the cloud computing kind of got got uh important and really kind of this uh virtualization allows you to pack many many virtual machines into kind of one physical machine. And this kind of gives you a lot of elasticity and it essentially reduces the friction right and so so by reducing the friction the cost of uh running things um you know you get a lot of economic uh uh value here and by running

these things at scale you get also a lot of uh value. So anyway, this kind of made a very reasonable um um uh economic sense, but then kind of brought in a new a new security problem which is kind of this outsourcing of computation, right? And and so this is kind of the a new security problem which kind of uh has two fundamental problems. So you know it used to be that I ran stuff in my data center or in or on my desktop and I trusted it more because it was my hardware. I had physical security there. Now I'm kind of outsourcing it to a cloud. Um, and this kind of brings me a new problem of okay, outsourcing. Um, and uh, you know, there's two things I want to worry about. One is if I'm outsourcing computation, maybe it's not doing what I told it to do. Maybe it's

doing something else. That's kind of the integrity problem. Uh, and and the other problem is kind of a privacy problem, right? Maybe it's doing what I'm telling it to do. Um, but it's looking at the input or even looking just at the code that's being run. Okay? So, these are two kind of natural problems. Make sense? Okay. Okay. So I would say the next evolution here is kind of these u this notion of a trusted execution environment which which are basically came trying to address this problem of of of cloud compute you know gain the e economic efficiencies but give you some sort of security of of uh of uh um okay and and the the kind of high level ideas just do two things right so previously we kind of ran a machine uh one machine in on

our hardware now we're running virtual machines, right? But you can just think about a machine. We're just running them virtualize running a lot of virtual machines on one piece of hardware. Basically, what we want to do is we want to have for each of these virtual machines a separate TPM. So, you know, we already know what that means. Um, and so that kind of will give us integrity that is more granular. Instead of kind of saying here's what the whole node does, I can have an integrity proof specific to this to this virtual machine. That's, you know, that's good. And the other problem is that well now there might be multiple things running on my machine, right? This goes back to the uh software adversary. And so I want to basically have some sort of isolation property.

Yeah. I want to say that if one VM is running, it can't kind of go and peak into the other other VM and learn information about that. And kind of the way that is done. So okay. So so this is kind of done essentially through the same type of technology but maybe virtualized this this TPM. And this other part is done essentially by having a trusted memory manager and through encryption. Okay. Maybe the somewhat surprising case here is that, you know, we all think, oh, we're just encrypting this thing, right? We're just encrypting the VMs. But if you think about it, somewhere somebody has to decrypt these VMs, right? And so they have to have the key. So really what you're saying is that there is a trusted memory manager, right? That's bas basically saying now we're running this VM and so I'm not going to let it look at that part and

now we're running that part that VM. I mean, it kind of has the keys to everything, right? So really what we're trusting here is the isolation of that that the code of the memory manager is providing. So basically we're trusting the memory manager and uh and the really important part here is uh again this is kind of this uh uh security versus friction trade-off. The reason why uh I mean you know you want to get a very low friction. So you want to make this work you know with very small overheads singledigit overheads relative to a regular VM. uh and because of that there were kind of design choices that made it essentially secure against or or the goal was to be secure against uh software attacks and so in particular yeah what do we assume here we assume that there's an adversary and uh and it

can really kind of control everything all the software running in the system so for example you might have a compromised BIOS you might have a compromised hypervisor you might have a compromised operating system you might have compromised virtual machines and still if your VM is kind of uh uh you know running as a TE you want to say that this adversary that can compromise all those things cannot kind of look into you and so you can still provide this integrity and confidentiality properties. Okay. So in particular there are certain firmware components for example this memory manager that we assume this adversary cannot compromise.

Okay. So if I had to kind of strictly say is it a software adversary? Yes it's a software adversary but there's pieces of I don't know firmware software I don't know how you want to call it um that the adversary cannot break into. So these are kind of the two two properties that that we can get from these things. So the first is kind of the integrity property. So this is um the ability of attestation and there's basically three things that you need to assume or trust in order to make this work. Right? So the first thing you want to kind of uh um make sure is that is that as we talked earlier that there is a way for me to measure the code running on the VM in a trusted manner. So for example, you know, if I measure the VM, but someone

is switching what it's running there, I, you know, that's kind of a man in the middle that's surprising me. So that then I lose kind of the the guarantee. Um the other thing that I want to kind of uh trust is that there is this uh component that has a secret and it can sign um this measurement. And then the problem is that okay, this signature, you know, is some public key of somebody. How do I know this public key makes sense? There's basically a chain of certificates that goes all the way to some top level certificate. So you know each hardware vendor has their own separate uh root chain of trust and you kind of have to trust this root this this uh chain of certificates right so for example uh if you're doing an attestation and you're using a intel hardware then at the end of the day

there is kind of a a root intel certificate that you have to trust is the correct public key okay so anyway so so if you have if you do trust these three components u then what you get is basically a a uh integrity proof right or a validity proof or a if you want to call it a ZK proof and uh you know uh all power to you uh and and you know the nice thing here is it's publicly verifiable basically what you have is a measurement of the code um that is signed and you have kind of a chain of of of of certificates all the way up to some top certificate that everybody trusts. Okay.

So it kind of it doesn't look like uh like your standard validity proof, right? uh your your your your jolt but but you can you know but but for all sensor purposes this is basically proving validity of uh sorry integrity of a of a of this I mean saying that this is what is running on this via that's the good news I guess about the attestation and and isolation is kind of the other side of that right we want to kind of protect ourselves again roughly speaking this is a little bit of a caricature but I think it's a reasonable mental model um is that there is this trusted memory manager and this trusted memory manager you know is basically letting different things run at different times in particular you can enter and exit your TE. Okay, so when you enter your TE, the TE starts running

and when you exit your TE, then other things run. Okay, and a very so that's kind of a very high level. You enter and exit it. And basically when you are outside when you exit it, then the memory manager takes care that uh if you try to read anything from from that part of memory, then you know it's either blocked by the memory manager or this happens to be encrypted. Okay. Um, and when you're inside, then what does the memory manager guarantee? It guarantees that the only code that's running is the code that you put on when you attested to it. So, you can't kind of put malicious code that will run on your on your thing. Okay, so that those are the basically the two things that are happening. Uh, and in terms of kind of uh what are you getting here, you know,

you're definitely getting some sort of uh you know, something similar to to FHE in the sense that uh um you know, uh you don't know what's being computed, but actually you you get kind of something that's even even stronger. you get kind of strong notions of of obiscation, right? I think even Ela has this paper with with Rafael trying to formally define some of some of these uh you know what is the formal thing that you can get from confidentiality but really think about it as kind of a a strong notion of offiscation in the sense that I can load code into this machine and you know it's very hard for you to know what what exactly is that code but there's a there's a butt here right so so there you know these are all the good things about uh about uh conf confidentiality but um I guess there's

definitely a lot of challenges um you know some of the challenges you actually uh heard about in Elaine's talk related to to side channels uh related to to memory access and uh and storage access. Um but you know I'll let's start from from the top. I think what we've learned is that uh getting good confidentiality uh is actually quite challenging um because you kind of want to get uh and with low friction, right? So if you want to have high friction then it's a it's less challenging. >> Um so you know the first thing really that you should remember that this is only good for for a software adversary.

somebody has physical access to this machine. Uh I think uh I think you know a lot of current tees are are very weak. Okay, you don't need a you don't need any fancy attacker. You um and then kind of you know there was many years of these uh uh horrible side channel attacks. Some of them were what's called micro architectural in the sense that the architecture was correct. the man memory manager did the right thing but the way the the code um that that that was written for these memory managers were implemented at the low level right so this is the micro architecture level was kind of incorrect um wasn't following the the requirements of the architecture and so that that's where you have these these horrible bugs uh at the micro architectural level and

obviously there were other problems so over the years there are many problems and I think um you know many of them are fixed and uh and I think uh my understanding is that it's getting much So there's less of these things over time. So that's kind of the side channel side of things. There's uh yeah the memory side and the storage sides. I kind of mentioned these this oblivious computation. So basically there's kind of two paradigms of using these TE's and this is kind of what we're we'll cover. So the first one is kind of a defense in depth and here I urge you or I want to say basically even if I'm not going to urge you um the world is just going to force you to default to use TEES. Uh the reason is kind of the the costs will be marginally very small. So few

percentages and it'll basically be like you're running you know network with HTTP and not HPS. Maybe 10 years or 15 years ago made sense. Today people will look at you as if you're a bit weird like why aren't you just doing this simple addition of of security. Um so I think in the future you know you won't have VMs that are not running inside these these types of things. But anyway, that's kind of the the view here and I'll kind of talk about cases where it actually makes sense and it actually provides you with meaningful advantages. And the other is kind of saying no no I really like my application really depends uh on the security of these tees. This is you know fundamental the security that I get uh and uh and and really you know what what does that imply? So what are we kind of when we do

that what are we saying? But we're kind of saying that we, you know, we trust that the cloud service provider that's that that that's running these TE's, you know, has physical security and and and they will kind of not allow certain types of adversaries from getting physical access. Um I do not know whether uh you know uh um maybe some organizations can have physical security to these these CSPs, right? So this is a but this is the assumption that you need to make. Um, and obviously you also need to make this assumption that you're trusting the the hardware providers to actually implement this thing correctly. Um, uh, and even if you kind of trust those two components, right? So you're trusting the CSP for physical security, you're

trusting the hardware providers to actually implement all these things correctly, fix all the bugs and all that, um, then yeah, you you still have to kind of make sure that the way you design your application makes sense and and doesn't leak things through through kind of, you know, non-oblivious computation, for example. Okay, so these are the two things and uh here's kind of a short list of of uh of uh interesting ways where tees can help uh in in the space that that you guys are more interested in. So obviously you know uh wallets and bridges uh definitely use secure hardware if you want to kind of get better anonymity and privacy when you want when you're read when a wallet is reading you can get that uh integrity proofs which we'll talk about you know block production and protection from me uh consensus protocols which is kind of

what I'll be talking about next so don't worry we'll hear a little bit about consensus obviously if you want to run in a you know private private contracts then this gives you kind of a very very uh nice thing to do and and I'll also talk about confidential inference so these are kind of a few things that uh I'll mention but really what I want to focus on is uh is consensus and I want to start with kind of a thing that you've probably heard. So some of you for some of you this is like a really uh well-known and boring and for some of you maybe this is like very new but you know you've probably heard this saying that oh you can't do consensus better than 33% uh with against Byzantine adversaries you know maybe you've heard that for for Ethereum say that or you know if you've

heard that in in the blockchain space then you know you can ask yourself why why can't I do that? what's the fundamental reason why this is blocking me and you know I think this is kind of a really uh amazing property of theoretical computer science that the lower bound is actually like this very very simple three node case there just three nodes and you can you prove some impossibility and that basically implies like these lower bounds for you know why if you have thousands of validators you can't do better than than get like 33% for them. This is really nice and you know if you know this this is what's called this split brain lower bound.

Okay. So, what is the problem we're trying to do? We have three nodes and what we're trying to do is reach consensus. So, we're trying to reach consensus on either zero or one. That's kind of what we're trying to do. Okay. And there there's three parties, A, B, and C. And A and B are kind of going to be, you know, reasonably good parties. And and B is going to be our Byzantine parties, the malicious party. And the goal of this malicious party is basically to make make people disagree on the outcome, right? They want one party to think it's the world is one and one party to think the world is zero. And the way this lower bound works is very very simple. This this uh this uh uh uh uh B adversary basically splits its brain into two parts into a left part and a right part. And the left part

it basically talks with party A and says hey my input is one and in the right part of B it says hey my input is zero and talks to C. And because of kind of network delays then kind of you know this this this link actually never gets any message across. So basically what happens is that you know B talks to A and says hey I have a one and B and A all look very very honest right and and basically what they think is that C crashed right so from B from from B and A's perspective you know just looks like C crashed and it's the opposite if you think about B and C then you know from B and C's perspective they have both input of zero and they kind of uh think that A is crashed and so it turns out that if

you kind of do the split brain then basically A will say okay so let's decide on one because you know we just have two inputs of there's nothing else to do. We have we have to be valid. So we output one and then kind of C says well B is saying one S zero and I have zero and so you know the only thing that we can output here to be valid is zero. Okay. So this is kind of the uh classic lower bound. If somebody you know hasn't seen this before um then and if you have a question then please ask and I'll kind of give you a little bit more um so is or it makes sense makes sense. Good good good. So yeah, so so this is basically this split brain attack. And I guess the observation here that I want to make is that we actually don't really

need to assume the adversary is Byzantine, right? Remember what is a Byzantine adversary? Well, it actually steals the keys and it can do whatever it want and it can run a different protocol. It can run it can kind of wreak havoc. But but actually, you know, it's doing something much simpler. Uh I claim that the only thing it's doing is rebooting the machine. Just rebooting the machine once. Okay. So basically what's the attack of this reboot adversary or or you roll back adversary? Well, it starts it boots up with input zero and then it just uh talks to C. Okay, it talks to C and you know C and C and B talk and they don't hear from A. So eventually they just decide on zero.

everything else is kind of you know delayed and after B kind of you know makes sure that C decides zero then you know B is really happy because what it does is it just reboots the machine okay so it's malicious in the sense that it rebooted itself and then what it does well it changes its input to one right so so it kind of chooses new input and then kind of um you know does the same thing with with uh with a so I guess kind of the main point I want to make here is that uh this you know very simple lower bound first of all this kind of explains to you why all the BF protocols that you know in the blockchain space that work for partial synchrony with a Byzantine adversary cannot do better than a third.

But on the other hand, it actually shows you that the adversary can be very very weak. Okay, make sense? Good. So, um yeah, the only thing we needed to do essentially is to keep our identity the same over reboots, right? Because if let's say I reboot and then when I reboot I talk to to A, now A is like, "Oh, you're you're a different person because you rebooted then this this proof wouldn't work." Okay? So really kind of what I needed here is to say that when I reboot I still maintain my identity. Okay. So what does that have to do with TE's? >> Counter.

>> Sorry. >> The counter. >> Counter. >> Counter. No. >> Increment the counter every time you reboot or not. >> Oh yeah. Yeah. If you had a counter that would be nice. Yeah. Yeah. Yeah. If you had a reboot counter that you could trust then then you could basically change it. Then your identity would change. >> Yes. Exactly. The problem is that you don't have a uh I mean we don't know about at least these TE's don't have a a counter right okay but yeah I think that's exactly the point the point is that uh and we'll show this next slide like basically even if you believe that you're running in a TE and the adversary can't do a lot if the only thing the adversary can do is let you run and then reboot you and let you run again you're in trouble. Okay,

so um yeah, here's the good good thing. Um so here's what you do, right? Basically, here's how you run consensus with T's. What you make sure is that you you know you you build your private key inside the TE, right? Why is that good? Well, because you know when you build the the key inside the T, nobody can see it, right? It's it's confidential. Uh nobody gave it to you, right? It's a it's a new fresh key. So you can be very very secure about it. And then yeah you know just like we assume that we have some PKI there needs to be some mechanism that your public key gets kind of recorded everywhere. So there's like some sort of root of trust or some sort of genesis file that contains all these public keys. Okay so this is this PKI assumption. uh and you know with this

thing basically what you get is for for TE is that if you have a Byzantine software adversary right so can do whatever it wants but it doesn't have physical access because if it had physical access could break your TE it is essentially you know equivalent to this oblivious omission adversary um you know basically what I'll say about this you know if you know then great if not then I'll say what is an omission adversary basically the only thing it can do is kind of block messages right so if you send a message it can block it but it can't kind of change the message or it can't see the co the it can't see the the your secrets. Um and really the high level intuition here is that what you get is non-equivocation. So if I'm running inside a TE and my code says uh

I'm sending you know for round one message that contains the value A then no matter what you do right if you are basically all you can do is like block this message you can't cause me to say A and B for round one. This is kind of this fundamental property of non-equivocation. You cannot say two different things in the same round. And once you have that then you can kind of implement consensus uh with 2T plus1 right so you can do this 2T plus1 you can do this even for a mobile adversary because it's obliv because it's oblivious I didn't even you know I didn't even say what what that means but you know again roughly speaking you kind of don't see the internals of the of the code and you know you can do this with n square communication which kind of the best you want and you can do this even

if you don't have a DKG and you can do this even in asynchronies all the wonderful things that you want you can get here with consensus okay >> but you're not claiming a PE E can do that, right? Or are you claiming that? >> Yes. So I'm saying if you have a T um and it does this thing, it chooses its private key and it broadcast this this private. So you have a Genesis file with this thing, then if you assume a Byzantine software adversary, you can get 2T plus one. >> Mhm. >> So I'm trying to understand why you get oblivious emission adversary. Why could I not restart it to the beginning of the round? Let's say, you know, I have so many rounds of messages. I replay so you're you're emit different subsets.

This is like you know the question of the next slide. So the next slide talks exactly about the see you kind of look at this oh this slide says the good. So probably what's going to be in the next slide is uh either the ugly or the uh there's two choices, right? But uh but you're right like you're asking basically what can we do if we reboot, right? And that's basically what this next slide uh asks. So that's a there's a great question. I don't know there's all these different definitions. Anyway, so so yeah, so what do we do when a VM needs to reboot? So you know, one option is basically say, well, I'll just use the same private key. Does that make sense?

>> No. then you're back to just B isn't fault. >> Then I'm back to the reboot adversary, right? So if I'm if I basically keep this key, store this key, seal it, and then when I reboot, I wake up, I use the key again, right? I'm basically allowing a reboot adversary. Okay, so that's not great. So that's what you cannot do. Okay, and that is kind of the So you know, everything until now was amazing because we basically said, well, we you know, we need 3F plus1 unusual BFT, but here we can get two f plus one because we're using T's.

That's great. Um and and so kind of uh um uh you know what we need to do is create new private and public keys and you know that basically means it's a reconfiguration event, right? It's basically saying you're adding a new node to your system. Um and and you know that's annoying and and but that is kind of the the world here. So again, as long as you have F+1 parties that are not faulty non-faulty, you can kind of use your own system to reconfigure your own system. You can record new members and that's great. But you know if you kind of lose livveness the system cannot make progress because too many people reboot it at once then you kind of need something stronger than a PI you need to have someplace where you need to record you know what are these new public keys

and you should trust this new place and so I'll call this this layer one trust anchor yeah you know say that you can kind of uh deploy these on multiple different clouds to get better livveness for some things uh not for all and I would say you know given this problem that every crash basically or every reboot requires you to re key and reconfigure it kind of makes them not great for layer 1 ones um but actually makes them pretty natural for layer twos because they can you can use this layer one as your trust anchor that's kind of uh I guess the main thing um and here you know here's kind of uh uh you know how it's being used so I'm going to tell you very very quickly about uh you know this notion of confidential inference which is uh you know a new type of use

case you know all the all the large companies are kind of looking at this uh uh confidential AI space and all of them basically use kind of this layer to uh uh state machine replication or consensus protocol uh that uses 2T plus1 using T's. And if you think about like inference as a task, you can think about that task as basically like a payment channel. Your your inference server is just kind of set up the channel. But once this channel is done, then you know when you're interacting with this uh this inference server that doesn't go on chain. These are kind of uh you know interactions that are just between you and the inference uh thing. So so that's why I'm going to call this a layer 2 application. Maybe maybe this is the killer layer sorry layer three application. So maybe this is kind of

the killer layer 3 application. You know, here's the here's one example of this. This is kind of the Microsoft confidential inference. This is Marinovich's blog post. And what you can see here is kind of the data path. Uh you know, an application is kind of asking and getting a confidential inference. And here you see a GPU. Everything here is a tested and secure and so on. And over here on the top, you can see there's a man key management service, an attestation service, and also a ledger here, right? And this ledger is basically a 2T plus1 uh consensus uh uh engine. I gave very long talks about the system. There's a lot of interesting things about it and and confidential inference itself is kind of a very interesting topic but uh a very high level thing I want to show you here is that this transparency ledger is key

to it. Yes, please. >> Uh why do you need consensus for this? >> You need a place to record uh what are the most recent values that you trust to you know for the inference server. So for example, what is the most recent software? What is the most recent uh um uh models and so on. Uh and so you kind of need to make sure that you are that I'm not giving you kind of an old buggy version in some sense. And then you need to make sure that this place has like high availability because if that that is kind of your single point of failure if that place is fails uh you fail. So so there's like three things you want to guarantee here. One is you want to get high availability. The other is you want to get safety in the sense that you're

really you know you are guaranteed that you're you have the most recent attestation that you're going to verify through. And the third thing that you want is confidentiality. Right? So you also want to make sure that if you're making these these queries, you know, that thing is not being made public. >> So in these applications, is is the T and 2T + 1 like 2 3 4 in that range or are we thinking of larger numbers? >> I think for now they're small. Yeah. >> Wait, so are you saying this is running a 2T plus one partially synchronous consensus protocol using TE? >> Yes.

>> Is that necessary or >> I don't know necessary is a mathematical notion. This is I'm showing you like a a system and giving you kind of an example of of you know one example of of a system. Here's another one. Um this is this is a Google this is actually not inference. This is kind of confidential federated analytics and but you know again I won't go into the use case too much. I'll just say here again you look here there's something called a T hosted ledger plus keystone. Well just as Elaine said this is running a 2T plus1 partial synchrony consensus protocol. Okay, this is another example of where I guess confidential AI use cases are kind of using this type of of paradigm. Um here's the the third one. This is Apple private cloud compute. Um again um they actually are using something a little

bit different. This is a what's called a transparency log, but again morally speaking it's very similar and there's this you know this this system has a lot of interesting aspects that I won't go into. But again the goal here is to kind of extend the inference from your phone to the Apple cloud. uh and you again want to kind of use a ledger to guarantee that you're actually talking to the most recent and most secure version of this Apple cloud. Um and here is you know finally uh WhatsApp also have a blog post and and there they also have a ledger which is also using a partial synchrony uh protocol that uh you know is 2T plus one. I think these are the kind of applications where traditionally you kind of argue Byzantine faults are overkill anyways because it's just kind of an internally run kind of permission consensus

protocol right so like why >> yeah so so I would say all of these all of these systems basically or or I would say confidential inference um the thing that changed here is that that many of these queries are so intimate um that you really want to get a very high security where you do not trust your CSP um so so kind of if I had to say what is different or why people now want you know a Byzantine fault tolerance is because the the intimacy of these queries are such that you actually care about a even worse adversary. Now to be honest, right, this is a this is not it's not that all your inferences today right when you go to chatgpt go through this this is like an

experimental system. So I don't know if this is going to hit product market fit or not. Right? But this is kind of you know some people are betting that the you know end game for inference will be confidential inference. Okay. So this I mean I think it's a it's a open hypothesis in that sense at this point. >> What are they doing to obtain privacy like you put things into put inference inside te >> yeah this thing is this thing is you see this this thing says it's running in a TE and this thing says that there's actually an attestation of the GPU. So this whole thing is running on on a on a T. Yes, >> I assume it needs many GPUs like multiGPU.

>> Yeah, there's there's many challenges. Yeah, I I I again I have a long talk only about this but not Yeah, I apologize. I want to sorry I apologize. There's like another two topics that I really want to talk about. So, and I don't have enough time so I'm going to I'm going to rush and if you want I'll do follow-up questions on confidential which is like a very cool topic uh and I've been working on it so I have a lot to say about it. Okay. So, um yeah, Tees and integrity. Sorry. So we started with consensus and then I kind of gave you here's example of people that are using it and now I want to go and talk about integrity uh and I kind of you know again make this observation or this analogy between uh I guess integrity and livveness and confidentiality and safety

uh in the following sense that uh you know if you uh have like n things and one of them fail in safety that that's bad because even one failure in safety is is not good for you and similarly if you have n things for privacy and one of them kind of leak information that's not good for you right So kind of uh safety and confidentiality is really like an n out of n thing while if you look at livveness and and uh and integrity you really have one of these things to succeed and you kind of make progress right so if one of them kind of make progress and you have livveness or you know if you want to prove integrity at least if one if somebody is saying it's you have integrity then that's already kind of a good signal okay then we're actually going to take advantage of the

fact that in some philosophical sense these properties are weaker than this sense uh in order to kind of look at this notion of using uh uh you know two two out of one out of two or two out of three type of solution and and here's you know some challenges with with uh uh zero knowledge proofs or you know I prefer to call them vality proofs and I would say you know they mirror the problem that happens with uh with uh with tees which is that typically when you're trying to prove very very large circuits your trusted compute base is not just the proofer itself but it's actually that this huge circuit doesn't have any bug and that's actually very hard and you know and there will be bugs and you will need to update it and upgrade Um, and I guess in many of these uh

systems that are using it, there's kind of this idea of having a security council. And so what ends up happening is that, you know, you want to have a permissionless and trustless system where you only trust cryptography, but at the end of the day, you're trusting a multi- signature. You know, I mean, maybe three out of five or whatever, some some multi- signature that can basically override your whole cryptography. Okay. Um, and so kind of, you know, I guess one kind of major goal for these proving systems is to improve that and rely less on a security council. Here's kind of a very nice idea which is basically let's compose integrity of a two one out of two. So how are we going to do that? We're going to do that by saying well we're going to take every every statement and run it through two different provers. So one

prover is just going to give us a zero knowledge proof the good old the trusted uh wonderful thing and the other is basically going to give us a signature of an attistation that goes up all the all the way up to the root of some uh hardware provider. Okay. So these are basically two different types of proofs. They're both validity proofs and the idea being is that there's if there's a bug in one or in the other then you know the the other one will hopefully catch it or the probability of having an error in both of them is small. Okay, that's the idea. Okay, so what would you concretely do? Well, if both of them say yes, then that's basically committed, right? That's kind of your execution.

And if one of them says no, then you can kind of go and do more fancy things. So, for example, you know, one of the options is to say, well, if you don't have, you know, if only one of them, if both of them say no, then you just, you know, just say okay, abort. But if one says no, one says yes, then maybe you can say, well, now I'll give you like a week for doing fraud proofs. That's like a third way of doing integrity checks. So that might be kind of a fallback. Or you could have you could say, well, if one says yes and one says no, we'll let the security council decide. Or we can let the security council decide after 3 days, right? So there's a fraud proof. And you know, you can do all these kinds of mixes. But I guess the high level

idea here um is really that uh if you're worried about or if you know if you want to get high quality high security um zero knowledge proofs then this approach of defense and depth doesn't add a lot of costs right the friction is small and the additional security is that you know it allows you to deal with some some of the some of the potential bugs that you might get that's kind of an a way of getting u uh defense in depth so so that's kind of the idea here and again I would say this is again a a security versus friction trade-off Right. So I think uh many systems today maybe just prefer to kind of say yeah you know we'll just do a we'll use our approver and we'll have a council and so that's kind of the lowest friction approach and adding kind of these

systems adds some friction but really what I want to argue here is that the security value is is good enough that you should look at this trade-off and say hey this actually makes sense and you know this should be kind of in some sense the default going back to uh you know using using uh default yeah using te as a default. Great. So that's kind of one thing. Oh yeah. Okay. Okay. There's the end game. I won't talk about it too much. You know what? How will we do this in the end? Um, yeah. And if you do have a security council, then then please use tees for the security council as well. That's another thing, but let's ignore that. Yeah. And I want to kind of go very quickly into my last topic because this is like a very fun topic.

Yeah. And so, so, you know, is is uh is a threshold cryptography broken? Okay. It's not broken in terms of the theory, right? But, you know, what's the problem with having councils? Um, uh, and I guess the real question is like why isn't there traction? Why aren't we seeing uh you know some some start of product market fit for NPC? And that's kind of the question I'm asking here. And really like for example when when I ask uh uh you know Vitalik uh then then his his answer is that uh is that parties can collude and there's no way for you to kind of figure out uh if if parties collude secretly and kind of uh leak these secrets. So in in a sense the problem is not the cryptography, it's the cryptoconomics. Okay. uh and uh and the problem is that is that basically if

we're doing threshold cryptography let's say you know uh twothirds of us need are holding a secret and we have to agree on something and we can also secretly meet and collude and kind of uh leak this secret and gain some things and make it such that it's very hard to detect us and all these problems and therefore I guess in that sense threshold cryptography is broken or you know you're not seeing a lot of use for for MPC that is based on threshold okay so kind of the punch line here is that uh uh you know why Doesn't this happen on blockchains? Well, we have this notion of of accountability uh where basically, you know, if many people are trying to collude and and break the consensus, then we have these beautiful results.

Some of them are, you know, people here in the audience that that show that basically a lot of people are being detected and can be cryptoconomically punished, right? So, accountability is kind of the reason the cryptography or the distributing says yes, you have a third, but the reason like this third doesn't collude to become a half more than a third is kind of because of these cryptoconomic things. And I want to say uh this has also been extended to to livveness. So you know also you so you say okay this is why blockchains are safe but why are they live right? So they're live because they're incentivized to be live and again there's like new exciting work about accountable livveness and I think I think these are things are very important and and the thing I want to talk about here is is accountable privacy uh and really want to say well

how can we get the analoges of accountable safety and livveness that we get in kind of blockchain systems to MPC or threshold cryptography and so on. And uh you know the big problem here is that if if a human uh has a has a has keys then kind of uh you know an adversary with a wrench can kind of uh convince you that it's actually quite nice to collude you know and and then you you would collude right um and and there's and it's completely secret. There's no way like you know you you can collude without uh anybody seeing it. So there's no way for you to be accountable. So, you know, one solution that is kind of obvious and nice, I think, uh, is that even though a human might be the one that's putting the stake, right? They're kind of the the validator of these this

this MPC node, it actually doesn't control the secrets of this node. So, the secret itself is held inside a TE. Okay. So, even though I put money into it, I'm the staker, I actually don't have the secret to collude. This this secret is going inside the TE. What is the problem? Well, the problem is still, you know, some some sort of physical security, right? Right. So, the problem is that this is great for a for for an adversary that can control the network or the or the software, but uh but not if the adversary can actually kind of physically go and and and and take your key out of your MPC server. Uh and so for that, basically what you want is your MPC server um to actually be able to look at the environment, sense the environment, right? You're all laughing now, but you know, let's let's talk five

or 10 years from now and and basically understand, right? So, so yeah, essentially through kind of a AI tools and and and robotic ability. Robotic might be just a simple camera if there's anybody near me, right? If there's anybody I mean one object just send it to to a satellite, right? Then it's far away, but it can be physically near near us but kind of protect it. And if it detects something bad, what what will it do? Not only destroy the secret, but we want to make it accountable. It'll actually publish a slashing effect that will kill your stake. Okay? So, it's not not just kill itself, but it'll actually harm you. it'll punish you.

>> Who Who's you? >> The the staker. Whoever put the stake to run this thing. So there's somebody that has like, you know, that's running the system, but he doesn't that that person does not control the the actual uh >> You're saying the person who was responsible for physical security and failed in that duty. Yeah. >> Will be staked will be slashed in effect. >> Yes. Or I would say you if you want to stake this system, then you need to guarantee that nobody's going to attack it. That is that is your like that is your guarantee and that's your accountable privacy in some sense. Yeah. Yeah. Exactly. Okay. One more minute I think. Yeah. So this is the the slide.

Tees plus robotic AI will give you MPC uh in in the real world. And so um I think publicly verifiable secure hardware is very interesting. I won't talk about fairness. There's wonderful things about fairness. TE's as a security anchor. That's kind of one type of use case. The other is defense and depth. And you know, here's kind of a list of nice things that I think are the future of of trust execution environments, publicly verifiable hardware, accountable privacy. You know, we can talk about integrity and FHE. We didn't confidential AI, which we did and I'm happy to follow up on. And eventually, you know, you think uh it's kind of a a joke, but eventually we'll get to to kind of uh robots and physical security uh through robotic interfaces.

Uh yeah, thank you. Thank you very much. >> Even in that like a robotics world, there's still like cryptography questions to solve. I saw something. Who says if this was a human being or not? What if someone tries to send something that looks like a human being but not a human? Like do do you see what I mean? It's like becomes a computer v vision question at this point. >> Yeah. That's that's why I have a a robotics and AI. >> Ah, and I see. Okay. Like yeah, sure. I don't know. >> Sure. Yeah. >> Okay. I you need to have some long-term. So, so I guess I have several question like when is you mentioned your vision is everything should be TE. So like let's just take Amazon for example. They have nitro enclave. Like what's

preventing them just from offering like TDX container. I mean shouldn't that be much more secure than Nitro Enclave? What's the barrier in practice? >> Um I think uh the in practice what will happen is that the friction of running a secure enclave like Nitro or like TDX will be so low. It will be like the friction of running HTTPS versus HTTP. There is an additional overhead but it will be so low that it will become the default. >> Yeah, I I agree with that but I'm just asking why isn't this happening? Like I still cannot get a TDX enclave on Amazon. There's no nothing SGX. There's only Nitro. Like this has been the state for a long time.

>> I see. So yeah. So you know we we were uh it's hard to to make predictions about the future. Uh and you know Yeah. So, so it's just like uh it took it took an inflection point for people to use HTTP to move from HTTP to HTPS. Some people say it's actually because of hardware changes that enabled to do this efficiently. Some people think it's because of the Snowden revelation. So I don't know what will be kind of the tipping point. I do think that it you know from my understanding of what's happening in clouds that definitely in the next few years um the enablement will be much much better.

>> And then then back to the TDX you said you are going to talk about TDX. So like how do you compare TDX's trust model with SGX and what is and maybe your take and not not necessarily Intel's take. >> That's a really that's a really good question but it's not it's not this call. I I would say that it you know uh yeah since I didn't talk about SGX and I'm let's take this offline. Yeah but but yeah I have a I have a whole >> I thought there was like one part of your talk you were referring to. >> Yeah, but I didn't I didn't actually talk about SGX. I don't want to just like then that would be like >> but but that that part about general computation that you you were not referring to SGX.

>> No no but I I I do I have a lot to say about that. So let's take >> that part was referring to TDX. >> Yeah. Yeah. Yeah. Let's take that offline. I think I have a lot to say about that. >> Is there a formal model for like physical security? Like maybe I have a circuit and I cannot extract information from that circuit no matter if I rewire things or something like is there like >> no I think that's a really good question and I can imagine uh a whole area there. I don't know of it. I'm not aware of it but I think it's a really good I think we have very coarse notions. Even if you saw my definitions they were very vague, right? They weren't very mathematical.

So I think that's a really good question. So capability for measure is that only a TPM thing or is it still um T also does T also need that? >> Yeah, T's also need that because you want to do attestations. So anytime you attest basically what you're saying is that you know the the the code that's running >> I thought that's uh measuring inside right that's code running inside T. >> So when you say inside I mean there are different parts of the hardware I would say. So okay so okay I want to separate the software the firmware that is doing this and the physical interface that's actually looking at the bits. So I would say you need some sort of physical trust in

addition to the software trust that you're making and and I'm actually I'm incorrect in the sense that in some systems this is all virtualized and so in those system is really you're trusting unfortunately you're trusting a lot of software you know if that would be kind of you know one of the challenges of say these hypervisor based uh solutions right uh that there's a large software that you're trusting >> but do you if you use uh hashes Merkel trees where everything for the entire external memory then is again measuring something you have control over instead of measuring something you >> yes so so that that goes back to um uh the friction of kind of uh building a

Merkel tree on everything and verifying it and then when you read and write so there's always this friction security friction trade-off uh and I guess a lot of these systems were built to provide very low friction uh and still give you some meaningful security And you're absolutely right that if you want like a high security application like like the like the examples that that Elaine talked about right you need you know oblivious computation and you want to make sure that when you're reading something it's verifiable and so on that's very important. >> You mentioned that we have the uh integrity and the privacy assumptions under software adversary. Uh does the integrity assumption underline the livveness assumption?

>> Uh what do you mean what do you mean underline? Like uh >> uh is it implied? >> Yeah. Yeah. I mean, okay. Yeah, of course. So, basically, uh, yes, that's a great great observation. I mean, in in part, what we're not only we're assuming that we can do this, but like the system won't get stuck doing it. >> Yeah. Yeah. Yeah. So, that's a really good point. Yeah. So, there's like a Yeah. So, we're implying that this uh the underlying kind of firmware that's doing it, it doesn't have bugs that, for example, have livveness bugs or safety bugs. Yeah, that's a really good point. >> Yeah. So, like the software adversary can't uh tamper with service. Yeah. Yeah. So, so that's a really good point. Yeah. So, one thing you can like two different types of attacks are one is kind of to yeah destroy this uh this trusted uh

software. The other is just to do an denial of service on it. And yeah, so that's a really good point. Yeah. So, you have to guarantee both of these things. And again, I would say the best of my understanding at least, you know, for software adversaries, the hope is that yeah, this is the case. Um but for but for uh yeah, for for for physical, >> yeah, I I'm not sure that's the case. >> The branch is still there. >> No, no, you have like these uh Yeah. more refined things. Oh yeah, you can you can use a wrench. >> Yeah. >> No, no, but for example, like the cisadmin, if you use a wrench against a cisman, that doesn't help you break a tea. >> You use a wrench against the tea itself.

>> Oh, yeah. Okay. Yeah, that that breaks liess. Yes, of course. Forgot about that one. Yeah. Thank you. >> Thanks again. >> Thank you.