Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering with Enclaves

onefootprint.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Engineering with Enclaves

#11

Post by Veserv »

sudhirj wrote: post #10
Veserv wrote: post #9

Earlier quoted context omitted.

How did you verify and validate that a AWS Nitro Enclave actually provides isolation and attestation guarantees? Do they provide certifications or audits confirming conformance to multi-level security guarantees? Or do they provide you detailed specifications allowing you to evaluate that yourselves? Did you run red team exercises that resulted in no detected deficiencies as would be required by a multi-level securit…

Trust in AWS and Nitro HyperVisor system is taken for granted here, if that’s what you mean. We don’t necessarily examine AWS’s code or hardware, we’ll just have to take their word for it. Which is what we and our customers do already, when we run our workloads on it. We know this is a problem, but this is where we’re ok with drawing the line. If you’ve seen Reflections on Trusting Trust you’ll know we have to draw t…

Do they provide any third party certifications with teeth, legally binding guarantees, or contractual guarantees supporting the claims you are relying on?

Re: Engineering with Enclaves

#12

Post by sudhirj »

Veserv wrote: post #11
sudhirj wrote: post #10

Earlier quoted context omitted.

Trust in AWS and Nitro HyperVisor system is taken for granted here, if that’s what you mean. We don’t necessarily examine AWS’s code or hardware, we’ll just have to take their word for it. Which is what we and our customers do already, when we run our workloads on it. We know this is a problem, but this is where we’re ok with drawing the line. If you’ve seen Reflections on Trusting Trust you’ll know we have to draw t…

Do they provide any third party certifications with teeth, legally binding guarantees, or contractual guarantees supporting the claims you are relying on?

Not right now, no. From what I've seen from our previous suppliers (HSMs from Thales) no one will take on liability (if that's what you mean). The trust instead relies on the FIPS-140 certification process - certified devices are sold as-is.

In the case of the cloud I haven't seen FIPS certification of any of the internal systems from cloud providers yet.

This need for certification needs to be balanced against usability - it's relatively easier to certify a hardware design that has no compute, or a physically isolated CPU and memory like a SEE Machine, but it's also much less useful.

We prefer general purpose machines that have the same strength barriers that we already know are being deployed to protect customers from each other, that are being probed and tested all day every day both by AWS internally and by bad actors trying to steal other people's data. The lack of known pending exploits, continuous patching by AWS and being battle tested on a massive scale is more important to us than a FIPS certification at this point. Although if AWS managed to get FIPS to certify the Nitro system it would be a big plus.

Re: Engineering with Enclaves

#13

Post by Veserv »

sudhirj wrote: post #12
Veserv wrote: post #11

Earlier quoted context omitted.

Do they provide any third party certifications with teeth, legally binding guarantees, or contractual guarantees supporting the claims you are relying on?

Not right now, no. From what I've seen from our previous suppliers (HSMs from Thales) no one will take on liability (if that's what you mean). The trust instead relies on the FIPS-140 certification process - certified devices are sold as-is. In the case of the cloud I haven't seen FIPS certification of any of the internal systems from cloud providers yet. This need for certification needs to be balanced against usabi…

Thank you for the replies. It helps confirm my belief that AWS is just peddling the same security bullshit as everybody else and people keep falling for it.

Literally everybody has been promising general purpose machine isolation for decades and basically every one of them has failed. Actually designing such a system is a extraordinary claim demanding extraordinary evidence. Actual standards that can actually distinguish such a property such as the Common Criteria at EAL 6 and 7 require rigorous verification work such as formal proofs of correctness to actually positively assert such properties. It is ridiculous that people keep believing such claims without any guarantees, verifications, or audits when everything uncertified is so catastrophically bad at achieving isolation.

To quote Theo de Raadt:

“You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it.“

Re: Engineering with Enclaves

#14

Post by s_dev »

sudhirj wrote: post #8

My team and I are deploying a zero trust independently verifiable secret forwarding system on AWS Nitro Enclave, please ask me anything. The idea is basic secret forwarding - you want to send a secret to many destinations, but find it too cumbersome to encrypt it with each destination’s public key, or you might not have all the public keys in hand. To address this, we provide you with a code base running inside a Nit…

Evervault?

Re: Engineering with Enclaves

#15

Post by danpalmer »

Veserv wrote: post #13
sudhirj wrote: post #12

Earlier quoted context omitted.

Not right now, no. From what I've seen from our previous suppliers (HSMs from Thales) no one will take on liability (if that's what you mean). The trust instead relies on the FIPS-140 certification process - certified devices are sold as-is. In the case of the cloud I haven't seen FIPS certification of any of the internal systems from cloud providers yet. This need for certification needs to be balanced against usabi…

Thank you for the replies. It helps confirm my belief that AWS is just peddling the same security bullshit as everybody else and people keep falling for it. Literally everybody has been promising general purpose machine isolation for decades and basically every one of them has failed. Actually designing such a system is a extraordinary claim demanding extraordinary evidence. Actual standards that can actually disting…

Having seen the FIPS certification process happening for a popular brand of HSM (as an outside observer on the attack side), I’d put a fair bit of trust in these systems.

Very good isolation at all layers, formal verification, highly resistant to tampering, fuzzing, and so on. Every single part was locked down in a very thoughtful way.

There may be no legal liability with the purchase contracts, but these manufacturers certainly seem to approach the problem with the level of consideration that I’d hope for given the importance of the technology.

Re: Engineering with Enclaves

#16

Post by sudhirj »

s_dev wrote: post #14
sudhirj wrote: post #8

My team and I are deploying a zero trust independently verifiable secret forwarding system on AWS Nitro Enclave, please ask me anything. The idea is basic secret forwarding - you want to send a secret to many destinations, but find it too cumbersome to encrypt it with each destination’s public key, or you might not have all the public keys in hand. To address this, we provide you with a code base running inside a Nit…

Evervault?

No, QubeWire https://www.qubewire.com/

Re: Engineering with Enclaves

#17

Post by Veserv »

danpalmer wrote: post #15
Veserv wrote: post #13

Earlier quoted context omitted.

Thank you for the replies. It helps confirm my belief that AWS is just peddling the same security bullshit as everybody else and people keep falling for it. Literally everybody has been promising general purpose machine isolation for decades and basically every one of them has failed. Actually designing such a system is a extraordinary claim demanding extraordinary evidence. Actual standards that can actually disting…

Having seen the FIPS certification process happening for a popular brand of HSM (as an outside observer on the attack side), I’d put a fair bit of trust in these systems. Very good isolation at all layers, formal verification, highly resistant to tampering, fuzzing, and so on. Every single part was locked down in a very thoughtful way. There may be no legal liability with the purchase contracts, but these manufacture…

Except they were discussing AWS which does not have FIPS certification. In fact, it has no third party certification of any security value, they did no first party verification, there are no public binding guarantees, and no private guarantees. There is nothing but Amazon’s marketing literature and wishful thinking backing the claims of its security. Amazon would never stand by the claim that it encourages people mindlessly propagate, that AWS provides the multi-level security actually required for general purpose shared tenancy as they are 100% incapable of delivering it and they know it.

Re: Engineering with Enclaves

#18

Post by Thom2000 »

sudhirj wrote: post #8

My team and I are deploying a zero trust independently verifiable secret forwarding system on AWS Nitro Enclave, please ask me anything. The idea is basic secret forwarding - you want to send a secret to many destinations, but find it too cumbersome to encrypt it with each destination’s public key, or you might not have all the public keys in hand. To address this, we provide you with a code base running inside a Nit…

It seems like everything you have described could be done with TPM: creating a signing key for TLS mutual authentication (against the secret store) with policy that allows using that key only if system configuration did not change (PCR values stay consistent). Additionally TPMs allow remote attestation (via quotes and endorsement keys).

So I'm wondering what's the advantage of Nitro Enclaves? Better out of the box tooling?

Re: Engineering with Enclaves

#19

Post by danpalmer »

Veserv wrote: post #17
danpalmer wrote: post #15

Earlier quoted context omitted.

Having seen the FIPS certification process happening for a popular brand of HSM (as an outside observer on the attack side), I’d put a fair bit of trust in these systems. Very good isolation at all layers, formal verification, highly resistant to tampering, fuzzing, and so on. Every single part was locked down in a very thoughtful way. There may be no legal liability with the purchase contracts, but these manufacture…

Except they were discussing AWS which does not have FIPS certification. In fact, it has no third party certification of any security value, they did no first party verification, there are no public binding guarantees, and no private guarantees. There is nothing but Amazon’s marketing literature and wishful thinking backing the claims of its security. Amazon would never stand by the claim that it encourages people min…

Apologies I misread the criticism and thought Amazon had FIPS, but that people weren't happy with that.

It sounds like Amazon should be getting that! I wonder if perhaps it's just ill-suited to service providers, and only really workable for hardware.

Re: Engineering with Enclaves

#20

Post by lxgr »

Veserv wrote: post #13
sudhirj wrote: post #12

Earlier quoted context omitted.

Not right now, no. From what I've seen from our previous suppliers (HSMs from Thales) no one will take on liability (if that's what you mean). The trust instead relies on the FIPS-140 certification process - certified devices are sold as-is. In the case of the cloud I haven't seen FIPS certification of any of the internal systems from cloud providers yet. This need for certification needs to be balanced against usabi…

Thank you for the replies. It helps confirm my belief that AWS is just peddling the same security bullshit as everybody else and people keep falling for it. Literally everybody has been promising general purpose machine isolation for decades and basically every one of them has failed. Actually designing such a system is a extraordinary claim demanding extraordinary evidence. Actual standards that can actually disting…

Nobody that knows what they are talking about is making claims like "system x does not have any security holes". It's all about threat models, probabilities, and ultimately tradeoffs.

Consider a scenario where you need to compute some a function of secret data, but unfortunately that function isn't of the shape that any CC- or FIPS-certified solution (HSM or otherwise) supports out of the box, and ordering one to be built against your specifications would eat through your budget for the next 15-20 years. Your choices roughly are:

- Use a HSM anyway, but only use it to encrypt the data (or its encryption key), and have your application servers decrypt, evaluate the function, return the result and delete the data from memory every time they need to? Then you're arguably just doing fancy encryption at rest.

- Use enclaves. Even though they are much less hardened than a CC certified and audited solution, let's say you assign some probability to the event that somebody compromises them and burns the corresponding 0-day on you. Would you assert that that probability is 1? If not, why not still do it?

And you can still store the actual data encryption keys in a HSM and any higher-level features that it does support! In fact, if you use your HSM in a pretty low-level way (i.e. with an interface like "decrypt data x using key k"), access to the HSM needs to be guarded carefully, and enclaves can be a candidate for that.

- Don't evaluate the function, or possibly don't even store the data in the first place. The only problem with enclaves, in my view, is if they would make people disregard this option due to the misunderstanding that "enclaves are perfectly secure". (This applies to any security technology, but the fancier/more magical a solution looks like or is marketed as, the higher the temptation.)

- Do none of the above, but still store the data and evaluate the function on your systems. This is arguably the norm today in most organizations.

Post reply on HN