# Vitra / TEEKit * _2025-09-29: v0.0.1 of [QVL](https://www.npmjs.com/package/@teekit/qvl) and [tunnel](https://www.npmjs.com/package/@teekit/tunnel) are now live!_ * _2025-10-24: v0.0.2 adds Hono support, additional typings, and a workerd-based runtime._ * _2025-10-28: Presented at the [Kernel research salon](https://x.com/Kernel0x/status/1982893398550863987). Thanks to our hosts!_ * _2025-11-05: Our friends at [Common Tools](https://common.tools) open-sourced a [remote attestation proof of concept](https://github.com/commontoolsinc/RATSnest/) using TEEKit._ * _2025-12-01: v0.0.4 adds support for TDX cloud deployments._ * _2025-12-13: v0.0.5 adds support for SEV-SNP and persistence._ --- Trusted execution environments (TEEs) are a technology for running verifiable server applications, with private data, without transaction costs. Rather than generating cryptographic proofs of correctness like ZKPs or signatures, TEEs use hardware extensions to *attest* that specific code is running on a device. These hardware extensions work like a security level above root. The manufacturer embeds the capability to *measure* what's running inside the kernel, and *sign* attestations to those measurements, from secure hardware baked into the CPU. If you accept the trust assumptions of TEEs, this means you can run any application that can run in a Docker container verifiably and privately, even from the developer, with only a [small overhead](https://www.intel.com/content/www/us/en/developer/articles/technical/trust-domain-extensions-on-4th-gen-xeon-processors.html?utm_source=chatgpt.com)[^2]. TEEs give you all the stages of [programmable cryptography](https://0xparc.org/blog/programmable-cryptography-1), including ZK, FHE, and IO, as well as other useful primitives like one-time signatures. ## User-verifiable TEEs TEEKit is a [minimal, end-to-end verifiable stack for TEEs](https://github.com/canvasxyz/teekit) with two components: 1) a verifiable tunnel for browser-to-TEE connections, and 2) a cloud VM that simplifies complex TEE setups. The tunnel lets frontends verify they've established an encrypted connection to a specific TEE, and prevents SSL proxies like Cloudflare from intercepting and modifying in-flight requests. This makes TEEs verifiable for untrusting browser clients, which can be pinned to immutable hosts like IPFS for maximum verifiability. The cloud VM is a simplified stack for deploying web applications to cloud TEE providers, e.g. Azure, AWS, GCP. We mentioned earlier that TEEs rely on trust assumptions; one reasonable assumption might be that we trust Google or Microsoft! (Related: This makes TEEs appropriate for processing private data or transactions, and inappropriate for infrastructure like uncensorable base-layer blockchains.) ### Demo You can try a simple demo at [teekit.vercel.app](https://teekit.vercel.app). ![image](https://hackmd.io/_uploads/r1eoo9Fhgg.png) The `MRTD` measurement is a hash of the initial state of the TEE. In this case, MRTD is the measurement for a TEEKit image built for Google Cloud. The `report_data` measurement contains additional data that our VM adds to the verification. Currently, it's just a hash of the public key that's used to establish our encrypted channel, but different VMs can encode additional info in `report_data`. ### @teekit/qvl To create this demo, we reimplemented [Intel TDX/SGX quote validation](https://www.npmjs.com/package/@teekit/qvl) in the browser using WebCrypto, to run full chain-of-trust verification from the Intel Root CA down to MRTD and report_data. We also implemented an extensive test suite, the most comprehensive of any quote validation library on Github, that verifies tens of quote samples across versions of SGX, TDX, and SEV-SNP. ### @teekit/tunnel Using the quote validation library, we implemented an [encrypted channel](https://www.npmjs.com/package/@teekit/tunnel) with key exchange, that implements drop-in replacements for the `fetch` and `WebSockets` APIs in JavaScript. Web applications can replace their existing fetch calls and WebSockets, or use a ServiceWorker that automatically intercepts fetch calls, and all traffic will be routed through the encrypted channel. ### @teekit/kettle The kettle runtime is a JS VM, built on Cloudflare's `workerd` runtime and an encrypted `sqlite` database, that makes it possible to deploy generic JS web applications. We use our own JS runtime to support multi-tenancy, upgradeability, and interoperability between applications, so that kettle applications can be forked and upgraded with public data persisting between upgrades. ### @teekit/images To deploy the kettle to cloud TEEs, we've created two VM images: - An Gramine SGX image which produces **hardware measurements** from SGX enclaves, combined with an attestation from a cloud provider like Azure. The user verifies these two measurements separately; we use an additional attestation from the cloud provider to show that SGX isn't running inside a potentially side-channeled environment. This is the "defense in depth" version. - A SEV-SNP image which produces **software measurements**. This version is bound by limitations in modern cloud-based confidential VMs, which rely on proprietary hypervisors and "virtual TPMs" to generate measurements. This is the "trust the cloud" version. The limitations here deserve more explanation: When a user connects to an SGX application, they verify a full chain-of-trust down to Intel's Root CA, which attests to SGX measurements of the kettle application code. When a user connects to a TDX or SEV-SNP application, they verify a proprietary JWT. The JWT is a Microsoft, Google, or AWS vTPM attestation, where *they* verify we're running inside a properly configured TEE. Cloud providers do not share how they perform this verification, and you generally cannot get a direct `MRTD` or SEV-SNP measurement for your application, because cloud providers use an OVMF firmware bootloader that gets measured before your application is loaded. In other words, vTPM attestations are black-box, closed-source systems that cannot be fully audited by users. (If the goal is to trust the cloud provider, maybe that's okay?) We'll go live with the Gramine SGX version first, and then figure out what to do with the SEV-SNP version. Maybe we'll use SGX to run JS kettles, and customize the SEV-SNP version to run Docker containers instead (our `workerd` build works quite well inside enclaves, but Docker containers require a confidential VM like SEV-SNP.). ## What's next? You can already deploy TEEs today on platforms like Phala, Oasis, and EigenCloud. So why write a new TEE stack? One reason is that proprietary TEE systems traditionally don't do a very good job at verifiability. While open frameworks are better, ones like Dstack introduce significant complexity from supporting bare-metal cloud providers and TDX.[^3] Early conversations suggest there's room for a focused, open stack for cloud TEEs that just gets deployment to AWS, GCP, and Azure right. This means developers can deploy cloud TEEs while adopting minimal new infrastructure. They can audit the TEE integration by reviewing just one repo, instead of a long chain of dependencies, and they can spin up their own VM in minutes, to test whether it's properly hardened. Today, TEE applications are deployed like E2E encryption commercially. Applications are often closed source, or publish only a whitepaper and audit. Sometimes they release only part of their verification flow, or they're missing key links in the chain of verifiability. But if we are going to deploy systems with real data at stake, we need TEEs that are simple and stable enough to verify end-to-end. This is important not only for security's sake, but for the quality of applications as well. Credible developers and users with reputation at stake care that the systems they're using actually protect their privacy, *even more so if private data is involved*, as opposed to just private finance. Fully verifiable TEEs are important for developers and users to close the loop, and build a space with real applications that move beyond hype and excitement, towards a solid foundation for broadly useful applications. --- _Acknowledgements: TEEKit is based in part on [SUAVE](https://writings.flashbots.net/suave-tee-coprocessor) and the initial version of [Dstack](https://collective.flashbots.net/t/dstack-speedrunning-a-p2p-confidential-vm/3876). Thanks to Andrew Miller and Xin Sun for conversations about kettles and private applications. Other parts of this system are based on prior work on the [Canvas VM](https://github.com/canvasxyz/canvas)._ [^2]: If you don't like the trust assumptions, there are still ways to leverage TEEs to get interesting forms of verifiability, through e.g. ZKPs. And while existing TEEs do not adequately protect against hardware adversaries, and efforts to build [more secure hardware](https://forum.teekettle.org/t/trustless-tee-overview-june-2025/67) are beginning. [^3]: TDX doesn't have sealing, which means that TDX-based clouds need to add additional key management servers and replication, which introduces a lot of complexity. SGX and SEV-SNP have been around for longer and support sealing out-of-the-box.