Everything Is a TEE

This is gonna be my talk with the most props. So, you know, this sets I've basically decided that I'm willing to trust all of the chip manufacturers, and instead I've decided that the chip manufacturers are cool, but I'm going to make my problem software people that aren't doing their part, assuming that hardware people are doing their part. And this is inspired by realizing that there are a ton of, processors across all, like, processor form factors from microcontrollers to full-on GPUs and all of the things in between, like application processors, that actually all support some form of, TEE.

So, you know, It's, like, provided by hardware. Whether or not it's actually secure against hardware attackers, I'm gonna say is not my problem. They're at least secure against, software attackers and in many cases are secure against hardware attackers too. If you know the story of SGX, it's like they downgraded their security. They initially in the early designs were secure against physical attacks as well, and then they sort of downgraded in and erased to the bottom to keep up with performance and issue hardware security. So I, was looking forward to finding hardware manufacturers that had TEEs in them, especially ones that could go back to this world where we don't just have to trust the clouds, but instead, can just trust the hardware manufacturer and these are safe to run even in a physically adversarial environment.

So I've been on the hunt for different microcontrollers and application processors that, provide this, and so I'll show you some of them. I mean, first of all, just to comment, I think it's a really interesting time. Maybe you've seen me pitch this before, but there's a bunch of private inference providers that have the NVIDIA GPUs in confidential compute mode. Chutes is one of the ones that's the most flexible. I find this super interesting. One of the things that I've decided to, you know, push out a little bit is to try to find, you know, even though we have this confidential compute mode, the people offering these private inference things are like smart contracts before there was a smart contract auditing culture.

Like, they have huge gaps in their remote attestation systems. Like, they leave off critical environment parameters that aren't covered by what's attested, and just no one's looking at these yet. It's sort of a blind spot. So this is a little snippet from a dashboard called Awesome Private Inference, which is a misuse of the Awesome meme format. But it's a dashboard that every time NEAR pushes an update to their, private inference software, which gets published without an audit and without any disclosure period, the, same way of, like, someone updating a smart contract every day with new contract code because it's the owner of the smart contract before audits. Well, I have a little swarm that goes and, you know, tries to at least sound an alarm if, like, too much has changed for it to just say, "Oh, just a comment or something trivial has changed."

So this is not a very great job of a swarm, but it's something that, people should join. The other, like, interesting stories here are just, like, we found Phala launching their first version with the dev SSH portal back in. Like, which no one was calling them out on until I tried to call them out on it. And it's like it technically is in a TEE, just it also has an SSH backdoor, which obviously completely undermines the whole point of the TEE. But it's not wrong. It is still in a TEE, just, you know, that's not enough. And so I'm interested in, you know, popularizing this to close that gap. The other thing that I've got is this TEE interop bridge.

So this is a heterogeneous network of smart contract capable TEEs. So you may know that I was interested in Oasis Network and Secret Network before. These are co-processors that process private smart contracts, mostly associated with SGX, and then it used to be decentralized. Then they realized, oh, these are not designed to be secure against physical attacks, so now they only run in a somewhat centralized proof of cloud mode. Well, now we actually can have a heterogeneous network of co-processors, including GitHub actions, the dstack TEEs like you'd expect, but also Pixel phones. So this is a Pixel phone. The, Pixel phones have really good attestation. Like, they have a root of trust that's Google's. You have to flash the OS because the default OS only gives you an attestation mode with a thing called App Attest, which is, like, censorable.

Like, it's up to the discretion of the Google Store to let your app go through or not. So probably not suitable for running a smart contract co-processor. But if you're willing to flash Graphene on it, then you actually get really good remote attestation. The other device that I have is the Silicon Labs, microcontroller. So it doesn't have a memory manager. It's, like, really weak. But you can run C programs on it. And so I have a demo of this. Well, let me show you what I have a demo of. So if you can see this, I had these unplugged. I clicked the buttons. They weren't there. I've plugged them both in. So this is going to be running an attestation check on my Pixel phone running a modified Graphene OS that's modified to have a specific app baked in.

And so I am now getting an attestation from the underlying hardware. No Google App Play Store is involved at all. But I get an attestation that covers the OS, including my modified little APK there that runs. I'm now gonna ask for a remote attestation from this little Silicon Labs chip.

I don't know why that's not taking so long. The rest of my demo is Pixel based, so that'll be okay. All right. Well, you'll have to take my word for this guy. Among all of the other hardware vendors of this choice, the thing that's most interesting about this one is that you don't need any NDA with the company to be able to use the entire attestation chain. Most of the other processors in this class, that's not the case. They have a TEE system, but you have to make a business deal with the vendor in order to be able to get the intermediate certificates that make that work. So this Silicon Labs one is the one that's most friendly to that.

You know, excuse the demo. This won't, you know, show a whole ton maybe, but it is actually doing a Smart contract co-processing demo. So this is posting a transaction with some payload on the blockchain on, like, the base Sepolia chain, and now it is talking to the little custom kernel of a Graphene OS on this Pixel phone. And it is then going to go through some process of executing some payload and then signing it and then probably making that signature go back on chain. I guess the state that it's stuck at Well, I'm not sure what it's stuck on. Let me just proceed and see if the demo Hail Mary is gonna work well. So this one is a sealed bid auction.

You know that that's, like, my, favorite, form of kind of basic demo. So if this demo works, okay, it's posted a sealed bid auction description to the Sepolia base blockchain. What I can do is then place encrypted bids. So I have, like, three bids here. And now I'm going to invite this Pixel phone to act like the secret network validator node. Only this Pixel or, you know, rather any Pixel running exactly this fork of the operating system with the little executor is eligible to, do the decryption. Any other device, on it would be able to, like, share its key with these as long as, like, one of the keys of this heterogeneous class of networks where just this Pixel phone is, like, one of the eligible participants can share the key with each other, and then this actually carries out the node execution.

This is technically, like, not even on Wi-Fi because I just, like, flashed it. Didn't set up Wi-Fi. So it's like the phone is, like, the secure co-processor. My laptop is controlling it, and it's, like, passing the ciphertext from the blockchain back to it. So you should think of this Pixel phone as running a modified Graphene OS that's effectively being, like, a secret network co-processor node and, that's what's being demoed there. And then my last demo, because I'm just showing all of these, you know, props, is, a TEE camera. So this is a off-the-shelf TEE camera you can get from B&H Photo for about three hundred and fifty dollars. I mean, and it's just an ordinary camera by the Axis security camera.

They also make law enforcement body cams, so they're like, you know, a full-on surveillance cameras company. But you can buy this little portable-ish camera, and it's got a TPM and a, signing module in it. And let me go to the demo where we should be able to look at its signed data format. Yeah, this is like the live preview of it.

Yeah, just, like, prop it up so I can wave at it for a bit. Now when it's in preview mode, you aren't getting anything. But if I capture, I'll do capturing just five seconds of it.

So I'll go wave at the camera. I believe it has audio as well, but I, don't know whether I'm capturing the audio.

All right, I'm gonna, like, thumb sign a private key or something to it. Okay, and if I play this, it should be scrubbing through so you can see that it's playing this little recorded thing. And what you're seeing is the yellow frames are like the key frames. Those are you know, full data. The, you know, blank dark gray frames are like the little incremental frames, just deltas. And the yellow frames are the cool thing. They're basically signature frames that are injected into the H264 stream as little signature packets. And the rest of what's shown here is the attestation chain. So, the root of the, key chain is the across all of these devices, the, like, long-term public key of the Axis company.

The intermediate certificate is each device. Each leaf certificate is this particular instance of the device rather than, like, the device family. And all of these are checkable by a smart contract because it's just a chain of certificates and the root of the trust is the public key for Axis, which never changes across all of their, you know, device families. And I don't have to register with them or anything. I can buy these and I can make zero zero-knowledge proofs of this. So I could say this is coming from some Axis camera without having to say exactly which. You would almost to use this have to think in terms of, like, can I have a trusted deployment initially just because it doesn't prove that I haven't put, like, a fake, like, you know, screen in front of the camera or do, like, an analog injection of it.

As a whole, it's not a whole tamper-proof seal, but you should view this as, like, a component of a tamper-proof system. It would be cool to have a device like this, like, in the shipping crate with my RTX 6000 Pros so that, like, the little camera could be installed at the NVIDIA factory and keep an eye on a battery pack while these 6000 Pros are being transferred to my co-location center where I may be willing to trust it. What I don't want is to have my RTX 6000 Pros be, like, sent off to a Mossad site where they are, like, hacked up and I can't tell what's happened when they've been, like, in transit. So having a signed video camera constantly emitting a signed video stream would be one way of defending against that kind of attack.

So, well, I just wanted to make you aware of all of the hardware TEEs that are available and you could go buy and think about how you'd integrate them.

So this will, like, take things in a slightly different direction, but I guess what, like, your, you're one of your core theses here is basically that there's, like, a lot more different things are TEEs than we think and they're actually super abundant. So I always get this feeling that with, like, projects in the blockchain space and, I mean, like TEE space that are doing TEE things, it almost feels default for people to put them in data centers. And to me, that, like, feels justified when you want to have a one one-of-two two trust model between the TEE and the data center. But in every other context, it feels, like, needlessly centralizing. So why does this imply that people really should, like, cut it out with the data centers a lot of the time and just put stuff onto pixels instead?

Like, what, what would you recommend?

All right. Let me see if I can unpack this. Like, I think the move to data I mean, there's kind of a couple of axes. Obviously, moving something to a data center makes it, you know, their problem. You get economies of scale. It also addresses the really significant problem where if the only TEE that you have is SGX and TDX, then, like, you can't just say anyone can join like Secret Network used to because you could join from a side channels lab, and then they don't really mount any defense against a side channels lab. So putting it in a data center also doesn't on its own solve that problem, but it does allow you to say, well, the data center that takes care of the racking but is already like, you know, a common carrier basically.

I don't think data centers are in the business of doing memory tapping of all of their tenants, and they've got a reputation about not doing it. So it's nice for them to be able to, you know, insert themselves into the trust anchor set rather than have every tenant in there have to somehow be on the hook for being trusted for the entire thing. So it's, a compromise, but it kind of sucks, but they already are in a business of having like long-term processes for physical security. It's the guy with a Glock, meaning you're trusting their security processes and intrusion detection and, you know, long-built reputation for that matters. So relying on data centers is a crutch.

If we had TEEs that we thought would be part of a tamper-proof system that would eject secrets if anyone seemed to get close and jostle them as like a precursor to a decapping or microscope kind of attack, then you would ideally not have to rely on data centers. You would instead just be relying on manufacturing time or deployment time setup, but not on ongoing operation like you'd have to in data centers. So I think that this data center world is like a transitional phase, and it's a pretty reasonable goal to try to end up to where we're trusting chip manufacturing as a setup process, but not ongoing operation. I think the best place that we are likely to end I mean, I hope that we end up in the trustless TEE world where we have a whole process for being able to tell that the devices that are open source spec and are built according to spec and we can check all of that.

That's what we should be aiming towards. I think we're right now in this provisional time where we have, basically just data center trust is the only thing that anyone's using. In between, I hope we get to this point where we have basically tamper-proof boxes that are set up, but then you don't have to continue to rely on a particular centralized vendor for their ongoing operation. I think that was long-winded. Do you feel like that addressed the question? Do you That sounds like the answer basically just is like you want the one of two trust model, right? Yeah. Yeah, that's fair.

I think one thing that's interesting, if we do end up in a world where you leave the data center, at least with some of the machines, or even, even in the data center, but especially outside of it becomes much harder to reason about these the security assumptions of these heterogeneous systems. Like if you're spinning up many interactions and you're interacting with different like privacy systems, you have to sort of reason about the lowest common denominator of your security assumptions and all of how all those things interact with each other. And I wonder if like simplicity doesn't also have value there. I'm not saying the data center has to be that, but, it feels like a very complex world to navigate this heterogeneous trust environment.

Yeah, it's a great point. I mean, we should be seeking simplicity of these. I mean, a simple rule would just to say, "Here's a network of just pixels six A, and that's it." I mean, that would be simpler. I think that I kind of expect to be in an entropy increasing mode. Like, yeah, that's the message of this. Hey, there's actually lots of TEEs everywhere. To actually build systems and conventions and networks on that, I think is pretty complicated, and it is a least common denominator. That little thing that I depicted of, oh, I've got this heterogeneous network, bring all of these different TEEs. That is not a system design recommendation. That's meant to be, you know, provocative because, yeah, that's kind of too complicated in your security.

That is the weakest one that is allowed on the network. So I kind of expect to be in a more expanding mode for a little bit. Like, we should be aware out of all of these, divide and conquer. There's a lot of room to go, you know, look at how TEEs might apply, and then probably end up trying to converge on a fewer number that are then easier to do. So yeah, great spotting. This is suggesting a lot of complexity. That's my explanation why. Yeah, yeah, Ryan.

So we have the ideal of privacy based on the security of, and trust of math, right? And that ideal, the struggle there is like finding utility and giving resources to the average builder and creator to be able to do create privacy resources based on highly complicated things, right? So that ideal basically lives in crypto land. Now we have this marriage of AI and hardware basically creating the perfect ceremony to marry cryptography, crypto, and, AI together. My question is, given this ideal of privacy based on math and the compromise that we have to compromise with TEEs and trusting vendors and whatnot, do you see, with the opportunity of seeing TEEs living in other devices that aren't just chips, do you see You just said that, well, the network is the lowest common denominator.

It's not the ideal. But I see that as an opportunity if we can figure out how to build these decentralized systems, based on these everyday type of objects that have TEE capabilities. Do you think that compounding effect of a network of ordinary devices Gets us back to that same hope or ideal or promise that we have in trusting math. Like, can we trust a network of everyday objects, everyday people attesting to privacy and have that same ideal and trust that we have in a contract that's represented by math?

Yeah, that's a fantastic question. I mean, so I, view that there are three relevant anchors of trust. There is the mathematics kind, the pure cryptography. Although even the sealed bid auction you can't do with zero-knowledge proofs alone. You can't do with fully homomorphic encryption alone either. You can do with multi-party computation, but that's actually just crypto washing trust in how you select the group of people, because you've then got to trust whoever are the auctioneer nodes at least in some three out of five or twenty out of thirty, you know, stake sense. So the only actual cryptography that would bail us out here is indistinguishability obfuscation. We should totally be trying to make that work, but it's way more complicated than really where the cryptography is at right now.

I am kind of pessimistic on the, like, twenty out of thirty or staked panel kind of one. I do think that Vitalik is more optimistic about that, and I may be more contrarian in just saying I've kind of carved that out. So I, view there's, like, the hardware manufacturing trust, there's the cryptography trust, but really the goal has to be indistinguishability obfuscation and the ability to, you know, select a pool of people like a network whose kind of incentives in aggregate are understanding. I'm kinda more interested in the cryptography and hardware somewhere together, although kind of think that IO is, like, too big for me to want to approach. And, I, would say that I kind of have just developed this blind spot of not really thinking about the value of the network trust as being kind of viable.

Like, I'm kind of reacting to burning out after working really hard on MPC for a while and then being like, "This is actually just trusting the twenty out The cryptography is not the relevant part there." But yeah, why don't you have the last word?

Yeah. I mean, one, kind of fun take I have on, the obfuscation is that I think one way that we should be starting to hit the grounds running on that stuff very soon is that I'm a, I'm a fan of, like, basically stacking crappy IO plus crappy TEE. And so essentially you take whatever the best-in-class obfuscation is that can run within a day at all right now, and then you stick that inside of a TEE, and then you use that. And, you know, the, argument is basically that the things that cause both of those two things to break are very disjoint. And so it's, likely that if one is, i-is broken, the other one would still be safe.

And, this way we, actually kind of get into more and more into the real world on both of those things and, hopefully speed them up.

The, crappiest IO is crappy in terms of performance. What task runs on a day right now? Is it, like, an auction or a sixteen-bit multiplication?

Well, I mean, I, yeah, in my recent post I have a, like a, trade-off curve. But realistically, the part of the trade-off curve that is feasible to run at all is crappy in terms of being sketchy on assumptions.

You know? So A day for what? A day for what task?

A day for... I mean, ultimately, like, you can turn any obfuscation of unlimited size into obfuscation of SNARK verifier and FHE decryptor, and then you, like, verifiable FHE everything else. And so, to me, like, that's the target. And so you'd basically find, like, the whatever the least bad obfuscation is, no matter, no matter how sketchy the assumptions are, they can do that within a day, and then, like, you stack that on a TEE. That's my suggestion.

Yeah. Long term, I hope to use TEEs to generate demand for millennium prizes on IO for what Vitalik said, a SNARK verifier of FHE decryption. That would be great.

Okay. S-some, some basic questions here. One, are, So are side channels more or less a concern with, like, this Pixel graphene approach? Second question, people are, you know, some people propose these ideas where you have a TEE video camera watching another device. I'm curious if you have any thoughts on that. And then the third question is if everything is a TEE, how do I make my brain a TEE?

Oh, man. I'll have to go think over dinner about a good answer to how to make your brain a TEE. I bet we can do it, like locking you in a box with one of the cameras watching you, and then you've only got your brain, and, you can only output through a channel. One of the things I put some, you know, Fable token... No, this was Opus tokens, because Fable wouldn't work on it because it was cybersecurity, but I built a little memory manager thing. So you know how, like, SGX removed the Merkle tree that provided defense against integrity attacks? You have the same problem on the Pixel phone, like the, you know, sixteen gigabytes of RAM is not on the same chip.

It's on, like, a different chip on the motherboard. So I But since I'm already patching the kernel, because you have to anyway, I put a kernel thing that puts the Merkle tree, like a software version of the Intel thing that they had. Makes the memory four times slower, but if you're just running like a smart contract, you know, validation, I think that's justified. So, you still have to do all of that. I mean, you could do that on SGX as well, and it might, you know, bring back some of the physical security of it too. So yeah, those are still present. And that's not even talking about the, you know, hardware side channels. You still have to basically write the software to be power channel, you know, constant regarding the different branches.

So, even if it does everything that it says, it's just a start and probably should be... Yeah, I really like the idea of having tamper-proof sensor packages, which is a cool thing for an integrator to take, like, used Pixel phones and package them with tamper-proof sensors. There were a bunch of demos of this in that, trustless hardware day in San Francisco a while ago. Yeah, I, think there are a bunch of people that are trying to make, like, whole tamper-proof integrated systems. I, think that's a great way to go.