Remote attestation sample using MAA: why communication with MAA inside SGX enclave?

[dimakuv]

Hi,

I was looking at this example: https://github.com/edgelesssys/ego/tree/master/samples/azure_attestation

You have the following diagram:

Here you have all the HTTPS communication with the MAA attestation provider -- more specifically, its attest/ REST endpoint -- happen inside the SGX enclave.

From what I imagine, the HTTPS codebase in Go is rather big. Also, you need a JSON/JWT parser. Maybe some other dependencies. But even with this HTTPS dependency -- this should increase the TCB of the SGX enclave significantly.

Do you consider it a problem?

Couldn't this whole communication with MAA be moved out of the enclave? From what I understand, none of these communicated objects are private/secret: the attestation request (contains the SGX quote) and the attestation response (the JWT token) can be viewed by anyone. Then the enclave won't need the complex dependencies of HTTPS and JSON. Especially if we're thinking about tiny enclaves that do some simple things, e.g., Redis caching.

[dimakuv]

By the way, technically steps 2-4 can be moved to the Sample Client. In this case, the Sample Client won't need steps 6-7 at all, because the Sample Client already talks to the MS Azure attestation provider during steps 2-4 (so, the client already verified that he talks to a proper Microsoft-endorsed service and can trust what it receives from it).

[thomasten]

Hi @dimakuv,

Yes, this all happens inside the enclave. This is because EGo doesn't follow the model of partitioning an app. Currently, we implemented the MAA support as part of the enclave library that we provide to the developers. But I agree, as long as we can hide it from the developer, it would be better to partition such code and there's no technical or UX reason against it. However, at the moment that can't be done effortlessly. (We don't have Go support for host code, so we'd either need to add it or implement this part in C++.)

The JSON parser is part of Go's stdlib and JWT is only needed at the client, so at least there's no third party library involved.

I think you're right about moving steps 2-4 is technically possible. When you look at https://docs.microsoft.com/en-us/azure/attestation/workflow#intel-software-guard-extensions-sgx-enclave-validation-work-flow, in our example the relying party is the ra_client and what they call client is merged with the enclave, but could/should be partitioned to the enclave host.

[dimakuv]

Thanks @thomasten, these are very good insights. I'll close the issue.

In case you're interested, my proposal to implement MAA support in Gramine's RA-TLS is outlined here: gramineproject/gramine#626. Feel free to comment, especially if you notice a design flaw or some incorrect assumption.