arcurn

This is very helpful — thank you!

On #2, we have carried out security audits with Cure53[0] and others, which we are happy to share. We also have a root of trust which is provably embedded in the AWS Nitro System[1]

#1 and #3 are great suggestions which we will implement in our next website revamp. Thanks!

[0]: https://cure53.de/ [1]: https://evervault.com/blog/e3

This is mostly true, but even if somebody manages to get access to an application runtime there won't be a major data leakage issue using Evervault because all data has been encrypted using a key that our customers don't host.

All plaintext data processing happens on Evervault's infrastructure, so our customers don't have any runtimes that handle sensitive data in plaintext.

Thanks for pointing this out. I agree that the tone here doesn't align with what we want to commit to with our customers.

We'll do some work on improving this (probably removing the entire clause around waiving a right to claim) and ship the changes ASAP.

We encrypt data at the field level so your infrastructure (including code and database) never handles sensitive data in plaintext. We also help you manage the decryption keys, so rogue developers or data breaches are as close to inconsequential as they can possibly be.

Thanks for the comment — I understand the sentiment, but we invest a lot more effort in trying to persuade security pros and cryptographers through the technical and security features of the product itself.

The people making the decision to use a product like Evervault isn't always a technical/security audience, so it's a tricky balance to navigate. We want both engineers and non-engineers to understand why using Evervault is important, so sometimes we fall short. This feedback is much appreciated though, and we'll definitely keep it in mind next time we do a website revamp (soon!). Thank you!

This is a great suggestion, thank you! We'll get to work creating this.

Hi! Founder of Evervault here.

You're totally right in saying the number of developers who are actively integrating encryption is pretty small as of today. What we're trying to do is improve developer experience to a point where encrypting all sensitive data is a no-brainer. Still early days here, but we're expending a lot of energy to make this happen.

Re: third-party dependency — we think the same way at Evervault. We bring third-party vendors into the mix if we think they can build something better than we could do ourselves, which is why we partnered with AWS on their Nitro Enclaves[0] product. Our root of trust is the AWS Nitro System. For customers who still aren't comfortable with us managing their security posture, we also offer on-prem and in-VPC options.

[0]: https://evervault.com/blog/e3

Yep, but there will be no variance in timing from the end user's perspective (regardless of what payload they send to E3) because neither encryption results nor timing data get returned to the end user.

Yep! All dependencies etc. are cached locally on a build machine so everything's deterministic.

Sure! Our model is focused on making sure that data gets encrypted before it hits our customers' infrastructure, so that there's nowhere on the backend where the data exists in plaintext. This isolates developers from misconfiguration and key management.

Yep, but the binary running in the enclave has access to both the attestation document (including PCRs) directly from Nitro as well as a mechanism to fetch IAM policies and verify that they are from the genuine IAM server (verify the TLS CA).

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.)

Yes! You might be thinking of node-secureworker[0]. We've been the maintainers for the last couple of years, but haven't been using it in production (concerns around Intel SGX)

[0]: https://github.com/evervault/node-secureworker

Yep, I think that makes sense. Certain use cases will have a need for some kind of on-prem/HSM approach, less from a practical perspective but more from a "doomsday modelling" perspective. Reminds me of the "nobody ever got fired for buying IBM" adage :)

Hey Danny, correct — we do not currently expose attestations to consumers. Over time, this is something we absolutely plan on doing.

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!

Thanks for commenting! One thing worth clarifying before diving into specifics is that Evervault doesn't store user data. We do store encryption keys, but the model is that our customers store encrypted data but not keys; Evervault stores keys but not encrypted data.

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.

Hey Danny, I completely agree. Full end-to-end encryption is the ideal scenario.

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.

[0]: https://signal.org/blog/secure-value-recovery/

Makes sense — the practical answer is: it doesn't. This is the eternal debate with TEEs. At some point, a company/fab/service provider has to be trusted to be acting in good faith. HSMs have existed for a very long time, and compliance approaches like FIPS 140-2 have been (although painful) quite successful.

When compared with other TEE alternatives like Intel SGX and AMD SEV, we are extremely confident that AWS Nitro Enclaves is the best choice.

> That sounds interesting. I'd like to test this hypothesis sometime ;)

That sounds great! Feel free to shoot me an email on [email protected] 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.

Thanks for the question! I addressed some of this in an answer above: https://news.ycombinator.com/item?id=28129362

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.

Hi there, our current root of trust is the AWS Nitro Security Chip. This means that if there was some kind of rogue supply chain within AWS' procurement + installation of these chips, the root of trust could be tampered with. We've spent a lot of time with the AWS team and have been deeply impressed by the thought they have put into this, to the point that we trusted them with something as security-critical as Evervault. They have also worked with us on our specific implementation, which was extremely helpful.

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!

Good point! We can safely isolate ourselves from any timing leaks by E3 because all E3 requests with potential timing leaks simply get transparently tunnelled to the end destination (e.g. an API you're passing through Relay), so a malicious end user can not determine if there was a crypto error and, specifically, how long that crypto error took to happen.

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.

Hi there, thanks for the question!

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 [email protected]

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-det...

[2]: https://aws.amazon.com/ec2/nitro/nitro-enclaves/