sbellem commented 3 years ago

Documentation

https://software.intel.com/content/www/us/en/develop/topics/software-guard-extensions/attestation-services.html

Examples

https://software.intel.com/content/www/us/en/develop/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example.html (source code: https://github.com/intel/sgx-ra-sample)

More involved examples, with remote attestation:

Both examples are based on the paper Integrating Remote Attestation with Transport Layer Security.

Also, see the secret provisioning example at https://github.com/cloud-security-research/sgx-ra-tls/tree/master/apps/secret-provisioning-example.

Remote Attestation in different Frameworks

Occlum ...
https://github.com/alibaba/inclavare-containers ...
https://docs.microsoft.com/en-us/azure/attestation/ ...
https://github.com/openenclave/openenclave
...

Look at each one and see how they get the "trusted configuration" aka "MRENCLAVE, MRSIGNER, etc". The being here that at some point someone, some entity must establish what the trusted config is, and that establishment event, can only (one could argue), be based on the "trusted source code". Leaving aside how the source code becomes "trusted" (e.g. through audits, reviews, battle tested, etc), we want any party to be able to reproduce the trusted configuration from the trusted source code. To be able to reproduce the trusted configuration from the trusted source code, require reproducible builds. Going back to the different SDKs, frameworks etc, the question is then for a given enclave built, how can one reproduce that build?

First thing to find out is whether these frameworks all depend on the SGX SDK (linux-sgx for linux OS)

sbellem commented 3 years ago

I am the auditor. Where do I get the MRENCLAVE?!

tl;dr

From the signed enclave, using the linux-sgx SDK sgx_sign tool, and using the information found in Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3 (3A, 3B, 3C & 3D): System Programming Guide, Chapter 38, Section 13, Table 38-19 Layout of Enclave Signature Structure (SIGSTRUCT) as mentioned in the sgx-ra-sample.

/*
 * From the "Intel(r) 64 and IA-32 Architectures Software Developer 
 * Manual, Volume 3: System Programming Guide", Chapter 38, Section 13,
 * Table 38-19 "Layout of Enclave Signature Structure (SIGSTRUCT)"
 */

Also see issue https://github.com/intel/sgx-ra-sample/issues/64.

From https://software.intel.com/content/www/us/en/develop/documentation/sgx-developer-guide/top/attestation/remote-interplatform-attestation.html:

The enclave data contained in the quote (MRENCLAVE, MRSIGNER, ISVPRODID, ISVSVN, ATTRIBUTES, and so on.) is presented to the remote service provider at the end of the attestation process. This is the data the service provider will compare against a trusted configuration to decide whether to render the service to the enclave.

From https://sgx101.gitbook.io/sgx101/sgx-bootstrap/attestation#enclave-measurement-aka-software-tcb:

The “Enclave Identity”, which is a 256-bit hash digest of the log, is stored as MRENCLAVE as the enclave’s software TCB. In order to verify the software TCB, one should first securely obtain the enclave’s software TCB, then securely obtain the expected enclave’s software TCB and compare those two values.

How is this trusted configuration obtained? How is this expected enclave's software TCB securely obtained?

The MRSIGNER can be extracted out of the SIGSTRUCT of the signed enclave binary (e.g. Enclave.signed.so)
The ISVPRODID and ISVSVN can be found in the Enclave.config.xml

But what about MRENCLAVE? Can it be extracted of Enclave.signed.so like MRSIGNER can?

Most basic examples do not show case this. For instance:

linux-sgx's sample RemoteAttestation skips the check: (code)

    // A product service provider needs to verify that its enclave properties
    // match what is expected.  The SP needs to check these values before
    // trusting the enclave.  For the sample, we always pass the policy check.
    // Attestation server only verifies the quote structure and signature.  It does not
    // check the identity of the enclave.
    bool isv_policy_passed = true;

sgx-ra-sample only checks the MRSIGNER via a policy. Consequently, it's possible to change the source code of the enclave and get the verification to pass. (I know it's just an example ... but for learning purposes it would be nice to see MRENCLAVE verified as this is quite crucial, if not the actual purpose of the verification.)
svartkanin/linux-sgx-remoteattestation also skips the check, just like it's done in intel's linux-sgx sample. (code).
SGX 101 example is a fork of svartkanin/linux-sgx-remoteattestation and also skips the check.
apache/incubator-teaclave-sgx-sdk is based on svartkanin/linux-sgx-remoteattestation and did not modify the C++ part, and consequently also skips the check as well. (code)

More advanced examples that do check the MRENCLAVE:

cloud-security-research/sgx-ra-tls has a secret provisioning service which does perform a "full" check of the enclave's identity by checking both the MRENCLAVE and the MRSIGNER. This example is not an "entry-level" example though.

apache/incubator-teaclave verifies both the MRENCLAVE and MRSIGNER of an attestation report against expected ones. (code)

/// Verify whether the `MR_SIGNER` and `MR_ENCLAVE` in the attestation report is
/// accepted by us, which are defined in `accepted_enclave_attrs`.
fn verify_measures(&self, attestation_report: &AttestationReport) -> bool {
    debug!("verify measures");
    let this_mr_signer = attestation_report
        .sgx_quote_body
        .isv_enclave_report
        .mr_signer;
    let this_mr_enclave = attestation_report
        .sgx_quote_body
        .isv_enclave_report
        .mr_enclave;

    self.accepted_enclave_attrs.iter().any(|a| {
        a.measurement.mr_signer == this_mr_signer && a.measurement.mr_enclave == this_mr_enclave
    })
}

From the two more advanced and involved code bases shown above it's not clear yet, how the expected MRENCLAVE is provisioned or obtained.

To Look into