Why isn't the MRENCLAVE part of the policy for verification?

sbellem commented 3 years ago

Hi, this repository is very useful to learn about remote attestation and I would like to propose to add the expected MRENCLAVE to the policy file so that it can be part of the verification, but I am not sure how to do so.

Some things to do:

[x] Add MRENCLAVE to policy.in file. For development purposes it can first be hardcoded, and if there's some kind of automated way to add it to the policy.in file like it is done for the MRSIGNER, then sure, otherwise, a hardcoded one may be ok, as it would correspond to the version of the code. If the enclave code changes then the hardcoded MRENCLAVE would have to be updated. That seems reasonable for an example, if the reasoning is not flawed.

In enclave_verify.c:

[x] Add MRENCLAVE check like it is done for MRSIGNER.

[x] The verify_enclave_identity function must be modified to take in the mrenclave as a paramater. Something like:

int verify_enclave_identity(sgx_measurement_t req_mr_signer,
sgx_measurement_t req_mr_enclave, sgx_prod_id_t req_isv_product_id,
sgx_isv_svn_t min_isvsvn, int allow_debug, sgx_report_body_t *report)

In sp.cpp:

[x] Add to config_struct

typedef struct config_struct {
    // ...
sgx_measurement_t req_mrsigner;
sgx_measurement_t req_mrenclave;
sgx_prod_id_t req_isv_product_id;
// ...
} config_t;

[x] Pass config->req_mrenclave as a parameter to the call to verify_enclave_identity():

    if ( ! verify_enclave_identity(config->req_mrsigner, config->req_mrenclave, 
        config->req_isv_product_id, config->min_isvsvn, 
        config->allow_debug_enclave, r) ) {

        eprintf("Invalid enclave.\n");
        msg4->status= NotTrusted;
    }

[x] Take care of command line argument --mrenclave and its processing, and setting the config accordingly.

Others:

[x] Header files
[x] run.in
[ ] Windows related files

Reasoning

My understanding is that in order for a remote verifier to be sure that an enclave is running the expected code, the MRENCLAVE in the attestation report must be checked against an expected "trusted" MRENCLAVE. It's not clear to me how a remote verifier is expected to obtain that "trusted" MRENCLAVE, and this example could also demonstrate this, which would be very useful for learning purposes.

For instance, this repository shows how the expected MRSIGNER is extracted out of the SIGSTRUCT from the Enclave.signed.so, using the sgx sdk sgx_sign tool, (and mrsigner program) but how does one get the MRENCLAVE? Are there recommended protocols for the remote verifier to obtain such information?

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

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.

But it does not mention how to get this "trusted configuration". This example gives ideas on how to obtain this trusted configuration but it is missing one crucial piece: the MRENCLAVE.

jmechalas commented 3 years ago

There are a large number of policy matters that could be implemented and I had to draw the line somewhere to ensure the code sample --which is already complicated--would not be even more complicated.

The automatic extraction of MRSIGNER is a convenience that allows you to build the sample in one step. "Normal" application development would mean running the _sgxsign tool to extract MRSIGNER and MRENCLAVE from your enclave, and then hardcoding those values into your service provider to form a whitelist of who you would talk to. I chose to show MRSIGNER rather than MRENCLAVE because the latter is simply more restrictive. For a small service, you'd be more likely to implement security based on signer (allowing all enclaves you have written) rather than listing every MRENCLAVE for every revision of your enclave. You can use metadata like the product ID and security version number to identify enclaves without having to hardcode MRENCLAVE values.

sbellem commented 3 years ago

Thanks for the information!

"Normal" application development would mean running the _sgxsign tool to extract MRSIGNER and MRENCLAVE from your enclave, and then hardcoding those values into your service provider to form a whitelist of who you would talk to.

I assume the place to look for to know how to extract the information (MRENCLAVE) is in the guide, Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3 (3A, 3B, 3C & 3D): System Programming Guide, mentioned in the code:

https://github.com/intel/sgx-ra-sample/blob/876dde79ca58f5f60c4d9dd5b2a6d5e0ef66c5fd/mrsigner.c#L39-L43

ScottR-Intel commented 3 years ago

Please see the "Enclave Signing Tool" section of SGX Developer Reference for info on dumping all enclave metadata using the sgx_sign tool, including MRENCLAVE:

https://download.01.org/intel-sgx/latest/linux-latest/docs/

As an example, here's how you would do it:

sgx_sign dump -enclave ./enclave.signed.so -dumpfile out.txt

sbellem commented 3 years ago

@ScottR-Intel Thanks!

sbellem commented 3 years ago

@jmechalas I made some additions to the related PR (#65). I am willing to bring the PR to a merge-able state if you are interested in adding the MRENCLAVE verification. Otherwise I can close it and will maintain a fork of the repo that have the MRENCLAVE verification because for the use cases we are working on it is crucial. Thanks for the feedback!

intel / sgx-ra-sample

Why isn't the MRENCLAVE part of the policy for verification? #64

Reasoning