Hi everyone,
we are a team of 4 PHD students in the field of IT security, working at the Ruhr-University Bochum at the chair for systems security and the information security group.
Currently we work on a research project with the goal to leverage the security of Tor against timing attacks by integrating mixes in Tor nodes. The general idea is to differentiate high-latency and low-latency traffic among the network for applying additional delays to the former type of packets. Based on this the success of traffic analysis attacks should be decreased without restricting the low latency assurance of Tor.
We plan to integrate the mix into Tor version 0.2.5.10 and analyze its performance along with the Shadow simulator.
As there are a lot of details to consider, both regarding the technical aspects of the integration as well as practical assumptions, e.g., "how do we get DiffServ-like nodes?", we would be pleased to receive some feedback on the idea and support for the implementation of the mix. Further details on the mix and stuff will sure be provided if needed!
Cheers, Katharina
On 23 Feb 2016, at 01:11, Katharina Kohls katharina.kohls@rub.de wrote:
Hi everyone,
we are a team of 4 PHD students in the field of IT security, working at the Ruhr-University Bochum at the chair for systems security and the information security group.
Currently we work on a research project with the goal to leverage the security of Tor against timing attacks by integrating mixes in Tor nodes. The general idea is to differentiate high-latency and low-latency traffic among the network for applying additional delays to the former type of packets. Based on this the success of traffic analysis attacks should be decreased without restricting the low latency assurance of Tor.
Does differentiating traffic into multiple timing classes make traffic timing analysis easier? (For example, while high-latency traffic is better protected from fingerprinting, low-latency traffic is easier to identify and fingerprint.)
We plan to integrate the mix into Tor version 0.2.5.10 and analyze its performance along with the Shadow simulator.
The latest stable release is Tor 0.2.7.6.
As there are a lot of details to consider, both regarding the technical aspects of the integration as well as practical assumptions, e.g., "how do we get DiffServ-like nodes?", we would be pleased to receive some feedback on the idea and support for the implementation of the mix. Further details on the mix and stuff will sure be provided if needed!
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Does differentiating traffic into multiple timing classes make traffic timing analysis easier? (For example, while high-latency traffic is better protected from fingerprinting, low-latency traffic is easier to identify and fingerprint.)
The opposite should be the case, as the delaying of HL traffic should slightly obfuscate the traffic patterns of LL packets. The idea is to send everything through the mix but only delay what doesn't require performance with low latencies.
Nevertheless, we are not sure if it's more secure to let the user decide delays for packets (like in the alpha-mixing approach) to get a greater fraction of the overall traffic delayed or to assign random delays within the relay, based on a classification of the packets.
The latest stable release is Tor 0.2.7.6.
... and as there is also the new scheduler included we will continue our work with the latest version :)
Hello Katharina,
Sounds like a great project. I have a couple of suggestions: 1. Consider how to use mixing to anonymize Tor’s name resolution system. Currently, clients connect to onion service by first resolving the onion address (e.g. xyzblah.onion) to a descriptor using a distributed hash table. That hash table can easily be infiltrated by an adversary running relays, and if the adversary also controls a client’s guard they can deanonymize the client during the lookup. This is the attack that the CMU/CERT researchers performed [0] as well as Biryukov et al. [1]. Onion-service descriptors are very small, and so it seems to me that mixing could be applied here to defeat deanonymization. 2. Read the alpha-mixing paper [2], which first described how high-latency and low-latency traffic might be mixed together.
Good luck!
Aaron
[0] <https://freedom-to-tinker.com/blog/felten/why-were-cert-researchers-attackin... https://freedom-to-tinker.com/blog/felten/why-were-cert-researchers-attacking-tor/> [1] Alex Biryukov, Ivan Pustogarov, Fabrice Thill, Ralf-Philipp Weinmann; "Content and popularity analysis of Tor hidden services”; IEEE 34th International Conference on Distributed Computing Systems Workshops; 2014; <http://arxiv.org/abs/1308.6768 http://arxiv.org/abs/1308.6768>. [2] Roger Dingledine, Andrei Serjantov, and Paul Syverson; "Blending Different Latency Traffic with Alpha-Mixing”; In the Proceedings of the Sixth Workshop on Privacy Enhancing Technologies (PET 2006); 2006; <http://freehaven.net/doc/alpha-mixing/alpha-mixing.pdf http://freehaven.net/doc/alpha-mixing/alpha-mixing.pdf>.
On Feb 22, 2016, at 9:11 AM, Katharina Kohls katharina.kohls@rub.de wrote:
Hi everyone,
we are a team of 4 PHD students in the field of IT security, working at the Ruhr-University Bochum at the chair for systems security and the information security group.
Currently we work on a research project with the goal to leverage the security of Tor against timing attacks by integrating mixes in Tor nodes. The general idea is to differentiate high-latency and low-latency traffic among the network for applying additional delays to the former type of packets. Based on this the success of traffic analysis attacks should be decreased without restricting the low latency assurance of Tor.
We plan to integrate the mix into Tor version 0.2.5.10 and analyze its performance along with the Shadow simulator.
As there are a lot of details to consider, both regarding the technical aspects of the integration as well as practical assumptions, e.g., "how do we get DiffServ-like nodes?", we would be pleased to receive some feedback on the idea and support for the implementation of the mix. Further details on the mix and stuff will sure be provided if needed!
Cheers, Katharina -- M.Sc. Katharina Kohls
Ruhr-University Bochum Research Group Information Security Universitätsstrasse 150 ID 2/123 44780 Bochum / Germany
Phone: +49 234 / 32 - 26991 Web: www.infsec.rub.de _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Katharina Kohls katharina.kohls@rub.de writes:
Hi everyone,
we are a team of 4 PHD students in the field of IT security, working at the Ruhr-University Bochum at the chair for systems security and the information security group.
Currently we work on a research project with the goal to leverage the security of Tor against timing attacks by integrating mixes in Tor nodes. The general idea is to differentiate high-latency and low-latency traffic among the network for applying additional delays to the former type of packets. Based on this the success of traffic analysis attacks should be decreased without restricting the low latency assurance of Tor.
We plan to integrate the mix into Tor version 0.2.5.10 and analyze its performance along with the Shadow simulator.
As there are a lot of details to consider, both regarding the technical aspects of the integration as well as practical assumptions, e.g., "how do we get DiffServ-like nodes?", we would be pleased to receive some feedback on the idea and support for the implementation of the mix. Further details on the mix and stuff will sure be provided if needed!
Hello there,
I'm also very interested in this latency-mixing research problem! We are currently trying to address these timing attacks by adding padding to our links. However, defending against these attacks with padding is not easy, and it also puts additional load to the network.
FWIW, there has been some previous work on this topic but nothing that can be used currently in a practical setting. For example, see the paper named "Blending different latency traffic with alpha-mixing" if you haven't already. The biggest challenge with that paper is switching the message-based approach to be stream-based (like Tor is).
Other potential papers are "Stop-and-Go-MIX" by Kesdogan et al. and "Garbled Routing (GR): A generic framework towards unification of anonymous communication systems" by Madani et al. But I haven't looked into them at all...
Here are some basic system-agnostic questions about the project:
a) What are the benefits from mixing low-latency Tor traffic with high-latency traffic? Is it to leverage the already existing network so that we don't need to bootstrap a second trusted anonymizing network?
On this note, do we actually get any additional security properties from mixing low-latency traffic with high-latency traffic? That is, does the low-latency traffic provide cover for the high-latency traffic? What about the opposite?
And for what kind of adversaries do these security properties apply? Will this actually confuse adversaries who run Tor relays themselves? What about network adversaries that monitor the network of Tor relays?
b) Does this increase the hard disk or memory requirement of people running Tor relays? That is in high-latency mode, will Tor relays need to store client's traffic for longer? How does that impact the memory and hard disk requirement of people running Tor relays?
c) Does this impact the legal liability of people running Tor relays?
Looking forward to learn more information about your project :)
Cheers!
-
Aaron Johnson -
George Kadianakis -
Katharina Kohls -
teor