A remote entity may provision some secrets to an enclave after remote attestation has been accomplished. Typically, secret provisioning is conducted through a secure channel. The secure channel establishment must be bound to the remote attestation process. Otherwise, the remote server might provision the secret to an entity other than the enclave that has been attested.
Step 3.b in the attestation flow referenced the ability to include a public key to facilitate the creation of a trusted channel. To accomplish this, in step 3 the enclave may wish to authenticate the server first, to ensure that it is about to receive a secret from a trusted entity. A known good root certificate can be embedded within the enclave code or initialization data for example, allowing the enclave to validate the server. Once the server has been authenticated, the enclave can generate an ephemeral public/private key pair and include the public key in the user data portion of the report.
After the enclave has been validated in step 7 of the attestation flow, the server can generate an encryption key E, and encrypt it with the enclave’s public key P, and send P(E) over the channel to the application. The channel itself does not need to be protected, because the secret is encrypted.
Once P(E) has been received by the application, it can be passed to the enclave. Inside the enclave then, it can decrypt P(E) since it possesses the private key that is associated with this ephemeral public/private key pair, so now both the challenger and the enclave possess the encryption key E.
Similar to attestation, this is not the only way that a trusted channel can be established between an enclave and a remote entity to exchange a secret, just one example.
The verifier of the remote attestation must check the identity of the signer (MRSIGNER) before provisioning any secrets. The Intel SGX architecture does not verify the certificate chain when an enclave is instantiated. The hardware only verifies the enclave measurement (MRENCLAVE) and saves a hash of the ISV’s public key contained in the enclave signature in MRSIGNER. This means that anyone can modify an enclave and re-sign it. Similarly, the verifier must also check the enclave attributes to prevent provisioning any secret to a debug enclave, for instance.
Once a secure channel has been established, secrets can be provisioned to the enclave. The challenger can now encrypt a secret S with the key E, and send E(S) to the application, which in turn passes it to the enclave. The enclave can now use E to decrypt E(S), and now it possesses S. It would be inconvenient, however to require the enclave to connect to the remote entity for secret provisioning every time the enclave is instantiated. Instead, the enclave may choose to store the secret in non volatile storage using the sealing techniques discussed in the next section. Even when the secret is sealed outside the enclave, the secret remains inaccessible to anyone but to the enclave that sealed it, and only on the platform on which it was sealed.
Secret provisioning is a critical feature enabled by the Intel SGX technology. It allows building enclaves that are more robust than current Tamper Resistant Software (TRS). TRS typically provides security through obscurity, for instance it obfuscates secrets in the executable in an attempt to keep secrets safe from unauthorized observation. However, this approach simply makes it time-consuming, but not impossible, to extract secrets embedded in a TRS binary. Furthermore, it is a complex technique for developers to use and its practice is discouraged.