# Enhancing the Privacy of Network Services through Trusted Computing
## 3 A Trusted and Backward-Compatible Addressing Service
### Trusted Service  
To offer confidentiality and integrity for DNS programs, we propose a trusted and backward-compatible DNS based on the Intel SGX. In this service, a resolver running in an enclave is introduced into the traditional DNS infrastructure. After verifying the attestation evidence of a resolver and establishing an authenticated TLS channel, the DoTT encapsulates the encrypted query content in a standard DNS message to keep it from exposure and disclosure to unwanted parties.  
The flow of the authenticatable DNS service for privacy-preserving is illustrated in Figure 1. The DNS client is a stub process that can run in a normal environment without the SGX hardware. This stub is responsible for receiving and forwarding DNS resolution requests from various web applications, such as browsers that run on the same host as these applications. Benefiting from the design of DNS, we can enhance the privacy of DNS by simply replacing the regular certificate validation in TLS with a Quote report validation from an IAS. This change has less impact on the existing architecture and is transparent to the upper-layer web applications. We assume that: (i) the DNS stub (denoted as \(S\)) has deployed a list of trusted DoTT values (denoted as \(L\)); (ii) there is a channel between the DoTTs (denoted as \(D\)); (iii) public domain name servers (denoted as \(NS\)) are safe and faithful; (iv) there are no vulnerabilities and malicious code inside the enclave. This assumption is reasonable since enclave code is often developed by users themselves and has been audited.  
The DoTT consists of two stages: (i) the remote attestation and the establishment of a secure channel between the DNS client (stub) and the DNS resolver (DoTT); (ii) the private DNS query based on the TLS channel. The first stage closely integrates TLS with the remote authentication using SGX features as follows:  
Figure 1: DoTT: The privacy enhancement framework for DNS based on TEE (Intel SGX).  
When web applications initiate a DNS query (denoted as \(R\)), the \(S\) will check whether a TLS connection has been established.
2. The \(S\) directly forwards \(R\) to \(D\) using the encrypted channel if the connection is established. When \(D\) receives the request, it will get the IP address corresponding to the request from the NS as the conventional recursive resolving method and return it to \(S\).
3. The \(S\) will challenge \(D\) by sending a nonce to it if the connection is not established. To convince \(R\) that it is a genuine Intel SGX enclave running on an authenticatable DNS resolver, \(D\) first performs the LA with the quoting enclave (donated as \(Q\)) in the local machine. If S succeeds in generating an authentication message (denoted as \(M\)), \(Q\) will sign the hash value of the authentication result, which comprises the public key of \(D\).
4. After receiving the report, \(S\) can forward it to the IAS, which is a public webserver to provision a message generated by genuine Intel hardware. We can also adopt the Intel SGX DCAP [31] (Data Center Attestation Primitives) as an alternative to provision attestation services into a user-side database. After registering the genuine information to DCAP during the deployment phase, the whole remote attention procedure can be finished without an Internet connection in DCAP. After validating the reported signature using the certificate of IAS, S will check the enclave identify (MRENCLAVE) is in the list \(L\). Then, the DNS stub can assure that DoTT is running a genuine SGX enclave and uses the public key hash in M for the following TLS connection.
5. Once \(S\) confirms the authentication and validation of \(M\), it will exchange a symmetric session key (donated as \(K\)) to encrypt subsequent DNS queries. Therefore, \(S\) and \(D\) can communicate in an authenticated and privacy-preserving way with \(K\).