Hi all,
When the enclave is initialized, the documentation mentions a technique for communicating secrets from the service provider to the enclave:
The enclave generates a report structure and returns this structure along with a manifest to the application. The manifest contains those values which are included in the user data portion of the report. The manifest may include the nonce and an ephemerally generated public key to be used by the challenger for communicating secrets back to the enclave.
If I'm reading this correctly, it seems like the suggestion is to generate a keypair inside of the enclave and include the public key inside of the user data section of the report. The service provider could then encrypt secrets with the enclave's public key and send them to the enclave after it has been initialized.
However, it also appears that there is a built-in way to communicate secrets of this type provided in the remote attestation example.
The format of msg4 is up to the service provider. [..] It may optionally contain: Secrets to provision to the enclave. Any secrets should be encrypted using a key derived from the KDK (see msg2).
Question: are these approaches redundant? If not, what would be the benefit of supplying an ephemeral public key in the user data section of the report, when secrets can be provisioned as a part of the remote attestation process?
