topic Quote:Prabu Rajathirumoni in Intel® Software Guard Extensions (Intel® SGX)

Intra-Platform Attestation

AB_ — Mon, 06 Mar 2017 14:54:00 GMT

Hi,

Reading from the https://software.intel.com/en-us/articles/innovative-technology-for-cpu-based-attestation-and-sealing, Section 3.1 Intra-Platform Attestation, Figure 3, in step 2, if application A behaves adversely and launches a replay attack by sending a previously (i.e., say launched at some point in history) valid report of Enclave A, can Enclave B still attest that report? If not, what prevents it from successfully attesting it?

Anitha

If the Enclave A performs

Prabu_R_Intel — Tue, 07 Mar 2017 11:30:30 GMT

If the Enclave A performs replay attack with the old report that was launched at some point in history, there is a chance for Enclave B
to successfully auntheticate Enclave A's report.

case 1: After generating old report, if there was any change in TCB, Enclave B fails to authenticate.It's because the Enclave B may consider that report generated by Enclave A might be old or not from valid TCB.

case 2 : After the generation of report, there is no change in TCB of the platform, then Enclave B can authenticate successfully.
But even in this case, the secret information like keys can't be leaked to malware application.Here report authentication happens within
enclave(trusted zone).So there is no chance of accomplising the benefit of replay attack.

Quote:Prabu Rajathirumoni

AB_ — Tue, 07 Mar 2017 13:09:00 GMT

Prabu Rajathirumoni wrote:

case 1: After generating old report, if there was any change in TCB, Enclave B fails to authenticate.It's because the Enclave B may consider that report generated by Enclave A might be old or not from valid TCB.

What parts are counted as TCB here?

Prabu Rajathirumoni wrote:

case 2 : After the generation of report, there is no change in TCB of the platform, then Enclave B can authenticate successfully.
But even in this case, the secret information like keys can't be leaked to malware application.Here report authentication happens within
enclave(trusted zone).So there is no chance of accomplising the benefit of replay attack.

Sure signing keys cannot be leaked. But I am thinking of a scenario where Enclave A has been corrupted and the malicious application A would like to get Quoting Enclave (say Enclave B) to attest the report of Enclave A. Now application A might be able to launch replay attack and get Enclave B to sign an old valid report of A. This may have some implications in the remote attestation where the ISV can now be fooled into thinking that Enclave A might be running right software.

Thanks

What parts are counted as TCB

Prabu_R_Intel — Wed, 08 Mar 2017 11:31:46 GMT

What parts are counted as TCB here?

TCB stands for Trusted Computing Base. It corresponds to the software and hardware component that helps to build the protected region.

Quote:Prabu Rajathirumoni

AB_ — Wed, 08 Mar 2017 19:57:00 GMT

Prabu Rajathirumoni wrote:

What parts are counted as TCB here?

TCB stands for Trusted Computing Base. It corresponds to the software and hardware component that helps to build the protected region.

Sure, I meant to ask what exactly counts as TCB. Perhaps I will be more explicit. Suppose an enclave A was launched with program p (binary) at some point, say yesterday. If I launch an enclave today with the same program p (same binary as well), on the same machine, and say there is a change in TCB. Since I am using the same hardware, what exactly does attribute to the change in the TCB?

Even though the same binary

Prabu_R_Intel — Thu, 09 Mar 2017 10:47:47 GMT

Even though the same binary and same hardware are used at different point of time in the same system, there is a chance of change in other TCB components like BIOS version, run time component provided by PSW package.