How we built the Evervault Encryption Engine (E3)
evervault.com
evervault.com
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.
The attacks you mention (correctly) base themselves on the security of the signing key used to sign the E3 binary. The security of this key is obviously extremely important, but is only one part of the attestation process. Nitro Enclaves exposes attestation documents with platform control registers (PCRs). PCR8 is a hash of the key used to sign the binary itself, but there are also 5 others which contain hashes of the specific binary that is being run as well as the in-memory state of the enclave. Combining these together, means that attestation focuses both on deployment integrity (and GitHub Actions is the weakest point here) as well as the code itself. This is why exposing the code that runs inside E3 is a major focus of ours.
Re: KMS policy integrity, having the enclave communicate with IAM with TLS certificate validation is one way of E3 proving to the end user providing keys/data that the enclave key has not been tampered with. It's a messy solution, but cryptographically robust assuming that the AWS Root CA has not been compromised.
Other options do not rely on compromising any encryption keys or production servers, they just need a developer's machine being compromised.
You are talking about PCR and hashes, and they are all good, but ultimately, it all ends up as a "Attestation" field in the request to AWS. And then it is evaluated against a policy, like that one: [0]. So what prevents someone from planting a trojan on arcurn's machine, waiting until they log into AWS console, and changing this policy to remove "Condition" block? Once this is done, anyone can fetch AWS keys and decrypt customer data.
And I don't think "TLS certificate validation" is going to help here, as it will be talking to authentic server. Nor checking of PCRs -- because this is done in that "condition" lock which is so easy to remove.
[0] https://docs.aws.amazon.com/enclaves/latest/user/kms.html
Making sure the IAM policy hasn't been tampered is just a case of adding logic to the enclave app to make sure that the IAM policy is configured correctly for that particular enclave (compare PCRs, make sure there's no wildcards, etc.)
The "dishonest Evervault" scenario is solved by us exposing the Nitro Enclaves attestation documents to customers (as well as E2E TLS where only the enclave has access to the plaintext). We currently only share source code + the corresponding platform control registers (PCRs) to prove that the E3 running is a "valid" E3 to enterprise customers, but over time we're expending a lot of energy to make these kind of proofs accessible to our smaller customers as well. Stay tuned!
When compared with other TEE alternatives like Intel SGX and AMD SEV, we are extremely confident that AWS Nitro Enclaves is the best choice.
Your data is not really encrypted if Amazon, Intel, or AMD can be compelled by a secret government order to decrypt it. All of these trusted execution environments... rely on a trusted party with master keys, i.e. Amazon, Intel, or AMD, who can reflash microcode and expose all plaintext trivially and silently.
It's. Not. Secure. Whatsoever. It's anti-encryption. It's just another version of the Clipper chip: https://en.wikipedia.org/wiki/Clipper_chip
The biggest challenge is how we can bridge the gap between how companies build software today (very little, if any encryption) and how companies will build software in the future. End-to-end encryption is great for scenarios where it's a closed ecosystem (e.g. messaging apps like Signal — although Signal actually trust Intel SGX as a single point of failure[0]), but modern web applications are not that. They interact with third-party APIs, they have UIs; they are not built in complete isolation.
Things like Fully Homomorphic Encryption are exciting (and FHE is ultimately the endgoal for how we built Evervault), but still a long way off being practical for a typical company to build general purpose software with. It also doesn't solve the data sharing scenario — certain companies just can't escape using third-party APIs and services.
Our mission is to encrypt the web, so the first hurdle we have to cross is getting developers who would normally not think about encryption to bake it into their software from day one. We think TEEs, and specifically Nitro Enclaves are the best way to make that happen.
If a better solution comes along, we'll be the first ones to pounce.
off-prem vice on prem
cloud vs discrete
cloud vendor vs Evervault vs customer only HSMs
Speaking of my specific requirements for HSMs, am most interested in high security use-cases for which cloud, off-prem, are less of a match.
I do think there is value in using Nitro for some of the use-cases, because some HSMs have astonishingly low MTBF.
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.
Shane
[0]: https://evervault.com/blog/e3
[1]: https://press.aboutamazon.com/news-releases/news-release-det...
- I skimmed the article, and I honestly am not sure who the customer is. AWS customers I suppose? It would be nice to have a quick "TL;DR" section so I can quickly tell if I am the right customer. (I'm also not an AWS customer, so maybe I just don't understand the jargon).
- A big pet peeve of mine when reading security related things is not seeing security assumptions. It would be nice to understand what your infrastructure does and does not protect against.
Our customers are mostly developers working at startups which process high volumes of sensitive data (things like payment details, healthcare data, credentials etc.). We abstract away all of the infrastructure that E3 runs on, so we don't have any requirements for where our customers our hosted. Our customers run on a very diverse range of stacks/clouds, so being cloud-agnostic was a key design requirement.
The core security assumption with Evervault is that your API key is reasonably well managed. API keys can be easily rotated in our dashboard, but having encrypted data and an Evervault API key could potentially lead to data leakage. Over time, we plan on adding some cool features around data leakage whereby we can proactively block data exfiltration/leakage. More on this soon!
A simple model for how security with Evervault works is: you store encrypted data, but not keys; Evervault stores keys, but no data. This creates a nice dual-responsibility model which far exceeds what most companies can do today.
Feel free to email directly if you have any other questions! I'm on shane@evervault.com
If I may say, that would be great to have as an up front summary!
The summary version is that we share source code and platform control registers (PCRs) with enterprise customers who need these kind of security guarantees, and also expose the Nitro Enclaves attestation documents to them so they can establish secure channels with E3 in a provable way.
Or maybe you're a government honeypot, like Crypto AG, or the numerous other cryptography companies that turned out to actually be mass decryption companies.
If you're building an encryption company, the onus is on you to prove it. BitWarden for example is fully open source, and you can self host the server.
One thing worth focusing on is that Evervault is built for developers. Developers do not have to build using Evervault, so a developer using Evervault to mislead their customers about their security isn't something we focus heavily on. There are much easier ways for developers to mislead customers about their security, but that's a conversation for another time :)
I completely agree re: the onus being on us to prove it. It's something we're actively trying to improve, and sharing how we built E3 is just the beginning of us sharing more about how we design & build. Transparency is an existential requirement for us to become a standard part of the developer toolkit. Watch this space!
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.
More broadly, though, we don't currently use RSA and chose ECDH instead — so padding oracles aren't something we have to worry too much about. We also have similar safety models for things like invalid curve attacks.
That sounds interesting. I'd like to test this hypothesis sometime ;)
> We also have similar safety models for things like invalid curve attacks.
What is your defense against invalid curve attacks exactly? I'm very curious about that (although your target audience largely won't care, so this post probably doesn't need to be updated).
Two defenses that work:
1. Always check that the (x, y) coordinate is a solution for the curve equation
2. Use compressed public key points
I prefer option 2 (especially since the patent on point compression expired years ago), but option 1 works.
That sounds great! Feel free to shoot me an email on shane@evervault.com if you'd like to get further into the weeds :)
Our main defence against invalid curves is compressed public key points. It's not often that security mitigations also give some other nice advantages (smaller public keys!), but for this scenario it made total sense.
This is the point in Slack when I usually reply with a sparkly heart emoji.
I'll get in touch sometime. This is a busy month for me so I won't have a lot of spare cycles, but if I catch a break it might be fun to test. :D
Can't remember what it was called but I think I remember seeing the repo on github