Attestations Alone Aren’t Enough

Transcript

Okay. Hello. I'm Peter Us from the Oasis Protocol Foundation. Welcome to my talk. The first slide is not working. The talk is titled "Attestations Are Not Enough". Okay, it's working now. Um and yeah, let's talk about attestations and TEEs and what it takes to build practical applications using this technology. So, as a user So, as a user, once you visit a project that's using TEE nowadays as a like as their security primitive, I usually see a bunch of green check marks that say something like verified, trusted, attested even, and then a bunch of raw

data that like nobody really actually understands or reads them. And unless your users are security researchers, I think this is more of a security theater than bringing any actual security to apps using TEEs. So, as a like high-level what a TEE gives you, you get three things basically. You get isolated execution, which means that your code is run privately in a part of the CPU that even the operator cannot see. You get per CPU root of trust. These are basically some cryptographic keys that are baked into the CPU set the time of production.

And the third thing is the remote attestations. And this is a quite powerful concepts which allows us to prove to a third party that we're running the code that actually we're saying that we're running without having to trust the operator directly. And all of this is nice and necessary, but it's not enough in practice to actually build applications that we can that can be considered trustless in a way. So, let's focus on Intel SGX attestations for this example. So, we got this what is called attestation quote. What can a user do with it?

So, they need to parse it. They need to extract certain fields out of it. There's a like 100-page PDF provided by Intel which describes how to do this stuff. Uh you need to validate certificate chains that these things actually came from Intel. You need to and interpret different fields inside the quote. You should check freshness cuz a quote might be old. And you and that if it's old you maybe it's not maybe the code changed since then, maybe the architecture platform that's running it it's not trusted anymore.

Um etc. And ideally we should be doing all of this continuously. So, in a say in essence what uh the attestation provides us, it's three things. It provides us that the specific hash of a code was run inside a specific enclave. It also um tells us that that enclave or that hardware is um deemed deemed secure, whatever that means by the hardware provider. And that this happened at some moment when the quote was produced.

And on the other side, what users assume or maybe even what users kind of are led to be assumed or like kind of what projects using TEEs try to tell users, that this automatically means that the application is safe, that it has no bugs, that it's actually running the version that it says it's running, um and similar. So, and now even if we like get attestations, we verify the quotes, we do everything correctly, we do this continuously, we can still get examples like that like this. So, this is a valid attestation that's produced by Intel. You can um but then you can check a bit more in-depth into it.

For example, this specific attestation was done on the third-generation Xeon CPUs, and those CPUs actually have very well-known and very practical attacks that are basically are able to completely break the machine and extract the hardware keys that were baked into them. But the nice thing is that Intel considers these features as out of scope. They seem it like as a feature, not as a bug. Because their threat model explicitly states that requirement of a physical access of the machine is out of their threat model.

Um so, what this shows us that we need actual policies on these attestations that go beyond just does the hardware provider says this is trusted or not. Cuz your your um threat model might not might want to involve also um the physical requirement of presence being a part of your trust model. Um maybe a bit of a as a side note, as I mentioned before, the attestation only proves you that a specific hash of a code was running inside a secure enclave. And this meaningless unless you make your source code public and also reproducible. Because everything else otherwise doesn't prove you anything.

Because if you can't independently compile the code, get the get the get the hash of the code, and ensure it matches the attestation, like there's the the security model collapses. Uh luckily, this is solved in 2026. Just developers need to be a bit more mindful. It's a bit more tedious sometimes, but it is a solved problem. Um Now, let's say we have some TEE application that's running somewhere in the cloud. You get the public code of the application.

You compile it. You verify it. You check it has no bugs. Maybe it's even reviewed. Maybe it has security audits done. And everything checks out. The attestations pass. Everything matches. Well, that might not be enough. Because maybe you checked the previous version of the code and maybe it had a bug that where it leaked the private key out. Or maybe it had a debug statement that was left in. Um And this this example is a toy example, but actually showcases that it's not enough to just verify the current version of the code, but you need to be able to verify all the past versions of the code as well.

Um because um Yeah, if you if the upgrade path of the applications isn't transparent, again the trust model of the applications collapses. So, maybe just a as a short recap, what attestation doesn't give you, it doesn't give you any trusted computing-based governance beyond what the hardware provider says and he deems trustful. It doesn't tell you anything about previous versions of the code. It doesn't enforce freshness. You need to manually check that the quote was produced recently.

And also there it tells you nothing about the operator. As we saw, maybe some CPUs have attacks that actually require trusted operators, not just the trusted code or the CPU. And ideally in an ideal world, we'll be doing all of this all the time. So, we would be verifying attestations. We would be enforcing freshness. We would prevent rollback. Um this I won't talk about this much, but this is an important thing cuz it's um like state rollback leads to a bunch of other attacks.

Um We should be able to apply custom that go beyond what the provider says it's valid. We should be able to track upgrades to the applications and ideally also know which operator is running the code. And this sounds like a good job for a blockchain system. Um So, this is what the Oasis Network has been doing for like the last 5 years. You can look at the Oasis Network as a continuous attestation verification system. Um there it supports on-chain policy definitions and enforcements.

It's run by independent and economically incentivized operators. The open source The code is open source and it's public. It's went through audits. There's bug bounties out. And I The whole idea of this is that instead of putting the burden of the verifying attestations to the users, let's have a agreed-upon consensus from operators doing this stuff, and the users can then use the consensus network state as a root of trust. So, for the user, this mean this means that now their raw attestations, he doesn't need to see them. The raw attestations now become the inputs for our network, and the consensus decision is something is valid or not or approved becomes the output.

And users now verify the Oasis on-chain state and don't even need to know or see the raw attestations. And this also gives us uh ability to abstract the attestations from multiple providers in a like unified model for the end users. Um So, once we have this like our Oasis Network or some other network that we have some um verified on-chain root of trust, we can start thinking on how we use this to build trustless applications that actually do something useful.

So, at minimum we we need like a on-chain registry of TEE applications which each app should have an ID, an owner, the currently approved code measurement. We should track updates and ideally also all enclave starts on-chain so the user can see the history. They can see what was the previous versions of the code. They can actually see how many instances of the application is running currently. And this should be done periodically. So, about 2 years ago, I think, we launched the Oasis Sapphire which stands for runtime off-chain compute logic.

And this in essence allows arbitrary containerized applications to be run on the Oasis operators. And Oasis network here is just used as the attestation and the trust layer. So, this can be completely off-chain applications. It can interact with other chains. The like the go the Oasis network is here mostly used as a security mechanism. Mhm. Now, once we have this on-chain root of trust, we can do more thing more useful things inside our um TE apps that we call Raffle apps.

So, for example, instead of again putting the burden of the user to verify the Raffle apps that they are attested and running via the on-chain state, we can put that in inside the code inside of the every Raffle application. So, every application that's running on Raffle in Oasis actually needs to contain a startup code which does the exactly the this thing. It fetches the on-chain state and it actually verifies itself. So, it can check is my code the one that's stated on the on-chain state? Am I running at the on a operator that's in good standing that I'm allowed to run on and similar policies like this.

Mhm. And similarly, if you have users interacting with these applications, they can follow the exact same path. What they need is a like a trusted access to the on-chain state. This can This can be done by light clients. Mhm. They fetch the registry of the registered apps. They get the mhm code hashes there. They can see the what policies are defined. These are all public. And they just compared what they see with what's in the on the on-chain state. And again, like here, no attestations are ever exposed to the clients.

Mhm. So, we've been building applications on top of this for about the last 2 years. And we've been we noticed or we found some interesting patterns like primitives that then enable more powerful applications to be built on top of this. Mhm. I'll go over a few examples now quickly. So, first thing is we call this attested TLS. It's basically how can how can you if you run a server inside a TE, how can you establish a TLS connection directly with that server without relying on any third-party certificate authorities or something like that?

And the idea is quite similar to the previous ones. So, the TE application on startup it generates public and private key pair for TLS. It publishes the public key on-chain. Mhm. There's like it's important to know that there's a part of the on-chain data which only the Raffle app itself can update, so that can be trusted that it came from the application itself. And then as an outside client, mhm you connect to the server, you get a certificate. You again use a something like a light client to get the Oasis on-chain state. And you can verify that the certificate matches to the public key that's published on-chain.

So, you get a full TLS directly inside the enclave without relying on any third-party custom authorities or anything similar. Mhm. Another very useful mhm feature is what we call encumbered wallets. Mhm. This was actually coined by uh the research paper made by Cornell Tech by the group of um Ari Juels and others. Um it's called the Liquefaction paper. Mhm. And in essence, this is These are basically keys that live inside enclaves and TE applications.

They were gen- They were generated there, never exposed, and then they define access to these keys via on-chain policies. And not actually access to the keys directly, but access to signatures made by these keys. So, this enables a bunch of useful use cases. Mhm. The paper itself listed listed listed a lot of them. But one cool example is Take My Ape. That's actually what they built as a proof of concept of their paper their paper. And what they did is they have a mhm Ethereum account that was generated inside the Oasis Raffle TE. That account actually owns a Bored Ape in some on the Ethereum mainnet network.

And they built then they built a on-chain bidding process where users can bid to get access to that key that key for a limited period. Mhm. So, with that, you can I don't know pay $5, get access to the Ape for 5 minutes. You can use it to produce signatures that actually prove that you own that Ape. And then you and you get I don't know, you can get invited into the Discord which is only to the for the owners of the Bored Ape Bored Ape Yacht Club. And things like that.

Mhm. And the important thing is here that the user never gets the access to the private key. There's actually on-chain code that enforces only signatures for proving the owning of the key. You cannot like generate a signature that would transfer the the Ape to another account. Another cool thing is Flex Wallets. This is what our team is working on. It's basically our take into taking the Liquefaction paper foundations into production with a bit more focus on DeFi. Mhm. And the pattern is quite similar. Like we can have keys for a bunch of different chains that are controlled by TEs.

Mhm. There is a policy engine which users can use to define custom policies like time-based spending, spending limits, token white list. There is DEX support integrated into it. Mhm. And here again, Oasis network is only used as a security for this software. This is not limited to Oasis network in any way. It The idea is that you interact with other chains through this. And if you want to learn more about Flex Wallets, um Nino is here. He's our product lead on that. And there's also a a side event we have today where we'll talk more about this.

Um one thing that's common to all of the use cases that I mentioned is that we're generating keys inside TEs. So, if you're using plain TEs, you get some hardware-provided keys there, but those keys are always um tied to the code measurement. Basically, if you update the code that's running in a TE, you get new keys. This doesn't really work in practice because for building useful applications, we need upgrades. And for that, mhm our network also provide provides a decentralized key manager where keys are bound to the app ID.

So, we call this like consensus-baked key provisioning. Mhm. Similary Sim- As I talked before, every Raffle application registers on-chain. There is a committee of TEs that we call key manager. They run a um decentralized protocol for sharing keys. And then these TEs use the Oasis network as a root of trust. Root of trust who is who gets access to which specific keys. So, when actually when a new version of a Raffle application is updated, the on-chain state in the Raffle registry updates, there's a new code measurements there, and now these key managers can provision the exact same pair of keys to the new version of the TEs.

Mhm. And yeah, let's just to wrap up, let's go over the takeaways. So, we are argue that the attestations should be the inputs and not the outputs that should be presented to the users cuz they would need to be security researchers to get any use of those. Consensus as a root of trust is a really powerful primitive that enables to building us applications that we couldn't build without this. Mhm. Ideally, every useful um system that uses TEs should also have support for policies which are public and reviewable on-chain which define additional rules.

And we require full provenance for any um actual security in practice. This means every enclave startup should be tracked, every upgrade to the code should be tracked, and it should be tracked in a immutable way. And this is what kind of turns TEs from security theater into actual security in production. And thank you for listening to the talk. If there's any questions, go ahead. We can talk after.

Thank you. Thank you.