initc3/auditee

Tool to verify the reproducibility of SGX enclave builds

auditee's Issues

Look into mobilecoin / reproducible builds

See https://github.com/mobilecoinfoundation/mobilecoin/blob/master/consensus/service/BUILD.md#build.

• Build the consensus enclave.
• Try to understand what's the role of the signed enclave, used to build.
• How can one re-build the downloaded signed enclave, to convince oneself that it was built from a specific version of source code?
• etc

Add sgx-iot example

Provide signed enclave, and ias report, like in the case of the hash machine example.

• Document how to extract the public key from the report data, and use it to verify the signature of the sensor data.

Add example with gramine (aka graphene)

https://github.com/gramineproject/gramine

IAS report signature verification

From https://api.trustedservices.intel.com/documents/sgx-attestation-api-spec.pdf:

4.2.2 Report Signature

The Attestation Verification Report is cryptographically signed by Report Signing Key (owned by the Attestation Service) using the RSA-SHA256 algorithm. The signature is calculated over the entire body of the HTTP response. Base 64-encoded signature is then returned in a custom HTTP response header X-IASReport-Signature. To verify the signature over the report, you should the following steps:

1. Decode and verify the Report Signing Certificate Chain that was sent together with the report (see Report Signing Certificate Chain for details). Verify that the chain is rooted in a trusted Attestation Report Signing CA Certificate (available to download [from Development (DEV) attestation service portal] upon successful registration to IAS).
2. Optionally, verify that the certificates in the chain have not been revoked (using CRLs indicated in the certificates)
3. Verify the signature over the report using Attestation Report Signing Certificate.

4.2.3 Report Signing Certificate Chain

The public part of Report Key is distributed in the form of an x.509 digital certificate called Attestation Report Signing Certificate. It is a leaf certificate issued by the Attestation Report Signing CA Certificate:

1. Attestation Report Signing CA Certificate: CN=Intel SGX Attestation Report Signing CA, O=Intel Corporation, L=Santa Clara, ST=CA, C=US
2. Attestation Report Signing Certificate: CN=Intel SGX Attestation Report Signing, O=Intel Corporation, L=Santa Clara, ST=CA, C=US

A PEM-encoded certificate chain consisting of Attestation Report Signing Certificate and Attestation Report Signing CA Certificate is returned in a custom HTTP response header X-IASReport-Signing-Certificate.

The attestation report root CA certificate can be obtained at https://api.portal.trustedservices.intel.com/EPID-attestation. Look for the line:

Attestation Report Root CA Certificate: DER PEM

Implementation

See example (C++): https://github.com/hyperledger-labs/private-data-objects/blob/04d6b93737bc2c0446d292a028087ef4fb365ca7/common/crypto/verify_ias_report/verify-report.cpp

If using Python, some options are:

• https://www.pyopenssl.org/en/stable/api/crypto.html?highlight=X509_verify_cert#x509storecontext-objects
• https://github.com/wbond/certvalidator
• https://opendev.org/x/cursive/src/branch/master/cursive/certificate_utils.py

Implement command-line interface

Rough sketch of the interface:

# check that an IAS report corresponds to the expected source code
auditee --check-mrenclave --ias-report <ias-report-json> --src-url <src-code> 
auditee --check-mrenclave --ias-report <ias-report-json> --src-path <src-path>
auditee --check-mrenclave --ias-report <ias-report-json> --nix-file <nix-file>

# check that the signed enclave binary corresponds to the expected source code
auditee --check-mrenclave --signed-enclave <signed-enclave> --src-url <src-code> 
auditee --check-mrenclave --signed-enclave <signed-enclave> --src-path <src-path>
auditee --check-mrenclave --signed-enclave <signed-enclave> --nix-file <nix-file>

Examples

Check whether an IAS report corresponds to some given source code, identified via its URL.

auditee --check-mrenclave --ias-report ias-report.json --src-url https://github.com/sbellem/sgx-iot

Check whether a signed enclave binary corresponds to the expected source code, identified via its URL.

auditee --check-mrenclave --signed-enclave enclave.signed.so --src-url https://github.com/sbellem/sgx-iot

Support building enclave from nix derivation without docker

Currently, everything is done within a docker image, as a base image with a nix package for the sgx sdk is already installed, and prebuilt, to save time. However, we now used cached prebuilts hosted on cachix, and nix derivation to build enclaves can be written to fetch from a github archive (tarball), and if the local nix installation is configured to use the cache, the sgx sdk will not be re-built (which could take more than 2 hours), but instead fetched from the cache.

Add example using ORAM

Upgrade to more recent python-on-whales

The --file option is not supported in newer versions. See the changelog to know what to change. Currently, since python-on-whales is not pinned, the verify_mrenclave() function fails.

In the meantime pin python-on-whales to a working version, such 0.17.1.

Document example with sgx-hashmachine

The example sgx-hashmachine involves hashing a string a billion times in an enclave and putting the result in the REPORT DATA of a quote for a remote attestation report.

Since computing the hash billion times is a bit annoying as it takes about 10 minutes, this example may be well suited to show that as an alternative to perform the computation oneself in order to verify that the resulting final hash is correct, knowing the initial string, one may instead "trust" Intel and the remote attestation process, etc.

This is a dummy example to demonstrate how one could gain trust in remote computations that are outsourced to cloud services. In other words, if the remote computations are performed in enclaves that are remotely attested, then one can be somewhat certain that the computations were done according to some known source code. How can one be certain that the deployed and remotely attested enclave was built from some source code? That is the purpose of this example, to show how the auditee tool can be used to automate this verification.

• Clarify how to get data to an enclave for applications that require user input in such a way that the integrity of the data is preserved and guaranteed. In other words, how can we prevent the untrusted part of the application to change the data submitted by the user? Is the [sigma protocol](https://en.wikipedia.org/wiki/Proof_of_knowledge#Sigma_protocols] as presented in https://software.intel.com/content/www/us/en/develop/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example.html to establish a shared key the only way? What if a user encrypts data with a public-key generated in an enclave and published in the REPORT DATA of a remote attestation report? The untrusted part of the application may also have access to the public key and encrypt something else and replace the user input and the enclave code cannot know the difference.
• Look at sgx iot example.

One way to ensure that the input data was not tampered with is to put a hash of it in the REPORT DATA of a remote attestation.

Support latest Python versions

Verify the SIGSTRUCT ATTRIBUTES field

See Intel SGX explained paper for why this is important.

Figure how remote attestation works with fortanix

Resources

• https://github.com/ndokmai/rust-sgx-remote-attestation
• fortanix/rust-sgx#207
• (not sure) https://github.com/fortanix/rust-sgx/tree/master/em-app

Support passing trusted source code as URL

When verifying the reproducibility of an enclave build, the file path to the source code must be passed. In addition to the file path, support also a URL, from which the source code can clone or downloaded. As a first iteration, support cloning with git. Note that it is somewhat redundant to do this because the nix derivation also fetches from a (GitHub) URL. So, we'd be fetching the code twice: once to be able to read the .enclavehub.yml, and second, to be able to build the source code.

Use SGX_SDK instead of SGX_SDK_CMD

Sealing example with protection against rollback attacks

From https://edp.fortanix.com/docs/concepts/sgx/

Also, if your enclave stores more than one sealed blob, the service may perform a partial rollback attack by returning different versions of different blobs. One possible defense against this attack is to track the integrity of all blobs as a whole, for example with a Merkle tree.

Update README

Re-work packaging using hatch

https://github.com/pypa/hatch

Add Black-Scholes-Merton (sgx-bsm) example

Source: https://github.com/sbellem/sgx-bsm

Test example on Windows platforms

pip installation does not work

auditee mrenclave --help
Traceback (most recent call last):
  File "/usr/local/bin/auditee", line 5, in <module>
    from auditee import main
ImportError: cannot import name 'main' from 'auditee' (/usr/local/lib/python3.9/site-packages/auditee/__init__.py)

Reminder: sgx sdk used to sign must match the one used to build

When attempting to reproduce an enclave build, the SGX SDK version used must match the one used to sign that build.

Look into binary correctness verification

Problem

How can we be sure that the trusted source code was correctly compiled? How can we be sure that the enclave binary is a correct compilation of the source code, and thus preserves the properties which are trusted?

Remote attestation allows a user to gain trust that a remote computer is running the expected source code, on genuine and up-to-date hardware. When an enclave binary is loaded in the protected memory region, a measurement is performed, which yields a cryptographic hash, known as MRENCLAVE. This hash uniquely identifies the loaded code, and is included in the remote attestation report. A verifier can consequently compare the MRENCLAVE in the report with the trusted MRENCLAVE. The trusted MRENCLAVE can be established by using a toolchain to build the enclave binary from the trusted source code, and simulating the measurement with Intel's sgx sign tool which will yield a data structure known as SIGSTRUCT, which contains the MRENCLAVE. The verifier and enclave developer must agree on the toolchain in the sense that the toolchain must yield reproducible builds, meaning that building the enclave binary from the same source code should yield the exact same MRENCLAVE.

The toolchain proposed by linux-sgx and auditee use nix as it provides strong reproducibility guarantees. However, the fact that a build is reproducible does not guarantee that it was correctly compiled, meaning that the compiler did not introduce some kind of deviations from the source code such that although one may trust the source code, one would not trust its "faulty" binary
representation.

Hence, the question: "How can we make sure that the compiler used was not faulty?"

For a somewhat detailed idea of what this is about see section 3.1 and more particularly subsection Translation validation in https://sel4.systems/About/seL4-whitepaper.pdf:

verify_mrenclave: accept IAS report dict

In addition to taking a json file as an argument, also accept a dict instead of a file. This is useful when using programmatically.

Emphasize the report data as the "trusted" or "untrusted" output

Given the following inputs:

• a signed enclave Enclave.signed.so,
• some source code, and
• an IAS report,

ouput:

• Whether the REPORT DATA can be trusted (based on whether the MRENCLAVE of each input all match).
• The report data itself
• The MRENCLAVEs

Add example using the Rust SGX SDK

Resources:

• https://nixos.org/manual/nixpkgs/stable/#rust
• https://github.com/mozilla/nixpkgs-mozilla#rust-overlay
• https://christine.website/blog/how-i-start-nix-2020-03-08
• https://github.com/nix-community/naersk

Rough outline of steps:

• Set a standalone simple Rust enclave repo. We can extract the helloworld from the samplecode into its own repo, and change the relative path ...