Mixe for Privacy and Anonymity in the Internet
The whole system consists of JAP's, mix-servers, cache proxies and the InfoService. (see Figure 1)
The local proxy (JAP) and the mix servers communicate using TCP/IP-Internet connections. Each JAP has one and only one connection to a mix server. A mix server has one and only one connection to one or two other mixes. If a mix receives data packets from JAP's and sends them to an other mix, we call them a first mix. So a first mix has exactly one connection to an other mix. If a mix receives packets from a mix and sends the data to the cache proxy, we call them the last mix. Consequently a last mix has only one connection to an other mix. Each mix with two connections to other mixes is called a middle mix. This type of mix will receive packets form one mix and forwards them to the other mix.
If mixes are connected in a meaningful way a chain is setup up, so what packets are transmitted from JAP's to the cache-proxies and than to the Internet. A chain of mixes is called a MixCascade (or cascade for short). Many different cascades could exist at the same time, but JAP can select one and only one at the same time.
Also a mix could only be part of one and only one cascade. If a mix is not part of a cascade, we call it a free mix. Free mixes are not useable for JAP, but could be connected to build a new cascade.
Beside JAPs and Mixes we have added a third component to our system: the InfoService. The InfoService is more or less a database which stores information about the system like available MixCascades, status of Mixes etc.
JAP acts as a local proxy for the browser. The browser opens many connections to the JAP (usually one per HTTP-Request). All this connections are multiplexed over the one connection to the first mix JAP is connected to. Every connection from the browser is called a channel (mix channel or AnonChannel). A first mix sends the stream of packets (from multiple channels) from multiple users to the next mix (all over one TCP/IP connection). So JAP and the mixes have to multiplex/demultiplex the channels. A channel can transport only fixed sized packets. These packets are called MixPackets. So a first mix for instance gets many packets from different users in parallel and sends them to the next mix in a serialized way. (see Figure 2)
The data bytes have different meanings in different situations and mixes. For instance the content itself is meaningful only at the last mix (because of multiple encryptions) The format of the data (at the last mix) is:
They payload are the bytes what should be transported from the browser to the Internet or back via the anonymous channel.
The channel-ID changes in every mix. Also the content bytes changes in every mix, because each mix will perform a single encryption/decryption.
The stream of MixPackets between to mixes is encrypted using AES-128/128 in OFB-128 mode. Exactly only the first part (16 bytes) of each MixPacket is encrypted. (see Figure 4)
The encryption is done, so that an attacker could not see the channel-ID and flags of a MixPacket. OFB is chosen, so that an attacker could not replay a MixPacket. If he replays a MixPacket, than at least the channel-ID changes after decrypting. If this MixPacket was the first packet of a channel, than the cryptographic keys for this channel will change to (because of the content format for the first packet of a channel, explained later).
For Upstream and Downstream different keys are used. See [Cascade setup] for information about exchange of these keys.
Before data could be sent through an AnonChannel one has to be established. This is done by sending ChannelOpen messages through the mixes. Figure 5 shows the format of such a message how it would arrive for example at the last mix.
If a Mix startsup it reads its configuration information from a file. See [MixConfig] for more information.
Figure 6 shows the steps which take place, than a Cascade starts. These steps are illustrated using a 3 Mix example. The procedure is as follows:
HTTP GET/POST-requests are used for communication with the InfoService. The filename part of the URL specifies the command (action) to be executed and additional information is transfered as XML struct in the body of the HTTP message. Example:
POST /status HTTP/1.0 Content-Type: text/xml Content-Length: 251 <?xml version="1.0" encoding="utf-8" ?> <MixCascadeStatus id="testmix" mixedPackets="567899" nrOfActiveUsers="235" trafficSituation="78" LastUpdate="126940258075"> </MixCascadeStatus>