3 ms·

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 ver

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.

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.