VP.NET Publishes SGX Enclave Code: Zero-Trust Privacy You Can Actually Verify

VP.NET has released the source code for its Intel SGX enclave on GitHub, allowing anyone to build the enclave and verify its mrenclave hash matches what's running on the servers. This takes "don't trust, verify" from marketing to reality, making privacy claims testable all the way down to hardware-enforced execution.

A move like this could set a new benchmark for transparency in privacy tech.

Slashdot, oh slashdot

[Anonymous Coward]

The worst slashvertisement I've seen in a while - specifically for a product none of us want, running on vendor specific hardware extensions that are questionable at best, making grandiose claims, with a language most of us dislike.

https://en.wikipedia.org/wiki/Software_Guard_Extensions#SGX_malware_arguments

Re:

[tlhIngan]

SGX is also deprecated. Support ended on the Gen 12 CPUs, but later on Intel disabled it completely on Gen 11 and Gen 12 CPUs so it only exists for Gen 8 through Gen 10.

There is no current Intel CPU supporting SGX.

Re:

[_merlin]

Didn't they only deprecate it for desktop chips? Last time I checked it was still supported on Xeon chips. Something about isolation between VMs on servers.

Oy

[cascadingstylesheet]

Just put them in the huge banner ad at the top, eh. We'll give them the attention they are due ...

Not great.

[Gravis Zero]

Honestly, I don't trust Intel CPUs for a second. All they are telling me with this is that they are heavily invested in bad hardware that they may or may not be running the mitigations for. If they are then it makes little sense and if they aren't then you are vulnerable. I mean, even SGX is insecure which is why it's deprecated. [bleepingcomputer.com]

I would trust them a lot more if they weren't using Intel CPUs.

Re: Not great.

[drinkypoo]

AMD CPUs have a processor inside of the processor as well, in everything after the FX line. You certainly shouldn't trust Intel, but who can you trust?

Re:

[Gravis Zero]

AMD CPUs have a processor inside of the processor as well, in everything after the FX line.

My concerns are more about microarchitecture design. Intel seems to be forced to advise users to disable fancy new instruction set extensions every time they add one because it's flawed. AMD is not perfect but the mitigations required are minimal in comparison.

ARM chips seem to be the best path forward at the moment. However, when companies (e.g. Apple) make their own extensions to the instruction set, they commonly fail to consider the security implications just like Intel.

Re:

[bill_mcgonigle]

> You certainly shouldn't trust Intel, but who can you trust?

Hopefully we'll have verifiable RISC-V before too long. With audits, stateside.

Any closed-source ISA is always going to be conditional trust. Coreboot helps a bit but if the hardware is bugged, only a bit.

as seen in

[awwshit]

> they talk about us.... slashdot

No we don't talk about this, these guys paid slashdot to put slashdot's logo on their site.

Funny, the summary doesn't even say that it is a VPN service.

What are you doing that you need a VPN and need to (somehow) verify that the VPN is not snooping on you?

Looks like this is the target market:
https://vp.net/img/graphic-dog... [vp.net]

or the worst mistake in the history of Intel

[usedtobestine]

If there are any bugs rated at a cvss of 10 in that code, every Intel based server on the internet is going to die a spectacular death.

what's the point?

[mbunch]

There is no way to verify that what they published is what they're actually running on their servers. Sure I can request a hash from their server, but there's nothing preventing them from faking the correct response.