Secure Networking
As discussed in Basic Networking, the networking proxies work on the TCP or IP layer with some components on the host. This makes them untrusted. Hence, another protocol is needed on top to secure the connection.
Fortunately, this is not a problem unique to enclaves. The entire internet relies on untrusted routers operating at the IP or sometimes TCP layers in order to route traffic to the right destination. The host of an enclave is no different from a router or an ISP from this perspective. Therefore, all security measures usually applied to the Internet carry over to enclaves as well. But what exactly are these?
Transport layer security
Conceptually, transport layer security refers to a protocol that is used to "secure" the transport layer of the networking stack, most commonly TCP. Security is intentionally vague, but the most important properties that are commonly desired are:
- Privacy, intermediaries should not be able to peek into connections.
- Integrity, intermediaries should not be able to successfully add or remove data from the connection stream without being noticed.
Some use-case specific properties include server authentication, client authentication, etc.
On the internet, it takes the form of the aptly named Transport Layer Security (TLS) protocol. It is used to secure a wide range of applications from emails to messaging to VoIP. However, the most common and recognizable use case is HTTPS, securing your connections to websites and ensuring intermediaries cannot tamper with the website or steal your passwords or credit cards.
TLS from the enclave
Initiating TLS connections from the enclave requires no additional setup and just work! Enclaves commonly include a set of root certificates matching Web PKI. TLS connections made from within the enclave work as usual and automatically inherit all the desired security properties, including server authentication.
TLS to the enclave
Some use cases might require servers to run inside enclaves and expose TLS endpoints. Just as with TLS from the enclave, the TLS part itself just works! Assuming a server running inside the enclave with the proper certificates and keys configured, clients can just establish TLS connections to the server as usual and automatically inherit all the desired security properties.
The real complexity is in the assumption above, how do you provision an enclave with the proper certificates and keys? A trivial method is the enclave generating a self signed certificate and including the certificate in remote attestations. It works and is secure, but it requires the client to be able to accept self signed certificates and more importantly, verify remote attestations.
But what if we need "normal" clients (like browsers) to interact with the enclave securely? Before discussing options, it is worth mentioning the properties that we are looking for. For one, the TLS certificates have to be "real", rooted in Web PKI that these tools accept. The most important property however is the clients not having to verify remote attestations and simply verifying TLS. This implies that clients verifying TLS is enough for security, they can be considered to have verified the remote attestation implicitly. This is only possible if the enclave can obtain certificates and keys without the host or other intermediaries being able to.
Provisioning TLS certificates
The naive way of packaging the certificate and key with the EIF does not work, it exposes the key. In addition, certificates expire, and should expire sometimes in a matter of months when following good security practices. Making new EIFs (with new PCRs btw) and deploying them every time this happens is an arduous task.
One option is the domain owner provisioning the certificate at runtime. It is possible to setup secure channels without needing TLS (see Enclave native TLS section below) and transfer certificates and keys to the enclave. However, this has similar problems of needing busywork and/or external automation from the domain owner to maintain such a workflow. This is also assuming that the domain owner is a person capable of performing these actions which might not be true in Web3 native domain registrars like 3DNS where a smart contract could be the domain owner.
Instead, is there a way for the enclave and only the enclave to obtain TLS certificates when they need it? Enter CAA records, and more specifically, RFC8657. These records allow domain owners to specify restrictions on who can issue certificates to whom. When configured correctly, TLS certificate issuance can be locked to a specific ACME account that is generated inside the enclave. This lets domain owners ensure that only specific enclaves can issue themselves certificates and users can rely on just vanilla TLS.
Enclave native TLS
Traditional TLS relies on Web PKI which in turn relies on Domain registrars, DNS, Certificate Authorities (CAs) and more. Oyster offers a much simpler option called Scallop which does not require trust in Web PKI for setting up secure channels.
Conceptually, Scallop can be thought of as a TLS protocol that operates with attestations in place of certificates, thereby removing dependence on Web PKI. It is implemented as a Noise-based protocol with configurable attestation generation and verification that can be tailored to specific use cases. The examples are a good place to start diving into Scallop.