- Delaytor: defence from practical attacks against low-latency anonymizing networks
- Potential project: E2E-encrypted Git repositories, wiki and issue trackers
- Potential project: Metadata-protected Messaging
Delaytor: defenсe from practical attacks against low-latency anonymizing networks
Thorough analysis of practical attack and defence methods is presented in our article (in Russian). Detailed abstract and conclusions are written below.
The most interesting, common and at the same time the most vulnerable model of user behavior is public communication within a wide circle. This includes conversations in a forum, social network, messenger; posting in a blog, leading or contributing to open source project and so on. Members of DeepTech group are engaged in exactly these activities.
Tor network is de-facto the only practical technology that allows to operate pseudonymously in a wide circle. I2P isn’t a proxy to Clearnet so it can be used to foster collaboration only within the core of community.
The main technical threat, the operators of the total surveillance and control are secret services and large corporations. They can be regarded as a local attacker: it sees and controls all incoming connections into anonymizing network (from every user at controlled area).
In Russia this property is implemented by SORM. This is a surveillance system installed in networks of every ISP. Watching all incoming connections on its own doesn’t comprise the direct treat to anonymity of the users. But in practice this local attacker can - control all outgoing connections from anonymity network to the target server, if the server is located in the same controlled area - see access events to the server related to user’s pseudonym / handle, if at least one of the conditions is satisfied: - events happen on a public server (e.g. commenting on a public forum, even if it is operating as hidden service) - the server is controlled by attacker (collaborates, gives access to logs; or subverted)
In described circumstances the attacker can perform following practical attacks on anonymity and pseudonymity of the users:
- traffic shaping attacks
- intersection attacks
To perform effective traffic shaping attack the adversary must control both ends of the connection. In the presence of SORM at least one end (at ISP) is already controlled. The second one is controlled if the server is located in controlled area. In Russia this condition is satisfied for many popular social networks, blogging platforms, forums and so on.
During this attack adversary modulates network traffic, controlling time intervals between packets and then detecting such “watermark” on the other end of the connection. A single request from the user is enough for deanonymisation.
Intersection attack is used for uncovering long-term pseudonyms. The victim posts a few messages using a pseudonym. The adversary using SORM creates sets of users who were online at each moment of posting. Intersection of these sets is the anonymity set of this user. Obviously, people change their online status, so after large enough number of posts the intersection will contain only the real author of the messages.
Note a specific feature of this passive attack: it can be performed retroactively based on network activity logs even years since posting incriminating messages.
There are following known measures to defend from the mentioned attacks:
M1. Use other anonymisation methods in addition to Tor / I2P. For example, use public/third-party Wifi networks without authentication (worth mentioning that such public networks are completely eliminated in Russia).
М2. (effective against shaping attack together with bisecting1) Reduce duration of the communication sessions.
М3. (effective against shaping attack) Use caching proxy, e.g. installed as a hidden service. In this case the attack can uncover only the proxy - and only if it is located in the adversary-controlled area.
М4. (effective against intersection attack) Hide date and time of the public events (posts) at the own hidden services (and do not keep the logs). Won’t help if the attacker installs active polling system to monitor the service (or simply break into it).
M5. (effective against both shaping and intersection attacks) Use VPN before entering Tor2. This measure can help only if the attacker is capable of analysing traffic to known public entry guards and bridges of Tor. Won’t help if attacker can detect and analyse VPN (SSH tunnels, private bridges).
As we can see, in practice it is relatively easy to build sufficient defence from shaping attack (caching proxy). But there is no acceptable defence against intersection attack, especially if public or adversary-controlled resources are used.
Creating new practical defence methods
There is a need to create the defence as an add-on for popular networks (Tor, I2P). DeepTech group suggests to research possible theoretical solutions, choose practically suitable one and start implementing it.
Preliminarily, the most reasonable research direction which covers both shaping and intersection attacks (including the worst case of the attacker-controlled server) is following:
М6. Delaytor: add substantial delays between sending and delivering a message.
In fact, this is dismissing of low-latency communications, looking towards anonymous remailer. Need to add such work mode for existing systems – Tor/I2P and social networks, messengers, forums. This is mandatory requirement so this new system is practically useful.
A little bit more about possible implementation see full article (in Russian, not translated yet).
The simplest working scheme is following. The user connects to hidden service in Tor/I2P and prepares a script which includes login/password/access token to the target server (social network, forum), required action e.g. send a message and message’s text. After a set randomized delay the client from the hidden service executes the script. The user returns to the hidden service and picks the result/response.
In this scheme we have a centralized service that user has to trust. In practice this service may be controlled by the user, e.g. executed at his VPS of some service provider. This isn’t suitable for mass use but at least looks quite feasible.
The question is open whether it is possible to implement decentralized (trustless) solution based on modern cryptography.
Potential project: E2E-encrypted Git repositories, wiki and issue trackers
Many projects and communitites (including DeepTech group) have to use services from third party providers to host project management software. Naturally, provider gains full access to the project data. This means it is impossible to develop projects in a truly private manner using common collaboration tools. Tools with E2E-encryption for project management are really needed.
Potential project: Metadata-protected Messaging
Most of the modern messaging systems (email, Jabber, Matrix, BitMessage, Tox, Ricochet etc) are real-time, hence susceptible to the same threats to anonymity as any low-latency system. There is a need for really secure system, a modern version of anonymous remailers.