Secure if True: Proving Security with TEE Attestations

Transcript

Hello. Cool. All right. So, um our well our colleagues are resetting the timer just so to introduce the topic. Uh we will speak about um securing uh keys and uh them being a vulnerable part of the latest compro uh latest attacks that we were um recently heard about. Not only recently but let's say the biggest attacks. Uh so yeah uh please go ahead. Sweet. Um, hey everyone. I'm uh my name is Jack Carney. Um, I'm the CTO and co-founder of Turnkey. Um, so I guess a little bit of background on myself. Um, I was a infrastructure security engineer

at Coinbase for a while. I built the cold storage v4 of Coinbase. Um, so it managed something like $200 billion for a long time. It was kind of the underpinnings of Coinbase custody, which is um, Coinbase's institutional crypto storage project. Um, after that I was the CTO at Polychain Capital for a while. Um, doing a lot of Polychain at the time was doing a lot of um, like sort of longtail asset investing. So assets that weren't really supported by existing custodians or exchanges, anything like that. Um, and so I built a cold storage system for Polychain and did a lot of um, DeFi participation actually using SAFE and some other tools um, for Polychain. Um, and kind of out of that experience, um, felt like some

of the tools that that we were using at Polychain weren't necessarily exactly the tools I wanted to use, felt like I didn't have the granular permissioning capabilities that I wanted to, uh, to participate in DeFi um, at scale. And so from that basically started turnkey um, which is um, basically a secure private key management system. So we are developing an API um to generate private keys, crypto private keys, um control access to those private keys. We have a very sophisticated authorization and policy engine that lets you express very granular permissioning in crypto. Um so an example of this is I can create an API key in turnkey, have a private key held in turnkey. I can um basically

create a policy that lets this API key call the swap transaction through unis swap but not call the transfer function on USDC. So in that way you can build very granular kind of permissioning on top of various crypto networks. Um so this talk primarily I'm going to talk about centralized verifiability really verifiability overall. Um and um I think just as a a quick definition here, I would say that verifiability really means that um it's a system that's capable of being able to be proven or capable of being proven to act in a particular way or auditable. Um really in a software system, what this means is a strong link between source code and system behavior. So when I interact with this system, do I actually

know exactly what's going to happen or is there going to be is this like a black box that I'm interacting with? And we at Turnkey want to make a fully verifiable backend. Basically, as a quick detour, um why do we care about verifiability at all? So, Turnkey is an incredibly security sensitive system. Obviously, we're holding money on behalf of um the customers who use us or we're sort of facilitating them storing money with us. Um but personally, I think we should care a lot about verifiability beyond just crypto applications. So, we're constantly um influenced day-to-day uh by social media that's being executed by, you know, algorithms in social media that are completely opaque to us, complete black

boxes. Um we have uh dating apps that we're using or friends we make online also controlled by black boxes. And so, I think that um verifiability as a sort of like solution beyond just crypto is incredibly important for people to to explore. And we actually think we've had a solution that kind of can extend far beyond crypto and be a pretty like interesting uh way to develop software and deploy software in the world. Um crypto has been verifiable pretty much since the beginning though which I think is important to call call out. Like there are no governments at play running the Bitcoin network. There's no laws and regulations in a bit in the Bitcoin network. And so um basically you like needed software to be verifiable or

deterministic in in in exe execution for it to actually be um valid and for people actually have trust originally in the networks. Um by contrast though centralized backends have never been verifiable. So every time you've interacted with an API I would argue that's actually not a ver verifiable system you've interacted with. Um okay. So how do you make centralized backend verifiable? um super simple pro like description of how software gets deployed to production but in short engineers develop source code um they then build and produce the source code and make an artifact and then this artifact is executed. So if our intention is to create a strong link between source code and and system behavior we need a strong link at each

of these phases. Um remote attestation is the capability that we use. This is a capability that a lot of secure enclaves have. um or all secure enclaves have. I think worth calling out historically a lot of people would have looked at something like TLS and said this is actually kind of verifiable verifiability of a centralized system. It's not actually verifiability of the behavior of the system though. All you're verifying is that the same institution or same company that's actually controlling a domain name is controlling the service behind that. Um, TEES have this capability called remote attestation as I said and basically in short there's a component sometimes it's it's the TE itself sometimes it's a secure co-processor that sits um kind of

alongside the the main box and it basically takes measurements about what is being booted. So it takes um it like looks at the hash of the kernel as it's booting, looks at the hash of the boot FS as this as it's booting. Um and it takes these measurements that are basically fingerprints about what is running in the enclave. Um turnkey uses Nitro enclaves and so we get kernel and boot Ramfs as one kind of fingerprint. We get the user application data as another fingerprint. And another thing that's interesting for us is you get the AWS IM role and um account ID is embedded in that. It's like another fingerprint. So you basically get a um you get a fingerprint of the workload.

Um but um importantly you get a strong means of verifying that a particular artifact is running but you actually don't understand anything about the artifact that's running. Um, and if the goal is to be able to fully verify or fully audit that a workload is running on a machine, just understanding that an artifact is running there is is only like part of the equation. The reason for this is just people can't understand binary data, right? So if you have an artifact and it's like a hash of you know a kernel that's running that tells you nothing about the actual system behavior. Um, this is where we rely on reproducible builds. So basically we want to be able to deterministically produce those same hashes from a piece

of source code or configuration every single time. Um reason for this is humans can understand code and configuration. So if you can basically if you can take something you understand which is the code and turn it into a hash and then prove that that hash is actually running in a machine every single time you have a pretty strong link that the artifact or the piece of source code that you're trying to run in a machine is in fact running in a back end. Um without reproducible builds you are essentially running on or you're just trusting a uh you're just delegating all trust to a centralized build pipeline. And in you know any organization basically in the world that's going to be controlled by one or two maybe a couple people in in the organization. They have actual physical access or SSH access or something to

this centralized build pipeline. And so if you're trying to prove to the world that you're um running a particular piece of source code and you have this, you know, ability for someone to pop in and modify the content of the build, you're actually not going to be able to prove, you know, that that particular piece of source code is in fact running in your back end. Um there are a lot of people who use reproducible builds and talk about reproducible builds. Um but actually there's a whole spectrum of what reproducibility means. Um, so specifically a lot of people will do what we would call like last mile reproducibility, which is basically they'll bless an OS, they'll take that artifact and then they'll take the application code and just do a reproducible build of like a Go or Rust

application on top. Um, they're not and then they're basically running that on top of an OS that they have no transparency into. And so we would say that that's not actually fully reproducible and that in order to actually do like endto-end reproducibility, you need something else. This is where uh we built this tool called Stage X, which is now a community-maintained project. Um and Stage X basically goes all the way down to to the core. Um, it starts with like a a couple bytes, I think like 96 bytes of assembly code and bootstraps all the way up to to like this kind of like intermediate C compiler and then goes all the way up to like modern rust um at modern go and stuff which we end up using. Um, I think there's a a famous

paper by this guy Ken Thompson called reflections on trusting trust. It's a really good paper and he kind of like outlines this um struggle and like how you can like what systems you can trust in the the comp compilation process. Um, and I would uh I would argue that stage basically solves that problem. So basically we're we're able to prove any package built with stage. We're able to go all the way down to every single like line of source code in it and show that it it like every single line of source code that that goes up to make the eventual artifact.

Um, okay. So at this point we've talked about two different tools that we have. We have reproducible builds which strongly tie a piece of source code or configuration to an opaque artifact. And then we have remote attestation which strongly ties an opaque artifact to a running workload. And this proves then that there's some machine out there that is running a particular workload. But it doesn't actually prove that you are going to hit that when you hit an API. So how can I ensure that when I exe execute a request it is actually hitting the particular machine this particular piece of source code that I'm intending to hit. Um this is where we introduce a concept called app proofs which um

basically uses an ephemeral asymmetric key pair to sign over the entire enclave response body. So um basically when our enclave OS boots up it generates an ephemeral asymmetric key pair. um we include the public key of that key pair in the attestation document. The attestation document then basically maps source code to that public key. Um you can audit the the the source code of of our OS or the applications that are using it and verify that this ephemeral key was never actually exported. And so then after you go through all those steps, you can basically convince yourself that a signature from this ephemeral key is uh proof that that something happened or like that action

whatever was signed took place in that in that enclave. Okay. So any centralized verifiable system I would argue has to one be open source two employ actual reproducible builds uh three have remote attestation and then four enable runtime verification and if you if you haven't had like a strong story for all of these I would argue it's not a centralized verifiable system and turnkey is almost a centralized verifiable system. So we're we're working our way to it. Um for some context about how turnkey works, basically our backend can be split into two different buckets. Um so there's basically services that can do scary or

dangerous things. These are things like generating API sorry generating crypto keys uh creating policies, evaluating policies, um mutating data for for a turnkey account that might leave the account in a uh more secure, less secure state, things that if you could compromise, you could compromise funds. Um, and then the other bucket of services are are services that can't do those scary things. So when I talk about verifiability of turnkey, I'm really talking about verifiability of those services that can do scary or dangerous things. Um, and we have this property that each service that can do a scary or dangerous thing, it has to be executed inside of a secure secure enclave. Um, where and then each one of these secure enclaves has uh reproducible build. So

we have basically full provability of everything that is running in the critical components of the back end. So what's missing here? So we don't yet have app proofs on everything. We have app proofs on a couple things, but not every enclave request has an app proof associated with it. We're incrementally working our way through that. Eventually we'll have app proofs on all the different enclave things. Um and then we actually haven't yet open sourced our enclaves. So we will be open sourcing our enclaves. Turnkey is a super security sensitive system. We're not trying to open source it you know. um just on the fly, but we're hoping to open source the first Enclave application by the end of the year, which would then make it turnkey like one more step towards verifiable.

Um this is um a link to our white paper. So our white paper goes into a lot more detail um into this whole concept. Um there's a lot more to it also than than kind of what I've been able to to rush through here. But um definitely if you're interested in this topic, this is uh a kind of very extensive description of how it's all fitting together. Um okay so as we were going to market with turnkey the wallets and signing API um we started to tell a story about how our backend was fully verifiable and um a lot of people were interested in that and you know wanted to talk about that and and like the product but they also had interest in basically using our enclave and this whole deployment stack

to run arbitrary other applications that they they had. Um and so this is where we are um we're now running this uh this product this new product basically called turnkey verifiable cloud TVC. It's in private beta right now. Um we uh started working with Anchorage. So Anchorage is now doing verifiable transaction parsing using an application deployed on TVC which is pretty cool. Um and we're starting to work with a bunch of other customers. Um and we think there's a bunch of cool things that you can build with TVC. Um I didn't go I guess I talked about it mostly through the lens of humans verifying attestations. So humans you know executing some tool on your machine

to to verify the attestation of what's running in the back end. But we could just as easily run that in uh smart contracts or other web 3 systems. So you could essentially verify in a web 3 uh system that a workload was run in on top of this this verifiable stack. Um so we think that turnkey turnkey verifiable cloud is actually a really really great bridge between web 3 and web 2. Um building things like oracles is going to be very easy with TVC. Um you can execute HTTP requests from within our enclaves prove to a smart contract that that HTTP request was in fact resolved and you know the response was given by a particular um by a particular web 2 API.

Um and um it's a very easy, it should be a very easy and kind of fast way to get started where you get to sort of circumvent a lot of the complexity of cryptoeconomic systems. Um I think there's a lot of interesting non-crypto use cases. So PII processing is is another um example here is has nothing to do with crypto, but I think you can very easily get a application off the ground. You can prove to your end user that you're not doing anything nefarious or weird with um your their PII. Um, and so we're interested in exploring kind of the whole gamut of new things built on top of uh on top of this stack. Um, so that's it.

Does anyone have any questions? Do we have time for questions? >> Yes, we have uh two three minutes for questions. If everyone wants to ask a question, now is the perfect time. Hey, I have a question about the verifiable um cloud >> for the for the attestations and the enclave like that makes sense how you can do verifiable cloud. Um the reproducible builds I imagine is is kind of tricky, right? Because you need the enclave images that people run to be built presumably with stage and like all the dependencies. How are you dealing with um with that? Yeah. So right now it would just be like user provides uh a basically application like just some source code to us and we would build it

and then a consumer if they wanted to could just rebuild it themselves and verify that you know the values they get when they rebuilt it is actually from included in the attestation document. Um eventually we we actually want to have like a almost like decentralized group of builders that are all building applications that are running in TVC and providing proof that when they built the particular piece of source code they actually got the resulting artifacts kind of like take it one more step towards a decentralized system. >> Cool. Thanks. >> Any other questions?

If not, uh, please give a round of applause. [applause] Thanks so much for your talk. And, uh, I would like to invite the next participant to prepare.