Architecture of the Anonymization Service

• JAP Client program installed on the user's computer.
• Mixes Anonymizing intermediaries which mix the data streams of various users together.
• InfoService A separate service which provides meta-information about the available mixes (that is, mix cascades), number of users currently using the mix cascades, and the current load on the mix provider.

How It Works

In the next step, JAP registers with the first mix station of the chosen mix cascade. A permanent network connection between JAP and the first mix station remains until logoff.

On installation of JAP, the user already configured the web browser so that each packet of data sent goes through JAP instead of directly to the internet. JAP encrypts the data and sends it to the first mix station. The first mix station then mixes the data with that of other users and sends it to the second mix station which passes it on to the third mix station which decrypts and sends the data through a cache proxy to the internet.

Each mix carries out cryptographic operations on the message so that the JAP-encrypted data is only readable when it's gone through the proper mixes in the proper order. That way it's insured, that an eavesdropper either only receives unreadable (encrypted) data or can no longer determine the sender. In order for it to work correctly, only one mix in the cascade need be trusted not to inform the eavesdropper as to the method of message mixing. Here is a description of the exact method of encryption.

Weaknesses of JAP

1. A mix in the cascade should not be controlled by an attacker and should not work together with an attacker.
2. The attacker should not control all other users. (An attacker could then observe a single real user, since the real user is alone and the attacker would know that all data which the attacker himself didn't send came from that single user.)

Possible Attacks

If an attacker keeps all network connections under surveillance, each user would have to send and receive exactly as much data as any other user. Otherwise the attacker, who observes both the connection to the user and the connection to the internet after the final mix, could correlate a user based on the amount of data sent. If one user sends more data than all the other users, that's most likely the one communicating with another user who is receiving large amounts of data at the end of the cascade.

Currently, we can't defend against such an attack for various reasons. Users have different connection speeds and varying amounts of activity at any given time. If one wanted to achieve an equivalent behavior pattern among all users who have the same connection speed, yet maintain a similar quality of service, the mixes would require many times the current bandwidth. In addition, any disturbance experienced by a single user would have an effect on all other users, since they would have to wait until the one user with the connection problems sent as much data as all the rest.

A second theoretically possible attack is as follows: Currently a single attacker could simulate multiple users by simply starting several JAP client programs. That way, he could at least fool the remaining users into believing in a higher amount anonymity than what is really available. If the attacker would furthermore block all real users except for one, the anonymity of that single remaining user would be completely eliminated.

To prevent this kind of attack, it would be necessary to authenticate every user at login, for example with a digital signature. With a pay-based service, such an attack could at least be made very expensive for the attacker.

There are currently still other attacks possible, since the planned basic functions are not yet completely implemented. On the other hand, an attacker would have to be relatively strong in order to succeed in any attack known to us.

You are already protected against an eavesdropper who can only eavesdrop on one point of the network or who controls only one of the mixes.

Reasearch on JAP

back