RA-TLS Feature request: Sign the Cert by an external Authority rather than Self Signed

[prakashngit]

This is a feature request to have the X.509 certificate used in Graphene RA-TLS signed by an external authority rather than self-signed by the enclave as it is now. The feature would be very useful to bind the graphene instance to the host of the enclave if the host can use its keys to sign the X.509 certificate.

Context

In applications such as Federated learning, one to would like multiple data owners to execute the same training algorithm but with different datasets. We use graphene to run the training algorithm at the data owner hosts. The "common" graphene binary for the data owners is built & signed at a central location and shipped to all the data owners. So all data owners will use the same enclave (so they will all run the same algorithm). During each iteration of the training, a data owner graphene instance sends a request to the Aggregator server to get information about the "training task" that this specific instance is supposed to execute. Before responding to the request the server needs to identify two things:

1. The request comes from a valid enclave with the expected SGX measurements (RA-TLS will satisfy this requirement)
2. Identify the data owner host from which the request is generated, since the response depends on the "specific" data owner host. There is nothing in the quote that can be used to associate the enclave with the host, during RA-TLS.

Ad-hoc solution for "2" above while still using RA-TLS: the host after standing up the enclave, gets the RA-TLS certificate (as it is today) from the graphene instance and uses an "out-of-band" mechanism to inform the Aggregator that "this graphene instance belongs to me".

Cleaner solution: The X509 certificate used by graphene for RA-TLS is signed by the host rather than self-signed. This way the host is easily added to the cert chain. The host certs are pre-established and globally known, and host identification becomes part of the RA-TLS framework without the application having to implement ad-hoc solutions.

Thanks
Prakash

Description of the problem

Steps to reproduce

Expected results

Actual results

[g2flyer]

Technically, this would essentially mean that instead of creating the self-signed certificate, the enclave would create a certificate signing request (CSR) with the same content and exports it to be sent to the corresponding organizational CA. As long as that CA would process the extension with the attestation and include it in the certificate, this should work nicely and shouldn't require that many chances to the enclave code. [In fact, this was an option which was considered in the original design of RA-TLS but omitted due to resource constraints ..]

[monavij]

This is where you can also use config id to identify the host. At create time specify the hostID that graphene can add to KSS/Config ID and you can verify tha via attestation.

[mkow]

The "common" graphene binary for the data owners is built & signed at a central location and shipped to all the data owners. So all data owners will use the same enclave (so they will all run the same algorithm).

The parenthesis isn't true, but let's keep this discussion in #2208.

The specific implementation suggested by @g2flyer sounds reasonable to me.

[dimakuv]

I agree that the "generate CSR in an enclave, send to a CA, receive the RA-TLS-enhanced certificate back" proposed by @g2flyer is reasonable.

We can implement this, though I currently don't know what this second step of "send to a CA" should look like. Do we want to rely on a specific implementation of this communication with CA, like a Kubernetes one? E.g. see https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/.

Ideally, this "send to a CA" should be proxied through a separate host service with a well-defined interface. It would be great to have such a plugin to AESM daemon, since Graphene already uses it for SGX quotes (i.e., to communicate with the Quoting Enclave).

[dimakuv]

@prakashngit What about the alternative approach of a central attestation entity: #2208 (comment)?