1. Seongmin Kim, Juhyeng Han, Jaehyeong Ha, Taesoo Kim *, Dongsu Han
Enhancing Security and Privacy of Tor’s Ecosystem by using Trusted Execution Environments
Seongmin Kim, Juhyeng Han, Jaehyeong Ha,
Taesoo Kim *, Dongsu Han
Good afternoon.
I’m Seongmin Kim from KAIST.
Today, I will present our work, “Enhancing Security and privacy of Tor’s ecosystem by using Trusted Execution environment”.
This is a joint work between Georgia tech and KAIST. *

2. The geographic location of Tor relays *
Tor anonymity network
Tor: the most popular anonymity network for Internet users
Helps users to defend against traffic analysis and keep user’s privacy
(e.g., what sites you visit, IP address) [from Tor project,
Freely available as an open source
1.8 million users on a daily basis
The geographic location of Tor relays *
Tor is the most popular anonymity network for Internet users.
It helps users to keep their private information such as what sites they visit and their IP addresses.
Since it is practical and freely available, it currently serves 1.8 million users on a daily basis.
(click)
Tor provides freedom of speech for activists and journalists from oppressive regimes and governments.
Therefore, protecting a privacy of Tor users is critical.
However, there have been many attempts to break the anonymity of users for a decade.
We see many examples of threats on Tor.
* from Onionview,

3. Tor network: Threat model
3-hop onion routing: a single Tor entity cannot know both client and server
Tor client
Entry
Middle
Exit
Destination
TLS channel
TLS channel
TLS channel
Plain-text
Processing Unit : Cell (512 Bytes)
Tor’s Threat model
Tor is a volunteer-based network: Tor relays are not trusted
Tor provides sender anonymity based on 3-hop onion routing.
When a client tries to connect a server using Tor network, it first chooses three Tor relays.
Then, it incrementally builds an encrypted circuit based on TLS communication.
Therefore, a single Tor entity cannot know both source and destination.
(Click)
Since Tor is a volunteer-based network, Tor relays are not trusted by design.
In the Tor’s threat model, it assumes an active attacker who can operate his own relays.
Also, he can compromise some fraction of relays.
Finally, Tor assumes an adversary who can observe some fraction of Tor traffic.
Can run a Tor relays of his own
Can compromise some fraction of Tor relays
Can observe some fraction of network traffic

4. Tor network: Threat model (Cont.)
Tor client
Destination
Anonymity
Broken!
Directory
authorities
Careful admission
Behavior monitoring
Tor tries to mitigate the threats in two ways under this assumption.
(click)
First, Tor has a centralized entity, called directory authority.
The directory authority exercises a careful admission of new relays through vetting process.
Also, it probes potential malicious relays and performs bandwidth scanning to detect malicious behaviors.
Fundamentally, an attacker can break the anonymity if all relays in a circuit are compromised.

5. Tor network: Threat model (Cont.)
Tor client
Destination
Directory
authorities
Anonymity
Broken! …
Careful admission
Behavior monitoring
Having a large number of relays
Out-of-scope: network-level adversary (controls a large fraction of network)
Currently runs ~10,000 relays
Large-scale traffic correlation is believed to be verify difficult in practice
In order to avoid such situation, Tor maintains a large number of relays.
It lowers the probability of choosing malicious relays by clients during the circuit establishment.
(click)
In contrast, Tor does not address a network-level adversary who controls a large fraction of network.
Currently, Tor runs more than 10000(ten thousand) relays.
Therefore, compromising a large fraction of relays is very hard.
Moreover, it is generally believed that large scale traffic analysis is non-trivial when the number of users and the Tor relays are large enough.

6. Tor network: Threat model (Cont.)
Tor client
Destination
Directory
authorities
Anonymity
Broken! …
Careful admission
behavior monitoring
Having a large number of relays
However, Tor is still vulnerable to many types of attacks under its traditional threat model
Out-of-scope : network-level adversary who can controls a large fraction of Tor network
Currently runs ~10000 relays
Large-scale traffic correlation are believed to be verify difficult in practice
However, Tor is still vulnerable to many types of attacks under its traditional threat model.
3.21

7. Modifying the behavior Accessing internal information
Limitations of Tor
Problem 1. Tor relays are semi-trusted
Authorities cannot fully verify the behaviors of them
Problem 2. Even attackers control a few Tor relays, they can
Access internal information (circuit identifier, cell header, …)
Modify the behavior of relays (DDoS, packet tampering, …)
<Low-resource attacks>
Malicious circuit creation
[Security09, CCS11]
Sniper attack [NDSS15]
Bad apple attack
[LEET11]
The first problem is the lack of a fundamental trust bootstrapping mechanism.
In the current model of Tor, Tor relays are semi-trusted in practice.
The directory authorities cannot fully verify the behaviors of Tor relays.
In fact, many attacks are discovered and reported after the fact.
Additionally, an attacker can gain advantage by simply running a Tor relay.
For example, he can get the sensitive information such as circuit identifier, and even he can modify the behavior of relays.
In other words, having a few relays is enough to break the anonymity of Tor in some cases.
We call attacks assuming such a condition as low-resource attacks.
By utilizing a combination of multiple factors, many previous studies show that the anonymity of users can be broken.
tagging attack [ICC08, TON12, CCS12, S&P13]
Bandwidth inflation [PETS07, S&P13]
Controlling HSDir [S&P13]
Harvesting hidden service descriptors [S&P13]
Circuit demultiplexing [S&P06]
Website fingerprinting [Security15]
Modifying the behavior
Both
Accessing internal information

8. Limitations of Tor (Cont.)
Tor clients
Entry
Middle
Exit
Destination
TLS channel
TLS channel
Cell
TLS channel
Cell
Plain-text
Processing Unit: Cell (512 Bytes)
Information visible to attackers
Cell:
header
Demultiplex and identify a circuit
Attackers can modify the behavior
Give false information to others
Modify or inject the cell
Bandwidth
20MB/s
150MB/s
Inflated!
(click)
Tor multiplexes multiple circuits in a single TLS connection and multiple TCP streams in a single circuit, to improve efficiency and anonymity.
However, once an attacker runs a Tor relay, the circuit-level information is visible to him.
Demultiplexing a circuit is trivial because an attacker can decrypt the TLS connection and can get the cell header.
The cell header includes a circuit identifier that specifies which circuit the cell refers to.
In fact, many attacks rely on being able to identify circuits.
Moreover, since attackers can modify the behavior of relays, they can modify or inject the cell.
It helps them to correlate the Tor traffic.
If an attacker modifies the relay to give false bandwidth information to other Tor components,
it makes a malicious relay to attract more clients.

9. Limitations of Tor (Cont.)
Tor client
Entry
Middle
Exit
Destination
TLS channel
TLS channel
TLS channel
Plain-text
To address the problems on Tor,
1) Fundamental trust bootstrapping mechanism
2) Advanced trust model to verify untrusted remote parties
are required
Therefore, a fundamental trust bootstrapping mechanism is required to address these problems.
Also, providing a method to verify untrusted remote parties will improve the trust model of Tor.
Then the question is, how can we achieve this?
5.44

10. Trend: Commoditization of TEE
Trusted Execution Environment (TEE): Hardware technology for trusted computing
Modified
Original
Secure container
Tor code
Integrity checking
 Prevents behavior
modification
edit
Cannot access data, flow control X
 Protects the secrecy of the program
Application (untrusted)
OS (untrusted)
In this work, we propose an approach that leverages commodity trusted execution environment on Tor.
Trusted execution environment, called TEE, provides a hardware-based mechanism for trusted computing.
(Click)
During the execution, the secure container protects the data and code of the program, even from the privilege software.
Also, it is possible to detect the modification on the program by checking the integrity.
Therefore, TEE can offer a fundamental low-level trust to protect the secrecy of Tor, while ensuring its integrity.
Among the commodity TEE technology, Intel SGX is the promising one.
It gives native performance to software running in the secure mode.
Currently, SGX functionality is available on several models of Intel Skylake and Kaby Lake CPU.
Intel SGX: a promising TEE technology for generic applications
Native performance in the secure mode
Available on Intel Skylake and Kaby lake CPU

11. SGX-Tor: Leveraging Intel SGX on Tor
Middle
Improved trust model
Operational privacy
Practicality
Intel SGX
Tor network
Improved trust model
Operational privacy
Practicality
Spells out what users trust in practice
Provides ultimate privacy
Protects sensitive data and Tor operations
Prevents modifications on Tor relays
The chance of having more hardware resources donated
Incrementally deployable
Compatibility
We develop SGX-Tor that applies SGX technology on Tor network.
We ask ourselves two fundamental questions,
First, what is the security implication of applying SGX on Tor?
Second, is the deployment possible to the current Tor network?
(click)
As an enhanced trust model, SGX-Tor explicitly spells out what users trust in practice instead of placing implicit trust on Tor relays, and provides ultimate privacy due to the mix-in model.
Also, it protects the sensitive information and denies the modifications on Tor relays.
SGX-Tor increases the chance of having more hardware resources donated, since it uses commodity TEE technology.
We make SGX-Tor compatible with a vanilla Tor and incrementally deployable.

12. SGX-Tor: Leveraging Intel SGX on Tor
Middle
Improved trust model
Operational privacy
Practicality
Intel SGX
Tor network
 Reduces the power of an attacker who currently gets the
sensitive information by running Tor relays
 Raises the bar for Tor adversary to a traditional network-
level adversary (only passively see the TLS bytestream)
Improved trust model
Operational privacy
Practicality
Explicitly spells out what users trust in practice
Provides ultimate privacy due to the mix-in model
Protects sensitive data and Tor operations
Denies modifications on Tor relays
Increasing the chance of having more hardware resources donated
Incrementally deployable
Compatibility
In this study, we show that SGX-Tor reduces the power of an attacker, who currently gets the sensitive information by running Tor relays.
In other words, SGX-Tor raises the bar for Tor adversary to a traditional network-level adversary, who cannot gain any information other than passively observing the TLS bytestream.
8:00

13. Intel SGX 101: Isolated Execution
Protects app’s secret from untrusted privilege software
Application keeps its data/code inside the “Enclave”
Trusted Computing Base (TCB) = Enclave + CPU package
Physical
Memory
Address
Space
CPU Package
Enclave
Processor Key
Encrypted
Memory
Encryption
Engine (MEE)
Cell
To understand how SGX-Tor works, let’s see more detail about the memory protection mechanism of SGX.
Using SGX, an application can keep its data and code inside the secure container called “enclave”.
An enclave is mapped to the encrypted memory region called Enclave Page Cache.
(Click)
The content is only decrypted by memory encryption engine inside the CPU package using processor specific keys.
Thus, even if a malicious adversary has full control over the hardware, it cannot access or modify the data.
Also, the enclave is protected from other software running in the host, including the OS and hypervisor.
This means that an attacker cannot get any Tor-specific data from the Tor program running inside the enclave.
Snooping
Access from
OS/VMM
EPC
(Enclave Page
Cache)

14. Intel SGX 101: Remote attestation
Attest an application on remote platform
Checks the integrity of enclave (hash of code/data pages)
Verifies whether enclave is running on real SGX CPU
Can establish a “secure channel” between enclaves
Application Enclave
Quoting Enclave
Remote platform
User platform
1. Request
Application
Challenger Enclave
Attestation
Verification
EPID key
Ephemeral
2. Create REPORT
3. Sign with EPID group key
(Create QUOTE)
4. Send
QUOTE
5. Verify
Another key functionality of SGX is remote attestation.
Using remote attestation, the host enclave can check the integrity of the enclave running in the remote platform.
Additionally, it verifies whether the target enclave is actually running on the real SGX CPU. 14

15. SGX-Tor: Threat Model <SGX Threat model>
Enclave
CPU
Application (untrusted)
OS (untrusted)
TCB : Enclave + CPU package
A powerful network-level adversary : out-of-scope
Only trusts the underlying SGX hardware & Tor code itself
Do not address network-level adversaries : who can perform large-scale traffic analysis
Out of scope :Vulnerabilities in Tor codes, SGX side channel attacks
 Mitigated by recent SGX research: Moat [CCS16], SGX-Shield [NDSS17], T-SGX [NDSS17]
Before explaining our approach and SGX-Tor design, let's take a look at the threat model of SGX-Tor.
(Click)
Instead of trusting the application and the system software that hosts Tor relays,
SGX-Tor users only trust the underlying SGX hardware and Tor code itself.
Following the attack model of Tor, we do not consider attacks assuming a network-level adversary
who can perform large scale traffic analysis.
Note that attacks assuming vulnerabilities in Tor codes or SGX side channel attacks can be mitigated by recent studies.
9:50

16. SGX-Tor: Design and Implementation
User process (Tor application)
Enclave memory
Tor code/data (Core)
- Circuit Establishment Hidden service Voting
- Encryption/Decryption - Cell/Consensus creation
Crypto/TLS operations
Securely obtains the entropy and time value
SSL Library
Integrity check with remote host
Validates the enclave hash of the Tor program
Attestation Module
Here is the design and implementation of SGX-Tor.
In the figure, the blue-colored box means the modified components from existing Tor and the gray-colored box means the newly added components.
We build a careful design to address several issues raised by leveraging SGX on Tor.
The enclave memory of SGX-Tor consists of Tor core operations, and SSL library for crypto and TLS communication.
(click)
We modified SSL library to securely obtain the entropy within the enclave, and the time value from the platform service enclave, which is a trustworthy source provided by SGX.
It also contains the attestation module to verify the integrity of Tor program,
and sealing module for temporarily storing the sensitive data outside the enclave.
Seals/unseals private data
Encrypts and stores the sensitive data outside the enclave
Sealing Module

17. SGX-Tor: Design and Implementation
User process (Tor application)
Trusted
Untrusted
Application memory
Enclave memory
SSL Library
Attestation Module
Sealing Module
Seals/unseals private data
Integrity check with remote host
Tor code/data (Core)
- Circuit Establishment Hidden service Voting
- Encryption/Decryption - Cell/Consensus creation
Crypto/TLS operations
SGX Runtime Library
Enclave
Creation
Enclave initialization
ECALL
OCALL/ECALL
Wrapper
OCALL
Request system services
Tor code/data
(Untrusted)
In the untrusted region, SGX-Tor has an SGX runtime library and the rest of Tor operations, which are not sensitive to Tor’s security and privacy.
As we mentioned in our threat model, SGX-Tor does not trust the operating system.
However, Tor must rely on system software to handle operations that require system calls.
Therefore, a trustworthy interface between the enclave and OS is required.
(click)
For this, we leverage ECALL and OCALL interface, which are provided by Intel SGX SDK.
Here, a function that enters the enclave is called an ECALL and a function that leaves the enclave is called an OCALL, respectively.
We use ECALLs to bootstrap Tor-enclave, while OCALLs are used to request services to system software.
System
Call
Standard Library
(glibc)

18. SGX-Tor: Design and Implementation
User process (Tor application)
Trusted
Untrusted
Application memory
Enclave memory
SSL Library
Attestation Module
Sealing Module
Seals/unseals private data
Integrity check with remote host
Tor code/data (Core)
- Circuit Establishment Hidden service Voting
- Encryption/Decryption - Cell/Consensus creation
Crypto/TLS operations
SGX Runtime Library
Enclave
Creation
Enclave initialization
ECALL
OCALL/ECALL
Wrapper
Narrow interface
OCALL
Request system services
Tor code/data
(Untrusted)
Sanity checking
Argument length
Address range
For each OCALL, SGX-Tor performs sanity checking to validate the length of pointer variables and their address range.
It prevents potential threats by malicious Operating System such as providing bad return values in system calls.
In addition to providing the narrow interface, we harden the interface.
SGX-Tor relies on minimal system support for networking, threading, and memory allocation.
We implement 57 OCALLs to handle system calls such as send, beginthread, and select.
The detailed types of OCALL that we implemented are listed in our paper.
12:30
System
Call
Standard Library
(glibc)

19. Attacks defeated by using SGX-Tor
Tor client
Entry
Middle
Exit
Destination
TLS channel
TLS channel
TLS channel
Plain-text
1. Tagging attack
Replay
Cell counting
2. Bandwidth inflation
Directory
authorities
Malicious relay
(modified Tor)
1. BW scanning
2. Detect
scanning
3. Report fake BW
4. Create
consensus
document
Advertised BW
Inflated!
Let me show how SGX-Tor defeats low-resource attacks with examples.
A tagging attack is a type of traffic confirmation by changing the behavior of the one end, for it to be recognized by the other.
For example, an attacker can detect a distinct pattern by duplicating existing cells, or counting how many cells are sent over the network at a time.
This is used to effectively de-anonymize communication between two parties.
(click)
Another example is a bandwidth inflation attack, which is used to increase the success ratio of low-resource attacks.
When a malicious relay falsely reports its bandwidth to the directory authority, the authority advertises inflated bandwidth information to Tor clients.

20. Attacks defeated by using SGX-Tor
Tor client
Entry
Middle
Exit
Destination
TLS channel
TLS channel
TLS channel
Plain-text
1. Tagging attack
Attract more clients!
Replay
Cell counting
2. Bandwidth inflation
Directory
authorities
Malicious relay
(modified Tor)
1. BW scanning
2. Detect
scanning
3. Report fake BW
4. Create
consensus
document
Advertised BW
Inflated!
Since the relay selection algorithm of Tor depends on the bandwidth status of Tor relays, a malicious relay would attract more clients during the circuit establishment.

21. Attacks defeated by using SGX-Tor (Cont.)
Tor client
Entry
Middle
Exit
Destination
TLS channel
TLS channel
TLS channel
Enclave
Circuit establishment
Cell creation
Encryption/Decryption
Onion/SSL key creation
Plain-text
access
Circuit identifier
Cell header
Private keys
modify the code
To modify/inject cells
To inflate bandwidth
Attackers cannot
Cell
Circuit descriptor
Private keys
However, such attacks are defeated by SGX-Tor, since they cannot access the internal data such as circuit identifier and cells.
If an attacker modifies the code to inject cells or inflate the bandwidth, it fails to pass remote attestation.
(click)
In the paper, we have more details on how SGX-Tor mitigates many low resource attacks.
좀 쉬었다가 넘어가기
Attacks defeated/mitigated by SGX-Tor
Circuit demultiplexing [S&P06]
Bandwidth inflation [PETS07, S&P13]
Harvesting/Controlling HSDir [S&P13]
Tagging attack [ICC08, TON12, CCS12, S&P13] …

22. New functionality: Automatic admission
Integrity verification of relays (Directory authority  Onion Router)
Automatically admits “unmodified” and “SGX-enabled” relays
Improved trust model: current implicit trust model turns into the explicit trust model
Tor relays
Consensus
document
Admit
(match success)
Nickname: OR1
Expected hash
Enclave
Attestation fail
(not SGX-enabled)
name: OR1
BW: 20MB/s
fingerprint: ….
Nickname: OR2
Enclave
SGX-Tor also offers a new functionality that helps Tor community to manage relays more efficient.
(click)
When a new Tor relay requests an admission to the directory authority, it first performs remote attestation to check the integrity.
Note that Tor uses the same binary for directory authorities, Tor relays, and client proxies.
If the target relay is not SGX-enabled or fails to pass the attestation procedure, it is rejected.
Therefore, the consensus document only contains the list of trusted relays that run SGX-Tor.
This feature improves the trust model of Tor, since it explicitly spells out what users trust in practice.
Here, the entire process is an one-time cost, so directory authorities can save the computational power to monitor the behavior of relays and can maintain more relays.
Therefore, it improves the scalability of Tor network.
Directory
authority
Remote
Attestation
Attestation fail
(bad hash)
Nickname: OR3
Enclave
(modified)
NOTE: Tor uses the same binary for directory authorities, Tor relays, and client proxies

23. Incremental deployability
SGX-Tor’s basic assumption: “All relays and authorities are SGX-enabled”
SGX-Tor supports interoperability
Allows admission of non-SGX relays without remote attestation
SGX-enabled clients can get the list of SGX-Tor relays from SGX-enabled authorities
Entry
Middle
Exit
Tor client
Destination
Enclave
Enclave
Enclave
Enclave
To make SGX-Tor practical, we also address the incremental deployability.
So far, we primarily consider the network that every Tor components are SGX-enabled.
This means that users cannot fully utilize every functionality provided by SGX-Tor, in the presence of partial deployment.
(click)
However, SGX-Tor supports interoperability.
For example, it is possible to establish a circuit with an entry-guard that runs SGX-Tor, while the middle and exit relays run the original Tor.
We add configuration options to enable or disable remote attestation.
Also, for the SGX-Tor client proxy, we add an option to get the list of validated relays from the SGX-enabled directory authority.
Without these options, SGX-Tor behaves like an ordinary Tor without attestation.
In other words, we provide an incremental deployment of SGX-Tor to Tor’s ecosystem.
Enclave …
Directory
authorities
Enclave
Remote
Attestation
Enclave
Enclave

24. Implementation detail
Engineering efforts
Support for Windows/Linux (based on Intel SGX SDK)
SGX-ported libraries: OpenSSL, libevent, zlibc
SGX-Tor is an open source: Available at
Trusted Computing Base (TCB) size
TCB size of Haven: More than 200MB (maximum enclave size : 128MB in Windows)
3.8x smaller (320K LoC vs 1,228K LoC) than Graphene (open source library OS for SGX)
We implement SGX-Tor for both Windows and Linux environment and make it publicly available at github.
Additionally, we port several libraries that are required by Tor, such as OpenSSL and libevent.
(Click)
We also compare the trusted computing base size of SGX-Tor with previous SGX studies that port operating system functionality.
Since SGX-Tor does not contain the whole library OS, it has 3.8 times smaller TCB size compared to recent work.

25. Evaluation
1) What kind of sensitive data of Tor is protected by SGX-Tor?
2) What is the performance overhead of running SGX-Tor?
3) How compatible and incrementally deployable is SGX-Tor with the
current Tor network?
Environmental setup
SGX CPUs: Intel Core i (3.4GHz) and Intel Xeon CPU E (3.5GHz)
Configuration: 128MB Enclave Page Cache (EPC)
Running Tor in Windows, Firefox as a Tor browser (in the client proxy)
Establish a private Tor network using chutney
We evaluate SGX-Tor by answering three questions.
First, we show what kind of data is protected by SGX-Tor.
Second, we show the performance overhead of using SGX-Tor.
Finally, we check whether SGX-Tor is compatible with a vanilla Tor and incrementally deployable.
17:10

26. What is protected by SGX-Tor?
Current Tor
Network-level
adversary
SGX-Tor
TCP/IP header
Visible
TLS-encrypted bytestream
Cell
Not visible
Circuit ID
Voting result
Consensus document
Hidden service descriptor
List of relays
Private keys
The table shows the data structures that are visible to current Tor, network-level adversary, and SGX-Tor.
For the case of the current Tor, sensitive data structures such as circuit identifier and the consensus document are visible to an attacker.
(Click)
In contrast, SGX-Tor protects every sensitive data structure.
An attacker only see the TCP/IP header and TLS-encrypted bytestream, by observing the Tor traffic.
In summary, SGX-Tor raises the bar for Tor adversaries to that of traditional network-level adversaries.

27. Performance evaluation
client
server
Entry
(KAIST)
Middle (Cloud)
1. EU 2.U.S. West
3. U.S. East
Exit (Gatech)
<Evaluation environment>
SGX-Tor performance : WAN setting
Establish a private Tor network
For the realistic scenario, we consider
the “locality of relays” (Asia, EU, U.S. West, U.S. East)
Enclave
Enclave
: SGX-Tor
: Original Tor
100MB
To evaluate the performance of SGX-Tor, we construct a private Tor network in WAN setting.
For the realistic scenario, we vary the location of Tor relays.
(Click)
As the figure shows, we run an entry guard in KAIST and an exit relay in Geogia tech.
For middle relays, we use Amazon EC2 cloud, which are physically located in Europe, U.S. West, and U.S. East.
We measure the file transmission throughput and time-to-first-byte of SGX-Tor and the original Tor.
The result shows that SGX-Tor has 11.9% performance degradation
and 3.9% additional latency compared to original Tor,
which is moderate overhead.
11.9% degradation (on average)
3.9% additional
latency
10MB

28. Performance evaluation (Cont.)
End-to-end client performance of SGX-Tor (using Tor browser)
Web latency: Visiting Alexa Top 50 websites
Hidden service: HTTP file server (downloading 10MB)
: SGX-Tor
: Original Tor
SGX-Tor : 13.2s
Original : 12.2s
SGX-Tor : 1.30Mbps
Original : 1.35Mbps
We also evaluate the end-to-end client performance of SGX-Tor.
For this, we measure the webpage loading time while visiting Alexa Top 50 websites in the same evaluation environment.
Also, we launch a hidden service, which is a simple HTTP file server, and measure the throughput.
Here, the client proxy is also SGX-enabled.
As the figure shows, SGX-Tor has an acceptable performance overhead, for both webpage loading time and the hidden service performance.
7.4% additional latency
3.3% degradation

29. Compatibility with vanilla Tor
Long-running: Admit SGX-Tor relays in the vanilla Tor
Collected results for two weeks
: SGX-Tor
: Original Tor
Fast
Stable
Finally, we verify whether SGX-Tor works correctly and is compatible with a vanilla Tor.
We admit SGX-Tor relays in the existing Tor network and collect the results for two weeks.
(click)
As the left-most figure shows, the SGX-Tor relay serves Tor traffic well.
Also, it is selected as a middle relay by multiple Tor users.
Finally, the SGX-Tor relay is listed in the published consensus document.
It also acquires fast and stable flags, similar to original Tor relays.
Therefore ,the result highlights the fact that we provide an incremental deployment of SGX-Tor.
Network I/O bandwidth per second
Middle selection Probability
Advertised bandwidth *
Serves Tor traffic well
Actually selected by multiple Tor users
Listed in the consensus document
* From

30. Conclusion
We design and implement SGX-Tor by leveraging commodity TEE and demonstrate its viability
Gives moderate performance overhead
Shows its compatibility and possibility of incremental deployment
SGX-Tor enhances the security and privacy of Tor by
Defending against existing attacks on Tor
Bringing changes to the trust model of Tor
Providing new properties : automatic admission
Available at github! (
To summarize, we design and implement SGX-Tor by leveraging commodity TEE, and demonstrate its viability.
Using SGX-Tor, it is possible to establish an advanced trust model and protects the privacy of Tor users.
As we provided SGX-Tor as an open-source, we believe SGX-Tor has great potential for communities to spark new research on Tor.
Thank you for listening and I’m glad to take questions.
20:20

31. OpenSGX is an open source project, and it is publicly available through github.
We modified nineteenth thousands lines of code and release OpenSGX at May, 2015.
We continuously manage and update the source code to improve it.

32. How can we trust Intel? Implicit trust turns into explicit trust
We already use x86 instruction set architecture
This means that we implicitly trust Intel
Our approach can be adopted to other TEE
Even our implementation relies on Intel SGX, design of SGX-Tor is not Intel-specific
As TEE technology has been developed, we can leverage other TEE technology on Tor

33. Intel remote attestation procedure*
Intel requires that the independent software vendor (ISV) obtain a signed certificate from a recognized certificate authority and be issued a service provider ID (SPID)
After the certificate is registered with Intel, the ISV will receive an containing its SPID
The server communicates with the Intel Attestation Service (IAS) server to perform the actual enclave verification
Possible to manage a version of enclave
OpenSGX is an open source project, and it is publicly available through github.
We modified nineteenth thousands lines of code and release OpenSGX at May, 2015.
We continuously manage and update the source code to improve it.
* From

34. Discussion Limitations of SGX-Tor Incremental deployability
Sybil attacks and attacks assuming network-level adversaries are still effective
Security tradeoff in the presence of partial deployment
Incremental deployability
Possible option : using cloud platform
Tor already provides default VM images to run bridge relays on Amazon EC2 cloud
Although SGX-Tor can mitigate many attacks against Tor components,
Attacks assuming network-level adversaries and Sybil attacks are still effective.
Also, there might be a security tradeoff in the presence of partial deployment of SGX-Tor.
As a future work, we will quantify the security tradeoffs and ways to mitigate attacks in such a condition.
The incremental deployability of SGX-Tor is an important issue in terms of practicality.
The simplest way to deploy SGX-Tor in the current Tor network is using cloud platform.
Tor already provides default VM images to run bridge relays on Amazon EC2 cloud.
Similarly, we can admit SGX-Tor relays by running virtual machines that support the SGX functionality.

35. Discussion Limitations of SGX-Tor Incremental deployability Good news!
Sybil attacks and attacks assuming network-level adversaries are still effective
Security tradeoff in the presence of partial deployment
Incremental deployability A
Good news! Google & Amazon supports VM with Skylake CPU
SGX virtualization support!
Good news!
1) Google & Amazon supports VM equipped with Skylake CPU
2) A recent patch provides support for SGX virtualization *
It is a promising option since google and Amazon supports VM equipped with Intel Skylake CPU.
Additionally, a recent patch on Intel SGX SDK provides support for virtualizaion. *

36. Attestation performance overhead
Introduce latency between authorities and relays to mimic that of the real network (measure the round-trip time of 9 directories and reflect the value)
The average attestation latency: 3.71 s
One time cost during the bootstrapping
Since the client bootstrapping time takes 22.9s on average on a broadband link to download
a list of relays, it is relatively short
OpenSGX is an open source project, and it is publicly available through github.
We modified nineteenth thousands lines of code and release OpenSGX at May, 2015.
We continuously manage and update the source code to improve it.

37. Overhead of TLS communication
OpenSGX is an open source project, and it is publicly available through github.
We modified nineteenth thousands lines of code and release OpenSGX at May, 2015.
We continuously manage and update the source code to improve it.
1Gbps through a single switch (in more CPU bound setting)
As hop is increased, SGX-Tor has 17.7%, 18.3%, 18.4% additional latency
Performance is degraded by 25.6%, 21.1%, 22.7%, respectively

38. Related work
Originally, SGX technology is motivated by cloud computing
To protect user data from the untrusted cloud
Pioneering research: Haven [OSDI14], VC3 [S&P15]
Previous effort : Adopting SGX on networking
Kim et. al [HotNets15] : Inter-domain routing, Tor network and middlebox
OpenSGX [NDSS16] : Showcasing Tor network as an application
S-NFV [SDN-NFV Security 16] : Securing NFV states using SGX
Town Crier [CCS16] : Smart contact
AirBox [SEC16] : Edge computing
Also, SGX provides remote attestation functionality.
Using remote attestation, the host enclave can check the integrity of the enclave running in the remote platform.
Additionally, it verifies whether the target enclave is actually running on the real SGX CPU.
Here, it is possible to establish a secure channel between enclaves by extending Diffie-Hellman key change.
Provide a proof-of-concept only
Use OpenSGX [NDSS16], an SGX emulator

39. SGX-Tor operation: Summary
: Remote attestation (For integrity verification)
: Circuit
Directory Authorities
2) Voting & Consensus creation
3) Get consensus document
1) Collect BW of ORs
Alice
(Client Proxy)
Bob
(Destination)
Middle
4) Key negotiation
& Circuit creation
6) Receive packets
Entry
Let me summarize the operation of SGX-Tor.
Exit
5) Relay packets (through the circuit)

40. SGX-Tor operation: Summary
: Remote attestation (For integrity verification)
: Circuit
Directory Authorities
2) Voting & Consensus creation
0) Perform remote attestation (Automatic admission)
3) Get consensus document
(SGX-enabled relay list)
Enclave
1) Collect BW of ORs
Alice
(Client Proxy)
Bob
(Destination)
Enclave
Allow trustworthy clients only
Enclave
Middle
Enclave
4) Key negotiation
& Circuit creation
6) Receive packets
Entry
Compared to original Tor, SGX-enabled directory authorities perform
remote attestation for admitting benign SGX-Tor relays.
Then, only a trustworthy clients can get the list of reliable SGX-Tor relays.
Here, internal data structures of SGX-Tor relays cannot be leaked or manipulated by an attacker.
Exit
Enclave
5) Relay packets (through the circuit)
Enclave
SGX-Tor Relays: Internal data structure cannot be leaked or manipulated

41. SGX-Tor: Trustworthy client
Integrity verification of clients (Directory authority  Client proxy)
Attacks that uses malicious client proxy : malicious circuit creation, Sniper attack
A trustworthy client can get a “list of SGX-Tore relays” only
Client proxies
Success
(trustworthy)
name: OR1
BW: 20MB/s
fingerprint: ….
Consensus
document
Expected hash
Enclave
List of SGX-Tor relays
(Trusted)
Also, SGX-Tor offers a new functionality that classifies the trustworthy client through remote attestation.
There are several attacks that assumes malicious client proxy.
For example, attacker that runs malicious Tor client can create a malicious circuit,
which contains malicious relays of his own.
(Click)
To defend against such attacks, directory authorities of SGX-Tor verify the integrity of the client proxy
to figure out whether it is potentially malicious.
Only a trustworthy client can get the list of reliable Tor relays from the directory authorities.
Therefore, SGX-Tor provides the chain of trust ~~
Enclave
Directory
authority
Remote
Attestation
Attestation fail
(bad hash)
Enclave
(modified)