[arcurn]

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!

[tw04]

That doesn’t seem to answer the question. He isn’t asking how AWS protects against a supply chain attack, he’s asking how this protects against AWS lying about how nitro enclave functions, and/or intentionally giving themselves a back door into it.

[arcurn]

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.

[dannyw]

The solution then is proper end to end encryption, not the solution you masquerade.

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

[arcurn]

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/

[OrvalWintermute]

Perhaps what is needed is different levels of security that can scale according to varying requirements.

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.

[arcurn]

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