That's... not, quite accurate. It's leaving out guards, which is what had me thinking it was the protocol before their introduction. But sure, maybe they skimmed over it (or I missed it in my own skimming). But further on, they clearly state:
....
Sure, that's all well and good... except they STILL haven't mentioned the fucking guards? It's like they're analyzing the network before guards were introduced. Now in fairness they go on to talk about them when detailing their next attack, but there's weirdness there. Before skipping to VI A though, this line in V A caught my eye:
Well, they're describing the first part of the attack. The other part is to flood the network with guards, the economics of which is described in VI.C:
In early 2012 we operated a guard node that we rented from a large European hosting company (Server4You, product EcoServer Large X5) for EUR 45 (approx. USD 60) per month. Averaging over a month and taking the bandwidth weights into account we calculated that the probability for this node to be chosen as a guard node was approximately 0.6% on average for each try a Tor client made that month. As each hidden service chooses three guard nodes initially, we expect over 450 hidden services to have chosen this node as a guard node10 . Running these numbers for a targeted (non-opportunistic) version of the attack described in Section VI-A shows us that by renting 23 servers of this same type would give us a chance of 13.8% for any of these servers to be chosen. This means that within 8 months, the probability to deanonymize a long-running hidden service by one of these servers becoming its guard node is more than 90%, for a cost of EUR 8280 (approximately USD 11,000).
Just like any Tor client, an attacker is able to compute the descriptor IDs of the hidden service for any moment in the future and find the fingerprints of expected responsible HS directories. After that she can compute the private/public key pairs so that SHA-1 hash of the public keys would be in-between the descriptor ID and the fingerprint of the first responsible hidden service directory. The attacker then runs Tor relays with the computer public/private key pairs and waits for 25 hours until they obtain the HSDir flag.
I thought you could only calculate the descriptor IDs 24 hours in advance
Unless a cookie is set with the HiddenServiceAuthorizeClient option, the descriptor IDs are deterministic and computable arbitrarily into the future:
Tor hidden service desc_id‘s are calculated deterministically and if there is no ‘descriptor cookie’ set in the hidden service Tor config anyone can determine the desc id‘s for any hidden service at any point in time.This is a requirement for the current hidden service protocol as clients must calculate the current descriptor id to request hidden service descriptors from the HSDir’s. The descriptor ID’s are calculated as follows:
descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica))
The replica is an integer, currently either 0 or 1 which will generate two separate descriptor ID’s, distributing the descriptor to two sets of 3 consecutive nodes in the DHT. The permanent-id is derived from the service public key. The hash function is SHA1.
time-period = (current-time + permanent-id-byte * 86400 / 256) / 86400
The time-period changes every 24 hours. The first byte of the permanent_id is added to make sure the hidden services do not all try to update their descriptors at the same time.
identity-digest = H(server-identity-key)
The identity-digest is the SHA1 hash of the public key generated from the secret_id_key file in Tor’s keys directory. Normally it should never change for a node as it is used for to determine the router’s long-term fingerprint, but the key is completely user controlled.
but whatever, skipping that: how can this be possible at all, since even assuming they get to the point of impersonating the HSDirs in question due to the properties of the distributed hash table... they still won't have the private key for those servers that the 6 (is it 6?) authoritative directories will be checking for, and so will be ignored anyway?
I'm not sure what you're asking here.
In order to confirm that an attacker controls a guard node of a hidden service she needs to control at least one more Tor non-exit relay. In the attack, the hidden service is forced to establish rendezvous circuits to the rendezvous point controlled by the attacker.
...
If all the conditions are satisfied, the attacker decides that her guard node was chosen for the hidden service's rendezvous circuit and marks the previous node in the circuit as the origin of the hidden service.
I skipped over some stuff because I"m tired, but I don't understand how this is possible, unless you're running Tor over Tor...? How can a guard ever be chosen as an introduction point for a hidden service -- the guard knows what hidden service it's a guard for, why in God's name would it blindly say "sure, I'll be the rendezvous point for my pal there!" 
The guard node isn't the intro point. The guard and rendezvous nodes are controlled by the attacker.
Show Posts
