Enhancing Security and Privacy of Tor’s Ecosystem by Using Trusted Execution Environments Seongmin Kim, Juhyeng Han, and Jaehyeong Ha, Korea Advanced Institute of Science and Technology (KAIST); Taesoo Kim, Georgia Institute of Technology; Dongsu Han, Korea Advanced Institute of Science and Technology (KAIST) https://www.usenix.org/conference/nsdi17/technical-sessions/presentation/kim-seongmin This paper is included in the Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’17). March 27–29, 2017 • Boston, MA, USA ISBN 978-1-931971-37-9 Open access to the Proceedings of the 14th USENIX Symposium on Networked Systems Design and Implementation is sponsored by USENIX. Enhancing Security and Privacy of Tor’s Ecosystem by using Trusted Execution Environments Seongmin Kim, Juhyeng Han, Jaehyung Ha, Taesoo Kim∗, Dongsu Han KAIST Georgia Tech∗ Abstract because Tor relays can identify the circuit using its iden- With Tor being a popular anonymity network, many at- tifiers. To prevent malicious relays from entering the tacks have been proposed to break its anonymity or leak system, Tor exercises a careful admission and vetting information of a private communication on Tor. However, process in admitting new relays and actively monitors guaranteeing complete privacy in the face of an adver- their operation. At the same time, to make traffic analysis sary on Tor is especially difficult because Tor relays are more difficult, Tor relies on having a large number of under complete control of world-wide volunteers. Cur- relays and tries to keep a diverse set of relays spread out rently, one can gain private information, such as circuit world-wide [33, 34], which helps to decrease the chance identifiers and hidden service identifiers, by running Tor of selecting two or more relays controlled by an adver- relays and can even modify their behaviors with malicious sary. However, having a large network and keeping all intent. relays “clean” are fundamentally at odds in a volunteer- based network. This is exemplified by the fact that, by This paper presents a practical approach to effectively design, Tor relays are not trusted; in operation they are enhancing the security and privacy of Tor by utilizing carefully admitted and their behaviors are examined by a Intel SGX, a commodity trusted execution environment. centralized entity [27, 35]. We present a design and implementation of Tor, called SGX-Tor, that prevents code modification and limits the Even having control over a relatively small number of information exposed to untrusted parties. We demonstrate Tor relays still gives significant advantages to attackers. that our approach is practical and effectively reduces the For example, a malicious adversary can change the be- power of an adversary to a traditional network-level adver- havior by running a modified version of Tor, compromise sary. Finally, SGX-Tor incurs moderate performance over- keys, and/or have access to other internal information, head; the end-to-end latency and throughput overheads such as the circuit identifier, header, and hidden service for HTTP connections are 3.9% and 11.9%, respectively. identifiers. In fact, many low-resource attacks (i.e., at- tacks that do not require taking control of a large fraction 1 Introduction of the network) heavily rely on adversaries acquiring in- Tor [35] is a popular anonymity network that provides ternal information or being able to modify the behavior of anonymity for Internet users, currently serving 1.8 million Tor relays. These low-resource attacks utilize a combina- users on a daily basis [13]. Tor provides sender anonymity tion of multiple factors, such as being able to demultiplex through multi-hop onion routing/encryption as well as re- circuits, modify the behavior, and access internal data sponder anonymity using “rendezvous points” that allow structures. For example, harvesting hidden service iden- the operation of hidden services. It is a volunteer-based tifiers [27] requires access to a relay’s internal state, a network in which world-wide volunteers donate their com- sniper attack [43] requires sending false SENDME cells, putation and network resources to run open-source Tor and tagging attacks [60] require access to header informa- software. At the time of this writing, Tor consists of tion. Selective packet drop [27, 43] or circuit closure [28], 10,000 relays, with some relay nodes even known to be used by many attacks, also requires being able to demulti- run by a variety of law enforcement agencies around the plex circuits with circuit identifiers. world [5, 15]. However, it is not without limitations. This paper aims to address the current limitations of Tor Fundamentally, Tor is vulnerable when an attacker con- and practically raise the bar for Tor adversaries by using trols a large fraction of relays; anonymity (or privacy) Intel SGX, a commodity trusted execution environment can be broken if all relays in a circuit are compromised (TEE) available on the latest Skylake and Kaby Lake USENIX Association 14th USENIX Symposium on Networked Systems Design and Implementation 145 microarchitectures. We ask ourselves three fundamental discusses remaining issues and concerns. x 8 presents questions: (1) What is the security implication of applying related work, and x 9 concludes our work. TEE on Tor? (2) What is its performance overhead? and (3) Is it deployment viable in the current Tor network? 2 Background To this end, we design and implement SGX-Tor, which This section provides key features of Intel SGX and an runs on real SGX hardware. We show that it can effec- overview of the Tor anonymity network. tively reduce the power of Tor adversaries to that of a Intel SGX: Intel SGX provides isolated execution by network-level adversary that cannot see the internal state putting and executing the code and data of an application of Tor components. Specifically, we protect private Tor inside a secure container called an enclave. It protects operation, such as TLS decryption and circuit demulti- sensitive code/data from other applications and privileged plexing, from adversaries, so that only the TLS-encrypted system software such as the operating system (OS), hyper- byte stream is exposed to them, unlike the original vanilla visor, and firmware. The memory content of the enclave Tor. We further argue that this has far-reaching implica- is stored inside a specialized memory region called En- tions on the trust model and operation of Tor: clave Page Cache (EPC). The EPC region of memory is • Trust model: Currently, Tor relays are semi-trusted. encrypted within the Memory Encryption Engine (MEE) While they are monitored and vetted during admission of the CPU and is hardware access controlled to prevent and operation, their behaviors are not fully verified. In snooping or tampering with the enclave page content. fact, many attacks are discovered and reported after Intel SGX instructions consist of privileged instruc- the fact [20, 43, 60, 68]. With SGX-Tor, behaviors are tions and user-level instructions. Privileged instructions verified through attestation, and private information is are used for loading application code, data, and stack into securely contained without being exposed to untrusted an enclave. When the enclave is loaded with appropriate parties. This simplifies the vetting and monitoring memory content, the processor generates the identity of process, allowing Tor to grow its capacity more eas- the enclave (i.e., SHA-256 digest of enclave pages) and ily. This will provide a stronger foundation for Tor’s verifies the integrity of the program by checking the iden- privacy (anonymity). tity that contained a signed certificate (EINIT token) of • Operation and deployment: SGX-Tor has signifi- the program. If the verification succeeds, the CPU enters cant implications in Tor operation. First, because we the enclave mode and the program within the enclave can both prevent and detect code modification and forg- starts to execute from a specified entry point. User-level ing false information, many attacks can be prevented. instructions are used after the program loads. Second, because SGX-Tor controls the information SGX also provides remote attestation and sealing func- exposed to the external world, it helps operational pri- tions. Remote attestation allows us to verify whether vacy. For example, we can ensure that the consensus the target program is executed inside an enclave without document, which lists Tor relays and their states [35], any modification on a remote SGX platform [24]. Fi- does not leave the secure container (i.e., enclave). This nally, sealing allows us to store enclave data securely effectively turn all relays into bridge relays, a set of re- in a non-volatile memory by encrypting the content us- lays that not publicly listed [18]. Finally, SGX-Tor can ing a SEAL KEY, provisioned by SGX CPU [24]. Unseal be easily deployed because it uses commodity CPUs restores the content back into the enclave. Intel white and can even be incrementally deployed. papers [39, 40, 53] describe the specifications in detail. In summary, we make the following contributions: Tor network: The Tor network is a low-latency 1. We analyze the assumptions and components used anonymity network based on onion routing [35]. Tor in existing attacks on Tor and discuss how the use of consists of three components: clients (Tor proxies), di- Intel SGX nullifies them to disable the attacks. rectory servers, and relays. Suppose that Alice uses Tor 2. We present the first design and implementation of proxy to communicate with Bob through the Tor network. Tor that run on real SGX hardware. By default, Alice’s proxy sets up 3-hop (entry, middle, exit) onion-encrypted circuit to ensure that any single Tor 3. We demonstrate that SGX-Tor limits the power of component cannot identify both Alice and Bob (e.g., entry Tor adversaries to that of a network-level adversary.