[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.

[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.