Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remote attestation #15

Open
sbellem opened this issue Nov 18, 2020 · 2 comments
Open

remote attestation #15

sbellem opened this issue Nov 18, 2020 · 2 comments

Comments

@sbellem
Copy link
Contributor

sbellem commented Nov 18, 2020

Documentation

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

Examples

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

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
Copy link
Contributor Author

sbellem commented Feb 9, 2021

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 intel/sgx-ra-sample#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:

        // 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;

More advanced examples that do check the MRENCLAVE:

    /// 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

See Intel's forum: https://community.intel.com/t5/Intel-Software-Guard-Extensions/Who-has-the-original-hash-of-enclave-in-remote-attestation/m-p/1103756#M1136

@sbellem
Copy link
Contributor Author

sbellem commented Feb 10, 2021

Using the Report Data field for remote attestation

Interesting question on stackoverflow:

How to prove that certain data is calculated (or generated) inside Enclave (Intel SGX)?

Related github issue: intel/sgx-ra-sample#53

Interesting related post, on Intel's community forum, by Dr__Greg: https://community.intel.com/t5/Intel-Software-Guard-Extensions/remote-attestation/m-p/1073263#M364

@sbellem sbellem closed this as completed Jun 10, 2021
@sbellem sbellem reopened this Jun 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant