remote attestation message flow?

[jamason]

Hello, i have few questions about the remote attestation message flow

1. how does the ISV enclave know that it is communicating indeed with the intended ISV server.

• shoud we always put the ISV server certificate as part of the enclave/application?

1. does the quoting enclave encrypt the quote with IAS public key? Would that mean that the service provider wouldnt be able to do anything on the quote except forward it to the IAS
2. is the communication between IAS the service privider secure

[Roshan_Mehta]

Did you get the answers to your question? I want to know the same. 

[Dr__Greg]

Good evening, I hope the week is going well for everyone. Short on time tonight but lets see if we can contribute some background on this issue. The Service Provider (SP) model for remote attestation is basically about establishing a security context between the enclave and the SP. As with the establishment of any security context the goal is to end up with a shared secret between the enclave and the SP. That shared secret can be used as the derivation root for a key which can be used to symmetrically encrypt material so that it can be securely conveyed into the enclave. The mediation of the shared secret is implemented with an Elliptic Curve Diffie Hellman (ECDH) key exchange. As with any proof of knowledge protocol the exchange does not need to be confidential but it does need to be integrity protected, otherwise the exchange is susceptible to a man in the middle attack. The role of the certificate, as with a standard TLS connection, is to validate the integrity of the SP side of the key exchange. The integrity of the quote is protected with an EPID private key which is provisioned onto the attesting platform in a separate exchange with the Intel provisioning servers. The attestation report from the Intel IAS server verifies the integrity of the ECDH generator value created by the attesting enclave. The actual mechanics of that integrity check are implemented in the ISV application by an enclave<->enclave trust relationship which is verified by the SGX report key which is specific to the processor running the enclaves. Hopefully this background information is useful, we can expand a bit when I'm not on the run.

[Hoang_N_Intel]

The details of the remote attestation message flow is documented at https://software.intel.com/en-us/articles/intel-software-guard-extensions-remote-attestation-end-to-end-example#msg0

In addition, this online resource goes into the message flow, how the secure session is established https://software.intel.com/en-us/node/709016 and how the secret key can be sent into the Enclave.