Multiple Directory Authorities' keys compromise: a partial solution for Tor clients protection

[unknown]

Happy 2008! Here we go again ;-)

Any comments?

On Fri, 28 Dec 2007 13:29:37 +0300
unknown <unknown at xxxxx.xxx> wrote:

 Multiple Directory Authorities' keys compromise: a partial
 solution for Tor clients protection.

 The core problem with Tor is the lack of directory
 authorities which one need to unconditionally trust. Despite
 the mechanisms of DAs consensus voting and client comparing
 signed data downloaded from different DAs, an opponent
 controlling more than half of DAs' keys is able to conduct
 a multitude of attacks.

 Unfortunately, we have a really small set of semi-trusted
 authorities and more than a half of them are in the single
 jurisdiction (US), so we are forced to believe that owners
 of these servers really protect their servers' keys from
 compromise, and operators themselves are free from any
 third-party malicious influence ;-)

 Main security and trust problems were improved in v3 directory
 authority protocol, but not resolved completely.

 If the third-party agent Mallory possesses more than half
 of semi-trusted DA keys and has an ISP-level access to user
 traffic, he still can make an MITM-based virtual network
 simulation for that user, like this:

 Normal client activity:

 Alice -> encrypted traffic -> [real Tor cloud] -> decrypted
 traffic from exitnode -> Bob

 Intercepted client activity:

 Alice -> encrypted traffic -> [Mellory's virtual Tor network
 simulation] -> decrypted traffic for Mellory ->
 -> [Mellory's Tor client using Alice's circuits] -> [real
 Tor cloud] -> decrypted traffic from exitnode -> Bob

 ###

 We propose a partial (very limited, but adequate) solution:
 Tor client with active connection and relatively "fresh"
 stats cache can resort to "heuristic" analysis for suspicious
 stats changes.

 At most two criteria can be analyzed:

 1) An attempt to download stats from all of the mirrors
 is blocked or gives the stats with invalid signatures. As
 a result, it could be downloaded only from semi-trusted
 DAs. (Possibility of a legitimate DA's IP substituted with a
 malicious one, and data authenticated with compromised keys).

 2) Tor-nodes' keys signed by a DA are changed significantly
 (for example, >90% of all keys) during a very short period of
 time. (This case rises a suspicion about fake stats injection
 for user cache.)

 Some questions remains: How many keys have to be affected
 by this attack to raise a suspicion? What the minimum time
 period threshold should be?

 ...) What's about other criteria of suspicious activity
 or formal model of other possible attacks detection for
 Tor clients?

 We propose next log messages for the Tor client as an
 indication of probable attack-in-progress:

 -> Warning! Warning: a lot of tor-nodes' keys were changed
 during a short period of time!
 -> If more than a half of Directory Authorities' keys are
 compromised, stats could be poisoned with a fake data.

 As a paranoid option listed in config file (client-only
 section) one may use:

 StopTorIfTooManyKeysChanged 0|1

 Other open questions: Suppose user has this option
 enabled. Is it then sufficient to stop Tor-client when
 before-mentioned log event comes up or should also be done
 some other things too? What are the right things to do for
 users who got that log event? What's the right procedure to
 run Tor-client for users who have an outdated cache to be
 safe from this attack?

 There is a long discussion on this problem on our site where
 we continue to propose a lot of ideas related to the topic.

 "OpenPGP-in-Russia Team"