5 ms·

If I'm reading the documentation [1][2] correctly, you're overselling the security. Verifying an SGX attestation requires trusting not only the integrity of the

If I'm reading the documentation [1][2] correctly, you're overselling the security. Verifying an SGX attestation requires trusting not only the integrity of the per-processor secret keys, but the honesty of an Intel-provided online verification API. The API allows you to POST an attestation report to Intel's verification web service, and get back a response saying "OK" or "not OK". You can use TLS to verify that the authentication was done by Intel rather than a MITM, but there seems to be no cryptographic way to prevent Intel from simply lying to you. They don't offer any way for third-parties to verify attestation reports themselves. [3] Is there something I'm misunderstanding? [1]: https://software.intel.com/en-us/articles/intel-software-guard-extensions-remote-attestation-end-to-end-example https://software.intel.com/en-us/articles/intel-software-gua... [2]: https://software.intel.com/sites/default/files/managed/ac/40/2016%20WW10%20sgx%20provisioning%20and%20attesatation%20final.pdf https://software.intel.com/sites/default/files/managed/ac/40... [3]: https://software.intel.com/en-us/forums/intel-software-guard-extensions-intel-sgx/topic/703192 https://software.intel.com/en-us/forums/intel-software-guard...

bascule 9y ago
Can you describe which API you're even talking about? This one? /attestation/sgx/v1/report If so, perhaps you missed this: > "The Attestation Service verifies the validity of the platform. It is the responsibility of the Service Provider to validate the ISV enclave identity." This API gives back considerably more than just an "OK" or "not OK". It gives back an attestation verification report (see section 4.2.1 of https://software.intel.com/sites/default/files/managed/7e/3b/ias-api-spec.pdf https://software.intel.com/sites/default/files/managed/7e/3b...) But beyond that, as noted in the document, this is Intel certifying that the attestation was created by genuine Intel hardware. It also carries a data-at-rest signature in addition to TLS: > "The Attestation Verification Report is cryptographically signed by Report Signing Key (owned by the Attestation Service) using the RSA-SHA256 algorithm. The signature is calculated over the entire body of the HTTP response." What Intel is providing here is not too far off from OCSP: the main things that can go wrong with "isvEnclaveQuoteStatus" beyond messages being malformed or signed by untrusted keys are the keys being revoked. An OCSP server could just as easily lie to you about the revocation status of an X.509 certificate. C'est la vie.
- teraflop 9y ago
  I did see that document, and I don't see how it addresses the underlying trust issue. Again, I don't claim to be super-knowledgeable about this stuff, which is why I asked if I'm missing something. > If so, perhaps you missed this: "The Attestation Service verifies the validity of the platform. ..." No, I didn't miss it. The Attestation Service claims to "verify" the validity of the platform, but it provides no proof of that verification. And if the platform is not valid (i.e. not verified to be using an authentic Intel key) then it doesn't matter what other checks you do; the security of the entire system falls apart, because the supposedly "secure" enclave could actually be being emulated. > It also carries a data-at-rest signature in addition to TLS: That's a signature generated by the Attestation Service, not by the original processor. It's generated using a "Report Signing Key" which has no cryptographic relationship with the processor's keys, or with the signature of the attestation; it just tells you that Intel claims to have checked that attestation and found it to be valid. > An OCSP server could just as easily lie to you about the revocation status of an X.509 certificate. C'est la vie. Right, this system seems as weak as OCSP, in the sense that it can be easily compromised by (for instance) a court order to modify the behavior of Intel's verification API. That's much weaker than the original claim, which was that it could be compromised only by tampering with the processors during manufacture. (Not to mention, the TLS certificate infrastructure would be vastly less secure if browsers had to rely entirely on OCSP and couldn't do any certificate validation of their own. OCSP can lie about revocation, but it can't lie about the signature itself.) I'll add that v1 of the reporting API seems to have been even weaker than OCSP. In that version, the signed response didn't even include any identifying information about the request, so if Intel faked a response, you wouldn't even be able to prove it to a third party! Thankfully, v2 seems to have fixed this obvious oversight.
  - bascule 9y ago
    In the end this system is just a PKI, albeit one based on a "privacy preserving" scheme based on bilinear pairings. It has all of the same failings as any PKI. They aren't going to do any better than OCSP. > the entire system falls apart, because the supposedly "secure" enclave could actually be being emulated. I'm not sure what else you're expecting? Even if the signatures were cryptographically verifiable end-to-end (which I believe is still on Intel's roadmap, but in the meantime they have centralized revocation) Intel could still issue an attestation certificate for a malicious enclave which is in fact a white box software emulation of an enclave, and you'd be none the wiser. There is no magical way for Intel to provide a mathematical statement that a device is a genuine Intel CPU. You are trusting the hardware and the key management to do what Intel says on the box.
xyzzyz 9y ago
Of course the Intel could lie to you, but Intel is already in the TCB. If you don't trust Intel to correctly verify the attestation report, you probably never trusted any kind of SGX security guarantees in the first place, as they also depend on you trusting Intel to do the thing they claim to do.
- caf 9y ago
  There's certainly a difference of degree between, on the one hand, distributing to every customer hardware that doesn't do what they say it does, and on the other, providing a limited number of false attestations of a particular emulation of the SGX hardware.

bascule 9y ago

Can you describe which API you're even talking about? This one? /attestation/sgx/v1/report If so, perhaps you missed this: > "The Attestation Service verifies the validity of the platform. It is the responsibility of the Service Provider to validate the ISV enclave identity." This API gives back considerably more than just an "OK" or "not OK". It gives back an attestation verification report (see section 4.2.1 of https://software.intel.com/sites/default/files/managed/7e/3b/ias-api-spec.pdf https://software.intel.com/sites/default/files/managed/7e/3b...) But beyond that, as noted in the document, this is Intel certifying that the attestation was created by genuine Intel hardware. It also carries a data-at-rest signature in addition to TLS: > "The Attestation Verification Report is cryptographically signed by Report Signing Key (owned by the Attestation Service) using the RSA-SHA256 algorithm. The signature is calculated over the entire body of the HTTP response." What Intel is providing here is not too far off from OCSP: the main things that can go wrong with "isvEnclaveQuoteStatus" beyond messages being malformed or signed by untrusted keys are the keys being revoked. An OCSP server could just as easily lie to you about the revocation status of an X.509 certificate. C'est la vie.

teraflop 9y ago
I did see that document, and I don't see how it addresses the underlying trust issue. Again, I don't claim to be super-knowledgeable about this stuff, which is why I asked if I'm missing something. > If so, perhaps you missed this: "The Attestation Service verifies the validity of the platform. ..." No, I didn't miss it. The Attestation Service claims to "verify" the validity of the platform, but it provides no proof of that verification. And if the platform is not valid (i.e. not verified to be using an authentic Intel key) then it doesn't matter what other checks you do; the security of the entire system falls apart, because the supposedly "secure" enclave could actually be being emulated. > It also carries a data-at-rest signature in addition to TLS: That's a signature generated by the Attestation Service, not by the original processor. It's generated using a "Report Signing Key" which has no cryptographic relationship with the processor's keys, or with the signature of the attestation; it just tells you that Intel claims to have checked that attestation and found it to be valid. > An OCSP server could just as easily lie to you about the revocation status of an X.509 certificate. C'est la vie. Right, this system seems as weak as OCSP, in the sense that it can be easily compromised by (for instance) a court order to modify the behavior of Intel's verification API. That's much weaker than the original claim, which was that it could be compromised only by tampering with the processors during manufacture. (Not to mention, the TLS certificate infrastructure would be vastly less secure if browsers had to rely entirely on OCSP and couldn't do any certificate validation of their own. OCSP can lie about revocation, but it can't lie about the signature itself.) I'll add that v1 of the reporting API seems to have been even weaker than OCSP. In that version, the signed response didn't even include any identifying information about the request, so if Intel faked a response, you wouldn't even be able to prove it to a third party! Thankfully, v2 seems to have fixed this obvious oversight.
- bascule 9y ago
  In the end this system is just a PKI, albeit one based on a "privacy preserving" scheme based on bilinear pairings. It has all of the same failings as any PKI. They aren't going to do any better than OCSP. > the entire system falls apart, because the supposedly "secure" enclave could actually be being emulated. I'm not sure what else you're expecting? Even if the signatures were cryptographically verifiable end-to-end (which I believe is still on Intel's roadmap, but in the meantime they have centralized revocation) Intel could still issue an attestation certificate for a malicious enclave which is in fact a white box software emulation of an enclave, and you'd be none the wiser. There is no magical way for Intel to provide a mathematical statement that a device is a genuine Intel CPU. You are trusting the hardware and the key management to do what Intel says on the box.

xyzzyz 9y ago

Of course the Intel could lie to you, but Intel is already in the TCB. If you don't trust Intel to correctly verify the attestation report, you probably never trusted any kind of SGX security guarantees in the first place, as they also depend on you trusting Intel to do the thing they claim to do.

caf 9y ago
There's certainly a difference of degree between, on the one hand, distributing to every customer hardware that doesn't do what they say it does, and on the other, providing a limited number of false attestations of a particular emulation of the SGX hardware.