Episode 379 - Verifiable Key Management and TEEs with Turnkey

Transcript

[Music] Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. [Music] This week, Kobe and I chat with Arno Busu and Jack Kernney about verifiable key management and trusted execution environments or TEEES. We explore how their work in the custodial validator space prompted them to work on the key management problem. What earlier

solutions such as HSM offered and where they fell short and how modern approaches are evolving to make key management more transparent and verifiable with the use of TEES. The discussion covers a range of challenges and techniques, the role of remote attestation and reproducible builds in ensuring trust, strategies to prevent downgrade attacks, and the use of authorization and policy layers to reduce misuse of keys while still enabling automation. We end up touching on the overlap with ZK and with AI agents. So, I hope you enjoy. Now, before we kick off, I just want to make sure you're following our release of the ZK whiteboard sessions season 3. These videos produced by ZK Hack and supported by Bank Capital Crypto feature our hosts

Nico and GMO exploring the building blocks of the ZK systems we know and love. We are currently releasing one module every 2 weeks. These can be found over on the Zero Knowledge podcast YouTube channel. Subscribe there to be reminded and we'll be adding the link to the show notes. Now, here is our episode with Arno and Jack from Turnkey. Today, Kobe and I are here with Arno and Jack from Turnkey. Welcome to the show, Arno and Jack. >> Hey, thanks for having us. >> Hi, good to be here. >> So, today we're going to be digging into verifiable key management and revisiting the topic of TE's and hopefully we'll get to see how ZK intersects with this.

Kobe, how are you doing? >> I'm good. >> There was a conversation in the big ZK podcast chat that prompted this interview. Do you want to just recap what happened there, Kobe? >> Uh, yeah, sure. So there was a question about state entities and how that is managed in the Zika podcast Telegram group and you know quick disclosure ven capital crypto where I work at and led the series B for Tanky >> so I know these guys pretty pretty well and I thought it would be perfect to answer that question. So I told them hey guys please come answer that question >> and they were happy to do that and we also later thought it would be a good idea to kind of discuss more thoroughly

the technical work that they've done. >> Cool. Yeah and I think this is I mean this is a perfect opportunity for us as I mentioned to revisit tease something we have covered on the show before. We'll try to dig up our last episodes on this but we don't usually go that deep into it. It's usually just sort of thrown out as this like throw a te at it kind of idea. Like it's just sort of this abstract thing that we bring up every once in a while. So yeah, I'm excited to learn more. Before we dig into Turnkey, I'd love to hear a bit about you and what got you excited about this? What got you started? Arno, why don't we start with you?

>> Yeah, sure. So, my name is Arno. I think I first dug into crypto and key management and security at Coinbase, right? So that was kind of my first entry point into this realm and yeah building Coinbase custody and seeing the the folks at Coinbase doing cryptography doing security and you know all the problems that come from key management and asset support and expansion of asset support. That's kind of what got the sort of the problem framed in my mind. Um, and I think turnkey is a continuation of key management and so building that system from the ground up and taking all the ideas and taking all the the things that we've learned at Coinbase uh was really

something that was super exciting to me. >> Were you part of that team before they joined Coinbase? Cuz like this as far as I understand is the team. They used to be Bison Trails and then they were kind of like brought into Coinbase and became a bit more like the custody team. Or am I thinking of something else? >> Oh yeah. Yeah. Different team. different team but yeah I've worked with the Bison Trails team actually uh but yeah after so basically I joined >> joined Coinbase around 2018 2019 and that's when Coinbase custody got off the ground >> as a product and so the buildout of Coinbase custody led to Coinbase Prime and then part of the Coinbase Prime offering was staking >> and staking was something that was offered through Bison Trails. Yeah.

>> And then they got incorporated into it. Got it. Exactly. And I think at this point maybe the team has dispersed throughout like I know some folks that I think are part of the custody team that originally were Bison Trails but Okay. >> Yeah, for sure. >> Cool. Nice. And what about you, Jack? >> Yeah, so I've I've been in crypto or I guess I followed crypto and been interested in it for a a really long time at this point. First got into it in 2011. >> Oo, very early. Is that before Kobe? >> I think so. I mean, I heard about it before, but I didn't get seriously into it.

>> Okay. >> It was it was hard to get seriously into at the time. I mean, you could go deep on the internet and read a lot, but there was not anywhere to work really at the time. Not too many companies formed, and frankly, the companies that were formed at that time were sort of sketchy. Yeah. So, yeah, I was I was in college at the time and just kind of I was studying math and economics and it was right at the intersection of of kind of the things I was interested in in reading about. So, went pretty deep down the rabbit hole. Then >> joined Coinbase in 2016. So, it was >> okay >> pretty early still. I think I was like engineer 30 or something like that.

there was one combined infrastructure and security team and I joined that team and then it quickly split off and you know the company grew pretty pretty far from there. Um, >> didn't Coinbase go through Y I'm not sure if this is correct but did it go through YC? >> Yeah. Yeah, it did. >> Were you there at that time? >> No. No, that was in like 2012 I think. >> Oh, okay. Okay. >> Yeah, I think actually Brian was solo going through YC which they typically frown on. Yeah. >> Interesting. Um but but yeah, so then I was like the first person working on Coinbase custody or one of the first people working on Coinbase custody and you know had a chance to kind of help design the whole new cold storage system from the ground up and think a lot about key management from first principles and

like how not only Coinbase would want to use the system but also our customers you know through Coinbase custody would want to use the system and then we built the product and then and then sort of started scaling it. That's where Arno and I first met >> back then. Like were there tools that sort of existed for this kind of thing? Like I'm trying to understand if it was like a purely cryptonative concept, this verifiable key management or just key management or if it was like it existed in all sorts of industries. There were kind of some best practices that needed to be ported into this space or if you had to invent it. I mean there were definitely like HSM have been around for a long time like the traditional like banking sector and and some healthcare applications use HSM which are hardware

security modules. >> So yeah they definitely there were definitely like some some like best practices around key management and stuff and Coinbase had been around for what 6 years or something by the time we were building Coinbase custody. So they had we for Coinbase custody we built cold storage v4 and so there were three kind of systems that had existed at Coinbase prior to that. >> Yeah. And they were already managing like quite a lot of assets. This was not like so early that you could experiment too too much. I guess you need >> some tried and trueue solutions already. >> Yeah, it was a pretty big company at that point. I think it was >> like when Coinbase Custody was getting started, I want to say it was two or 300 people.

>> Okay, cool. And then you did you spin out like at what point does turnkey start? Like what's the year? >> Yeah. So early 2022 actually I think the first conversation I would say I had about turnkey was over the Christmas holidays 2021. >> Okay. and then kind of started thinking about things and actually I had been at I was at Polychain for the three years leading up to starting turnkey and had been using Fireblocks and so it was kind of I was doing a lot of like internal asset operations at at Polychain cuz at the time Polychain was invested in a ton of really like longtail crypto assets that weren't readily supported by US-based exchanges or custodians. Mhm.

>> Um, and so we were doing a lot of manual asset operations and and that kind of was super clunky and and tricky. COVID hit and like we had one cold storage system for Polychain that required people being in person together. >> Oh wow. >> And so CO hit and suddenly like we couldn't move money around in the way we needed to. >> So yeah, 2022 hit and I was like it's time to build build this thing. Did Polychain also, I'm not sure if it was Polychain, but didn't they have a like a validator business that spun out as well? Were they taking some of that key management stuff with them for that?

>> Yeah. So, I was that's what I was working on. Okay. >> It was called at the time Polychain Labs. And Polychain Labs then split off and became this company called Unit 410, which was ultimately sold to Coinbase. >> Oh, wow. >> And still actually operates independently. >> Cool. And so they took a bunch of that key management system and and sort of staking operation with them. >> Interesting. I think I actually met with someone from that team back in 2021 because I think they were based in Austin. Is this true? >> Yep. >> Yeah. And I'm I feel bad. I can't remember the name of the person, but we like I knew about this operation just as it was it was getting off the ground.

>> Yeah. Maybe Rob. >> Yeah. Yeah. I think it was interesting. So you had been sort of like at least there. Did you actually join this unit 410 or was it like you you were sort of part of the initial creation and then you you left to do turnkey? >> Well, yeah. So I I think I stuck around for like a year at Polychain. Kind of like helped deal with the handoff and um you know just stuck around at Polychain for a little while longer and then went off and started turnkey. >> Cool. You guys have been thinking a lot about what it means to use these you know both for verifiable key management but also beyond that.

And I think it would be really interesting to understand first of all what you do there but also the challenges of doing that and there are a lot of challenges that I learned from you guys. So would love for you to share this with the rest of the people here. I guess yeah we can start maybe with the piece that is the easiest to understand which is the key management use case and why that's difficult right and when I say easy to understand I don't know we'll see when we get deeper into the details but yeah so a key management system at its core has to hold a key and then be able to offer basically two operations right it's like create a key and then sign a message with it and that's kind of at the core of any sort

of crypto operation that you do. So that's the first thing that we recognize. I think as a as a company we didn't want to stretch ourselves too thin and take on too much scope because that's something that we saw in previous experience. It's as soon as you start taking into account asset ecosystems etc. you get into problems in terms of scale of software and dependencies and special casing. So basically what we said as an an initial bet for turnkey is we are a key management system. We're not something that is going to take a transaction end to end. And that's what we want the TE and the secure operations to be centered around is this notion of you give me something to sign I will

sign it. Right? So that sounds well and good. It also sounds very much like an HSM. And so what is an HSM compared to turnkey? Well an HSM gives you those primitives. Turnkey gives you those primitives and a bunch of stuff around it which is in my opinion just as important and that's the authorization of what you signed. Right? So if you enable a piece of technology to sign a message, it can sign a message that you want, it can also sign the message that you don't want. Right? So for example, send my phones to an attacker's wallet.

That's something that should be denied. Send my phones to the person I intend to. That should be allowed. Right? So the first thing that you want to consider in the key management system is how requests are authorized into that system. And so the that's basically the first hurdle that you have to go through is you need to build the key management and the cryptographic operations around that. But you also need to build the authorization layer. And so what we chose to do is really go all the way and build the authorization layer inside of a TE as well. I think it's a very important insight in the sense that putting a key inside an HSM is like very important step but that's like one step because as people know if you have a

blind signing oracle that basically can sign anything it can sign exactly the messages that you don't want and hardware wallets for example chose to handle it in a way that they do the hard work of parsing transaction data on the device and show it on the screen and then you have to click and authorize it. But that's one way to do it and it works for some cases, but you guys do something pretty different. >> Yeah. >> Do you need this to be like able to to do much more automated tasks too? Like what that example you just gave Kobe where it's like you're manually sitting there and you're clicking through like you Yeah, you can't automate that very easily, I'm assuming, without it being somewhat dangerous.

>> That's I think the the main reason why turnkey was born is to basically automate these things safely, right? So just like Kobe said, if you have an like a ledger device sitting next to you parsing the transaction, yeah, you can make the decision as a human to say this is going to go through or this isn't. And you know the authorization layer in an automated system needs to have also those kinds of rules that you currently have in your brain codified as and so that that's the other sort of piece of the puzzle that we needed to put together is this notion of policy, right? So how do you fold in policy data and policy execution in that picture and how do you roll this into the

authorization and authentication logic that also needs to live in an enclave right and then the the last piece that I think is kind of sort of completing the cycle is well once you have policies codified once you have your users and who has access codified how do you make sure that data like all together is protected and authentic and guaranteed sort of canonical so That's why you need also a secure enclave or a TE to sign that data regularly to make sure that you have the right version of the data. So we can get into into that kind of flow and in more detail later in the podcast maybe. But yeah, this is the problem of downgrade protection and making sure that your data and your policies and your users and the public

keys that you authorize are the public keys that you're authorizing and the policies that you think should be applied right now, not the policies that you wanted to apply last year, >> right? So basically summarizing a little bit like an HSM gets you protection against key theft, right? So that's good. like you your key cannot be excfiltrated, but it doesn't prevent key misuse. And so really the the length that we've gone through at turnkey is to protect people against key misuse. And there is a really big difference between key theft and key misuse in theory, but in practice for crypto, the difference is really not that big, right? If you authorize somebody to use your key,

well, you might as well give them the key because all the funds can be gone in in a minute. >> You can't revoke it. I guess can you >> exactly? Yeah. Okay. Yeah. Yeah. Crypto transactions are forever and so your funds are gone. That's also why I think doing cryptography and security for the crypto space is very different from doing >> uh cryptography and security for other traditional sector because of the irrevocable nature of it. >> I see. Just to simplify when you sign transactions using turnkey how is it different than signing transactions otherwise?

>> I mean in a lot of ways it's really similar. So you can think of signing a transaction with the ledger. Maybe you're interacting with some DAP. You have MetaMask. You have a ledger hooked up to your MetaMask. The DAP is actually creating the transaction, serializing it, and then kicking it off to a ledger. Similarly, turnkey can can kind of be a remote signer in a lot of contexts. So a DAP can be kind of directly hooked up. Turnkey can be embedded into that DOP and then the transaction generated on the DOP kicked over to turnkey which is similarly a remote signer and then ultimately turnkey can make a decision autonomously in this case or like without a human approving something whether or not to sign that transaction >> and this is based on the rules

>> or like these policies that you've just described. Okay. Is it is it dangerous to add this much kind of like programming though? Like whenever I hear about like anything extra complicated when you're like, "Oh, and we're going to add functionality that like has rules." Like isn't aren't those the places that like bugs pop up or like hacks happen? >> Definitely. >> Like I I always get this sense like the simpler the safer, but also obviously less functionality. So yeah, can you speak on that? >> Yeah, I think it's a balance. I think like you can push logic into the enclaves and and it's sort of you know I think a big part of the engineering challenge of of building turnkey is like what's the line? How do you simplify

what you ultim are ultimately pushing into the enclave? >> What does like what do you not have to push down into the enclave applications is like a big thing we talk about a lot internally. We have this threat model or way of thinking about things which is basically any logic that could be used to manipulate data, touch user keys, sign using a user key, you know, anything that's like scary has to be deployed into an enclave. >> Okay. >> And then anything that isn't scary doesn't have to be deployed in an enclave. It sounds simple, but that mental model I think is really important. And >> scary threshold >> kind of. Yeah. The scary threshold.

>> Yeah. And then I think it's also important to say that from a user point of view, we also give people flexibility to pick their own >> scariness level, right? So if you want to automate something and >> I don't know, you're just putting $10 worth of coins that you don't care about on that key, well, by all means, just give full access to that key and experiment and give that to an AI agent and >> tell the AI agent to have fun. But in the case of a you know customer like bridge well they probably have some policies and internal rules and controls such that you know there is a human in the loop when it gets too scary. And so at Turkey we have this >> halfh human half automation sort of

possibility with consensus rules. So when a transaction becomes too scary, however you want it to however you want to define it really, that becomes something that is kicked off to a layer of approval where a human has to go in the dashboard, review the transaction, could potentially run more checks on it and then you know give the final approval. So there is this you know escalation principle that we have built in the product for people who really need that. >> Yeah. And and I think that you know Jack what you said about treating it as a remote signer in the metal model is a really important one and I think that's probably also going to be useful to discuss that in the set of challenges that this introduces especially when you run things on your own machine and I've

seen people making this distinction which I liked when you run things on your own machine you have control of what runs there and what what code is run and where the keys are stored and so on. But when you use a remote signer, you really hand off a lot of power to someone else. >> Ooh, Jack, the way that you mentioned previously to think about it is as a remote serer in some mental model and I've seen people making the distinction which I liked which is that when you run code that for example manages keys on your own machine, you have a lot of control. you know body runs, you know where the keys are stored, you know all

of that. And when you use something like turnkey or tees or remoteies in general, you basically hand off a lot of power to some remote place and there is a set of challenges that is involved with doing that securely and one of them for example is things like remote stations that would be interesting to talk about. >> Right. So you're interacting with something, you need to trust this external something and you know you don't have full control over it. You definitely don't have physical access to it. And so in this case there's this TE's like one of the kind of like properties that make TE's super interesting is this thing called remote

attestation which is remotely so from afar. it from my computer. I can reach out to another machine that's external to my computer and I can attest to what is on it or I can attest to what is currently being run. In some cases, I can attest to kind of what was booted up. Different TEES, different kinds of secure hardware have different sort of forms of attestation. But the broad strokes is that you want to be able to prove that what you think you're interacting with is actually the thing that you are interacting with. And turnkey has done just a whole ton of like the engineering leg work to make this kind of as buttoned up as possible.

>> Yeah. And that includes, you know, both the specificity platform you're using is the correct one, but also the code that you're using is the correct one. And I know that you guys talked a lot about reproducible builds for example. So why is that important? >> Yeah. Okay. So a lot of times people will use tees. They'll they'll say we're going to we're going to leverage TE in our backend architecture and they build an artifact in a CI pipeline somewhere. They deploy it into the TE and then they say look we're using a TE it's everything's secure.

>> Um >> but no one can see inside the TE. I guess >> exactly no one can see inside the TE. No one knows uh what actually built the thing that's running inside the TE. >> But hey, you get a signature on a code hash. Is that not enough? >> Yeah. Yeah, you get you get some signature on on on the the hash. You say, "Hey, look, my my machine built this thing. Isn't that good?" But then it's like what what was the compiler that was running the thing that built the thing? You know, you kind of start peeling back the layers of the onion and and you say at some point I'm trusting something opaque. And you know, kind of the the foundation of what I'm trusting is something opaque. And that's you're you're ultimately then just trusting

something that that you know, you can't really trust. And so turnkeys put in a ton of effort into reproducible builds. And I think even within reproducible builds, there's a huge spectrum of of what what this means. Broadly, reproducible builds is like you take a piece of source code, you compile it, and you get the same artifact. So you get the same thing every single time you build it. And that's true if I build on my machine or Kobe built on his machine, >> etc. And this is sort of counterintuitively like not always the case. So most software when you compile it there's like linking order can can change the the eventual artifact or time stamps can leak into the compilation process or you know a whole host of

other things can can happen that means that the eventual artifact isn't deterministic and so it's it's kind of a pretty tricky thing to to actually figure out how to make something fully reproducible. The critical thing though is a lot of times people they they talk about reproducibility like what we would call last mile reproducibility which is you take a particular piece of application source code and then compile it and get the same artifact. Turnkey has kind of gone way way way deeper than that. And we go all the way down to not just like the application source code but the compilers that are building the application source code, the operating system in in this case Quarm OS which runs in our enclaves. um all the way

back to you know build environments and tool chains that are like you know decades old at this point. So we've we've kind of dug down to the end of the rabbit hole of of reproducibility and gotten to this very very minimal kind of like original foundation um which is literally 190 bytes of assembly code which is like wellknown and audited and then from there you can bootstrap up to kind of these intermediate build systems compilers and then eventually to modern rust or go or or you know other things. >> It's all created in this reproducible way like you're able to replicate no matter who runs it. can always get the same output.

>> Exactly. And so this is important. Basically then our intention is we're going to open source huge chunks of turnkey source code and then the goal is like we're running something in inside turnkeys back end and then anybody in the world should be able to take that compile it get the resulting artifact and then remotely attest that our enclaves are actually running the things we claim. By the way, one analogy that I would make to the ZK world is that running in T is without doing that is somewhat equivalent to running a verifier for a circuit that you can see the circuit composition itself.

>> Ah, interesting. Going back to what you described about like I I almost want to understand what the kind of bad actor could do if you like if reproducibility has not been done and you sort of talked about this like what happens in the TE is unknown. what could actually be injected in there and like who does it or is it just like computer code breaks period? It's like an accidental thing. I'm just wondering if it could be like malicious and if so like but how do they get like if there's code running in a tea even if not reproducible but if like it was deployed with good intention you can't see into it. So like how does a bad actor either inject bad things into it or act badly in that space?

>> Yeah. So I think a really simple example of this is like hijacking entropy which is relevant for key generation. >> So let's say I was specifically trying to target you and I had full control over the enclaves. I could wait and say okay as soon as I see a key being generated for an account that has your email. I'm going to basically make it look like it's a it's a you know freshly generated key but actually I'm going to generate a key that I previously generated using a seed you know on my machine. >> Okay. and then it's returned to you. It's a it's sort of an address that you think is is fresh and new. You've deposited a bunch of funds on that, but actually I'm able to reproduce the generation of that address on my machine and can steal everything.

>> That's even happening though within the TE or is that happening on top of the TE? Is it sort of in between the user and the TE that you're kind of injecting it or is it like within it? >> No, if so this is all if I had the ability to fully control like enter key within the TE. Yeah, that would that would happen in the TE. Okay. Interesting. For some reason, I always think of it as like a very safe black box that like no one can touch, >> but it sounds like >> you can actually change it. You can change it. You can go in and do stuff. >> I mean, in that case, it would have basically the changing would have happened before it was deployed into the enclave.

>> Okay. Okay. So, it is the person deploying it in a way or it's in the deployment that this needs to be accessed. It's not post deployment someone goes into the te >> deployment build process all the stuff that happens between source code on GitHub to you're running the code. >> Okay. >> Maybe like the like building of the compiler from 10 years ago that that there's this I think worth >> long game. >> Yeah. Yeah. Yeah. Worth calling out here this this famous paper by a guy named Ken Thompson who's like a famous computer scientist. It's called reflections on trusting trust.

>> Definitely recommend reading it. paper. >> Yeah, really great paper and I think speaks exactly to this problem. >> Cool. All right. Now, going back to the reproducibility that you just introduced because as far as I understood like reproducibility makes something safe because or it's like it's a way to prove that things are safe. But in that case where a bad actor had added something, wouldn't it still be reproducible? Like wouldn't it reproduce the same way even if there's a bug in it? >> Yep, it would. it would be reproducible but at that point the intention is that people are able to audit what is being reproduced.

>> Okay. >> So going back to the example I used somewhere along the way there's source code that says you know if Anna's email then generate this particular address and people hopefully review the source code and say like hold on what's this doing? This seems really sketchy. This is like not the way turnkey should be operating. So something bad's going on. >> Would you be reproducing it outside of the TE when you're auditing it? Mhm. >> Okay. So, it's just like having Yeah. Sort of just like don't it's no trust me bro situation where it's like oh this is stuff in the tea don't worry about it.

>> You're like actually you can also run it outside of the tea and just see if there's anything wrong. >> I would also recommend reading something that I got inspired by which is Arnold's blog post around why TE's without reproducible builds make no sense. >> Is this the remote attestations are useless without reproducible builds? Yeah, exactly. Exactly. >> We're gonna add that in the show notes. >> And I think that gives a really nice overview of this problem. >> Yeah. I mean, I I think the one one thing that's important to conceptualize is basically this, you know, three-step process. You start with the source code, then you have an artifact, and on the other side of that artifact, you have a deployed artifact somewhere. If you have

source code to compile and review and then you produce an artifact from that, that's one step and that's basically what most people do with code reviews. And then once you want to go from an artifact to like a deployed artifact and running somewhere, having the insurance that this is actually done faithfully is what remote attestations really give you. And you can't really have a full end to end auditability of a system unless you have those two links because if you miss if you're missing one well the chain breaks right and so you're not able to really reason as a human about what is running because in order to reason about what is running you need to

reason about source code which is written by human as opposed to reviewing an artifact which is just you know binary garbage that is only executed by computers. So that really is kind of the the crux of the problem. It's this you know from source code to artifact from artifact to deployed computer. The first link is sort of you know on GitHub typically with social consensus. Second link is usually done with a blackbox secret operator within a company that usually nobody knows about and remote attestation sort of let you remove that trust that you have to have in the operators of the machine. And as an operator at Turnkey, I feel a lot safer

because I can remotely attest to what is running inside Turnkey. But as an end user, right, you could also do that and sort of be sure that Turnkey deploys what it's supposed to be deploying and not lying to you. >> Given that Turnkey and you sort of described this was like an it's more like an agnostic tool and people can choose, you know, how how much of this is in the TE. I'm sort of curious like when it comes to reproducible builds, do you have something built into your tool set that enables that? Like I I don't really understand if this is more like a concept or if it's something that turnkey is like offering or if it's like the way that you check if your software is right. Like is this like an auditing process, a tool or Yeah.

>> Yeah. So we haven't really said what we're doing for reproducible builds, but the solution that we've come up with and the thing that Jack described really well with, you know, this system that goes all the way down to compilers and compilers of compilers all the way down to the assembly seed that is called stage X, right? So stage X is an open source project and you can check it out. It's it's hosted on codeberg, I believe. So codeberg.com/stageex. Yeah. So this system is how we build software internally. So we have basically CI jobs and we have you know recipes to build software through stage X and so it's not just a check that we do after it is how we build software dayto-day and so we build our go applications our rest applications

>> even our NodeJS applications actually that we don't run in tees we still build them with stage because it's it's both sort of like a convenient build system and also something that provides reproducibility out of the box without us having to even think about So Kobe, this is a little bit of a question to you. This idea of using reproducible builds to prove sort of something that's secure and and trustworthy. Is that actually something we do in ZK as well or is there like some variation of this? So one thing that I mentioned before was that there is some sort of inherent reproducibility in the sense that verifiers for ZK programs they are tied to a specific program.

uh so some specific circuit let's say uh so there is some sort of code that runs that can only be verified for a specific program so that's something that we already have inherent in ZK >> what is maybe not inherent is what happens on the prover side so one kind of thing that's in the zeitgeist is that people say all right when you audit zk systems you only need to audit the verifier because the verifier is the one that is actually running or verifying the execution of a specific problem. That should be enough. And that might be true for many situations like any prover can produce a proof that verifies against

this audited verifier and you're good. Especially when things are not really zk like rollups, let's say. But when you start involving secrets, then it becomes more touchy. And I wrote something about it and again inspired by Arnold's blog post initially about what happens when your ZK system has let's say a mobile prover that has to rely on some secret data, your passport or even your secret keys or whatever. And in that situation, if you don't take some care to verify what is running on your phone, then that program can leak your secrets in a way

that is completely undetectable outside. Like it could look as any other proof that comes out of that system and it could leak your secrets to some actor that they're the only one that knows how to decrypt it or read it, let's say. So there is something that reproducible builds can help even in ZK >> especially on the prover side >> especially when it's zk zk what's actually private >> yes exactly >> huh >> yeah and there's also maybe worth mentioning the the recent paper right how to prove false statements it's something that came out like a few months ago that basically is an attack on on the same side it's the prover side

and it's a paper that explains in that in some cases if you don't audit the code that is running in the prover what it and and it's running the wrong circuit then it's actually able to prove to you something that isn't true and so that's obviously the case of like an attack and we can kind of think about ways to m mitigate it but the real way to mitigate that is to audit the prover code in the end and having reproducible builds >> and remote attestations help a ton with that because you know I just think zk and t's compose well together when they're used in that in this way. It's you know zk within t's is stronger than zk without t's >> and I think it's true in general of a

lot of computation that you consider critical or that you want to trust in some way. I think >> adding a layer of attestation and reproducibility is just net good for for security. Mhm. >> It's funny as you describe this, I just think of the sort of way I've been thinking about the Tx ZK so far, which has been mostly like ZK helps TE's. So you can prove things about TE's, what's happening inside the enclave with ZK. But what you're describing is like using T's in the proof generation almost like so then it's T's as part of the ZK flow.

>> That's cool. >> Yeah, there there are a lot of interesting combinations to be explored there. I think we'll see more work in the community around it. That's that's my hope at least. >> Is there ways to use turnkey or is this sort of just like conceptual? Maybe that's a good place to sort of start talking about how applicable TE's are and how far it could go because key management is just one of the application for TE's and obviously key management is a sort of critical workload that you care about a lot but what we're starting to do at turnkey is let people run arbitrary applications inside of TE's and so >> okay >> um I think running a ZK prover is something that we've talked about with a

customer they may end up doing it. Uh so we'll see. But yes, I think definitely we'll I think either have external applications running inside of turnkey and inside of our infrastructure with Cormos or you could also imagine turnkey taking a more firstparty approach to that and having a easy to use API around ZK verification or around ZK proving. We don't have in-house expertise on ZK right now and we don't have those primitives but I think it's definitely >> on the road map you know in the next like year or two to start exploring more primitives packaged inside of TE's and packaged around our API because you can then

>> sign but also proof stuff we've also talked about having encryption and decryption APIs right because that's something that's very adjacent to signing so any sort of critical cryptographic operation you might want to imagine I think they're safer when they're executed with trusted code inside of a trusted environment that you can attest and yeah I think generally the the space in the industry would be safer with a whole bunch of stuff run in TE's >> okay so maybe taking it on a different direction we solved let's say one problem now you you guys got the code deployed into the TE in a reproducible way and there is something running there but that's like not the end because

there's a lot to still be done there in terms of security. So what kind of attacks can happen? >> Yeah. Well, a bunch a bunch we're thinking through. One thing I think is worth worth flagging is as as we're deploying these remotely attestable machines basically prior to them being able to do anything in our back end, we need to ensure that they have a secret in them. So we need to basically ensure that they are able to represent themselves to other enclave applications to be trusted versions of an enclave application. They need to in some cases be able to decrypt state that is relevant for their application. So if you're going to sign with a private key

for instance, you need to be able to decrypt that private key inside of a trusted environment first before signing with it. And so in order to operate turnkey securely, a really big thing that we had to solve was how do we safely transport this secret material into the TE >> such that they're able to perform whatever we need them to perform in our back end. So that led us down this crazy path of using air gap machines to and kind of have portions of the key split in certain ways and kind of actually doing the remote attestation process on an air gap machine which itself is not necessarily trivial like so that a variety of people multiple people who are in control of portions of this key

are able to know that as they're about to provision the enclave with the secret material that it is a trusted real version of the enclave. and you know it's not some some fake insecure version of the enclave. >> Our deploy process is crazy and it is I think unlike most other companies um out there it's it's really complicated and you know has been a huge engineering effort for us to to get into a place that's consistent. >> For example, in one of the scenarios that that you mentioned you can work on old versions of data. So how do you guys prevent this kind of data downgrade attack?

>> Yeah. Okay. So taking a little bit of a step back here, one thing that maybe isn't super obvious when you're starting to think about TEES is that they are primarily stateless. There's not a disk attached to a to an enclave. You need to use traditional storage mechanisms to to have persistent data, which is really kind of critical in, you know, a reliable hosted application. And so you have to use something like a traditional database. And that database itself is not trusted, right? So we it's kind of a weird way of thinking. Most in most companies backends the database would be just like this pretty like trusted place. If you store something in it, it's what you what you think is there or what is there is kind of trusted. In turnkey, we we don't trust the database.

And I say that in quotes cuz like we rely on it for reliability. Obviously, if data disappears, it's it's bad. But we do a lot of verification as it gets ingested from this untrusted location, the database, into the trusted location, the secure enclave. So that's a whole pattern. We call that our verifiable data pattern. But essentially what we're doing is every time state is mutated, the mutation of that data is signed by one of the enclaves that we we're on. So that's that one's called the notorizer and then ultimately that gets persisted inside of the traditional database. the question you're asking Kobe and and Arno maybe you can go into a bit more detail actually into that that thing later on but I think that Kobe that question

you're asking is like how do we deal with old versions of the data that was valid and and basically how do we know that when we're operating on inside the enclave it's not old and it's actually canonical >> so let's just set up an attack here so say that I go in I make a turnkey account I generate a key in that account and I'm just testing so I like have an API key and there's no policies in place. The only policy is like my API key can can sign anything with this this key in here. And I do some testing. I'm like, okay, I build an application I I like. I get some policies in place to control access to it, batten down the hatches, and then I I want to go go live with it. So, I I put a bunch of money

into this key. How do we prevent against the initial state of the application or the the organization which is where my API key controlled everything from being considered a valid sort of state of the organization at a later date? That is a really tricky problem. We call that kind of attack a downgrade attack. So that's like we've progressed the state of the organization to a later state and then now I'm saying I'm downgrading to a prior previously valid state and and trying to you know how do we invalidate that at the current time. So the first version we had here was incredibly janky. I'll I'll say it it works but it was incredibly janky which was every you know interval let's call it every hour or something you go

through the entire set of organizations inside turnkey and you just rearize them. So you just say like if this was valid 10 minutes ago, it's still valid now and I'm going to resign it. >> And so what that meant was every hour or something, we were pumping our whole database through our system and just resigning everything constantly. >> Wow. >> It worked. >> It worked. It meant that every time we were going to operate on a piece of data, we knew it had been, you know, piped through the system for like within the past hour. So it was still valid, but it it definitely didn't scale. So we got to you know millions of wallets and suddenly everything started falling over. the current system. It's basically saying instead of having to refresh as we call it organizations every hour,

instead we're refreshing this Merkel tree and every time we're going to operate on one of these organizations instead of saying is this a recent version of an organization, we instead ask the question, is this a organization that belongs to a recently notorized version of a Merkel tree? So like a valid Merkel tree. So it essentially lets us collapse down the entire state of of turnkey into one Merkel tree which itself can then just be refreshed consistently. >> And you're still doing that like once an hour. Some part of the Merkel tree is being refreshed but doesn't have to be the whole >> the root of it.

>> Okay. >> Yeah. And we actually have a a blog post which I think will be out by the time this podcast comes out that goes into a lot more depth here. Definitely recommend checking it out. >> It's funny. I really realize I don't know that much about how tees work in the tea. Like you just said that they're stateless and I was like, "Oh, I thought like how do you program in there?" Like how do you do stuff? I actually completely have a like a bit of a false mental model of a little blackbox computer >> like a VM. >> Yeah. Like something little that you can like put programs into and it will do stuff. It will compute.

>> I think that's like a pretty like fair model. It's just you start kind of like start kind of like peeling back the layers here and you're like well okay if we don't trust this thing then that means we can't trust this thing and if we you know >> it has no state like there's no trust you can't put a trusted database or like they can't have any memory >> you have like volatile memory but but yeah not like persistent data yeah >> interesting >> yeah another big limitations of TE's are the way we use them is that there's no external connectivity so a te cannot reach out to the outside world at all.

Which makes the architecture very interesting, right? Because usually in in sort of internal architectures of companies, you see service A calling service B and service B calling service C and then all the way back up. So our architecture actually has to have what is called a coordinator which you know calls service A gets results from service A and then inject service A's result into service B and and and so on and so forth. So the the no connectivity is also a pretty big >> you can't do a sequence really you always need some coordinator in the middle >> not with enclaves. So basically enclaves in terms of like call graph have to be leaf nodes of the call graph which is interesting. So we have this uh star- shaped pattern with the coordinator at

the center and then all the enclaves around it. And so that's uh yeah pretty unusual pattern but not not too bad to work around. So given that these don't have this external connectivity out of the box, how do you handle that? Like because a lot of applications do need connectivity, right? They they would enjoy calls to other systems, especially in verifiable ways, especially those that have TLS involved within them. So how do you guys think about that? >> That's a good question. I think that's also I mean we we have written a blog post about that. So I recommend people check it out. But basically there is a way to make HTTPS requests from inside of an enclave to outside but it requires

a little bit of extra setup. Right? So typically enclave applications run inside of an isolated environment. They are connected to the outside world with a socket basically and so they only accept requests inbound. What we had to do was poke another socket through and run infrastructure outside of the enclave to be a proxy between the enclave code who needs connectivity and the outside world. I'm I'm going to skip over a little bit of detail, but essentially what is very important is you want connectivity and specifically like TLS requests to be trustworthy and the content to be authentic. So in order for that to be the case, you need the

TLS session keys to be handled within the TE, right? >> And the proxy that we run on the outside is only a layer 4 proxy. So at the TCP level, so basically what happens is the enclave establishes connection through the proxy at the layer 4. So establishes the TCP connection and then all of the application level, you know, protocol at the TLS level and HTTP level, etc., etc., All of that happens inside of the enclave through that proxied TCP connection. And so it is a little bit of an involved setup, but we have done it.

And the way we use it today at turnkey is to basically fetch the canonical signers of OIDC token to enable people to connect to turnkey and have authenticators that are linked to their Google Gmail account for example. And so part of the way we do that is through this bridge that we have in in our TLS fetcher enclave. So we have an enclave type called TLS fetcher. And the TLS fetcher is the only enclave type that has this external connectivity component essentially. But it does enable applications to opt into having some sort of external connectivity if they need to. By default, that's just not the case. So for our serer, for our policy engine, for notorizer, we don't have

that external connectivity piece. H could you ever combine that because you talked about having a coordinator sitting outside if you needed to do like a sequential thing. Would the external connectivity unit also be a coordinator if you needed that? >> Yeah, you could. Yeah. So, we do that as well. So, basically the the other pattern that you could do is >> fetch data from outside and have the coordinator fetch some data somewhere and then inject that data in an enclave. But then you have to think about the problem of how does the code inside of the enclave trust the data that's injected. Right? So it has to be signed by some component that you trust. And so in our threat model, the coordinator is not considered trusted. And so it it

becomes a little difficult to say, oh well, I I trust that the coordinator is going to do a good job injecting the canonical correct data. So that's why we had to do all these tricks to make sure that the TLS content is actually authentic. But it does work in some other cases. For example, if the user wants to inject a piece of data that they consider trusted, they could sign it with a key that they have and then we can inject that inside of the Enclave and the Enclave code can then verify that it was indeed signed by the user and so there's this trust relationship between the user and the enclave and that works. So it depends on the use case. So given that you now described how to do things like verifiable TLS and you know I know that you guys put a lot

of work into that how does this compared to the zikk side of things which is zkls >> or mpcs depends on how you want to >> sure so maybe we should frame that question on like how do you transfer trust from TLS which is basically like trust in the PI system that we have with certificate authorities and you know, certificates that live on servers, etc., etc. How do you transfer that over to something that is self-contained into a proof, right? And so T's, the way I described it is a way to do that because the T is handling the session keys, verifying the certificates and sort of the response authenticity inside of the

TE and then exchanging that with a signed package that you can then verify outside of the enclave. So that's one way to do it. ZKTLS is another system to do this, right? So, you exchange the sort of transcript that you have from the request pulling out to a proof about that transcript and then ZK is the way that you kind of like transfer that trust over to something that is self-contained that people can then verify. Again, I think ZK TLS versus TTLS like they don't have to be one or the other. I think it would be actually most secure to have both because ZK is super useful inside of the TE as well.

So an example use case that we can't solve right now is how do you make sure that private inputs or private outputs as part of TLS requests are correctly protected. So if I wanted to fetch the most recent Google OIDC signers, that is a very trivial use case because the input is basically just a public request to the Google URL. The output or the response is also public and not not sensitive. So we can do it in the way that we're doing it today by just like fetching the response, signing the response, we're good to go. A use case that is very difficult is something like

proving that you have more than $10,000 in your bank account balance, right? Because in that case, the TLS request goes to your bank with some sort of private session >> and it comes out with maybe your private balance that's $10,01 or maybe a million dollars, maybe a billion dollars. I don't know how rich people are, but so you don't want to disclose that, right? And and ZK is useful to obiscate parts of the response and make sure that you're not leaking information out to people that verify the proof.

>> Then that that makes sense. >> I want to go back to what you described, Jack, when you were talking about like how you you were putting the secret into the TE and like you have these processes to do that. Like that's about the way I've understood as like it's the transferring of a secret. It's not really transferring of code, but >> I'm assuming like if you're deploying code, are you doing it in a similar airgapped? Like I'm assuming there's a lot of security that would have to go into like the deployment. And then I kind of wonder about like upgrading. Do you also have to go through some sort of process to keep that secure?

>> Yeah, totally. So the code itself will be open right before too long. It's open to everybody who's going to be involved in the release process at turnkey right now. And you know the artifacts are deterministic or reproducible. And so if you have the source code you can make a the same artifact. So there's nothing really secret about producing the artifact which ultimately gets deployed into into the enclave. That that part is totally totally kind of like transparent. >> What is secret is inside of our applications there's this thing called a quorum key which is quorum OS is the operating system which which runs in or which runs all of turnkeys enclave applications. The quorum key then is kind of the only piece of state you need

to be able to do anything in our back end or for an enclave application to do anything in our back end. And yeah, that quorum key itself is is kind of everything in some senses. Like that's the thing that if you lose it, you can, you know, not recover funds actually. Yeah, >> some bad stuff could happen. >> Yeah, bad stuff could happen. Yeah. So, we're really really careful about how you kind of securely store that quorum key. >> Got it. And basically the process to reconstruct that quorum key inside the enclaves is really cumbersome and challenging and requires all of this airgapped stuff that we were talking about. One thing that I think is is not obvious if you're running enclave applications like a a backend and a highly available system based on enclave

applications is that you typically need to be able to like autoscale or like scale up and scale down the systems that you're running in the back end. So you're more requests than you're able to process given the machines you have running right now. You want to be able to add some more machines so you can process the the new requests that are coming in. And if it were the case that turnkeys engineers or operators needed to basically break out the air gap machines and you know remotely attest every new enclave instance that was coming online, we'd be super slow. We couldn't kind of like respond in real time to you know surges and requests.

And taking a step back, this is a a major problem with HSM. So a lot of, you know, the traditional kind of custodians and stuff that were based on HSM technology, this is a problem they have. Like they have physically racked HSM in a data center somewhere. And so if they're, you know, suddenly get a major surge in traffic, like sorry, you're out of luck. You got to wait for a new shipment of machines to come in, rack them, and put them online before you're actually going to be able to handle. >> And the other way around, if if they break, right? If they break, you have to e like emergency 2A go and replace these things. So yeah, that's >> like fun little anecdote. Like a lot of HSM actually have tamper like resistance basically baked in. So if you if you feel the chassis of the HSM being like

unscrewed or something, they'll zero themselves out. And so that can actually happen like someone walks by your cage in a data center and actually like bangs it, your HSMs can go offline. So like there's a lot of operational challenges physical machines. Yeah. But anyway, so we solved this problem using a process called key forwarding basically where either versions of the enclaves that are identical to one another or versions of you know kind of an old version of an enclave which is maintained by the same set of people for a new version of the enclave. They have a process by which they can essentially like exchange this core secret between each other after remotely attesting what is running on them. And that in turn allows us to

scale up or scale down the machine safely without needing to break out the machines and also simplifies the deployment process considerably. >> When it comes to the I'm just kind of going back again to that example where you had the machine and the air gap and you're deploying it. You talked a little bit about distributing parts of the key. Would that be like a DKG? this like a distributed key generation event that creates that or like I'm just curious if we've had that topic come up before on the show and I don't know if it's what you're talking about there. >> Yeah, we use Shamir's under the hood. I think there's like layers of of things that that we can talk through but fundamentally when we talk about splitting keys it's using shmere secret sharing which is like a you know very old battle tested algorithm for for

splitting keys in this case but can be used for splitting arbitrary data into components of which you need to end to reconstruct them. >> We've touched on a few different parts of the turnkey system but I'm sure there's parts that we're not as aware of. What are other things that you've built that people can use that sort of like allow for more I don't know functionality in this in key management and in working in groups? >> Yeah. So I guess we mentioned every enclave in turnkeys backend other than one which is our transaction parser enclave.

>> Okay. >> So transaction parser basically you you feed in you know serialized transactions into turnkey and then we do some stuff say can you sign this and then sign it. Well, that that stuff is basically taking this serialized transaction, parsing it into something that's more human readable, and then comparing that human readable thing against policies that humans have written to dictate whether certain kinds of transactions should be signed or not, and then ultimately making a decision and signing that transaction. >> That's like the human side of thing or like the legal side of thing basically.

>> Yeah, more human. It's I mean it's really like how do you control access like what kind if you're building an application how do you control what parts of the application can perform certain tasks or who in your back end or in your organization can perform certain things. >> Yeah. >> So I think one really cool example of this is we just rolled out AI parsing in in Ethereum and SPL parsing or IDL parsing in in Salana. So essentially what that means is users of turnkey or developers in turnkey can upload smart contract APIs to turnkey. So for instance say I upload the you know unis swap contract to turnkey and then you can write a policy that says you know Kobe can sign a transaction so long as

that transaction is only transferring assets in unis swap using this one trading pair. But if Kobe tries to call the transfer function on the USDC contract, he will be rejected. And so you can get like really really granular with the kinds of things that humans can do unilaterally or that machines can do unilaterally while not necessarily being able to have full control over the the assets. So we think this is like super important for setting up you know just safe access controls. Like this is actually one of the motivating instances that made me want to start turnkey was >> I was again at Polychain and it was I'd have these relatively young traders come to me and say, "Hey, I want to acquire a

position in some totally obscure crypto asset. Will you send me, you know, $20 million of USDC so I can go acquire this position?" And I'd be like, "Love the agency. Probably a good investment, but I'm not going to send you $20 million of USDC to your MetaMask. That's just not going to happen." And I was like, well, it'd be great if I could give them an API key or some tool so that they could trade but not necessarily be able to sweep the funds in a decentralized setting, >> like give them controls or rules as to how much they can interact with. >> Yeah. Like what can you do without giving you full control? And I think the same is true actually for AI agents which we haven't really talked about here but you can imagine all different kinds of applications where you'd want to say I want to give an agent some

capabilities with this key or this address but not all. >> Um and that's fully kind of you know you can control that in really granular setting using turnkeys policy engine and transaction parsing capabilities. >> Interesting. I mean actually the example that comes to my mind is like from the validator world where maybe you're running a validator maybe you also want to do voting which is like a very like it's something that maybe the person running the validator may not want to be doing the votes you could have somebody else on the team >> uh maybe something like this could be used >> yeah totally to I think it's a great example governance of all kinds yeah >> just a separation basically between use of key and and like long-term control of key >> it's a shame we're totally at time we don't have time really to cover this AI

case. There was an episode that I did with Tun talking to Kostas from SUI who had created this really interesting access control using ZK and Tun had all sorts of questions around AI and access control. I feel like yeah the more we dig into these I don't know like signing agents like having kind of different roles how do you define them within these cryp cryptographic systems within this software. Yeah, it's just coming up a lot. It's a shame we don't get a chance to talk about it today but maybe another time. So, we'll add a link to that episode in the show notes, but I do think it's worth another conversation uh for sure at some point. All right. Well, thank you, Jack Arno, for coming on the show and sharing with us the story of turnkey, digging back into TE's. I've

learned a bunch of things along the way. I thought I thought I knew TE's. Not really, but yeah, it was cool to to explore how you're working with them. >> Thank you. That was great. Thanks so much for having us. >> Thank you, guys. >> Thanks, Kobe. >> Thank you. And I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Hector. And to our listeners, thanks for listening. [Music]