Description of the system and communication protocol

Basics

The whole system consists of JAP's, mix-servers, cache proxies and the InfoService. (see Figure 1)

Figure 1: The Architecture of the Anonymous-Service

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.

Mulitplexing and Demultiplexing

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)

Figure 2: Mux/DeMux of fixed sized MixPackets

Each MixPacket has a size of MIXPACKET_SIZE (998) bytes (see Figure 3). The header of each packet is as follows (see also: MIXPACKET):

4 bytes channel-ID
2 bytes flags
DATA_SIZE (992) bytes data (transported bytes)

Figure 3: General format of a MixPacket

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:

2 bytes len
1 byte type
PAYLOAD_SIZE (989) bytes payload

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.

Inter-Mix Encryption

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)

Figure 4: Encryption between two mixes

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.

AnonChannel establishment

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.

Figure 5: ChannelOpen packet (example for the last mix)

Initialisation of a Cascade

If a Mix startsup it reads its configuration information from a file. See [MixConfig] for more information.

Figure 6: Steps during Cascade initialisation (3 Mix example)

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:

Step 1: Each Mix starts, reads its configuration file (including own key for digital signature and test keys from previous and next mix) and generates a public key pair of the asymmetric crypto system used by the mix for encryption (currently this is RSA).

Step 2: Mix 2 establishes a TCP/IP connection with Mix 3. No data is transmitted during this step.

Step 3: Mix 3 sends its public key to Mix 2 (signed with its signature key). See [XML] for a description of the XML struct send in this step. The <Nonce/> is a random byte string of length=16 (chosen by Mix 3) used for replay detection.

Step 4: Mix 2 generates and sends a symmetric key to Mix 3, encrypted with the public key of Mix 3, signed by Mix 2. This key is used for inter-mix encryption and is actually a 64 byte octet stream. See [XML] for a description of the XML struct send in this step.
The first 16 bytes a used as a key for inter-mix encryption of packets send from Mix n-1 to Mix n (e.g. upstream direction). The next 16 byte are used as IV for this cipher. The next 16 bytes are used as key for downstream direction and the last 16 bytes are the IV for this cipher. To detect replay attacks Mix 3 checks if the <Nonce/> element sent from Mix 2 is equal to SHA1(<Nonce\/> chosen by Mix 3 in Step 3).

Step 5,6,7: This steps are equal to step 2,3,4. Mix 1 establishes a TCP/IP-connection with Mix 2. Mix 2 send it publick key to Mix 1 and Mix 1 generates and sends a symmetric key to Mix 2.

Communication between Mix and JAP

Figure 7: Communication between Mix and JAP

JAP opens a TCP/IP connection to a FirstMix
FirstMix sends information about the cascade (including public keys of the Mixes) to the JAP. See [XML] for a description of the XML struct send.
JAP sends a special MixPacket, containing only 2 symmetric keys (IV is all '0') encrypted with the public key of the FirstMix. This keys are used for link encryption between JAP and FirstMix. Note: At the moment this is binary - but will use XML in the future. The data part of this MixPacket is as follows:
- the ASCII string: "KEYPACKET"
- 16 random bytes used as symetric key for packets send from Mix to JAP
- 16 random bytes used as symmetric key for packets send from JAP to Mix

Normal MixPacket exchange according to the mix protocol.

Communication with the InfoService

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>

Communication between Mix and InfoService

Figure 8: Communication between Mix and InfoService

1. HELO-Messages send from each mix to the InfoService every 10 minutes to announce itself. This is a POST request and the command name is: "helo". See [XML] for a description of the XML struct send.

2. Status-Messages send from the FirstMix to the InfoService every minute to update the current status of the MixCascade including Number of Users, Traffic situation etc. This is a POST request and the command name is: "status". See [XML] for a description of the XML struct send.