Los trabajos actuales Sobre “lo que sale” y los límites

In the last section we presented the protocol. Here we will try to explain some of our design decisions and show how they relate to the properties we want our system to satisfy.

There are several novel aspects in the design of our censorship resistant system as compared to existing architectures:

• Replication. The use of a Peer-to-Peer layer such as PAST to replicate state in forwarders and storers.

• Forwarders. The use of forwarders to provide an extra layer of indirection and prevent the storers from being visible by clients.

• Encryption of shares. Storing the shares in an encrypted form and keeping the keys at the forwarders.

• Decrypters. The use of separate nodes (as opposed to, for instance, forwarders) to decrypt shares.

8.3.1 Replication

Replication of state in the system provides fault tolerance, efficiency and prevents several kinds of attacks.

Firstly, it makes denial of service attacks and simple efforts to take down individ- ual forwarders ineffective because there are always a number of other hosts ready to forward requests. Furthermore, even if the attacker succeeds in taking down a particular forwarder, state will be replicated onto a new node which will also start forwarding requests.

More subtly, it reduces the link between any particular forwarder and the share which has been retrieved. This is because the address for a particular forwarder (for instance, a0) which is published in the anonymous newsgroup denotes a dynamic

set of physical hosts rather than a single machine. This is due to the behaviour of the underlying layer (PAST): if asked to route a request to a node (a0), it does not

necessarily forward it to that specific node, but instead to any node which shares state with a0. Therefore, it is not easy to establish precisely which physical machines

the address a0 represents; indeed, this set changes as machines go down and come

back up.

However, this introduces a slight complication. Although the forwarders share state, they cannot share private keys (it would be impossible to keep these keys secret because the set of forwarders constantly changes as nodes go up and down). Therefore requests addressed to them must be delivered in plaintext4_{. This turns out not to}

be problem here as the attacker who watches traffic arriving at the forwarders sees v0 and rc. The former is public anyway, and the latter gives away no information

about c itself (but enables him to send a fake share to c5_).

8.3.2 Forwarders

The use of forwarders serves several purposes. First of all, they help protect the stor- ers against “Rubber Hose Cryptanalysis” by hiding them from the clients. Secondly, they can help provide active-server document anonymity by randomly introducing new dummy requests into the system and dropping some of the valid ones. Thus, it will make it hard for the storer to find out (part of) which document it is storing, even by acting as a client in the system. Finally, we use the forwarders to store keys which decrypt the shares and forward them to the decrypters.

4_{This means that the last layer of the onion is not encrypted. Therefore, the message is still}

anonymous but not secret.

5_{This does not constitute an attack as the adversary would have to perform this active and}

8.3.3 Encryption of Shares

We have argued that the storers should not be able to see the content they are storing, to prevent the possibility of them being pressured into censorship. Therefore, we must make them store the shares in an encrypted form and stop them from getting hold of the keys which would decrypt the shares. Thus these keys cannot be published as this would enable the storers to retrieve all of them and see which one decrypts each of the shares. Hence they are stored by the forwarders.

8.3.4 Decrypters

Some would argue that the use of decrypters is superfluous. The storer could just send the shares back to the forwarder who would send them back to the client. However, this would expose the forwarder to the risk of being caught red-handed with the share. Furthermore, they might be pressured into installing a filter to censor shares which the attacker does not like. As the forwarder is the publicly visible part of the system (and therefore the most vulnerable), we decided to delegate the task of decrypting the share to a completely different entity who does not have any information about what it is decrypting.

Having looked at the various features of the system, let us see how they combine to protect against the attack we described earlier. First of all, the use of forwarders means that the storers do not have to be included in the address of the document. Furthermore, the use of a strong anonymity system does not allow the storers to be identified even by a global passive adversary who tries to analyse where the messages from the forwarders travel to. Finally, even if the attacker picks a particular storer for reasons other than analysing the communication patterns, he can deny knowledge of the content on his machine – the shares are encrypted and he does not possess the keys. Having established the fact that we protect the storers against this attack, let us consider the forwarders. Certainly, it is possible to determine some of the forwarders for a particular share of a certain document are. However, it is possible for a forwarder to deny that a request for a particular share has been forwarded. Firstly, due to replication of the forwarder state, over time different machines act as forwarders for a singe share, so simply sending a request for a share does not identify the machine which forwarded it. Secondly, even if a record of a forwarder is identified, his link to the document is extremely weak – he forwards what essentially amounts to random bits which may (or may not) cause a part of a document to arrive from a completely different part of the network (the decrypter) later. Certainly, in our view this provides much better protection than, say, Publius.