[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Multiple Directory Authorities' keys compromise: a partial solution for Tor clients protection
Happy 2008! Here we go again ;-)
On Fri, 28 Dec 2007 13:29:37 +0300
unknown <unknown@xxxxxxxxx> 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
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
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:
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.