# How secure enclaves work Instead of a promise, we offer a mathematical guarantee that neither we nor anyone with server access can read your data. - Canonical: https://garlic.ai/blog/how-secure-enclaves-work - Markdown: https://garlic.ai/blog/how-secure-enclaves-work.md - Published: 2026-08-03 - Updated: 2026-08-03 - Author: Mukhamediyar Kudaikulov - Category: Privacy engineering - Tags: Secure enclaves, Attestation, Cryptography - Reading time: 6 min read - Keywords: secure enclave, confidential computing, public key cryptography, hardware attestation, trusted execution environment, PUF This article intentionally simplifies several concepts in cryptography and confidential computing. The goal is to build a mental model of why secure enclaves fundamentally change the privacy story. ## The problem Major LLM providers' privacy claim today is basically a pinky promise: "we don't read your prompts," "we don't train on your conversations." But in principle, in theory, someone with privileged server access could just look at your data. Nothing stops them architecturally, only policy. And this isn't hypothetical: in July 2026, shared Claude conversations, including legal strategy, source code, and crypto wallet keys, turned up in Google search results because a noindex tag was missing from one feature. Nobody at Anthropic read them; a config gap did the damage instead. That's the real failure mode of policy-based privacy: it only takes one mistake, anywhere in the stack, to expose you. What we do different is this: instead of a promise, we offer a mathematical guarantee that neither we nor anyone with server access can read your data. And this guarantee hinges on three components: public key cryptography, secure enclaves, and hardware security guarantees. We're going to build up the intuition behind each one first. If you're already familiar with these, feel free to skip ahead to how it all comes together. ## Public key cryptography A public/private key pair is just two numbers that are mathematically related, such that you can use the public one, give it out, distribute it, hand it to anyone, as part of an encryption algorithm. The decryption algorithm uses the private key instead. That private key has to be kept secret, known only to whoever is authorized, and expected, to read the data. In practice, this key pair isn't used to encrypt the whole conversation. It's used once, to deliver a symmetric key to whoever holds the private key. From there, both parties share that same symmetric key and switch to symmetric-key cryptography for the rest of the exchange, since symmetric cryptography is what lets you encrypt much larger payloads efficiently. That's why the handoff happens this way. One more term worth knowing: a signature. A signature is an attestation that a particular piece of data was written by the person or device claiming to have written it. Signing works almost the opposite way from encryption: the device or person signs using their private key, and the public key is what verifies the signature is correct. Concretely, a signature is a number attached to a message such that when you run the verification algorithm against the message and the public key, it produces the expected result. It is mathematically impossible to attach a number that checks out in verification unless the private signing key was actually used to generate it. ## Secure enclaves To understand this, first assume the hardware really is secure and isolated from the OS: nothing, not the OS, not an external wire, can inspect what's happening inside it. The next section covers why that's true. This hardware contains a master key, the ingredients for which are burned in by the manufacturer at fabrication. That master key is what's used to derive the public/private key pairs the enclave actually uses to communicate. Here's the part that matters most: the public keys generated this way are also signed by the hardware manufacturer. Literally: the big tech companies that manufacture these chips keep a public list online where you can look up a given public key and verify it really did come out of a secure enclave they built. That manufacturer's signature is the certificate we keep referring to. There's no separate certificate object; it's just the hardware provider's signature sitting on top of the enclave's public key. So when an external device talks to the enclave, the first thing the enclave does is hand over that certificate, the manufacturer's signature on its own public key. All your device has to do is check that signature against the manufacturer's public key, which is typically baked into your computer already, or trivially available online. If it validates, you now know the enclave's public key, and you know you can trust it. That's the whole basis for being able to talk to it privately. ## Why you can't just wire it up So why can't an attacker just solder a probe onto the chip, or have the OS quietly watch what it's doing? It comes down to how these things are manufactured. The master key doesn't sit around as ordinary stored data. It's tied to volatile SRAM state and physically unclonable functions, or PUFs, meaning the key only exists as active electrical current, or as microscopic, manufacturing-time irregularities in the silicon itself. Nothing you can read off a chip after the fact; it's not there unless the circuit is live. Two consequences fall out of that: Cutting the power erases it. Prying the chip open to attach a probe cuts power first, which erases the volatile state before anything can be read. It's too small to physically touch. The master key and the associated processing happen deep inside the silicon, at nanometer scale, thousands of times thinner than a human hair. You can't just attach a wire, a probe, or even a microscopic needle to a single transistor the way you could solder onto a circuit board. At that scale, physically reaching the circuitry without destroying or altering it is an engineering problem far beyond simply opening up the computer. So the moment you try to open the chip and tamper with it, everything on it turns to garbage: the key is gone before you could ever read it. You've just broken the computer, and you still don't have the key. A note on how this actually works Security chips protect master keys using volatile SRAM and PUFs. The key exists only as active electrical current or microscopic silicon imperfections. If an attacker physically opens the chip, internal power cuts instantly erase the memory, and structural shifts permanently alter the silicon, destroying the key before it can be read. ## How it all comes together Your client initiates a connection and asks the secure enclave to prove it's actually a secure enclave. The enclave responds with its certificate: the manufacturer's signature on the enclave's public key. Your client checks that signature against the manufacturer's public key, already on your device or easy to look up, confirming the certificate is valid. That also hands your client the enclave's real public key. Your client now encrypts a freshly generated symmetric key using the enclave's public key, and sends it over along with a MAC, a message authentication code: a tamper-resistance code functionally similar to a signature, but built on the symmetric key instead. The enclave decrypts the symmetric key using its private key. At that point, the handshake is done, both sides share a secret nobody else has, and you're ready to send data, encrypted from here on with fast symmetric cryptography. ## Why we can't read your data, physically or mathematically Eavesdrop on the wire? You get ciphertext. Garbage, without the private key. Forge the enclave and pretend to be it? You'd need a certificate the manufacturer never signed. Same problem, running through signature math instead. Physically wire into the chip? Covered above: you brick it before you ever learn the master key. If you think you've found a hole in any of this, please reach out to us; we want to know. But structurally, we can tell you almost no attack is possible here, or these chip manufacturers would be in a lot of trouble.