[jchw]

Intel SGX/remote attestation for verifying that servers are running the code they say they are running is very interesting, I believe Signal talked about doing something similar for contact discovery, but at a base level it requires a lot of trust. How do I verify that the attestation I receive back is the one of the machine I am contacting? Can I know for sure that this isn't a compromised SGX configuration, since the system has been broken in the past? Furthermore, can I really be sure that I can trust SGX attestations if I can't actually verify SGX itself? Even if the code running under SGX is verifiable, as an ordinary user it's basically impossible to tell if there are bugs that would make it possible to compromise.

Personally I like the direction Mullvad went instead. I get that it means we really can't verify Mullvad's claims, but even in the event they're lying, at least we got some cool Coreboot ports out of it.

If you're really paranoid, neither this service nor Mullvad offers that much assurance. I like the idea of verifiability, but I believe the type of people who want it are looking to satisfy deeper paranoia than can be answered with just trusting Intel... Still, more VPN options that try to take privacy claims seriously is nothing to complain about.

[MagicalTux]

Intel will not attest insecure configurations. Our client will automatically verify the attestation it receives to make sure the certificate isn't expired and has a proper signature under Intel's CA trust.

A lot of people have been attempting to attack SGX, and while there have been some successful attacks these have been addressed by Intel and resolved. Intel will not attest any insecure configuration as do other TEE vendors (AMD SEV, ARM Trustzone, etc).

[jchw]

I really am interested in how this works. How can the client software verify that the SGX attestation actually is from the same machine as the VPN connection? I guess there's probably an answer here, but I don't know enough about SGX.

[MagicalTux]

The way this works is by generating a private key inside the enclave and having the CPU attest its public key.

This allows generating a self signed TLS certificate that includes the attestation (under OID 1.3.6.1.4.1.311.105.1) and a client connecting verifying the TLS certificate not via the standard chain of trust, but by reading the attestion, verifying the attestation itself is valid (properly signed, matching measured values, etc) and verifying the containing TLS certificate is indeed signed with the attested key.

Intel includes a number of details inside the attestation, the most important being intel's own signature of the attestation and chain of trust to their CA.

[jchw]

Hmm. That really does seem pretty clever, and if it works the way it sounds like it does, obviously does resolve most of the concerns around how this would work and avoid obvious pitfalls. I still stand by the more obvious concern (paranoid people probably don't trust that Intel SGX isn't possible for powerful actors to compromise) but I do understand why one would pursue this avenue and find it valuable.

[deknos]

> has a proper signature under Intel's CA trust.

That's a pretty big trust already. Intel has much to loose and would have no problem covering up bugs for government in SGX or certifying government-malware.

And intel had a LOT of successfull attacks and even with their cpu they are known to prefer speed than security.

[m4rtink]

What happens to the system if Intel goes under ? Seems like a single point of failure.

[junon]

> Can I know for sure that this isn't a compromised SGX configuration, since the system has been broken in the past?

As far as I'm aware, no. Any network protocol can be spoofed, with varying degrees of difficulty.

I would love to be wrong.

[MagicalTux]

Intel audits configuration on system launch and verifies it runs something they know safe. That involves CPU, CPU microcode, BIOS version and a few other things (SGX may not work if you don't have the right RAM for example).

The final signature comes in the form of a x509 cerificate signed with ECDSA.

What's more important to me is that SGX still has a lot of security researchers attempting (and currently failing) to break it further.

[junon]

Depends on your threat model. You cannot, under any circumstance, prove (mathematically) that a peer is the only controller of a private key.

Again, I would love to know if I'm wrong.

The fact that no publicly disclosed threat actor has been identified says nothing.

[doublerebel]

Proving a negative that information has not been shared has been a challenge from the beginning of information.

Are you suggesting a solution for this situation?

[pydry]

In this case it's rather like trusting that a government issued private key has not been stored by the government for further use.

[rasengan]

> Any network protocol can be spoofed, with varying degrees of difficulty.

Because of the cryptographic verifications, the communication cannot be spoofed.

[junon]

Pray tell how a black box peer can validate its not had its private keys cloned?

[immibis]

Because the code doesn't have any code to clone private keys.

The trust chain ends with you trusting Intel to only make CPUs that do what they say they do, so that if the code doesn't say to clone a private key, it won't.

(You also have to trust the owners to not correlate your traffic from outside the enclave, which is the same as every VPN, so this adds nothing)

[rasengan]

The first part is definitely true.

The second part in terms of correlations is untrue since we include a number of techniques to frustrate timing attacks among other things.

[immibis]

There's also the factor of why should we trust the person who destroyed Freenode while telling everyone he was actually saving it from the evil people who were trying to steal it from him? That's a liability. He might sell all our traffic logs to some evil entity while claiming he's just protecting us.