When Trust Gets Tricky: The State of TEE Security Today

DeFi Security Summit at Devconnect Argentina 2025 · November 2025 · 17:55

Anup Swamy Veena, staff security engineer at Eigen Labs, examines trusted execution environments such as Intel TDX and AMD SEV, which promise hardware-enforced isolation. The talk introduces how TEEs work, what they actually protect against and where their trust boundaries fail under modern cloud and supply-chain threats, so their real-world guarantees can be judged accurately.

Speakers

Topics

From DeFi Security Summit at Devconnect Argentina 2025, hosted by DeFi Security Summit.

Transcript

All right. Uh, everyone's just coming in, I guess. Okay, we can start. Um, hi everyone. Um, I'm Anup. Um, security engineer at Labs. Um, one of the main reasons I wanted to start this talk was to sort of give a like sort of information um data that we found when as part of IGN cloud we started looking into TE's very seriously and um you know there's a lot of information out there there's a lot of uh very interesting conflicting talks and uh predispositions about the uh hardware and what does it mean? So I

wanted to sort of explain this in a way that either security folks or app developers would sort of need to take things into consideration when you wanted to deploy your app um on a TE and on any of the offerings that you know you might have been hearing throughout the conference here. Um so what primarily we'll go through is primarily the two intended audience which is as an app developer how does an attestation life cycle look like and you know you'll find many many flowcharts of what an attestation flow looks like from hardware TPM to all the way to what it

is but I'll show an example of a a testation from GCP primarily um because that was the easiest I could get to work without having to you know contact Azure or others to get things working. Uh the other one is at the end I'll sort of go through how how do you realistically sort of understand a trust model and assumptions and so that that translates as a security person if you're looking at it like oh I can attack something like this versus an app developer like okay I can take this much trust away from by deploying it on a TE but I do have to consider these other

mechanisms as So I um quick intro this does not do TE's justice but I'll just do a quick intro. Trusted execution environments you can think of it like um extension slash a protected region from the processor and whose whole job is to provide confidentiality integrity and the one of the most important parts the attestation. So confidentiality um only the code inside the TE can read the TE's memory. neither the hypervisor or you know if you if you know about the ring trust model ring zero ring one ring two um even the hypervisor who would be

involved in scheduling your you know VM and other things would not be able to read once it's started and you know that's the model that they want to go for integrity again nothing outside some other process even the h um CPU hypervisor and the other things cannot modify this like only within the DE and that's what they attestation. This is where app developers and everyone else comes into play, which is you can get to a test very specific and interesting things about your app, the environment you're in, um the firmware you want to comply, the many other interesting parts. You'll see an example um benefits. again what you get away from running a normal

process where there's already segmentation from the CPU versus running in a hypervisor [clears throat] which is you don't you can remove a lot of the trust um away from the hardware manufacturer like even almost the cloud itself um there's a paper demystifying TDX by IBM research where they try to take the trust away from say GCP like Google cloud itself to sort of uh help people understand like just with pure intel you're able to verify a lot of the things and you know it's one of uh the backbones for modern computing almost every cloud vendor offers a version uh interesting versions of TEES for

workloads um um there's there's a few of them um we're probably going to focus on just TDX so a attestation this is an example I'll go True. Um, so three main stages you can think of. So measurement, the actual attestation and the verification. And so measurement is when your TE starts up you have a lot of um data points that the CPU measures like what's the software what's the firmware what are you running inside what's your docker what's your environment variables and couple and a lot of other things that you can also specify to a test or to measure. So measure is just recording like you

record this in a giant JSON structure. That's what you'll probably mostly see. And you know they hash it shmp compute hash and somebody will sign it and you know the usual stuff. Um the measurement is primarily to make sure that you know what is running inside a TE is what I measured and that's where that is one of the core important parts. this the CPU measurement and other stuff. It measures like the trusted computing base, what firmware version am I running, what is the software version of the GCP's orchestration layer itself, etc., etc.

So, um once you have the structure, someone worthy enough or you know the trusted computing base in this case needs to sort of sign it. So there is a key that is you know when the hardware is generated like by Intel or AMD it is burnt into the the hardware layer and rooted in CPU and that signs off. And you might be thinking oh if anything can generate a quote can can it's signed off I can spoof it. Uh it's not. This is a rabbit hole if you want to dive into um there's very specific processes which can request a quote and even the signing process is not give me the key I'll sign

it is hey can you sign this for me and this is my attestation to the fact that I was approved by this trusted process to sign this quote and I haven't changed it and that's a very high level thinking of how quotes from the hardware measurement is signed and provided to you um in like this JSON structure here. So verification the third part is what you know we all kind of fight about. um the verification you can think I've come across like two mainly two different ways where interprocess te like te talking to another TE within the same CPU so to speak you can get

away by not attesting a certain few things um to optimize for like TPS or RPS or some of your apps but you have you still have the same level of verification because it is the same CPU and there's some optimizations that people are working on but the most common one is the generic verification so if you were given or if I was given this JSON structure like I this is signed over etc etc here's the verification code let's start verifying this so you can see is the mouse shown yeah um no that's not useful can I zoom in no okay um is this visible at all no a little bit. Okay. Um ISS

issued at by Google APIs. Here the supported attributes is quite interesting. It says latest, usable and stable. These values mean very specific things in the world of GCP. So latest means latest firmware. That's all I want to do. And if you know the verification like a quote comes back and says this is stable but not the latest you as an app developer or you know in your operator set so to speak can reject this uh operator from joining your entity saying that like you're not running the latest and I don't want this. So that's one thing usable is probably the least where it can tolerate one or two attacks and you know version bump and stuff like that. So here on the right side top

you'll see containers container arguments how did this docker start what are the arguments um down below you'll see the environments like what is this docker started with what environment the image digest the docker hash uh image d that's publicly referenceable and the image structures the layers that you can get and gce spec like uh Google cloud specific stuff and here you can see this is the confidence credential space and this is the software version that you're running. So this is a you know this is on the lighter side of a quote like a code can be really really large depending on what all things you want to you know verify or add as an app

developer. So if you were verifying say all the docker container versions but you weren't verifying say the latest um attributes. So if you had only stable or say usable and there was an there was an attack, Intel patched it, GCP patched it, but you were one of your operators that were still running an older version or something. Now that's an entry point for them to start, you know, playing around with and you wouldn't be um you wouldn't know about this until like you update it to say that you should only use the stable version. So it is a way for Google compute or you know Amazon whatever it is to sort of specify that

these are the versions. This is signed by the hardware that is running it and you can verify this all the way from the hardware manufacturer AMD or Intel because the key that is rooted in the hardware actually is signed off by the Intel PCS or whatever the certificate authority that they control. Um yeah so that's the JSON structure is what mostly people will use to sort of understand what's happening. Um the attacks this is the most recent one that um took Twitter by storm and a lot of people screaming and it was fun to think about this. So um I'm not going to go into DRAM

interposer and you know RAM speeds and stuff but the one of two of the main things that people were fighting about were physical access. So one of the things that is a debated topic and Intel has taken a very interesting position on this is physical attack is according to Intel not in their um threat model which is interesting but you need act physical access. So if you need to walk in into a data center with all the you know the measurements and things to sort of get at the chassis that controls you know your CPU to try

to put all these things there to measure. So physical access is one of the um attack vectors threat models to actually see like there are side channels of course but the main one is the physical access and the other part is the components required to perform this attack was just a couple hundred and this wasn't customs sourced or anything this was off the top like I think they bought it on eBay or something. So they were able to perform or extract like close to keys and other things and almost started spoofing or probably spoofed for 500 couple plus dollars and

a physical access to this. So this is something that app developers kind of need to take into consideration that if you want to let anyone run your your app and you want to let them in your operator set so to speak um you need to consider someone doing this and there's a full description of how to do this. So they will try to do it. Um couple other attacks uh wiretap.fail was probably from the same folks. Um this one was attacking the latest and greatest Intel TDX, AMD SEV um and couple others. This was um attacking SGX primarily. So the again similar attack vectors which is

physical access and couple hundred dollars that you would need to uh construct and perform this um um these attacks. So the one of so of the two things physical access is something that everyone's trying to solve in very different ways all the way from sending TE's to space to you know very interesting stuff um but this is something that caught um some interest from our side which was proof of cloud in the sense that CVM here is confidential VM um would attest to a quote that something like you saw in the JSON structure and the TPM also um would

quote to show that it came from the same machine and the TPM um certificate was issued by one of the vendors that probably you want to allow or whitelist or do something so you can verify like oh came from Dell Super Micro and Google whatever production environments. So you can and they also go to like you know data center location and things like that but it's it's a very interesting way to say that you anyone can join but you will have to run it in a specific cloud sort of a statement. So it's you know it's it's getting there and the alternative to this is trustless tees and there's a

whole um research section on that as well. Um but this is one of the interesting ways that people have been heading towards to sort of say that you know it's a it's a compromise. It's not the best, but we can still do a lot of things and verify and you know within reason the data center is protected by people with guns and a whole thing and it's data each data center has levels of certification and I think most any of the bigger clouds have level three certification. No one's gone to level four where it's like autonomous entities like going and plugging in and doing stuff. Maybe data centers on Mars will have that but we'll see.

Um so I just have a couple minutes. So um one of the main takeaways when we started this journey was we started with SGX but we ended up with VMs full TDX CVM mode and that's where a lot of the research is going and a lot of investment from major cloud providers are also going and the other hard part is you know cloud providers aren't really that open to giving out information on which data center how is it protected can you tell us your operational procedure. No, they're not going to answer any of those questions, but you know, it takes a few companies asking like, "Hey, we want to

bring a few hundred million dollars with you. Can you answer these questions?" Maybe they will. So, we'll see. The other part was hardware route isn't perfect. Ex those attacks alone show that, you know, it's easy enough to extract and you don't have to do a lot of complex things, especially when it's like listed out. And there are dedicated companies whose whole job is to break tees. So it will happen. is just the fact that it's cool, you did it, but can you do it on my machine is the question that everyone wants to answer and you know they're protected in the data center environment and attestation for all the security folks who would look at or audit like a TE implementation to say

that like yeah this is cool the attestation verification and the parts that are verified to the statement that the app developer or the engineer wants to do is very important to take into consideration that it's not just enough you just generate this quote and say like it's cool. You need to make sure that you're verifying the right parts and actions are being taken onchain, offchain, whatever the app wants to do to have your tbased app function properly. Those are some of the references. um you're you know uh feel free and um there's been a good amount the last one uh there's been a good amount of uh effort put into different

layers of how an app developer would need to take a tbased app security consideration and the guarantees that it would make um yeah that's pretty much all I had um I can you know uh talk to anyone else about each of those has a rabbit hole I don't want to dive too deep into we'll be here all today. But um happy to talk to anyone else. But um yeah thanks [applause]