Introducing Enclavia
Most companies handling sensitive financial transactions, private keys or healthcare data are one compromised employee, one misconfigured cloud database or one subpoena away from exposing everything.
Trusted execution environments, also called enclaves, can fix this at the hardware level, but almost nobody's using them. Enclavia is launching to change that, and I'm here to explain why.
What an enclave actually is
The word has been used in geography to describe a piece of land cut-out from something larger. Like a country fully surrounded by another. In computer science it means an isolated computation environment, similar to a virtual machine, with two key properties:
- The surrounding "area", the operating system and even many hardware components, can't access or modify its memory in any way. The enclave's memory is always encrypted, at the CPU level, with a unique key. Not even the owner or operator of the physical machine can see what's inside.
- The enclave can produce an attestation, which is a cryptographic proof of what code is running inside it. Anyone can independently verify this proof.
Those two primitives could be leveraged by themselves or combined to achieve something powerful: a company processing sensitive data can guarantee that not even its employees or cloud provider can see it. Think of medical records, financial transactions, etc.
Secondly, the same company could also leverage attestations to prove to their customers that they are processing data privately. Their users could establish an end-to-end encrypted channel directly to the enclave, verify the attestation, and only then upload any sensitive data.
So why isn't everyone using them?
Two reasons.
The first is historical: until recently there weren't that many options to build enclaves. The only widely available solution was Intel SGX, which has been broken multiple times, and is especially painful to use. SGX doesn't run virtual machines, it can only launch binaries compiled with a special toolchain with memory measured in hundreds of megabytes.
The second is more important, and it's why Enclavia exists: as more powerful tools are being released, like AWS Nitro from Amazon and even hardware-level primitives like Intel TDX and AMD SEV-SNP, the ecosystem around them is still optimized for big enterprises. And even they struggle with the complexity of using enclaves: in a recent survey from the Confidential Computing Consortium over 84% of companies with 500-10000 employees claimed it's not a "why" problem but a "how" problem.
The deeper issue is that even those powerful enclave solutions still lack things most developers take for granted: to preserve isolation, enclaves have no networking and no storage. They have a single bi-directional channel with a "parent" instance, which is usually a normal virtual machine running on the same host.
Launching enclaves means managing two different VMs and proxying connections from the outside to the enclave just to replicate the functionality of a regular virtual machine. Then to actually take advantage of the primitives provided by enclave, the user would also have to build an end-to-end encryption protocol and properly validate attestations.
It's like shipping an app and asking every customer to re-implement TLS first. And as we all know, it's never a good idea to roll your own crypto.
What Enclavia does
Enclavia makes launching an enclave as simple as pushing a Docker container. Just write your code, in any language, push the image and we run it in a real enclave: we manage the parent VM, proxy connections for you and provide all the client-side tools to validate attestations and to establish end-to-end encrypted channels. Every build is reproducible and the libraries are open-source: you don't have to trust us.
We are starting with the bitcoin ecosystem because it's where the pain is most acute, and where the culture around privacy and security is best fit. Self-custody wallets, node operators, key-management infrastructure would all massively benefit from running sensitive code inside of enclaves.
Why you have nothing to lose
If you are already running software in a normal cloud virtual machine, moving to Enclavia is only a strict upgrade: in the worst case scenario, even if the end-to-end encryption and attestation were to be completely broken, it wouldn't be any worse than where you are now. The default thinking changes: you'd need reasons not to use an enclave.
Also knowing the bitcoin ecosystem well, I think this unlocks products that just weren't viable before: a self-custodial wallet provider could offer fast syncing and server-side monitoring of transactions, without actually seeing the user's balance or history.
I'm incredibly excited to be building this, in the next posts I'll describe the technical aspects of what we are building, such as our encrypted storage system.
— Alekos
CEO, Head of Engineering @ Enclavia