How we built the Evervault Encryption Engine (E3)
In this technical retrospective (2021), @arcurn shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
The document is not clear how did you achieve goal #1 ("must verifiably not be able to access or decrypt data"). There are lots of low-level details about Rust and padding attacks, but ultimately your security model is:
We keep the keys in AWS KMS and we use AWS policies settings to ensure that only executable generated by our Github Action job can access those keys.
This immediately shows how the Evervault (or a hacker impersonating Evervault employee) can access or decrypt user data:
Option 1: Go to AWS dashboard and change that KMS policy to be less restrictive. Then you can fetch the keys directly using awscli or download them from console.
Option 1a: if you are using some IaaS solution (terraform, cloudformation etc..) you can take over this, it may be easier.
Option 2: Commit a code into E3 repo that exfilatrates the keys and have that code deployed. Enclaves cannot connect to internet, so you'll have to be a bit creative -- perhaps encrypting a string "HELLO123" should produce a master key?
Option 3: If you cannot commit a code without someone noticing, go to Github settings and get all the environment/secrets from the repo. Then find an ssh key used to manage the self-hosted action runner which signs the images. Once you have those, you should be able to run the action steps locally on your repo.
It is worth noting that this change could potentially leave implementations vulnerable to Bleichenbacher’s attack on PKCS#1 v1.5 RSA padding. In our implementation, these concerns are not an issue as there we have no access to any of the decrypt responses or stack traces.
You don't need those things to exploit a padding oracle. A timing leak is sufficient.
Unless you're doing what s2n does to blind response times of any potential timing leaks, you're probably still vulnerable.
https://github.com/aws/s2n-tls#timing-blinding ↗
You're probably not using s2n to talk to a Nitro enclave.
Not bad, but I use https://peacemakr.io ↗ because it's open-source https://github.com/peacemakr-io ↗ and actually solves the same problems with much less hastle and overhead.
Relay looks a lot like what Tanker (https://tanker.io/ ↗) does. Even the method seems quite similar. Why should I choose Evervault over Tanker ?
Didn't evervault get started on top of some open source work from a PhD student at Berkeley?
Can't remember what it was called but I think I remember seeing the repo on github
Hi all, founder of Evervault here.
We're building encryption infrastructure for developers. At the core of this infrastructure is our encryption engine, E3.
Today, we’re excited to share how we built it. Our blog[0] goes into more detail, but there's a quick summary below. We'd love to answer any questions you have!
``` - E3 is a simple encryption service for performing cryptographic operations with low latency, high scalability and extreme reliability. - E3 is where all cryptographic operations for Evervault services happen. - E3 ensures that Evervault never handles key material in environments that are not provably secure. - E3 is written in Rust.
``` We’re grateful to the AWS Nitro Enclaves team for welcoming us to be a closed preview design partner, and are delighted to have been featured in the Nitro Enclaves Press Release[1] and on the Landing Page[2].
Shane
[0]: https://evervault.com/blog/e3 ↗
[1]: https://press.aboutamazon.com/news-releases/news-release-details/aws-announces-general-availability-nitro-enclaves ↗
[2]: https://aws.amazon.com/ec2/nitro/nitro-enclaves/ ↗