ZK Whiteboard Sessions - S3M6: Trusted Execution Environments, w/ Andrew Miller

Transcript

[Music] Welcome back to season 3 of the ZK whiteboard sessions. Uh today we'll be talking about trusted execution environments. Uh I am GMO Anderis, I guess, chief scientist of Bane Capital Crypto and we have Andrew Miller, uh what is it? Adjunct associate professor. That's right. um back in the day at UIU. >> Uh now I guess what do you do? It's like a grab bag combination, you know, uh of stuff.

>> Focused. I'm a junior product manager at Teleport. >> Oh, good. Okay. Oh, junior product manager. Well, yeah. >> Good, good, good. That's a I think it's um >> you know, it fits it fits the position coming from professor down to to the junior product manager, I think. You know, you learn new things along the way or something. >> Exactly. Oh, good, good, good. Okay, so anyways, today we'll be talking about TEES, which I'm very curious about. I don't know if you have a rough outline of what we're going to be talking about today or if we just want to get started. Totally up to you on this one. >> I bet we can make one real quick. >> Okay. >> Um I do have a rough plan in mind, but uh I expect you to help on uh you know massaging this outline um as well.

>> I know that at least uh I want to start with a little bit of like uh high level trust model and like the uh basic model like what is a tea, where it comes from that sort of thing. Um, I know that I want to get into like some application examples. I think that um, one of the highlights of this, but I think that's going to come like maybe three is going to be the uh, you know, co-processor model and an auction. I think this is um, >> okay, cool. Cool. >> Can go through. I bet this is going to be kind of the natural second module break cuz I like this cuz we can go into I think like in detail how you construct like a good application that you know makes use of everything that TE's have for pretty clear application motivation.

I think I'll go through an auction as a motivating example. how to do a secure auction in the uh TE co-processor model. >> Okay. >> And I want to leave some time to go over uh what do I want to say here? Um pitfalls in security mindset kind of things especially the ones that are um we'll get into kind of the trust model details. A lot of this I mean the main kind of principle of TE's that makes it uh you know controversial in web 3 is that it's not just that there's stuff for you to do this is stuff that's made by you know hardware developers. It's >> not like ZK we can go learn the math and go you know fix all of it ourselves or kind of beholden to you know hardware manufacturers for part of it. So a lot

of this is just understanding what goes into the trust model under what circumstances do we believe in it or are okay with it that sort of thing. Um but I do want to talk about uh like software security pitfalls because those are the you know my best outcome out of >> teaching like this is um get a bunch of people building applications building software components on top of this and then there's a lot of uh you know you need to be mindful of a handful of security details and actually just as the placeholder for this really the two main topics are um side channels. >> Sure. Yeah. Yeah, definitely.

>> And uh replay or roll back attacks kind of like statefulness issues. >> And um maybe this will end up being the last thing is um you know upgrade processes. There's actually a bunch of things to say here. It's actually a lot like smart contracts like it's the you know it's not the TE that brings this but you have to think about immutability or like the flip side of immutability of upgradability and then that's like a tricky thing to get right. So >> sure >> this will have a bunch of like you know detailed stuff to talk through.

>> Yeah. So the side channels and replay attacks do feel you know somewhat akin to parts of uh many cryptographic things already. >> Yeah absolutely. It's not you know fundamentally different but you have to consider them kind of I don't know with extra importance or really I think it's like you get to the point of this being the bottleneck there because you get to take so many um >> you know uh uh speed up improvements and kind of developer simplification relative to other crypto stuff. So you get to the upgrades being you know the real remaining sticky thing when working with TE's a lot. >> Very interesting. Okay. >> Um and I I the second bit will be going in through uh some details of like SGX and TDX attestation specifically. I I will draw on the board like the visual aid of like what you get in the

attestation certificate and then that also serves as kind of a checklist of all of the things that are worth talking about because those are all the things that you have to you know inspect as a client or that form part of your audit surface if you're an auditor looking for these. >> Um so my guess is that we're going to break this into sections maybe along there. >> Perfect. That sounds great. >> Maybe it'll even be like that. Yeah. >> Sure. All right. So let's start with I guess a high level trust model. Yeah. So, I mean, I guess we're not going to be talking too much about hardware today. We're going to be talking more about like idealized models, but there is some stuff that, you know, like you mentioned, there's a difference between uh SGX and what was the other one? I believe you mentioned

>> TDX. >> TDX. >> And there are a bunch of others as well. Um, >> sure. >> Like Intel, you know, part of why this is um this works or you know, what we're talking about is it's something that's it's not even a new kind of hardware. It's basically like a feature that's already present in most of the processors that you have. That kind of takes a while to kind of acclimate to. >> So like if you buy both Intel and AMD server processors, >> not like all of them, but maybe like half of them or something have support for trusted execution environment. So it's not even special hardware, but it's like an unusual execution mode or like a less known, you know, execution mode. So it's just, you know, an execution mode present in your server class processors.

very I always assumed that like tees were you know like a little black box sitting somewhere in some core of a processor or something separately and then I mean I know that that's kind of the mental model that we should have but in reality the implementation seems to be pretty different >> so okay so anyway so we're going to start with defining the high level trust model and what the hell these things mean how does it work okay >> uh so you know the basic uh the basic kind of four parties that are relevant here are uh the manufacturers so that's like the uh you know, your Intel, your AMD processor companies that build processors with TE support in them, >> right? And then the execution environment refers to um uh this like secure operating mode. Really, there

there's two main features that I think define T. So, the first one is isolation. The basic gist of what this does is that when you run uh familiar with like kernel mode and like user mode, this is something that's supported by processors. It's not just the operating system defining it. The processor is aware of like >> different processes having different access to different parts of memory that sort of thing >> like the different rings for example >> the different rings. Exactly. So >> um where like the you know lowest ring actually I think hypervisors are sometimes regarded as like ring negative one because like super user was already ring zero and so you know have like a even above that is kind of like ring negative one.

>> You can kind of think of t as like another ring but it's it doesn't quite fit into the hierarchy right because those rings are always like everything at a ring below control everything over there right. So like a user process can't defend itself against the root kernel reading its memory. the hypervisor can read you know the things of VMs. >> So it's not right to say that tees are like a ring negative two like low hypervisor. It's actually a little bit different. If anything it's actually like a kind of you know side quality that makes even your user processors defend it against the hypervisor or the kernel being able to inspect it. So it's almost like protection in the other direction.

>> Yeah. Yeah. So it's it's like instead of a total order, you know, we have like -2gative 1 0 1 2 we have a partial order I guess somewhere where the like where the uh TE lies. >> Yeah. So that's the gist of it. So you run when you run a program or a VM in TE mode. It's isolated from hypervisor kernel other processes. It's completely isolated. Nothing else can inspect its memory. So that's what secures it against other tenants, other user processes and even you know people with admin access, root access on the machine itself.

>> I see. >> Uh the other most important feature that TE's then provide is um remote attestation. We'll like unpack this um you know in a little bit and go into more detail on what exactly that includes. But basically this gives you a signed certificate >> generated by your program running in TE mode. Um, and in this signed certificate, it's got like a chain of signatures that goes all the way up to the manufacturer's public key. >> Okay. >> Uh, and in the body of the certificate, it includes like the program that's running, like the hash of the code that's running, um, like uh, data that it outputs, like application defined data that it outputs.

>> Uh, and some other details like the configuration of the processor that's running. Mhm. >> Um, so the point of this is that, um, I guess I put this right in the middle of this and that wasn't really what that's meant to be. You know, that's kind of okay. >> I did mention that the manufacturer has a public key. It's going to be important to come through. >> Um, >> we'll get into this trust model kind of difference a little bit, but um, you know, this was going to be the hosting provider or cloud. unpacking and understanding the trust model and its nuance kind of is going to involve like the interplay and reputation and other kind of soft stuff but between this like separation of >> roles there and um you know the key thing is like who is going to be checking the remote attestation well end

users who are going to be deciding to share sensitive data with an application >> on the basis of knowing this is going to be an open source program I know that it treats my data you know safely it doesn't just output it >> um I'm going to look at this remote attestation to get confidence that the you know thing I'm sending my data to uh is running a program you know is running the program that I think it is >> got it >> you know if you rent a cloud and like run a service on the cloud and your users you know connect to this service they have no idea what code you're running and even you say oh well I'm running this open source code here's our GitHub code >> and users connect to this service there no way to know that there's a connection

between the service there >> and um it's even kind of tricky was like the account owner like the one who owns the cloud account like they have a business contract with the cloud, right? So, they have some standing like they're not going to be, you know, screwed over by the cloud, but the random like, you know, website visitors that go hit, you know, the EC2 IP address, they don't have a business relationship with the, you know, EC2. So, it's like whose side are they on anyway? I mean, so normally the cloud isn't like inserting itself in the middle between the, you know, app developer and users. >> Sure. >> Um, but in a way, that's exactly what we want, right? So it's like um this whole viewpoint to me is kind of like with web 3 mentality and values and expectations and trust model with like

disintermediation and like you know low barrier to entry for developers being kind of the key point >> and largely it's about basically inserting you know this manufacturer and hosting provider system together in between app developers and the users or relying parties. So basically you know the users get to like uh you know they get to what do I want to draw here? Well clearly like the users directly connect to the you know system running in here >> and they do this based on you know interpreting either by themselves or auditors that they trust you know the code that describes the application >> but they don't just have to take the developer word for it. They basically

get this chain of certificates from the hosting provider and the manufacturer that say this is the program that was running when you interacted with the server at this time. So that's why you know you send your encrypted bid into an auction it's going to be treated according to auction rules and not picked apart and peaked at. >> Got it. >> Yeah. So so okay so like even even higher level the like very simple mental model I have for this stuff. It's still funnily enough this blackbox thing. So like >> you know I am whatever uh AWS.2. >> Yep. Right? Um I have a rack, right? And then someone's like, "Cool." uh you know, developer wants to run or some company wants to run some code on this particular rack. Like in this rack, there's like this magical black box that

says >> if you run code inside of me, I can make certain guarantees so long as you trust the manufacturer. >> And those guarantees could be anything from >> you. So and can make certain guarantees to people who are not you know me, right? So like for example you come and connect to my like cool you know rack >> you connect to this particular black box >> right and in there if uh you know the developer is running code in this black box the little black box says I can guarantee you Andrew that like you know I am indeed running the code that the developer says I should be running. uh and you know depending on whether you want it right like I gear monjaris like who runs this cool you know rack in my

server cannot read the thing you're sending to this black box for example >> um again there's some trust assumptions here between if you trust the manufacturer of the black box and things like that but like fundamentally that's I think I believe so that that incorporates isolation in the sense that I even though I physically have the box right I cannot you know essentially I can't like mess with the that the developer has put in this black box >> and the remote as aation point is >> know you andrew can check that like the um >> code is indeed running in this black box and you know if you trust the manufacturer and all this stuff so that's like my dumb very dumb mental model of it that seems to be roughly correct but here >> that's exactly right I mean so the

developer the developer the developers like own the account at the hosting provider right but themselves aren't installing the box the hosting provider that you know installs and manages the rack run the processor you know that they've got and aren't involved in the you know public keys assortium of that. >> Um I mean the limits of the trust model maybe just to go straight to this. So this manufacturer like uh certificate kind of system certificate chain of signatures involved in remote attestation. It starts with a public key for you know a long-term public key associated with Intel if it's like the Intel chip.

>> I see. I see. >> Um >> clearly like Intel could use the private key to that to sign you know fake remote attestation. So the first level of trust model is you have to trust them not to do that. Although if you also as a relying party are checking the system that comes with like a signature from Azure you know as well as the underlying remote attestation signatures from Intel then it's like both of them would have to be you know making use of that to basically dup you into using a fake you know a fake enclave system. Wait sorry repeat the last sentence. So if I have Azure and I have Intel, what is the like what do I have to not trust for this to be the case?

>> You'd have to trust both of them colluding essentially. >> Yeah. Okay. Sure. Yeah. Yeah. >> Right. Which hopefully is unlikely. We we don't know but like that seems fine. Okay. >> Cool. Cool. Cool. And then yeah we there's some way so so long as like I know that the you know Intel has not you know formally colluded with AWS to sign you know bad boxes like we should be good which I think is a pretty reasonable assumption maybe but >> roughly that's it. Yeah. >> Okay. >> Um yeah this isn't a bad section to go into um you know more of the like philosophy about that just cuz the other security and trust model stuff I you know end up wanting to spend the most time on is kind of into the weeds on like what the application developers have to bring and you know

>> worry about themselves. So I mean it's okay to kind of go and you know unpack some of those. I guess another thing worth mentioning is the idea of threat model and um physical attacks. >> Um and maybe this will also come up a little bit later because I'll draw what do I want to draw here? Actually this is probably going to be an okay time to draw this bit. There's um two kind of main paradigms for this. There's processbased TEEES. >> Mhm. >> And VM based TEEES or confidential VMs. >> Oh, okay. I have no idea what the differences there. Okay.

>> Um SGX is kind of the main example of process based. I actually think that um ARM trust zone is not exactly a full system where it comes with the whole like signature like OEMs have to be involved in like using the ARM trust zone thing. It's a little bit more of a >> kind of a different thing whereas like with Intel and AMD it's like uh you know that manufacturer kind of sets up this whole system. >> Sure. >> Um so like SGX was this process based one. Same with Truss I guess. Um Keystone is like a Berkeley you know open- source research project uh kind of thing. It's like you can buy it. It's not like a finished uh production thing but this is also process based. The newer trend is confidential VMs. So if you see AMD SEV

>> okay >> that kind of works like that. And then um Intel TDX, this is the one that I have the most experience with and use the most now is of this kind. And and so these are very similar. I guess this is now like another way of illustrating this kind of like ring idea. So >> what you have is this TE execution mode. All right. And then you also have the untrusted uh you know environment outside of it. And so the and this interface between the trusted component and the untrusted everything else is like the most important you know thing to start thinking about the trust model and limitations and what you know pitfalls to worry about in architecting something based on this.

>> Okay. >> So um in the process based like SGX the kernel is untrusted. >> Sure. >> And uh an individual process runs in enclave TE mode. And one of the consequences of this is that you know the TE can process stuff you know it runs you know a process it can run code instructions it can access um memory I mean even then actually like you know main memory is somehow what do I want to kind of draw about this the main memory is encrypted in a TE situation. So like in a sense the you know boundary of the TE is the processor chip.

>> Yep. um the memory outside is going to be encrypted and basically every time memory is you know a cache miss occurs and memory is loaded from main memory into the processor cache uh is when it gets decrypted >> getting decrypted by a key that only the TE process you know can have so the kernel itself even though the kernel should be you know ring zero very powerful uh is not able to go like decrypt the memory and even the kernel cannot like open up debug mode and like look at the TU process while it's running and copy the decryption keys out of it. Got it.

>> The processor support for this like prevents even the kernel at ring zero from interfering with a TE process. So one way I I don't know if this is right right like the pro essentially version of the TE is u we have one ring lower than the is I don't know if this is right so but one ring lower than the kernel and that is enforcing that the kernel cannot for example access uh specific parts or is that not right >> I mean it's not right only because otherwise there's this like you know otherwise it's like you know user kernel >> hypervisor there The relationship here is everything below can read and modify everything at the row after.

>> Yes. >> All right. And so with this kind of notion, you almost need like you know one star or something because this TE process can't read the hypervisor. So it's not like a TE process is below and gets to like control you know metal with everything else there. >> Still kind of you know in a way it's like lower than user space mode. It like can't doesn't get special privileges to go access the kernel. But also it's in this kind of side area where even the hypervisor even the kernel can't go. >> Okay. So the hypervisor also cannot. So this is like >> it's kind of you know to the side.

>> Yeah. I guess even dumber question is I'm trying to understand in other words what type of like object this thing is relative to like the processor itself. >> It's a process. I mean how would you uh the same way like I mean if I say what what kind of if I what's you know calc.exe exe like a user process. >> What's the relationship between a user process the kernel and you know x86 code on a processor? >> Sure. Right. Right. But the process has to be kind of like there has to be like some sort of flag or something which essentially absolutely but like what what part of the processor essentially enables that flag or not enables a flag what part of the processor if that flag is enabled prevents the kernel for example from accessing those properties like the

>> memory manager essentially. >> Okay. So there is a memory manager. It's like some very low-level code that's running on the processor essentially enforcing the separation. So like the the dumb way I think about it if I may is like I think of it as like you know this is you know this is the dumb partial order model I think of the DAG and then I think of it as this right or I don't know if it's running the hypervisor maybe it's negative2 so maybe it's this right >> yeah but again I mean if these arrows would indicate that the kernel you know a user process cannot hide from the kernel >> that's right >> the kernel can absolutely like overwrite pages of code in the user process fully under its control you know same thing with hypervisor it can interfere with those error is not true Like even the

well the >> even the microode >> well >> yes I see what you're saying that's kind of interesting this is a very like graph theoretic like sorryving this kind of thing yeah there is no code that runs at this you know minus2 level but if you imagined a sort of like virtual minus2 level there that is inert and doesn't you know do anything yeah that's fair these yeah this is fair >> so there yeah there there is no code but there is like a piece of hardware for example that enforces the separation between these kind of, you know, standard rings.

>> Yeah, exactly. But it's just I think of it not even as special hardware, but it's just because even in the, you know, prete world, you still have processor support for isolation that keeps user processes from interfering with each other, right? That is still man, you know, by the memory manager. And now the memory manager is upgraded to be aware of this extra set of flags that processes >> this. Okay. Okay. Okay. Got it. Got it. Got it. Okay. So, >> that's really to think of it. >> That's cool. That's okay. I I think I get it now. Okay. >> Yeah. Cool. Okay. Okay. And so I mean this is in this like process world. >> Sure. >> Um now in the VM world it's the really similar thing only here you have a VM.

So processors also have virtualization support. So the reason why like VMs work so efficiently is because like you know processors Intel processors are like aware of VMs. >> It's not just like software virtualization. The kernel does like the processor supports it. So it has a which is why the like you know minus one and like hypervisor you know is sensible there. Um so here you have a confidential VM where they say a CVM for that and it is just like a virtual machine. So it's like a you know a virtual you know zero on the hypervisor but it can be in TE mode and then that prevents even the hypervisor from being able to you know look at it, debug it, tamper with it once it's launched and running.

>> Got it. >> And and what you still then have is that the hypervisor on the outside is still um untrusted. So we still say untrusted hypervisor. >> Okay. Okay. Okay. I see. So yeah, in this model essentially we're like instead of you know uh enhancing the you know memory access slash like paging and all that like fancy stuff that like happens in the processor and enhancing that with like the ability to write a 01 flag. Uh we're going to actually use the virtual mach virtual machine machinery inside of the processor and then have it kind of enable this you know sealed off isolated environment from the surrounding context. Mhm.

>> I see. That's exactly right. Okay. Okay. Okay. >> I think I think I understand the high level difference. But >> um >> um so what do you what do you think about the interface between these and the untrusted kernel and hypervisor? So like uh you can pick either side but um oh man >> I guess I have a couple examples in mind that I think you might you know come up with but like what could go wrong right? So the problem is untrusted right? So our threat model is a malicious hypervisor. >> Mhm. Um, so we think that whoever is the, you know, hosting provider or a CIS admin in the hosting provider is manipulating whatever they can at the hypervisor level in this VM approach or in the kernel, however, whichever one you want to pick to try to make up some answers here. They're malicious. So this

untrusted code is trying to run in, you know, tamper mode to the best of it can. >> Okay. um in order to try to either learn something that it shouldn't that was meant to be kept private from this or to tamper with the execution, you know, make it do something, you know, integrity failure that it wasn't supposed to be able to do. >> Mhm. >> Um like we already covered that the memory is encrypted. >> Mhm. >> Um and maybe implied in this is also authenticated encrypted. >> Sure. Fine. >> You can't just like write and tamper with the memory and have it like so if it tries to read something and it's wrong, it would you know uh say it was invalid.

>> Yeah. You can't just like randomly flip bits in memory or something and be like, "Yeah, sure, sure. We're totally cool. Fine." >> Um I mean, one thing that jumps out at me is like even though the memory is encrypted, you probably know what parts of the memory you're able to access or not. I don't know if that also I assume this also happened in the VM case, right? So you have this this property of like you know when things have been stored in memory and when they haven't when >> Yeah. Um although you might not be able to read it, you can always say like okay here I'm going to try to access this part of memory and then it just like you know the system gives you an error says sorry you can't can't do that but now you know there's something there.

>> Yep. So um the kernel is responsible for paging right so there's virtual memory so the actual amount of memory you have is much smaller than the total kind of expressable virtual memory space. >> Absolutely. Um if the kernel has um >> that's right >> all of the memory like it has physical memory backing all of the virtual memory that a processor expects then even when there's a cache miss and it needs to go read from um memory um you know kernel isn't involved but when memory is unmapped um then the kernel gets a page fault >> and what this looks like in SGX is control transfers from the TE mode isolated process to the kernel and it says this is the page of memory

that was being requested that caused this page fault. >> So yeah, that's the first and kind of I mean to be honest kind of skips us all the way to here and gets the main point of it which is you know everything that goes through this untrusted interface is going to be leaking some amount of control. The memory is going to be encrypted but it is going to be revealing if the colonel you know aggressively unpages. You know, one way to do this, actually, there's a name for this in a >> a pretty good research paper on it called controlled channel attacks >> and the control and the control >> channel the control refers to unpaging all the memory. So the kernel can just say screw you, I'm unpaging all of your memory. Now the next and it's even worse than you might expect cuz it's not just

the data memory. It's like the code because the program has to be running until you could get branches for example. So I learn which I learn roughly where you know to some granularity where in the I unpage all the memory the next instruction count >> hops to some page of code that's the page it tells me roughly where the code pointer is right >> so I can read you know >> yeah you can probably get some sort of branches especially if the branches are large you know you you can know where you end up in certain parts of memory if you like break and jump to some point if you like terminate some loop and then left with some other condition so certainly yeah you leak quite a bit of information because the kernel right unpages everything and then of course has control >> there's another really cool paper That's

just won't go into detail but it's directly responsible for you know responsive to this called >> aexit notify um which basically for asynchronous exit which is like what happens when you get a page fault out of the enclave and then control returns ordinarily or the way that it used to be uh or optionally is but you know unless you use this new thing added for security um when control goes back to the process because the page fault was handled and some memory is now paged in uh the process just resumes zooms right where it was as though nothing happened like some time's passed you know the buffers are empty cuz whatever I cleared cache on the way out but I just keep running as though nothing had happened and aeexit notify lets the enclave be notified that this

happened >> so it can like keep a counter and being I guess you know the 10th page fault and I haven't you know made any progress on my multiply so like >> weird I see very cute >> okay okay >> um >> very interesting >> this happens with memory that's kind of the important thing if it happens for memory. Obviously that happens with disk as well like the disk is external and you can't get to the disk except you know by permission through the kernel. >> Um all of this is true in the hypervisor as well. It's a little bit different. >> I was about to ask I feel like VMs still have this particular problem.

>> There's still a VM notion of a of a page fault. >> Sure. >> Um it's not as common like the kernel is like super like swappy and involved. So like there's a lot of like transfer back and forth between the kernel like on an interrupt timer the kernel will be interrupting processors >> um you know letting them go a lot at the VM level it's way more set and forget it you tend to just give like a big range of you know uh of allocated >> you just like slab allocate a bunch of memory right okay yeah yeah and then the ideally the the VM hardware is handling you know how to actually do the rest inside of the VM too but >> exactly yeah and so now um >> I see Exactly. That's basically it.

Uhhuh. >> Got it. Got it. Got it. Got it. So yeah, so this this prevents here if you want to switch also. >> Um >> okay space too. >> Okay. So yeah in the VM model now of course you still end up with >> right disk access right that still has to go through the kernel unless you partition >> through the kernel although now the kernel is part of this uh the kernel is inside the TE. >> Right. Right. When when you have a VM do you also allocate disk specifically to the VM? No you don't. Right. I mean what what you will do is attach like you know virtual device kind of you know passed through so the VM has a way to kind of request it but it's still like at the discretion of the hypervisor I think the hypervisor has to get like woken up um

>> each time uh uh that it is accessed certainly like it's able to the hypervisor can present like a virtualized disc there's no way to know it now what you will do is use full disk encryption right >> so the key to decrypt the disc is going to be managed only within the confidential VM >> so still kind of same thing as the memory like page by page. I can't, you know, tamper with anything. Um, and I can't see the contents of it, >> right? >> But I can definitely set it up where I learn which page of disk, which block of disk is being accessed, >> right? Although I'm sure you could, you know, if you have a small enough set of things in there, you just memory map the whole thing and so everything is kind of in the your allocated slab at CBM or

something. >> Yeah, that's right. little >> the hyper advisor still has um the ability to um you know lock pages and kind of you know set up the same thing. So like uh I guess what I would say is that with the kernel the like the average kernel like the standard Linux kernel is like way more actively involved in you know paging things whereas the standard hypervisors are way more like set and forget it. Um, but you know, a malicious hypervisor can still like pause pages and set them up where it has to bounce back to the hypervisor in order to access. So that you know, that kind of channel is still there.

>> I see. I see. I see. But it's just one one layer lower, which is more annoying to access for example. And you probably need to like do something where you root the processor and then when you update the BIOS, you have all sorts of nonsense. I see. Okay. >> Okay. >> And then essentially your point here is like everything is move mostly from here although there is some stuff here to confidential VMs for a lot of these reasons. Yeah, absolutely. Well, I mean, so the programming model for SGX used to be really difficult. First of all, there's a complicated interface because um >> uh what do you want to uh uh say here? Just this interface between processes and the OS is kind of a lot more involved.

>> Um and you have to define these like entry and exit points for the enclave. I guess even actually the um I spent a bunch of time doing SGX programming with Grammine. Grammine is this really cool framework that basically takes arbitrary compiled binary code and uh we can do it two ways either at the like interposing at the like the lib C level or it can just be at the system call level and it basically turns system calls in the process into uh O calls meaning calls out to the untrusted operating system. I see. So this is kind of like a like portability layer that

makes it easy to port um code to that. And so it was getting relatively easy. You could get like I don't know 90% of the way towards you know stuff just kind of porting over without thinking about it too hard. >> Some things would still be kind of difficult like shared memory between processes would it be supported with this? So like some things would be kind of difficult for kind of like a silly reason go um not using lib C made it where you would have to like >> trap the system call every time that a swap is there. So like go code would tend not to be very efficient with this whereas other ones would be.

>> Um so still kind of caveats and then on the other hand when you bring an entire VM um you everything kind of goes a whole much more easy >> right everything is purely containerized in this thing and you can change whatever you want right about it or whatever which >> yeah exactly. Mhm. >> Um when you have to bring a whole kernel, it also means that now the software developer has a much more, you know, uh kind of code challenge that they have to bring. If you bring a whole kernel, that's kind of a lot of attack surface. There's bugs in kernels a whole bunch. And now this turns into stuff that could be >> um you know, exploited. So if you call the TCB, the trusted compute base is everything that the developer downstream of the TE system brings in, then you know, you kind of have more

responsibility here with the VM. Um, >> right. So now there's a question about tooling and all this stuff like okay now you have to have a trusted kernel something that's reproducible and all this stuff. Okay. >> I think I think the model's pretty clear. I'm curious about you know maybe we can uh you know finish here first for a sec and then we can talk about the addestation part which I think uh I don't know unless you want to say anything else about the high level trust model. >> Let's see what else good to say here about the high level trust model. um maybe talk about like physical attacks just kind of briefly. So back to kind of like the philosophy and like um you know part of this.

>> So um the threat model that all of these are designed for is basically the software model. So it's very much like thinking in terms of these like software control layers. Um I think the gist of this like memory encryption is um kind of important. There's a paper that I like a lot called uh membuster which basically um describes how to use a memory interposer which is like you have your you know RAM chip >> right I don't know if this drawing is going to end up making any sense at all. Does that look like a RAM roughly RAM chip? I mean I'm assuming that this is you know tren this is like we've cut out >> a part but >> yeah and then this is a memory interposer

>> right? All right. And this is hooked up to like an oscilloscope or something kind of a display. I call this like a game genie for your uh you know your RAM like you get this as like some test equipment or something. And basically now even if you do this like a exit notify kind of thing. Um if you are like reading with this little like inserter like a copy of every you know the the me the data is still encrypted but the locations being fetched are visible. And I believe that here now it's actually also not just the page level but also the um I don't know the cache line specifically. So maybe even like more fine grain.

>> There's nothing at the system that prevents this from being you know visible. >> So uh essentially you have to be trusting the hosting provider not to be doing that. >> Sure. >> And I guess Intel can't tell whether they're doing that. So that's just having to trust the hosting provider. >> Yes. Um essentially any any like passive observational attack you're going to need to be trusted to hosting providers as far as I understand right because obviously like they could put you know between every wire and the PCB or something certainly they could put you know a digital oscilloscope or something. So, so RAM is a natural place, but you know, you can imagine all sorts of stuff uh happens if you um I don't know in these like fancier systems, you can imagine having, you know, systems where it's not just like a

processor with RAM, but you actually have more complicated things like thing handshakes between different pieces of hardware might like also be legible for some reason or another. >> Yeah, absolutely. >> Okay, >> close enough. And this was going to be kind of like high level and hopefully, you know, barely fits into there, but it's kind of a a short little exercise. I have some in mind. Maybe you can fill in others. So one of the appeals of especially the confidential virtual machine is just how really readily available you can get any code that already exists like legacy code not written with TEES in mind can at least be made to run in a confidential VM and therefore you automatically pick up some uh privacy benefits and integrity benefits and if

you use them together you can also do like you know distribution and failover like build you know decentralized network basically out of um uh any existing legacy code >> modular that you still have to like consider you know these things like side channel and um replay attacks which we'll get to later in terms of the disk and network and you know what kinds of things are >> uh are leaked to the untrusted environment about these you can basically play this game of like if you put in some legacy code that does some kind of thing you know what decentralized application do you get out of it and how well does that that go um >> I mean yeah even depending on how you like hash or something, you could do like weird private like Bitcoin stuff or something right?

>> I mean, like within a TE uh uh trust model type of thing, but >> um so one thing that you can do is have um you know, say you put in a say you have a roll up, so you have some sort of like, you know, fraud proof based rollup. >> Sure. >> Right. um when you put it through the T process and what you get out of it, you basically get this remote attestation evidence that a block that's produced by you know sequencer in this rollup is valid. So it's almost like you get a proactive proof. Um what would be the right name to call this? Would this be like a T validium if it's something like that?

>> Probably. I I actually don't >> I'll guess that it's like a >> I don't have the cool the cool name. >> That's not the cover here. >> It's very possible. >> Very well. Maybe. Okay. We'll discover in later episodes exactly how best to classify with this. But basically you can go from a retroactive proofs only to now you know a proactive uh you know proof of it. So you know justified for having you know finality in some way. I don't know if you saw this Ethereum magicians post kind of recently but Vitalik has a post really recently on how uh TEES can be part of a stage you know two or stage one rollup.

>> Okay. >> It's in a very nuanced way. Maybe I won't get into that. It's not that you just rely on TE for finality directly, but more like you could rely on a TE for um uh to you know if you have a security council based you know interrupt mechanism to like halt or apply a security upgrade to a rollup >> uh to count as stage one and you know the Ethereum you know framework for these the security council has to wait you know 30 days to for their you know action to take effect. Oh, but if you instead use a TE proof of bug, I'll just call this proof of bug. Sounds kind of silly. That's not the phrase used. So, we make that up here. T proof of bug.

You can use the TE proof of bug to justify the security council taking a fast intervention. >> Sure. >> Without waiting the whole 30 days. I mean the observations were replacing the like >> trust in the security council with a 30 days with just like trust in the whatever TE manufacturer or something. >> Yeah, exactly. In this limited way and only Yeah exactly. >> Uh and you can still call yourself stage one if you do this. That's kind of the >> Okay, cool. That's the definition expansion. I actually don't know what is Well, that's roughly it that's there. >> Cool. Cool. Cool. Um, okay.

>> You can do this with um, so say you put like a EVM smart contract >> VM. >> Okay. >> All right. You put this into a TE. Um, you basically automatically get a like uh some private smart contracts. >> Yes, exactly. >> Because now you can there's still more to do in terms of like defining the storage format and you know how you do with like I don't know things that are public like events or debug or trace logs that are there. Um but you can now have smart contracts that only operate on encrypted data and therefore >> um this is how it works in um like secret network and Oasis and there's several other FALA network also or um uh

TE based smart contracts and so you can take I mean not only do you take the VM and you get kind of a private smart contract VM but you can even take if you just take individual smart contracts like you take a unis swap style smart contract and now you have >> you know an encrypted unis swap style smart contract. >> You you get um >> depending on some other details, but like you can get like an MEV resistant swap contract for free >> cuz you can apply a rule that's like you only operate on the you know even if the pool balances at the end are are public after you execute it. You can do like the execution of the contract only after it's finalized.

So it kind of gives you the same thing as like um you know commit threshold encrypted memp pool and like only decrypt after the block is already finalized. >> I see. Okay. >> And you can get that by doing the you know uh doing the execution of the smart contracts directly on the you know encrypted data in that way. So you don't even have to publish the entirety of the contracts. So you can still infer some things about the trades that took place if the pool balances are public. >> Even the pool balances don't necessarily need to be public. You could even, you know, conceal or quantize the exact price for this. But anyway, you can take existing smart contract patterns and apply these, you know, smart contract patterns and get a kind of generic privacy uh upgrade for them.

>> Right. Right. Yeah. It's it's funny because it's it's actually kind of interesting, right? Like like you mentioned, right? There's some stuff that you do have to think about here. So, in the unis swap case, obviously, there's global information and >> uh we know that like >> you if you know the price before and after a trade, like totally screwed because you can always reconstruct the trade. But if you can quantize like you know remove a number of bits of information or if you require everything being processed in a batch and you only reveal the pre-contract pre-block state and postcontract postlock state >> you can definitely do some interesting >> uh stuff you know uh depending on how you do it. You could also have tra certain trades fail in certain cases. So if you have statistical so it's kind of interesting right like >> it's a really powerful tool for being

able to do you know stuff like this right where it's like look we're removing trust in security council like yeah I'm not going to trust random guy number five you know running a computer in like their basement uh more than I'm going to trust like Intel having like you know a correctly signed or attested to a thing um which seems like a perfectly reasonable way of like kind of feeling like Okay, there's a proof reduction technique. So, okay, very cool. Um, >> so, uh, this has all still been fairly like web 3, you know, centric, but it doesn't, um, you know, have to be that way at all. If you take like a PHP MySQL server, >> okay.

>> Right. That's certainly not written with like T in mind. >> Yes. >> Um, but no one can stop you from running it in confidential VM. >> Sure. uh especially if you also use like the T remote attestation or like an onchain uh manager of different you know nodes authorized to you know join a network and get a copy of something you can basically uh you know I would call this maybe a decentralized front end. >> Yeah. Yeah. Okay. >> Right. I can have basically a web server where all the rows in the MySQL are encrypted. So not even the admin can access you know raw data if they're not supposed to be the you know queries defined in the you know in the application and um you can then extend you know guarantees to end users that

they're actually interacting with the you know this particular code on the PHP server so you get like a high integrity >> and privacy guarantee out of it. >> Sure. Sure. Sure. Yeah. That makes sense. Cool. Okay. Okay. So like we have a good TE framework. I'm curious. You know, we've talked about sessations. Like what how do how do we guarant like what's the chain of you know uh what what do we call the there's like a fancy name for it. I always forget. >> Chain of trust. >> Chain of trust. Thank you. That's the cool name. >> Uh yeah. Like what's the chain of trust for these things? Like what do we assume? You know I we could pick a specific I assume it might be better to do so. A specific uh you know instance of a TE.

>> Yep. Yeah. So, I'm going to erase this real quick and I'm going to draw and I I find looking at the attestation like what's in the attestation as also a good checklist to talk about a couple of the other topics that are here. >> Right. Right. Right. >> Um, right. I guess like we have like the manufacturer of the devices here. Then somewhere in here is the host. Here is like the developer. Then there's also like the user. Right. Like four things that we had drawn earlier. >> What is Yeah. Yeah. Like the what things get shaken? you know, handshake meme between what uh different parties.

>> Yeah. Um normally I go and try to you know do at this with like looking at a specific um you know thing and try to explain all of the rows there. I can't you know give a good explanation for every one of the fields in the remote attestation but I select you know the good parts of this. So maybe I'll write these as I think of them and we go um >> good. >> Let me see which order I want to do these from. Um the first one is going to be you know certificate chain. Yeah certificate chain. >> Okay.

>> So this is going to be something that's like there's a leaf certificate that's unique per processor. >> Okay. >> It's like a platform certificate. There's intermediate certificate which is um you know changes sometimes uh but not like per processor and then there's the um like root public key. This is like Intel's long-term public key. So I mean the main thing is that the remote attestation is like altogether a c you know a certificate >> the whole thing is a certificate and like uh the >> uh platform certificate is like the next level intermediate certificate and then like the root of all of this is then a

public key from Intel that's like very you know hasn't changed long-term public key and that's kind of kept. So the first thing you do with a remote attestation to you know check it or you know interpret it. uh ultimately you're trying to make a decision whether to trust uh some you know you're about to send encrypted data to a public key that's mentioned in this certificate so you have to do all of these checks to decide whether that's you know worthwhile to do so the first thing is actually checking that yes this is signed by Intel >> and that involves checking this you know chain of certificates >> okay >> there's other things like expiry times and you know revocation lists that are there the revocation lists for these are mostly empty and um >> so but there the revocation lists for any any one of these steps or only for

the platform level only for the intermediate level. >> It could be for any of these. >> Okay. So yeah, revocation lists are like oh you know we found a essentially like impossible to patch bug or something. >> It allows Intel to say like we no longer think that you know this set of keys, you know, was valid, so you know, don't consider them any further. They have expiry times as well. Although um I tend to think that you don't necessarily need to um excuse the follow the expiry time and that it can be better not to have your application have to go do more >> checking. that's necessary, but you know, >> Yeah. Yeah.

>> And how often are these certificates rotated for the expiry? >> Um, that's a good question that I'm not sure exactly. >> Okay. Like on the order of days, months, weeks months >> say more than that. I would say weeks, but actually I'm just >> Okay. So, that's actually pretty often. I would have assumed that it was more on the order of months or years. But very interesting. >> Um, I think the most important one is like hash of program binary. really this should be decomposed into slightly more complicated steps but I'm okay just calling it that for you know this level of detail >> so this is kind of the most important thing this is like this is the code that was running that caused this attestation to be generated >> sure >> um this is now a compiled like program binary right it's not the highle source

code so this is exactly like the analogy of interacting with you know compiled bite code on a smart contract >> chain >> um you know that what you're interacting with is like defined by this hash of this binary code Um hopefully there's some highle source code that's supposed to be mapping to this idea compile to it. >> Um the job of actually checking that this source code matches this program binary. You're on your own. There's nothing that you know the processor Intel is doing to like help you with that. >> Um that's not really the role or you know their thing of this. So um reproducible builds comes up as like one of the more you know fundamental topics in you know building systems.

uh when I say reproducible build, you know, establish this correspondence, >> right? Like every source code always has a unique build that no matter what platform you build it on or whatever, it always has the same exact same source or excessive source code always but maps to exactly some >> bite code or in this case it will be like in assembly instructions >> and therefore the hash is equivalent. Uh and then actually how very dumb question but like normally this is like some binary loaded onto like a slab of memory. So essentially you're just literally hashing that big slab that just got loaded into you know program counter zero all the way to however long the program >> exactly and any of the initial data that's there. This is typically the

initial conditions. It doesn't go and like scan all of your memory when doing this. So this is like the initial state. So a lot of this is like you set up a program that you know in its initial state by induction you know it remains in this initial state that's like analysis about the program you know that you need to convince yourself of about and then the attestation you know >> uh uh guarantees what that initial state was so that's how you you know that reasoning together >> um it doesn't audit your code for you either right so just because here is so open source code right like you kind of view all of this kind of in the context of you know auditing as well Sure.

>> Um, sometimes for like silly reasons like and some good reasons like reproducible builds are hard to guarantee in all cases. >> Oh, interesting. >> Um, there's >> actually yeah what are some example I this is very dumb of me. I mean obviously like it could be the case but like you know in my head I think like ah LVM is doing some stuff you know it does some magic optimizations and like out comes like a nice little binary. Sure. But what like what what are standard ways in which like reversible builds fail? Sometimes there's like compiler options that basically like pick a layout dynamically and then it like can just essentially be based on I don't know race conditions or something pseudo random or time stamp or things that are like environmentally different in the you know environment that it's running.

>> I see. >> Usually there's options where you can go and tune you know turn those off if you're building especially if you're taking like random you know PHP legacy packages then like you it's hard to go trace down and you know fix all of the you know dependencies for the rest of those. If you view this as part of a whole auditing process like I need to convince people you know something about my code um sometimes you can make up for the lack of reproducibility in builds just by like you can audit program binaries you know as well. So you know it's not that reproducible build is the only way of getting confidence about what the compiled program binary does.

>> The goal is to get you know confidence about what this compiled program binary does. reproducible build is kind of like you know oneroach one of the most crucial you know things and you get as close to as it can things like time stamps that are you know injected into there. So a lot of times you do is like when you build the program you like kind of fix the system time stamp to 1970 or some you know fixed value >> um and it's like you have to it's like the one dependency you know fails to honor this and there's no easy way to go change it something like that. I see I see I see um >> okay >> there's even these things you know the reflections on trusting trust you know famous papers so like well who compiles your compiler so typically you have

trust anchors and you say well I will regard the you know rust compiler at this you know >> top of the month you know date major version or something as okay and I'm not going to make it you know my problem to go down all the things about how that was built and you know in the first place although arguably you should so um you know that's kind of >> this kind of this whole separate topic but you know the fact that the hat attestation includes at the program binary level kind of reminds you to go um you know check with that um there's um an application defined payload this is I think the fun part um so this is something that the

application that requests this attestation gets to specify >> and so this is somewhere where you know as an application developer or you you know you often make up something that you know will go here that makes sense. >> Sure. >> Uh a really common pattern is that you basically generate a private key in your program. Keep that safe. >> Um include the public key in this application payload. Now you generate this attestation once and it kind of like forwards your trust on you know it creates kind of now this trust in a public key. Sure. >> And now you can take signatures from this public key as having come from this. You don't have to check this remote attestation format all the time.

Um this pattern is especially used for you know web three things because um >> for you know kind of silly reasons. These are just certificates but like solidity is kind of a pain at just like you know string structure you know parsing. So that's kind of noisy. Uh and the signatures that are used in you know this ecosystem are like the wrong ECDSA curve. >> It's like B2B6 S1 versus K1. Exactly. So it's slow right. So it's like gas gas expensive. >> I see. Um, so if you want to do an onchain check of this, then you like do that once and forward it to a real ECDSA key that then you can check, you know, thereafter. Now, like maybe every block you want to output something from the enclave, you'll sign it with the public key that was, you know, added to the

chain of trust basically once. Oh, I see. Okay. So, so inside of the source code or slash whatever like we have I'm just making sure map. >> Yeah, you're on the right around it, >> right? we have the the private key which obviously like then results in some public key that we can then use to verify and the point is like the observation is look okay so long as nobody has access to this like private key other than ideally the like secure enclave which at some point is like you know dained to be good >> um >> we can then whatever we sign afterwards for that private key essentially can be assumed to have come from this you know good like so long as we've checked it once somebody has checked it once and the rest could simply just be verified

by like having that public key, you know, checking that everything has been signed with that or has been signed with the private key corresponds to the public key or whatever. >> Mhm. >> Okay. Okay. I think I think I roughly get it. Yeah. Because like essentially what you're saying is like look, check it once, we're all good. Everything after can be assumed to be good and then just only verify that signature. So there's like a weird initial condition setup time. No, thinking about this as like a >> source code running on a blockchain that is verifying this. There's like a single time setup when you first initialize the contract and then you check this thing along with like the map to the public key and then forever more you may simply just check this.

>> Yep. >> Okay. >> Absolutely. That's exactly right. And this is almost like a general purpose kind of approach. So like you can almost do this application you know maybe every application should do this. You do this in like a shim kind of way regardless of what particular app you do. And now now you can just the rest of the time think in terms of these public keys. You don't have to worry about the rest of Yeah. Yeah. Sure. >> Uhhuh. Um, this will be the last one that I go over in attestation and it's, you know, an interesting one. This will be a little more nuanced, but, you know, it's kind of good is, um, you have, uh, like CPU configuration. So, you have some metadata that describes which processor family you're using and what's the version of the BIOS that's there.

>> Okay. Sure. >> And now, what's interesting about this is um, you know, the the Intel chips are mostly software. like they're mostly microode. x86 is a virtual machine language. It's very, you know, separated from what actually happens there. >> So basically when bugs or vulnerabilities are found in the processor that undermine, you know, these isolation guarantees, um they go patch it and then they release the patch as downloadable content you can use to upgrade your processor. And so what they they publish these um TCB infos, >> okay, >> which is like uh they have one of these for every processor type.

>> So you go get like one for each processor type. It's like I don't know 40 odd, you know, processor families that you get in Intel and they publish a little like JSON file of TCP versions for each one of those. >> Okay. And in each JSON file is an array of different versions uh for different BIOSes. And then they also include you know like good or not basically like trusted or unsafe in you know bad. >> Okay interesting.

>> Uh and you can get these from an API that Intel at testation service publishes but they're signed so accountable to it. Uh yeah, exactly. Kind of a related Yeah, exactly. Or a related key, right? Something that traces all the way back up to >> fun little diagram that is that little thing, but yeah, absolutely. Goes to the same route for sure. >> Um and so what happens is sometimes you get a new signed TCB info in which some of the records change status from good to now no longer good. >> And that indicates that they're now, you know, disclosing that there's like a vulnerability associated with this outdated version of the BIOS. And hopefully by the time that happens, all of your cloud instances have upgraded.

Sure. >> Um >> Oh my. Yeah. Yeah. >> And what you also now have to do is um it's called a a TCB recovery. >> Uh okay. >> Meaning like it recovers the processor from in a bad state to now it has to you know go through this like a re that that's a time when like it redo the certific like platform certificate. >> Um and you know it can now have a CPU configuration that now matches a currently known as good status. Um, but you have to write off, you know, whatever you had had before. If your app was still running on an outdated version before, you need to know to do this. Um, and you have to basically, so part of validating that this attestation is appropriate before deciding to do it, you need to know that you're talking to something to the best of your current

knowledge is still considered, you know, in the good status. So you need to compare it against these reference values. >> Right. Right. So you need to just like every time you do this or this >> now go to the like Intel website, figure out exactly which whether you're running a bad version, right? figure out the root of trust is good and then come back and be like cool checks out or does not check out and we have other projects. >> Yeah, exactly. That's good. Um there's a project that I like a lot called the automata onchain PCCS. The PCCS is like platform collateral caching service. >> Oh my.

>> These are called collaterals things you compare against. I confusion but you know I call them TCB infos. It's I don't know. Um, so normally you go and fetch this from the Intel at testation service, but that's a little bit of like an unnecessary man-in-the-middle kind of vector. Like you wouldn't want Intel being able to, you know, or on the hook to be pressured into giving you a bad ver a wrong version of this to confuse you while showing everyone else, you know, the normal version. >> So naturally, put it on a blockchain. >> Put it on a blockchain. Use a bulletin board. It's um, if you know like the certificate authority system and the certificate transparency project, it's the exact same analogous thing there.

It's like you want to browsers enforce this like so to in order to prevent certificate authorities from man-in-the-middleing one targeted laptop with a certificate that no one else sees, >> browsers will not trust the certificate until they've like bounced it to like five other servers and like they know it's being like tracked. >> Oh, interesting. >> And so if you get man in the middle and you have a modern browser that supports certificate transparency, it was a big like Google campaign to get this, you know, widely adopted. So your browser now is defended against being singled out and no one, you know, getting in trouble for it. So like it's like the dash cam, you know, of having a uh trusting a set of certificates.

>> I didn't know that actually. Okay, that's cool. >> And so it's the exact analogous thing in browsers and TLS is for, you know, this and like the onchain record of these, you know, and Intel signs it. So it's not like they're trying to make it hard, but like why have to fetch their, you know, from an API when you can already have it documented in a bulletin board and referred to by smart contracts. So um >> uh yeah, that's that. Okay, very cool. And this is it. This is roughly all I mean this is pretty say. Okay, cool. Anything any last thoughts on addestations before we move on to specific examples?

>> Uh, no, I don't think so. Yeah, I'm good to go. >> Cool. >> All right. >> All right. Next up. >> Okay. >> All right. So I now want to go over uh this kind of uh architecture of applications as a um a TE co-processor for a blockchain and this gets into some of the like separation of duties about like what blockchains are good for how TE's require blockchains and you know kind of vice versa for the privacy >> I see >> uh kind of thing in a nutshell all cool applications of tees involve a light client in the TE. So you use the blockchain as your source of truth like

command, you know, manager. >> Um, you know, TE's don't have any um, uh, like redundancy, right? It's just a processor. The untrusted host can power off the machine. >> Yep. >> So, um, you are certainly going to need, um, multiple T nodes if you want to have any redundancy like failover ability for your application. Um, and then if you have multiple of those, you're going to have race conditions and an issue of like which one's active at a time. And so you need a bulletin board or, you know, consensus. Otherwise, just assume you have external. There's already blockchain, so use those.

>> Um, and you know, have that be like the uh coordinator for >> T's. So um basically a really common pattern for this application that addresses this is to have the T running in a like uh controlled mode where it follows instructions from a smart contract. >> So it inherits like the sequentiality like consistency guarantees censorship resistance guarantees from the blockchain >> and you know these are then like stateless worker nodes whatever that just do whatever the you know smart contract tells them to do.

So what you'll have is like >> in the in the HT co-processor program, it has a light client. The light client observes the smart contract >> and um I guess I wanted to set this up for like you know we're walking through I'm not even going to try to write pseudo code or anything but like imagine that the goal of this is going to be a sealed bid auction application. Okay. >> That also gives um say post hawk security for the trades. Like so anyone who didn't match um their bid is going to remain private. >> Mhm.

>> And I'm saying it kind of carefully this way just because um maybe the first way that you would do an an auction most of the way there is just a commit and reveal auction. That's like the you know classic solidity you know tutorial smart contract a sealed bid auction with hash commitments. >> Yep. Yep. um you know but then >> well I mean the first problem with sealed bid auctions with just commit reveal is like the guy can just not reveal you know and then you know over collateralize and stuff gets around it but it's kind of messy and even if you are okay whatever cryptoeconomically or do secret sharing or something so everyone has to reveal >> um if you reveal then everyone even the winner maybe the winner's inherent you have to make some onchain action that's going to be visible so winners say

that's okay but everyone else who didn't have their trade met >> also has to reveal >> also has to reveal And that's like unmet demand. So they still want to buy it like at that price. So it is like strategically you know even though the auction's over the unmet demand that's not you know there is still you know strategically relevant and Yeah. Exactly. >> Um >> yeah like doesn't it doesn't matter in the singleshot game but it definitely matters in like many shot game which you know is like real life. >> Yeah. Exactly. So um you know we we have chain smart contracts on the chain.

Don't know exactly what kind of visual language I want to draw here but whatever. There's a blockchain. >> Beautiful. >> Um what we would do is have so first of all there would be many of these nodes. Maybe I'll get to like uh going to say like other TEES here. We can talk a little bit about like what it looks like for them to, you know, join a new TE node to the network. These will be like ones that can be a backup for this one in case it goes down. >> Okay. >> Um, one node is going to do something where it generates a private key this to be what do we want to do? Going to update the boundary of this to include the private key.

>> Okay. So, this is essentially this is not a TE. This is a single TE. >> This is a single TE. Yeah. >> Okay. >> All right. TE compute node. Yeah, >> I don't know the TE co-processor node. >> Not using consistent terminology, but the concepts what matters here, right? Okay. So, the private keys here, >> public key would get stored on chain. >> Yep. >> Um the remote attestation would either be directly checked on chain or just it has to be considered part of the like constructor and code definition of the contract. >> Like you trust the contract cuz someone's audited it or you can audit it yourself. So look at some code on GitHub. You should also check that the attestation for the first compute node is also included. Doesn't necessarily have to be on chain, but checking it as

part of the audit surface. You know, it makes no sense to think of it like that. >> All right. So, this has the public key for which the private key, you know, just like we said like the attestation would include that public key. >> Yep. >> Um, so now that's the public key that if you encrypt messages to it, the TE and only this TE can access it. >> Yep. Um, and now if the user has a private bid, they would encrypt under the public key their bid and make a cipher text. >> Yep. >> Right. So now this is encrypted. So only the TE co-processor can access it. >> You would then post that cipher text on chain so it gets recorded in the smart contract.

>> Now this smart contract would also set the timing rules. Um so after like the deadline of the auction is collected or you know is reached all of the encrypted bids that are collected now have to be processed and treated as a unit. >> Mhm. >> Kind of skipping ahead like the implied kind of like trust model here. But like we don't want the host you don't wouldn't want users just to directly connect to this T as a service because that has to go through like the router and the network which is all controlled by the hypervisor. All right. >> So, the untrusted host could selectively, you know, drop packets or censor bids from >> be like, I know Andrew and, you know, I don't like that guy. Sorry. Just going to drop the bids. Sure. 100%. Okay.

>> But if they put it on chain, then you know, you either have to process everything that the light client says is, you know, you're supposed to on chain or nothing at all. >> Right. Right. Right. Cuz you're just going to take the head of the chain and you're going to be like, look, you know, you better process everything before that. And the head of the chain could be, you know, you're not going to give a stale head for some reason because the like client wouldn't accept that or something. Yep, that's exactly it. >> And then um you know when the result so it gets all the data it can compute on it because it has the private key. It has to compute on all of the bids because it's following what the light client says is the smart contract state. >> And um when it writes the result back uh

you know it can sign the result with yeah the same private key you can you know check it's now a signature coming from this. So I know it had to be generated by that program. I already have the definition of the program. So I know you know it did the correct of the auction. I see. Okay. Got it. Got it. So, yeah, this is the the cool part here is like essentially this guarantees that the number one is people aren't just rejecting your, you know, bids obviously because they get posted on the chain and people ideally don't, you know, you're assuming some honest majority thing already there, which is great. Uh, but then number two is, yeah, you never have to like the the only time you ever reveal a bid. Actually you don't technically I don't even think you need to reveal a bit if the chain is privacy

preserving but if it isn't then you just reveal is whoever won the auction >> right and then I guess in some sense potentially actually you don't even need to reveal the >> maybe everything is in the te and like there is no global state I have to reveal and uh >> yeah yeah exactly exactly so yeah exactly well you do you will have to reveal if you're using the blockchain for the actual transfer of value you'll have to reveal that but other than that I mean like look if it's offchain or whatever that's fine too or elsewhere. Very interesting. Okay. >> Absolutely. >> I see. >> Um now I I kind of claimed that part of the reason to have the smart contract.

Well, this is already pretty well motivated just by the censorship resistance. So, you know, maybe that's enough. But I mentioned like, okay, so this one node generates this private key at first. Um but we want redundancy. So, we want some way that if this node goes down, other ones can join. >> Um >> could also use the blockchain to basically have like an onboarding process. So, this node doesn't have the private key yet and all the bids are encrypted to this key. you don't want to make everyone like rebid or you don't want this guy to be able to crash and cause you know other people to go and get like a peak of it this way. >> So you could have this node do an attestation and >> but it too is cool >> you know some kind of onboarding maybe it generates its own private key for

receiving encrypted data and then other nodes that already have this private key encrypt this private key to the receiving public key of this you know other one. So >> you know this is enkpk prime if this is like priv key >> prime >> you know. Yep. >> Yeah. Then public key >> gets included on this onboarding you know message. this PK is this onboarding message that I meant and then you know the encryption under this new one of priv key the main one gets posted on chain and so now this node you know was able to join it and um doesn't matter how many of these nodes they are because the you know input output is defined by the smart contract like you have to

process exactly all of these >> so even if multiple of them do it it would be exactly the you know same >> right right should be exactly the same result at the end of the day and the smart contract would trust the result or Well, whoever whatever method we are using to transfer value should result >> and now you can have as many of these workers you know enough you it's kind of in any trust model then right like if even one of them is capable of running then you'll get a result you know posted to the chain eventually and the auction >> settles appropriately. >> Very interesting. Yeah, there's an implicit trust model here too happening right where it's like um this like chain of trust is like uh uh what do you call it like is um like transfers right so like you start

with this you then create a new trans trust the private key then gets transferred and so on and so forth so >> yeah transitivity kind of >> yeah transitivity thank you that was the term I was waiting for I could not >> okay cool okay okay I mean this is a pretty cool application right like it's quite difficult nobody really knows how to do this currently with even like standard zk proofs, right? I think there's some MPC approaches that actually are somewhat interesting. Um but but this is one case where like a te you know it's either I think the only ways that we kind of have good ideas of how to do this is like something ridiculous like use f which I guess is possible but quite difficult because these things are huge or use a te and like you know um the worst case whatever

someone leaks you know your historical bids or something but in the in the normal case it's fine right like really does not matter at all >> I'd love to be able to dig into this and do like a short table comparison like MPC and FHE for that. I'm going to have to go look for a slide on that to be able to do it. So maybe we could do that after um a pause. >> Yeah. Okay. All right. So um since you brought up ZK and uh FHE MPC others I want to try to describe how all of these can kind of and I went through this commit and reveal example. Just kind of want to draw like you know one way of viewing like how the these all fit together. Um, so we'll it'll still be kind of a similar

thing where we assume a blockchain is available for users to be able to put bids on >> and we have um an auctioneer whose party that's involved in carrying this out and we'll instantiate this auctioneer in a whole bunch of different ways like with ZK and NPC and kind of remark on the you know trust model that's involved with it. So um the first way of doing this of just commit and reveal is like the parties send their you know hash of their bids to the blockchain. you know, a time elapses, the auction's over. It's like deadline and um right then they, you know, reveal the bid and so for the losing bids, we cover the

strategic information that's there in this world commit and reveal like all of the bids get visible. >> Mhm. >> Um and visible to everyone. Um we did this paper like in 2015 now I think called um hawk which was basically how to improve on the commit reveal auction by adding zk as well >> and so the idea would be that you don't just rely on users to you know voluntarily whatever cryptoeconomic incentive to reveal their bid >> and forfeit it. So instead what they do is they commit the bid. There's for kind of a you know detail reason slight improvement in in in trust model to do it this way. You commit first, then there's a commit deadline. Then there's a phase when you send the encrypted bid.

>> Yep. >> And it's encrypted under the PK of the auctioneer. >> Yeah. >> You know, it contains the bid. And you also include some ZK proof that it's actually to the, you know, the auctioneer has their priv key. They put the public key on chain. So that's that of the auctioneer. >> And now when the auctioneer does these, it's kind of the same thing. all of the encryptions are valid. Only the auctioneer can decrypt them, but the auctioneer can't say, "Oh, I didn't get it." Or, "Oh, the encryption wasn't valid." Because like the smart contract checked the zero knowledge proof that it was valid. So then they do the decryption of all of the bids. They have to put the result, you know, of all of the bids there.

>> Uh, and a zero knowledge proof that the result is done correctly and covers, you know, all of the bids that's there. >> Um, and this is like the best you can do with just ZK. >> Oh, interesting. And the only thing that's bad about it is that the auctioneer still gets to see all of those residual bids. So now the auctioneer has that, you know, hidden alpha about all of the unmet demand, you know, implied by all of the bids that weren't matched. >> Um, and that I was really like really dissatisfying in 2015. I think the end of that paper is like, well, you could instantiate this with MPC or something else later >> or with tees, right? And so then that kind of like was the I don't know research direction that kind of kept going there. So I mean we could exactly

do that right the next thing is to um oh I mean in this little detail is just um input independence. So by having the commit phase and the encryption phase separately the auctioneer can't do the decryption before the you know no new commitments to bids are accepted. >> Oh I see I see I see that's why. Got it. Yes that makes sense. >> And now this is kind of the semi-reveal. You still need like a security deposit or something you forfeit if you don't put your encrypted bid there. Sure. So I mean that's how far you can push the zero knowledge proof. The problem with zero knowledge proofs is they have to be made by a prover who has all of the secret witness data. Um you can replace this auctioneer with now you know instead of it just being one party is the auctioneer you can instead make it

you know several parties that do some you know k of n secret sharing >> y >> um or mpc so they you know compute all of this. Um there's two notions that mean the same thing of like MPC plus snark. >> Mhm. >> You know is either you think people now mostly call this cos snarks. >> An earlier term for this was auditable MPC. >> Okay. I don't like the name cos snark for it because I think it makes it seem like it has more in common with snarks whereas I think it really has more in common with MPC >> trust modelwise because for privacy you're depending on this you know majority trust of this committee right

you have to trust this committee >> still you get the input independence guarantee if you do this and still you're not relying on them for integrity at all if you're producing these zero knowledge proofs but your privacy depends only on you know the trust in those parties if they all collude no one can you know check whether or not they all colluded they could just silent ly, you know, take this alpha and trade on it or, um, you know, collude, trade it away. So, um, you know, that's kind of what you're left with. Now, to add FHE to this, um, what FHE allows you to do is basically, um, you know, normally with this being MPC, there's like a lot of communication back and forth, right?

>> Stand in bad drawing for like, you know, lots of maybe another way of doing it. you know, it's a a complicated protocol, lots of rounds of interaction, you know, to do this kind of um thing. It's comput expensive, bandwidth expensive, gets worse with, you know, the larger number of people that there are. >> So, when you add FHE to this, um, what you do is now have untrusted FHE compute workers. >> Mhm. >> All right. And this can be anywhere because you don't have to trust it. It does the computation. >> Yep. And now um it just sends the you know encryption of the result and typically something like a ZKP that this was done correctly as well.

>> And now you still have these K ofN nodes. It's basically these K ofN nodes carry the decryption key. So is still a public key private key crypto system. There's a decryption key to get the encrypted you know to decrypt the result. So um you would have these committee of nodes secret share the decryption key. >> I see. I see. I see. >> And the key thing to stress here is that FHE didn't change the trust model. Like you're still relying on the committee trust and privacy. >> Yeah. >> Um what it did do is shift the computation workload elsewhere. So you did it as a performance improvement relative to MPC.

>> Mhm. >> I see. I see. I see. I see. I see. Okay. I consider this a terminology pet peeve because um you know MPC maybe is like rightly associated with this like well you have to trust this chaot of nodes threat model and that's not cryptography that's just like how do you select this committee of nodes what makes you think they're going to be you know honest even if there's no objective way to like prove that they you know didn't collude >> sure >> um and so you know if you just say co snark it's kind of hiding you know the co is the you know chaot assumption for privacy that's there >> not really >> and if you say f instead of mpc that doesn't you know quite cover because it's it's the it's doing the performance improvement but the trust model still

for privacy still comes down to the uh committee trust about the decryption key. >> I see. I see. >> And you can use all of this in conjunction with TE as well. So I mean I think a kind of best practice way to do this if you can afford the cost or the you know untrusted compute makes this a good deal is like these MPC nodes or coart nodes have them run in a TE as well for a backup. Um, in that way, not only would the MPC nodes have like they'd have to choose to collude and they'd also have to be exploiting, you know, whatever uh uh vulnerability in the cloud plus the hardware model to be able to um, you know, get away with it.

So then it's like the TE node is kind of, >> you know, >> helping the MPC nodes, you know, be honest by making it pretty inconvenient for them to be able to. >> So like any one individual >> casually just be tempted to do it differently. It's like those blocks make good neighbors kind of thing. >> Right. Right. Right. Right. Right. Yeah. And in that case like the trusted FPG compute part is fine. I mean it doesn't really give you that much here. Okay. I see. The question is so that the yeah the best possible thing is combine everything like throw it all into like one big pile and like stir the pile.

>> But >> you know I guess there's some high stakes auctions. it might be like quite quite good to do that. But like most of the properties that you have out of here um which I think are interesting and you know one of the difficult parts of auctions is the fact that you have to commit to the thing which means you have to have the money to be able to actually do the payment. >> Um and that reveals some amount of information about the underlying thing and in in a public blockchain on a private one. Um yeah okay I see I do I mean it's a good application and in general right you can think of like adding te the sauce to kind of improve security guarantees by having this like um you know now it's extreme not only is it you know inconvenient but it's

extremely inconvenient for even one party to kind of add this decryption thing and so naturally the k you know would have to have like you said k people exploiting each of these things >> uh you know three layers in to be able to to get this to work. Okay. Yeah. Yeah. Makes sense. >> This auction example has this quality of um being based on like uh multi-party information or um global private state is kind of the name for this. So there's no one party whose view includes all the information necessary to close the auction. >> So if there there's no like one natural party who can just do the result locally and prove something about it.

um lots of applications you know don't have this quality and then you don't need to go to MPC or TEES for you know processing on it like FHE is often used in this like outsourcing example where there's a data owner >> and it's their data they want computation on they just don't want to do the computation so you outsource it but the guy who provided the data is also the one who needs the data so just have them have the decryption key for themselves >> sure >> but it doesn't make sense in an auction just you know and then lots of other examples I mean arguably most things of interest where there's like multi people involved. That's why a blockchain might be necessary or that's why it's kind of interesting. Then if you need this shared private state, you really have to turn to, you know, committee trust andor

trust in the you know hardware and cloud operating kind of environment. One or the other or both of those. Um but mainly it's not that there's like um uh you know otherwise cryptography is not going to bail you out of it. You have to accept one of those. >> Okay. Very very cool. Cool. I guess there's one other I mean the only other thing that I wouldn't you know mention there and actually I'm not sure how I'm going to be able to draw you know a thing for this but there's the idea of um cryptographic obfiscation or IO indistinguishability obfiscation. This is like to FHE what FHE is to like ZK and the rest of you know cryptography in terms of being you know more expensive.

Uh so this is considered like not practical you know right now. Um and I guess I won't go into trying to you know describe the rest. You should get someone to talk about offiscation though for one of your um modules. You would do a similar kind of thing though. It's interesting because like this also doesn't give you like um I don't know one timeness. You can't like it gives you an obfiscated circuit that you can run but it can like embed a private key in it and you can only run the function that it was generated for. >> But still there's like problems. One is like this needs a trusted setup like who's going to generate this circuit and put the things in there >> and nothing stops you from running that function multiple times with different inputs. So you would actually still need to pack the circuit you put in here like

you would have to pack your light client in it and still be relying on an external blockchain for the statefulness. >> This gives you like a pure function. >> A pure function and you can't compel someone with that function, you know, to run it multiple times. >> I see. I see. I see. I see. >> Okay. Yeah. >> Very cool. Yeah, we should probably get someone to talk about IO. I don't know if we have somebody. I don't think so. So, that'd be fun. >> All right. And then last but not least, you know, we've talked about all like positive ends of this. Like I think it's time to talk about the the pitfalls. >> Yeah, absolutely. Um yeah, I'll race. >> I guess we talked a little bit about some of it.

>> Yeah, we talked quite a bunch. We talked um we talked to my satisfaction about side channels actually. >> Um perfect. >> The more interesting thing I want to talk about, it's not just um well, I mean it is a pitfall. It's kind of just something that you have to deal with is um how to do upgrades without um um getting stuck. And actually um I don't have a I don't have a slide immediately for this. So I'm not sure actually what we're going to draw for this. Uh I can certainly describe the problem. Maybe I will just talk about this for a bit and then come up with um what to draw. So um >> uh yeah, let me think about I think I do know what I want to draw for this. Um so say we are in um do I want to motivate

this with like an auction example? It's kind of tricky because like an auction sort of happens and has a natural conclusion. >> I mean if I say this is like a darkpool like maybe like a DeFi example or something. >> Mhm. Okay. So I want to set up a setting where I have like persistent state where I'm going to have long lived state and I can't just like say oh like game's over, everyone's going to like put their data back in again. I really need it to persist for a long time. >> Okay. Um, so I'll say this is like a dark pool withstanding orders and like I can't just cancel all of the orders. I really need to like keep the orders preserved. Um, you know, to be able to do that.

>> Um, uh, you know what the TE can give you and what we just drew with that co-processor example is like I have this remote attestation that covers the hash of the program code. Yep. >> And I encrypt my data so that exactly that and only that program can access it. um drawing like program you know version one here. Um immutability is like what you get then by default there. Um but in the same thing that happens with smart contracts like no one likes immutable smart contracts right like EVM smart contracts are immutable like except for one but all the rest of them are immutable >> and you but then no one likes that right

because you want the ability to upgrade contracts and so you build like a proxy layer where you like build in you know on top of the immutable substrate you build on like a migration method that allows like the you know >> the pointer to like point to somewhere else before you're able to like >> Exactly. So you like build in an upgrade mechanism. So the same h pattern happens with TE is like you don't want to be pinning yourself into like only being able to run a single version because then that's too rigid. You want to add a feature or be able to respond to a vulnerability or something in that. So what you typically then build is some you know migration mechanism. >> Mhm.

>> And if we had that idea that it's a co-processor so there's a smart contract here that every TE node if it wants to join the network it has to check in and pass this attestation challenge. It's the smart contract that's in control of the like coordination layer like control plane messages. It's like the orchestrator of these TE nodes that are running. So it can simply have in the same way you would have like you know >> uh you know governor bravo contract or something like a DAO vote to approve whether there's an upgrade allowed or not. You can do the same thing. This can say now it's not just a particular version but like the current version and that can be updated by you know a Dow vote. So this would be like this stores v_sub_1 you know maybe this also stores v2 and so this node before deciding to

send guess I'm now kind of like referring to that you know step from the previous one like when we encrypted the secret key to the new private key of this new TE that's running the version two of the program and now it wants to >> um receive a copy of the secret key encrypted to itself. This one has to decide whether to do that based on the attestation that shows up here. Use the smart contract to determine whether this version is allowed or not. >> Yep. >> Um, now the problem is that you still now introduce like in the same problem with smart contracts. If you just have like, you know, only owner, like whoever's the owner of the contract is some EOA jerk who can then just add a new, you know, method to it or add a new allowed program, you know, that's not

great. That's just still like a central party. Um, if you don't use the smart contract one at all, you just have like code signing or something, then it's maybe even worse because someone could make a signature to authorize it, but not even show it. >> Exactly. Just like sneakily do it and output all of the bids and no one would necessarily know. So, at least you should like post, you know, the up at least you should enforce in the structure having to post the update on chain. And even then, you probably want like a due process kind of thing where like it's got to be there for some notice period so maybe users can like retract their private data and keep it from being able to be included.

>> Um all of that's a lot of extra hassle. It's not extra hassle that's like put there because TE's made it difficult to put it there. >> Uh which you can tell because it's the exact same you know problem inside of constraints that you get in smart contracts and the hassle of you know live deployment of smart contracts like you have to you know confront all of this. So it's in no way unique to TEES. I mean it's in some senses it's also the same problem with like anytime you do an upgrade for anything right where like the upgrade path is deterministic you know and what's cool is like when you're running a node in some of the upgrade path is social right like surely everybody just runs the same piece of code but we trust the fact that like most people are honest to like you know

do the due process of moving up to a new version of the code and then they just run the new piece version of the code and like consensus all works nicely assuming that you know everything is good >> here we have like an intermediate layer because like you know the T has a notion of like social consensus. It's like look my social consensus comes from like is derived from a smart contract or something right and there's like an accessibility like piece in the middle. >> So my my grad student Nura is working on this paper about um like rage quits for this upgrade mechanism which is uh she presented it at like an Astria day talk.

So, uh, there's a talk already about it kind of already up, but the basic gist of it is, um, like you said, like you can rely on the social consensus, but I like this idea of, um, you know, avoiding the tyranny of the majority or something like I don't want to, and this is consistent with how L2s and stuff work like the rage quit mechanism is how even if the majority of the DAO votes to like cancel all of your coins, right? >> You're allowed to withdraw your, you know, the mechanism set such that you can like uncooperatively withdraw your coins, you know, before the upgrade takes place. You get to like take your coins and leave. So, you know, same kind of notion, but now with your private data and not just your coins, >> right?

>> Um, but you know, it's the same thing. So, this is drawing attention to a part that's not, you know, it's part of the whole tea world because T's bring in this kind of immutability on top of dealing with private data. >> And, you know, that introduces a bunch of like, you know, devel I don't want to say to someone, oh, till your T's you have to like deal with this whole thing kind of right in the way, but again, same thing with smart contracts like that. This all stuff doesn't show up in the like learn solidity tutorial, but it's, you know, part of understanding how the systems, >> you know, work in practice. So, >> uh, yeah, >> that's right.

>> Well, cool. And then I guess I don't know if you want to talk a little bit about replay attacks or >> Yeah, sure. Absolutely. And I think we can do it good. So, we talked about side channels. I mean, these are all under pitfalls. I call them pitfalls cuz it's not like something that you need to invent something around. It's like we know what to do to prevent them, but if you just kind of port code without thinking about it much, these are like the first things that you're likely to run into. We covered side channels really well. Upgrades I like talking about. That went really quick, but I think it was, you know, pretty clear. So, let me see if I can make replay attacks, um, you know, make much sense. Um, and actually, it goes back pretty easily. I think I'll I'll keep this

pretty simple and just draw, um, you know, back to what we had before. So, this is the TE. You also have the untrusted host >> on the outside >> and we covered things like the you know encrypted RAM is here >> network I think we kind of implicitly talked about forgetting what thing but like you know uh which is relevant for privacy and stuff too you know if you're going to just have TE nodes connect to each other like the IP address has to be you know visible to the you know >> yeah exactly and um you know disk was there you would have like an encrypted disc typically where the key for the encrypted disc here. Um, but nothing about this ensures that like the disc

doesn't get replayed. >> So if you just use some code that like is your PHP MySQL not intended for TES and you try to get it to here, it'll work. And if you don't, you know, you run it in ordinary mode, everything's going to look like it's working. But the pitfall that you have is that someone, you know, the the hypervisor even could, you know, rewind the disc to an earlier state. >> Yes. And typically the way that the disk encryption works is like it's authenticated encryption. So each um you know block of the disc is encrypted with a tag that depends on the location of the block.

>> So you can't like copy a block from one place and like replay it you know in another block >> but you could take the whole >> you could take a whole block a previous version of a whole block and replay it >> and that's like out of the threat model of the way that the like encrypted discs are going. And pretty much the only way around this is to have like a Merkel tree. So like if you if you have like a Merkel tree um over all the blocks of the disk and like maintain that then you have this like freshness tag kind of availability where your t can know that it's getting the you know write the current version >> of the block each time >> and you know maybe a decent design thing is just don't use the disk like where you had the disk instead go to the

blockchain for all of that use like a blockchain as your external you know consistency log >> um you know that can be kind of inconvenient or just like within the tea keep Merkel tree over all the But now that's not something that like the disk kind of does by default. >> Um and whether this is detrimental to the application or not just you know depends on the details of the application. Um and you know I I kind of show this for disk here but um I guess other sometimes you have like an external database and then even if you use you know same thing even if you use the T for like the encrypted rows of the database that's fine but the database state if that's just external you know on its own it's not going to bring you know these roll back uh uh defenses

against that. Um, >> yeah, the TLDR is like it's not clear if you have the if you have a fresh state or if you have a stale state and that stale state could always, you know, like there's no easy way for you to distinguish this at least not without, for example, a blockchain or something of like this because you have no notion of real external time with respect to a piece of data here right? >> Yeah. Exactly. >> Yeah. Yeah. Yeah. I mean, it's also an interesting thing. I mean, we get pretty meta about this, right? You could imagine that like the network chip itself has like a TE, right? And then you know that that thing you know essentially guarantees that like network inputs and outputs are I mean network may be a bad one but you know uh a database might be like in some stick

that itself has a TE which is trusted. >> Yeah. Absolutely. Or you know you might build your database out of a >> out of a TE for each node as well. Yeah. Sure. >> Right. or so all sorts of like you know it's it's kind of interesting like all these bits and pieces can be fit together and blown apart and all this stuff and you could have intermediate TE's and like you know >> like the camera case right you know there's like you were just mentioning this >> yeah the Sony camera has like Sony cameras are a hardware T like the new Sony cameras have a T mode where they will output along with like in the metadata with the camera they include a whole signature chain up to Sony >> right >> it's even more than that it has also time stamps like the time that it was

done I don't know how it knows the time but GPS >> something like that. Okay. And altogether this is meant to be in the kind of tamperresistant you know thing. Still have to trust the manufacturer not to fake it. They also include something like a range image. I was just reading their like docs you know on this. So there's like a range image like depth image. >> Oh really? >> Sensor or stereo processed kind of thing gets included in the metadata of the normal image. So you get some kind of like extra you know stuff. All of which is covered you know as part of the signed you know data for all of that. This is in some like closed beta where only journalists are allowed to have access to it and it'll roll.

>> Yeah. You have to have like a server or something inside of the >> like your or has to have a server which they then use to like assign the cameras or something. I remember trying to read through it. Yeah. Yeah. No, it's I mean it's it's cool stuff, right? It's like >> um you know very quickly, right? It's like I think very early on uh we were also just talking about this, you know, during one of the breaks is you know TE's were used as like kind of quote unquote only bad. I'm going to go on a limb and just say that of like DRM, right? And like DRM like prevents you from using like >> anti-consumer tech, anti-general purpose computing tech.

>> Exactly. And it's like now it's kind of fun because you know TE's have become this much more general platform. And I was like actually like no no no you can use exactly the same technology to like be able to run whatever you want on somebody else's you know like Amazon servers like trusting Amazon for example right so it's kind of an interesting you know yeah it's a pivot that's like along the kind of you know basic principle of like use you know cons apply constraints on like the powerful and you know to kind of like allow the so you don't want to impose DRM on end users and deprive them of general purpose computing on their laptops yeah was the original kind of you know use cases for you know SGX but now much more the other way use it to like you know constrain the already

powerful so constrain the you know cloud providers for that so uh yeah I think one of the reasons why like went through like a very you know negative hated phase was a lot because the you know the the first use of it was you know this kind of thing people rightfully you know were against >> even the trust model aside just the use of that is you know you know antisocial anti-consumer that's bad um but now that it's mostly deployed in you know clouds and for servers it's like a whole new purpose and now you know so I think that's really Right. I guess another thing kind of like on this trend I didn't meant to earlier mention the phrase like confidential compute but when I drew that thing that's like you know the T and the cloud and all together that's you know you view as

kind of one you know two component unit um you just call it confidential compute when it's like the T hardware and the kind of cloud you know uh service that they you know provide along with that and that trend is really increasing. So yeah, it's not farfetched to, you know, expect that like most hardware like routers, middleware, other kind of things seem likely to have this kind of, you know, approach to them by default. Um, so yeah, it's not even really contrarian anymore. It's like a a increasing direction that's pretty broadly already and only increasing so supported and uh, right?

>> Yeah, clouds and processors and other hardware increasingly. >> Cool. Any any last thoughts to the constructions? Cuz if not, I think uh, >> no, I don't think so. This was uh, went great. Yeah. >> Yeah. Thank you, Andrew. so so much. Uh, and thank you all for listening to a lovely, you know, CK season 3 and stay tuned for more. [Music]