Intel researchers propose HTTPS Attestable to secure web workloads via SGX | Hacker News Reader

Intel researchers propose HTTPS Attestable to secure web workloads via SGX

theregister.com

33 pointsDotnaught24 comments

Given that SGX is an Intel-only technology (it isn't even supported on AMD's x86 CPUs, let alone on ARM), and given that SGX has been repeatedly broken by speculative-execution vulnerabilities, this feels like a total non-starter.

The article repeatedly states that the protocol would also work with Arm's TrustZone. Is Arm’s technology insufficiently equivalent?

I believe it is: TrustZone is used for attestation in embedded secure boot models when verifying a new flash-image during in-field firmware updates. This paper sounds like an application of that process to HTTP.

TrustZone is used to secure the boot but can be used for other purposes too.

You can say the same things about virtualization. Vendors use different virtualization extensions (see AMD-V vs VT-x) but we have interfaces that let us treat them as broadly being the same thing.

Likewise virtualization has its fair share of bugs.

That doesn't make either virtualization or SGX worthless.

Virtualization has usecases beyond security though. So even if virtualization was completely insecure by design, it wouldn't be useless.

Does the same apply to SGX? What is SGX good for if it's not secure?

Days since SGX was hacked: 8

https://arxiv.org/abs/2110.06657

Is this actually a problem that anyone has -- sending workloads to untrusted servers?

And why does this feel more likely to be used to perform DRM on client devices in secure enclaves?

SGX already got used for DRM (it was required for UHD Blu-ray playback on PCs) and got so completely broken nobody will ever trust it for DRM use ever again, so no.

I've used lots of servers where my employer relied on organizational trust; if you believe in the attestations, it might be nice to have those as well.

Just like E2E encryption, you can rely on trust, but it would be really awesome if you _didn't_ have to trust, in this case AWS or your cloud provider of choice.

> Is this actually a problem that anyone has -- sending workloads to untrusted servers?

Yes, certainly, that's the whole point of HSM's (host security modules). They have been used since forever for encapsulating crypto secrets. The mapping between the number on the front of your credit card and the 3-digit CVV2 code on the back is done inside an HSM. They are cool devices to have inside servers. Having them in client computers makes them more likely to be used for evil (preventing people from controlling their own computers) as others have remarked here, unfortunately.

Not my specialty, but my impression here was that they'd ballooned the functionality of the HSM into something resembling a general purpose computer?

Or is this still talking about attested / secured storage more than processing?

HSM's have had computer-like capabilities since ages ago. SGX goes further and lets you run x86 apps (possibly such as media codecs) in an HSM-like "enclave".

Great. Even more ways for software to hide its inner workings from us, the owners of the machine. Thank god SGX has been cracked.

This reminds me of how Signal is using lots of claimed SGX magic for their storage certain data, the specifics of which data escape me. Something about device restorations, I want to say. And how peeps were lampooning SGX for being flawed.

Do those flaws apply here too?

Apparently this proposal would make it possible for web servers to say 'yes really, I really am running that open source code on Github, right now'?

But honestly I am nervous that somehow this (or the mutual HTTPA option described in the second half) could be twisted to serve the DMCA / DRM abusers crowd.

But honestly I am nervous that somehow this (or the mutual HTTPA option described in the second half) could be twisted to serve the DMCA / DRM abusers crowd.

I have exactly the same thoughts on any security technology based around centralising control and authority. They should be regarded as nothing but tools for furthering the goals of corporate authoritarianism.

Agree. Even if we could theoretically use it to our benefit, any such technology will disproportionally benefit these monopolists. They are the intended users, it's meant to secure "their" data against us hostile users. Its purpose is to literally provide a safe haven in our machines where these companies can do whatever they want without fear of our intervention. Unacceptable.

The actual paper: https://arxiv.org/abs/2110.07954

It's not specific to SGX, it can use any TEE.

Oh boy I can't wait to not being able to open certain websites because I am using software that American big tech doesn't like.

This is treachery on a chip and the fact that a sizable portion of people who are perfectly aware of how it works are okay with this just makes me lose hope for the future.

I don’t know whether to laugh or feel sorry for Intel. They are completely detached from the realities regarding the insecurity of both their product and the web.

Is this essentially the same as AMD's SEV-ES attestation reports, but per-application rather than per-VM? I don't see why any particular transport is required, if the attestation report is signed coming from the CPU firmware.

edit: The paper doesn't actually say if Intel are signing the attestation report in the CPU, so perhaps that's why.

Is this compatible with Apple’s process for secure client attestation over HTTPS?

Reply on news.ycombinator.com