How to Add TLS to Nitrogen

Cape provides an isolated compute environment to protect your data and code while it's being processed. But how do you get your data and code into Cape in the first place? For that, we rely on TLS (which is the protocol behind HTTPS). TLS within an enclave provides unique challenges.

TLS alone is not enough to verify you are communicating with an enclave. TLS certificates are issued for a domain, and any service behind that domain with access to the certificate could handle a request. Typically, TLS is terminated at the load balancer on the edge of the network. So how do you ensure that only the enclave has the certificate? We need a way to get the certificates into the enclave without any computer or person having access to them. Along with this we also need to ensure that attestation is properly implemented. The enclave provides an unforgeable attestation document which allows you to verify that the correct enclave is receiving the connection.

First TLS Implementation

During initial experimentation and testing we wanted to get TLS up and running as fast as possible. To accomplish this we bundled the certificates directly into the docker image that would then be turned into an EIF. For the very limited case of testing TLS and development this is a valid solution to make sure your software supports TLS right from the beginning. We added an example of how to set this up Nitrogen to easily test your TLS setup as well.

There are a few reasons why we wanted to avoid this solution in production. First, it was hard to manage the certificate in a way that would keep the certificate safe. If the certificate got leaked then it would be possible for someone to install the certificate elsewhere to impersonate the enclave by just hosting the same hostname. Also since we were bundling the certificate in the EIF if someone just had a hold of the docker image or EIF they could extract the certificate. 

We didn't end up keeping this implementation around for long and quickly switched to a more secure implementation.

Current TLS Implementation

Our current TLS implementation leverages a certificate generator enclave to generate a private key and certificate signing request (CSR). The private key is immediately encrypted within the enclave with a key that only allows a verified Cape enclave to decrypt and the CSR is sent to a Certificate Authority to be signed and converted to a valid certificate. This certificate and the encrypted private key are then linked to an attestation document to prove it was the certificate generator enclave that created the data. This data is then stored in a secure way for the main enclaves to download. There are three things protecting the private key: 

1. The private key is encrypted by the certificate generator enclave before being stored and can only be decrypted by the main enclave. It can never be seen unencrypted outside of a verified Cape enclave.

2. The attestation document can be used by the main enclave to verify the authenticity of the certificate and private key generated.

3. Within the main enclave the unencrypted private key is removed from memory once the TLS handshake has occurred.

While this solution is more complicated it ensures that the private key cannot be used by any other server or human.

There are a few technical details missing here that we could cover in a future blog. Let us know if you’re interested!

We have some ideas of future implementations for TLS that will make the infrastructure easier to manage. We’ll share more information once we’ve done more experimentation.

Let us know if you have any ideas or questions about TLS in enclaves!

Thanks for reading! We'd love to hear what you think in the comments below. Please star Nitrogen on GitHub, and come chat on Discord.

Check out the Getting Started Docs to try Cape for free. We'd love to hear what you think