Engineering with Enclaves • Hacker News Board

Re: Engineering with Enclaves

#21

Post by electroly » Tue, Apr 04, 2023, 1:40 PM UTC

Thom2000 wrote: post #18

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 to…

I'm not OP, but AWS introduced Nitro Enclaves about two years before Nitro TPM, which is a relatively recent addition. It's likely that TPM wasn't available in AWS at the time of OP's original development. Nitro TPM is not available at all on Graviton 1 or 2; only the newest Graviton 3.

Re: Engineering with Enclaves

#22

Post by Thom2000 » Tue, Apr 04, 2023, 2:03 PM UTC

electroly wrote: post #21

Thom2000 wrote: post #18

Earlier quoted context omitted.

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 to…

I'm not OP, but AWS introduced Nitro Enclaves about two years before Nitro TPM, which is a relatively recent addition. It's likely that TPM wasn't available in AWS at the time of OP's original development. Nitro TPM is not available at all on Graviton 1 or 2; only the newest Graviton 3.

That clarifies some matters - thanks!

Re: Engineering with Enclaves

#23

Post by sudhirj » Tue, Apr 04, 2023, 3:03 PM UTC

Thom2000 wrote: post #18

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 to…

I’ll check out the TPM, but our big draw with the Enclave system is being able to run general purpose code (Python / Go) inside a secure isolated environment. The earlier system we had was SEE machine on a HSM and required a special compiler to run - I haven’t seen the Nitro TPM just yet, but I doubt I’d be able run a container inside the boundaries of the TPM.

Re: Engineering with Enclaves

#24

Post by sudhirj » Tue, Apr 04, 2023, 3:06 PM UTC

danpalmer wrote: post #19

Veserv wrote: post #17

Earlier quoted context omitted.

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.

I don’t think there’s any specs to certify against for hypervisors. Think other AWS offerings are FIPS certified, like the CloudHSM, but Enclaves is a different system and use case.

Re: Engineering with Enclaves

#25

Post by phw » Tue, Apr 04, 2023, 4:39 PM UTC

sudhirj wrote: post #23

Thom2000 wrote: post #18

Earlier quoted context omitted.

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 to…

I’ll check out the TPM, but our big draw with the Enclave system is being able to run general purpose code (Python / Go) inside a secure isolated environment. The earlier system we had was SEE machine on a HSM and required a special compiler to run - I haven’t seen the Nitro TPM just yet, but I doubt I’d be able run a container inside the boundaries of the TPM.

In case it's helpful: I'm maintaining a tool kit that makes it possible to run unmodified, general-purpose code inside Nitro enclaves: https://github.com/brave/nitriding

Re: Engineering with Enclaves

#26

Post by Veserv » Wed, Apr 05, 2023, 12:52 AM UTC

sudhirj wrote: post #24

danpalmer wrote: post #19

Earlier quoted context omitted.

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.

I don’t think there’s any specs to certify against for hypervisors. Think other AWS offerings are FIPS certified, like the CloudHSM, but Enclaves is a different system and use case.

There are no off the shelf specs you can certify against for hypervisors in particular. However, the certification of general purpose isolation in a shared tenancy environment is structurally similar to certification against the Separation Kernel Protection Profile (SKPP) [1] as done for INTEGRITY-178B [2].

Unfortunately certification against that standard directly is no longer possible in the normal course because as part of the security assurance requirement (SAR) AVA_VLA_EXP.4 it requires a NSA penetration test and evaluation that identifies no deficiences to cross-verify the proofs of correctness.

However, with the amount of money the US government is spending on AWS it should be trivial for them to get such a certification done if they were competent to actually do it. In addition, you could always just use a comparable standard that replaces AVA_VLA with the standard AVA_VAN which just validates against a “generic nation-state attacker” similar to what PikeOS [3] did. Given that PikeOS is made by a relatively small company, especially compared to something like Amazon or even the just the AWS division, it would again be easy for Amazon to demonstrate such capability if they were competent to do so.

Instead Amazon is 100% guaranteed to fail such a evaluation like how Microsoft failed their evaluations because, like Microsoft, nobody in their organization has ever designed, worked on, or probably even seen a actual high security system and they have no incentive to learn when they can just make up bullshit that people believe. Their organizations and management are structurally incapable of developing secure systems without a complete management and technology replacement.

[1] https://www.niap-ccevs.org/profile/Info.cfm?PPID=65&id=65

[2] https://www.commoncriteriaportal.org/files/epfiles/st_vid101...

[3] https://www.commoncriteriaportal.org/files/epfiles/1146a_pdf...