FR: Separate BoringSSL interface to have a minimal trusted interface internally to an enclave

[mr-ma]

I wonder if the current BoringSSL wrapper is actually benefiting from the trusted hardware (see https://github.com/google/channel-id-enclave/tree/master/boringssl). Simply put, are the secrets (private key, session key, etc.) allocated inside enclaves?

[deeglaze]

Will you please elaborate on what you mean by "allocated inside enclaves"? Do you mean actual memory allocation, the creation of keys from a random source, or how one gets secret keys into an enclave from an untrusted environment?

[mr-ma]

Yep, more specifically, I'm curious to know if private keys, session keys used to communicate with clients, and all the code related to the TLS protocol implementation (e.g. SSL_read() and SSL_write()) are placed inside enclaves.
Right now, I'm more concerned about the runtime protection of TLS in hostile environments. Secure secret provisioning would be the next problem to tackle.

[deeglaze]

Every instance of memory allocation, either via the stack, malloc, or new, are all internal to enclaves. The enclave heap is entirely within the enclave memory, and the BoringSSL code is statically linked into Asylo enclave object files, so everything is within the enclave.

It is very awkward to write memory outside of the enclave. The only interface that does it is our boundary-crossing code. You essentially have to cast an int passed in from the untrusted environment to a void* in order to start writing to untrusted memory.

[mr-ma]

Thanks for the clarification. This is actually convenient.
However, shipping the entire TLS library into an enclave yields an excessive code base residing in trusted regions, which is in some cases undesirable (see the main motivation behind Glamdring)

IMO it would be very useful to have a trusted BoringSSL library in which only sensitive code (ssl_read, ssl_write, etc.) and data (private keys and session secrets) reside inside enclaves.

[deeglaze]

Okay, yes. Asylo currently doesn't have a lightweight way to call out of the enclave to user-defined interfaces/library wrappers. You can achieve this by using gRPC to make RPCs out of the enclave. This is an interesting offering for minimizing the TCB, so we'll keep it in mind for our roadmap.

I'll keep this issue open and edit the title to track this feature request.