EPID Provisioning

[AB_]

From the whitepaper - "EPID Provisioning and Attestation Services", Section 4.4 Provisioning Flows, Message 3 - Client Response:

1. Why is it necessary for the provisioning enclave to prove that it is running on a level of TCB?  Especially, given that the two mechanisms described later are dependent on the provisioning key, how does it differ from the information provided in "Client Hello" step?
2. Can you give an overview of how "EPID blind join protocol" is being used in this setting? I am particularly looking to know how EPID private key is generated without Intel knowing it. (I am aware of the join protocol in Direct Anonymous Attestation mechanism but looking to map details in this scenario)
3. In Section 4.4.4 Message 4:Server Completion, "The results of the certification process are returned in Message 4 including a copy of the encrypted key backup."  - Which key is this? Is this EPID private key? If so, why should it be part of message 4 when provisioning enclave itself is capable of backing it up?

[AB_]

Any update?

[Hoang_N_Intel]

Here is the response from our SGX architecture team.

1. Why is it necessary for the provisioning enclave to prove that it is running on a level of TCB?  Especially, given that the two mechanisms described later are dependent on the provisioning key, how does it differ from the information provided in "Client Hello" step?

The goal of attestation is to reflect that “A specific enclave is executed on genuine hardware that is up to date.” The “up to date” part is important because a device running old, microcode can be unsafe. The platform cannot be trusted to assert that it is up to date because an out of date platform might lie. Instead, during provisioning the platform proves to Intel that it is 1) a genuine platform, and 2) that it up to date. Intel then provisions an EPID key that reflects that this platform is “genuine hardware and up to date”

2. Can you give an overview of how "EPID blind join protocol" is being used in this setting? I am particularly looking to know how EPID private key is generated without Intel knowing it. (I am aware of the join protocol in Direct Anonymous Attestation mechanism but looking to map details in this scenario)

The EPID private key is generated randomly on the platform in the Provisioning Enclave. https://eprint.iacr.org/2009/095.pdf describes the join protocol. Please see the section of "Anonymity" in that document for more details.

3. In Section 4.4.4 Message 4:Server Completion, "The results of the certification process are returned in Message 4 including a copy of the encrypted key backup."  - Which key is this? Is this EPID private key? If so, why should it be part of message 4 when provisioning enclave itself is capable of backing it up?

It is the EPID private key having been sealed/encrypted by the platform. As part of the protocol, the encrypted private key is sent to the Provisioning Service for off-platform backup. Should the platform be unexpectedly formatted and lose its access to the EPID private key, the platform can contact the provisioning server and request a copy of that backup. Because it is encrypted by the Provisioning Enclave, only that enclave running on that platform can decrypt it, not the server or other platform.