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

[unknown <unknown@xxxxxxxxx>]

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 rise 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

Another 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"