Six hard problems, one solution

An enclave isn't trustworthy because of one clever feature: it only is if every stage and every component come together to preserve the trust boundary.

Exactly a month ago I introduced Enclavia and promised the follow-up posts would get more into the technical details of what we are building. This is the first of a series, meant to give an overview of all the components Enclavia implements for our customers so that they can enjoy the best developer experience without sacrificing security.

An enclave isn't trustworthy because of one clever feature: it only is if every stage and every component come together to preserve the trust boundary. Building, deploying, connecting to the enclave are all critical phases where a quiet break could completely undermine its trust.

So here's what it actually takes to run a trusted enclave, end to end.

Six ways it can go wrong

1. Building the image. Before the enclave is ever reachable by your customers, your build has to be reproducible. This is key to making your setup truly "trustless": only if anyone can rebuild your image and confirm it matches your open-source code can they be sure there's no backdoor hiding inside. This matters so much that a whole project named WalletScrutiny exists purely to verify and reproduce open source bitcoin wallets. Your enclaves deserve the same level of transparency.
2. Deploying it. Enclaves are deliberately crippled to keep their attack surface tiny: no network, no storage, no serial console, no graphics. They are just a fully isolated virtual machine "tethered" to a parent, a regular EC2 VM that does have network and storage. So deploying an enclave really means deploying two VMs and maintaining the link between them, using the parent as a blind proxy that can neither read the traffic nor inject anything into it, because it sits outside the trust boundary.
3. Connecting to it. Most deployments terminate the TLS connection inside the enclave. That stops the host from monitoring the traffic, but TLS is the wrong tool to enforce a trust boundary. A valid certificate only proves you're talking to something that holds a cert for the domain. The vendor can mint another certificate outside the enclave, and so can your registrar, nameserver, any CA, your cloud provider, or a government agency. TLS protects you against the network. It does nothing against the operator.
4. Persisting data. Since enclaves don't have any disk and only boot off /dev/ram, storage has to be emulated by proxying reads and writes to the parent, which keeps data locally or in S3-style buckets. Everything must be encrypted and decrypted within the enclave, so from the outside it's just noise. But there's a subtler attack: the host can't read your data, yet it can quietly feed you an older version of it, a snapshot the enclave itself wrote previously. It's like a notary who can't read your contract but can hand you last year's copy instead of this year's, and you'd never know. This can be critical for the security of many protocols such as Lightning and ecash.
5. Talking to the outside world. Network egress works the same way as storage, proxied by the parent instance. A few solutions exist but they don't provide granular control over outbound traffic, which is important to restrict the fallout of a compromised enclave: if only a very limited set of IP addresses can be reached, the blast radius shrinks dramatically.
6. Upgrading it. Upgrades are difficult for two reasons. First, shipping new code changes your PCRs (Platform Configuration Registers, the hashes of your image that are baked into the attestation). This means all clients have to rotate to a new set of PCRs, or they'll reject the attestation during connection. This might imply updating the client just to bump the trusted hashes. Second, if storage is involved, the common pattern is to tie a KMS key to a specific set of PCRs, so that only that exact image can decrypt the volume. Changing PCRs means having to re-key the storage to a new key tied to the new hashes.

That's six separate places where the whole promise of an enclave can fall apart. It's the same story as the first post: to actually use these primitives, you end up re-implementing half of an operating system and a few sensitive crypto protocols, just to get back to where a normal VM started.

So we did all of it for you.

What we shipped

For you, none of the above exists. Deploying to Enclavia isn't any more difficult than running a regular Docker container: we abstract the whole thing away.

Here's how we solve each problem.

1. A reproducible builder, on Nix. A single cli command rebuilds the image locally, pinning the exact version of every dependency. Confirms the PCRs match the running instance in the Enclavia infrastructure. If the image is marked as public, anyone can reproduce it locally on their laptops.
2. Managed infrastructure without trust. We run everything so you don't have to, but we are not in your trust boundary, except for uptime. Every Enclavia helper running inside the enclave is open source and auditable. The code we run to schedule and manage instances is not, and it doesn't need to be: by definition the enclave is the trust boundary. It can't see your data, or alter your clients' connections.
3. An open-source client library, terminated inside the enclave. It's written in Rust, with bindings coming for WASM, Python, Kotlin, Swift and more. It opens a fully end-to-end encrypted channel terminated inside the enclave, almost like a Wireguard VPN running over a websocket, so browsers can connect too. Once the channel is up, it validates the attestation and compares it against the set of known PCRs (or any future trusted upgrades) and only then starts proxying requests, completely invisible to our infrastructure and Amazon's. For backward compatibility we also released a transparent HTTP proxy you can self host, so any client can talk to the enclave with termination inside your trusted local network.
4. A full, encrypted, rollback-proof filesystem. We give the application a full btrfs filesystem, encrypted, stored and backed up by our infrastructure. More importantly, we ship explicit anti-rollback: a cryptographic guarantee to your enclave that the data it's reading is the latest snapshot it wrote, not an older one replayed by a malicious host. This is one of my favorite pieces of what we've built so far and it deserves its own blog post at some point. Storage is off by default, to minimize the attack surface. It's only enabled if, during creation, you attach a storage volume to the enclave. On upgrades, we handle re-keying to a new KMS key automatically.
5. An emulated network interface with outbound firewall. Egress is disabled by default, but when allowed traffic is transparently proxied to the outside. You pick your DNS resolvers and provide a list of IPs, CIDRs, FQDNs and ports that your enclave should be able to connect to. The enclave runs a DNSSEC-validating resolver internally, so it will locally check every DNS lookup and the connection is opened only if the resolved IP:port matches an entry on your list.
6. A cryptographic chain of attestations for every upgrade. We build a chain that goes back to the genesis of your enclave: this lets you verify whether a new set of PCRs genuinely descends from a set you already trust. Every upgrade request is signed by a control key, which is either managed by our backend for convenience, or locally in your CLI or even Yubikey for extra security. Upgrades are staged for a window of time, allowing you and your customers to verify the PCRs via the reproducibility feature before it's too late. When it goes live, the upgrade is acknowledged by the old enclave, and a receipt is kept in the upgrade chain structure. A user trusting the old set of PCRs can validate this chain and trust the new set, knowing they have been authorized by the enclave they trusted. And, if you don't need any of this, you can also mark the enclave as un-upgradable at creation, which disables this mechanism entirely. A company would generally approach upgrades as follows:
   1. Tag a new release on GitHub.
   2. Build an enclave image from the release.
   3. Stage it to activate after a few days.
   4. Announce publicly the intention to upgrade to the new set of PCRs, giving the community a window of time to audit the code before it goes live.
   5. If the upgrade is not revoked, it will activate automatically.
   6. If the upgrade is malicious, the community has a window of time to react. For example, they can withdraw funds, delete personal data, etc.

Where this is going

None of this should be something you have to worry about, any more than you think about the OS kernel running on your laptop. That's our value proposition: take six genuinely hard problems, ship the best abstractions we can, and instantly upgrade the security of your infrastructure and your customers.

If any of this resonates with you, make sure to sign up to our waiting list below to access our private beta or be the first to know when we open up.

More soon.

— Alekos
CEO, Head of Engineering @ Enclavia