core

SGX Attestation Crate

This crate exists to support remote attestation via Intel SGX, albeit on a lower level than the Intel SGX messaging. This enables application selection of the enclave's key algorithms and negotiation, rather than Intel's selection of the NIST P256 curve. In particular, it provides:

• A rust-like API for interacting with the SGX C library types and functions exposed by Baidu's rust-sgx-sdk.
• Support for and linkage to the SGX SDK simulation libraries via a cargo feature.
• An API for parsing and validating IAS verification reports in a no_std environment.
• Common serialization for SGX data structures, as X86_64 C structs (to aid validation of structures on non-x86_64 platforms)
• Common API for dealing with SGX structures, regardless of environment.

Compile-Time Features

There are several compile-time features which change the behavior of this crate, as well as the API compatibility:

• std - Enables the Rust standard library (this should not be used when built for an enclave).
• sgx-sim - Selects the fake IAS signing certificates generated at build time as the default verification certificates, and link against the _sim.so variants provided by Intel. Because this is dangerous, and should only be used during testing, a warning will be printed indicated what libraries are being linked.

Usage

In general, users of this crate will want to use it to emulate much of the SGX SDK process, albeit while staying within "safe" Rust wherever possible. For example, for an enclave returning cached IAS reports, the process will look something like this:

1. Untrusted calls TargetInfo::for_quoting_enclave() to retrieve the TargetInfo and EpidGroupId objects for the quoting enclave and the platform, respectively.
2. Untrusted provides the results to the enclave ("how" is undefined in this crate).
3. Enclave calls Report::new() providing it the enclave's identity as report_data.
4. Enclave returns the Report to the untrusted code.
5. Untrusted uses Quote::new() to communicate with the quoting enclave and get a quoted version of the Enclave's report, along with the QE's own report, intended for the Enclave.
6. Untrusted gives the resulting Quote and QE report to the Enclave.
7. Enclave verifies the QE's report using Report::verify(), verifies the quote was generated by the QE enclave, and verifies that it's own report was properly quoted (i.e. matches the results returned earlier).
8. Untrusted sends the Quote to IAS (how network calls happen are also unspecified), parses the HTTP result into a VerificationReport structure.
9. Untrusted sends the VerificationReport into the Enclave.
10. Enclave verifies the signature of the given report, and checks that IAS has properly approved it, and checks that the quote contained in the signed report matches the quote it earlier approved.
11. Enclave caches the VerificationReport and provides it upon demand to clients.

The API should also be viable for the case where a remote entitity (the "service provider," in Intel terminology) is performing it's own verification. In this scenario, the attestation should look something like this:

1. Untrusted calls TargetInfo::for_quoting_enclave() to retrieve the TargetInfo and EpidGroupId objects for the quoting enclave and the platform, respectively.
2. Untrusted provides the results to the enclave ("how" is unspecified).
3. Enclave calls Report::new() providing it the enclave's identity as report_data.
4. Enclave returns the Report to the untrusted code.
5. Untrusted uses Quote::new() to communicate with the quoting enclave and get a quoted version of the Enclave's report.
6. Untrusted gives the resulting Quote to the Remote.
7. The Remote loads the Quote into a request to IAS, and transmits it.
8. Remote parses the resulting response from IAS into a VerficationReport.
9. Remote verifies the signature of the given report, and checks that IAS has properly approved it.

Future Work

The most obvious missing functionality in this crate is support for the Data-Center Attestation Primitives, which is an alternative to the IAS signature chain for use in constrained environments. In addition to contacting configurable machines, rather than the hard-coded IAS server address, DCAP also uses ECDSA in preference to RSA signatures. Other differences are unknown as of the time of this writing.