[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-dev] Proposal 246: Defending Against Guard Discovery Attacks using Vanguards



Hello,

I'm attaching a proposal draft that should help us defend against
guard discovery attacks.

There are a few pieces left unfinished (see the XXXs) but I decided to
release early and release often for the sake of moving forward with
this. I consider this issue very important and any feedback is greatly
appreciated.

Thanks!


----

Filename: 246-hs-guard-discovery.txt
Title: Defending Against Guard Discovery Attacks using Vanguards
Author: George Kadianakis
Created: 2015-07-10
Status: Draft


0. Motivation

  A guard discovery attack allow attackers to determine the guard
  node of a Tor client. The hidden service rendezvous protocol
  provides an attack vector for a guard discovery attack since anyone
  can force an HS to construct a 3-hop circuit to a relay (#9001).

  Following the guard discovery attack with a compromise or coercion
  of the guard node can lead to the deanonymization of a hidden
  service.

1. Overview

  This document tries to make the above guard discovery + coersion
  attack harder to launch. It introduces an optional configuration
  option which makes the hidden service also pin the second and third
  hops of its circuits for a longer duration.

  With this new path selection, we force the adversary to perform a
  Sybil attack and two coercion attacks before succeeding.  This is
  an improvement over the current state where the Sybil attack is
  trivial to pull off, and only a single coercion attack is required.

  With this new path selection, an attacker is forced to do a
  coercion attack before learning the guard node of a hidden
  service. This increases the uncertainty of the attacker, since he
  will need to perform a coercion attack before he learns the
  identity of the guard node and whether he can compromise
  it. Coercion attacks are costly and potentially detectable, so an
  attacker will have to think twice before beginning a chain of
  coercion attacks that he might not be able to complete.

1.1. Visuals

  Here is how a hidden service rendezvous circuit currently looks like:

	                 -> middle_1 -> middle_A
		             -> middle_2 -> middle_B
	                 -> middle_3 -> middle_C
	                 -> middle_4 -> middle_D
	   HS -> guard   -> middle_5 -> middle_E -> Rendezvous Point
	                 -> middle_6 -> middle_F
	                 -> middle_7 -> middle_G
	                 -> middle_8 -> middle_H
                     ->   ...    ->  ...
                     -> middle_n -> middle_n

  this proposal pins the two middles nodes to a much more restricted
  set, as follows:

                                  -> guard_3_A
                                  -> guard_3_B
       HS -> guard_1 -> guard_2_A -> guard_3_C -> Rendezvous Point
                     -> guard_2_B -> guard_3_D
                                  -> guard_3_E
                                  -> guard_3_F

2. Design

  This feature requires the HiddenServiceGuardDiscovery torrc option
  to be enabled.

  When a hidden service picks its guard nodes, it also picks two
  additional sets of guard nodes `second_guard_set` and
  `third_guard_set` of size NUM_SECOND_GUARDS and NUM_THIRD_GUARDS
  respectively.

  When a hidden service needs to establish a circuit to an HSDir,
  introduction point or a rendezvous point, it uses nodes from
  `second_guard_set` as the second hop of the circuit and nodes from
  `third_guard_set` as third hops of the circuit.

  A hidden service rotates 'second_guard_set' every
  SECOND_GUARD_ROTATION hours, and 'third_guard_set' every
  THIRD_GUARD_ROTATION hours.

  These extra guard nodes should be picked with the same path
  selection procedure that is used for regular guard nodes. Care
  should be taken such that guard sets do not share any common
  relays. XXX or simply that they are not used in the same circuit?

  XXX maybe pick the second and third layer guards from the set of
      middle nodes but also enforce some kind of uptime requirement?
      that should greatly help our load balancing.

  XXX maybe we should also introduce consensus flags for the extra
      guard layers? Vanguard?

  XXX how should proposal 241 ("Resisting guard-turnover attacks") be
      applied here?

2.1. Security parameters

  We set NUM_SECOND_GUARDS to 2 nodes and NUM_THIRD_GUARDS to 6 nodes.
  We set SECOND_GUARD_ROTATION to 2 weeks and THIRD_GUARD_ROTATION to 1 day.

  See the discussion section for more analysis on these constants.

3. Discussion

3.1 How were these security parameters chosen?

  Consider an adversary with the following powers:

     - Can launch a Sybil guard discovery attack against any node of a
       rendezvous circuit. The slower the rotation period of the node,
       the longer the attack takes.

     - Can compromise any node on the network. We assume that the
       adversary cannot compromise too many nodes, otherwise Tor's
       security would be breached anyhow.

  We now calculate the time it takes for the adversary to launch a
  Sybil attack with 50% success assuming 5% network control. This
  depends solely on how frequently the hidden service rotates that node:

       +-------------------+-------------------------------+------------------------+----------------------------+
       |  Rotation period  | Sybil attack with 50% success | Sybil attack (2 guards)|  Sybil attack (6 guards)   |
       +-------------------+-------------------------------+------------------------+----------------------------+
       |      1 hour       |        14 hours               |      7 hours           |       2.5 hours            |
       |      1 day        |        14 days                |      7 days            |       2.5 days             |
       |      1 week       |        3.5 months             |      6 weeks           |       2.5 weeks            |
       |      2 weeks      |        7 months               |      3.5 months        |       5 weeks              |
       |      1 month      |        1 year and 2 months    |      6 months          |       2.5 months           |
       |      3 months     |        3.5 years              |      1.7 years         |       6 months             |
       +-------------------+-------------------------------+------------------------+----------------------------+
                                    Required time for Sybil attack by a 5% adversary

  Our security parameters were selected so that the first two layers
  of guards should be hard to attack using a Sybil guard discovery
  attack and hence require a coercion attack. On the other hand, the
  outmost layer of guards should rotate fast enough to _require_ a
  Sybil attack.

  XXX does this security model even make sense? what about a network
      adversary, or an adversary that can launch congestion attacks
      etc.????

3.2. Distinguishing new HS circuits from normal HS circuits

  By pinning the middle nodes of rendezvous circuits, we make it
  easier for all hops of the circuit to detect that they are part of a
  special hidden service circuit.
  XXX hm how does the outermost guard knows?

  Compare this to the current Tor network, where only the guard and
  the third hop of the HS circuit can trivially distinguish whether
  it's part of an HS circuit.

3.3. Circuit nodes can now be linked to specific hidden services

  With this proposal the hops of hidden service circuits will be
  static, and hence an adversrary will be able to map them to specific
  hidden services. For example, a middle node that sees two hidden
  service circuits with the same guard node in different times, can
  assume with non-negligible probability that both circuits correspond
  to the same hidden service.

  That said, this is also partially the case for the current Tor
  network, where the middle node can associate a guard with a specific
  hidden service.

3.4 Why is the torrc setting disabled by default, if it's so good?

  We suggest this torrc option to be optional because it puts
  additional load on guard nodes and we are not sure if the network
  will be able to handle it.

  However, by having this setting be disabled by default, we make
  hidden services who use it stand out a lot. For this reason, we
  should eventually fix our hidden service circuit load balancing so
  that we can enable this globally.

  XXX But hidden services traffic is only 6% of the total network, so
      maybe it's not that big of a problem and we should just enable
      this feature by default anyway

3.4.1. How should we load balance to enable this feature globally?

  The load balancing issue with this feature is that hidden service
  traffic that would otherwise be passing through middle nodes, will
  now be passing through guard nodes.

  Furthermore, this additional traffic is not accounted for in our
  bandwidth weights. This means that a guard node that had 1%
  probability of being chosen as a guard for normal circuits, will
  still have the same probability of being chosen as a guard even
  though the hidden service traffic that it pushes increases.

  To improve the load balancing here, we could have each relay report
  the amount of hidden service traffic it pushes every day (#15254),
  and have the authorities take this into account when they calculate
  bandwidth weights. The idea here would be that the dirauths would
  know that N% of the network is hidden services traffic, hence they
  would tweak the bandwidth weights such that guards would reserve
  some N% of their bandwidth for hidden service purposes.

4. Future directions

  Here are some more ideas for improvements that should be done sooner
  or later:

  - Maybe we should make the size and rotation period of
    secondary/third guard sets to be configurable by the user.

  - To make it harder for an adversary, a hidden service MAY extend
    the path length of its circuits by an additional static hop. This
    forces the adversary to use another coercion attack to walk the
    chain up to the hidden service.

5. Acknowledgements

 Thanks to Aaron Johnson, John Brooks, Mike Perry and everyone else
 who helped with this idea.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev