arcurn
Joined 5 years ago
Karma
60
Submissions
29
Member since
Aug 10
Recent submissions
Comment · 4 years ago
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!
Comment · 4 years ago
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.
Comment · 4 years ago
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.
Comment · 4 years ago
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.
Comment · 4 years ago
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!
Comment · 4 years ago
This is a great suggestion, thank you! We'll get to work creating this.
Comment · 4 years ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
Yep! All dependencies etc. are cached locally on a build machine so everything's deterministic.
Comment · 5 years ago
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.
Comment · 5 years ago
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.)
https://evervault.com
[email protected]