How can challenger verify code executed inside the enclave ?

[victormassy]

Hey, this is a more high level question to understand how attestations work.

If I understand correctly, when SGX report is send over to the trusted machine, it has to be verified by IAS and the challenger is not able to extract information from this report. It is important for the challenger to be able to trust the code run inside the enclave. My question is: How can IAS verify that this code does not reveal any secret information and does what the challenger allows ?

Thank you

[dimakuv]

If I understand correctly, when SGX report is send over to the trusted machine, it has to be verified by IAS and the challenger is not able to extract information from this report.

You mix a lot of different things here. Let's clear the terminology first.

1. SGX remote attestation sends so-called SGX quotes, not SGX reports:

   • SGX report is a hardware-defined struct that contains main enclave measurements (MRENCLAVE, MRSIGNER, etc.). See Intel SDM documentation, Volume 3, Chapter 34.16 "REPORT".
   • SGX quote is a software-defined struct that embeds the SGX report. Additionally to what SGX report provides, the SGX quote contains e.g. the signature of the special SGX Quoting Enclave (also called QE). See e.g. the definition here.

2. There are two properties that one wants to verify via SGX remote attestation:
   a. "Is this a real genuine SGX hardware on which the SGX enclave executes?" -- this question is answered by IAS server (or DCAP server, if using newer attestation scheme).
   b. "Is this the SGX enclave I am expecting?" -- this question is answered by the trusted machine (aka verifier aka challenger).

3. IAS (Intel Attestation Service) is only used for the older EPID attestation scheme. Typically, new SGX deployments/environments use the newer ECDSA/DCAP attestation scheme.

4. If you really want to use IAS (e.g., because you have an older SGX client platform), then you must understand the flow:
   a. SGX quote is generated for the to-be-attested SGX enclave,
   b. This SGX quote is sent to the trusted machine (aka verifier aka challenger),
   c. The trusted machine forwards this SGX quote to the IAS over internet,
   d. IAS verifies the "is this a real genuine SGX hardware?", by examining the incoming SGX quote,
   e. IAS produces an outgoing so-called SGX attestation report (not to be confused with SGX report), which basically has a string saying "VALID" or "INVALID, here are the problems: ...".
   f. IAS sends the SGX attestation report back to the trusted machine,
   g. The trusted machine verifies that the SGX attestation report contains "VALID" -- now the trusted machine knows that the SGX hardware is good.
   h. Finally, the trusted machine looks into the SGX quote itself, extracts SGX measurements (MRENCLAVE, MRSIGNER, etc) and answers the question "is this the expected SGX enclave?"

---

Now, knowing this information, let's answer your question.

How can IAS verify that this code does not reveal any secret information and does what the challenger allows ?

IAS doesn't verify this. IAS only verifies that the SGX quote was produced by a good well-known SGX hardware, which is up-to-date and runs good well-known QE.

This job is done by the trusted machine itself -- it must check the SGX quote. Gramine provides mechanisms for this, the most important one being RA-TLS. In particular, there are two ways to check the SGX quote's enclave measurements:

• via environment variables -- https://gramine.readthedocs.io/en/stable/attestation.html#mid-level-ra-tls-interface
• programatically in C -- https://github.com/gramineproject/gramine/blob/2a493353f06910850e4d4fc674b63cd813c5e5a3/tools/sgx/ra-tls/ra_tls.h#L79?plain=1

[victormassy]

Thank you for your help.

I'm still a bit confused about the check that is done by the challenger. RA-TLS creates a pipeline between the TEE and challenger. I assume that the challenger can send data and code to the TEE with this connection. But is it possible for the challenger to verify and use code that is already inside the TEE ? If yes, how can the challenger check that the code is not leaking secret data ? Does he need to have access to the code and check some kind of hashed value ?

[dimakuv]

RA-TLS creates a pipeline between the TEE and challenger. I assume that the challenger can send data and code to the TEE with this connection.

Yes, RA-TLS creates a normal TLS connection between the TEE and the challenger. Then this connection can be used to transfer any data the TEE/challenger want to and agree upon. If the TEE and the challenger have the logic to send data/code from challenger to TEE (and the TEE has the logic to "unpack" this data/code and jump into it afterwards), this can be done for sure. Note that this app-level logic is not part of RA-TLS; RA-TLS is merely a TLS layer.

But is it possible for the challenger to verify and use code that is already inside the TEE ?

Yes. Though I'm unsure what you mean by "use code".

The challenger gains trust in the initial state of the TEE (initial code, data and configuration upon TEE startup) by performing SGX remote attestation and examining SGX enclave measurements. In particular, to verify the initial code/data/configuration, the MRENCLAVE measurement is used. MRENCLAVE is a cryptographic hash that reflects several things: the Gramine binaries, the application binaries, the final manifest.sgx file (and transitively all the sgx.trusted_files listed in the manifest file).

In other words, MRENCLAVE is the "golden" value that the challenger is expected to know in advance and compare against during SGX remote attestation. If the code/data/configuration of the TEE was maliciously modified during startup, this will be reflected in MRENCLAVE (it will deviate from the golden value), and the challenger will notice this -- and fail the SGX attestation (refuse to trust this SGX enclave).

If yes, how can the challenger check that the code is not leaking secret data ?

The challenger must have trust in the code that is reflected in MRENCLAVE. Basically, the challenger must audit/review the code to make sure the code doesn't leak secret data. This is easier said than done -- basically, the challenger must more or less trust that some code (e.g. Redis codebase) is written in a way to not leak data.

Does he need to have access to the code and check some kind of hashed value ?

Yes to both questions. See my explanations above. Also, I'd recommend to learn more about SGX attestation and MRENCLAVE on the internet.

[victormassy]

Thank you for your time, I think I have a better understanding of the technology now. I will continue my research on my own.