IMPROVING QUALITY OF ANONYMOUS COMMUNICATION SYSTEM
THROUGH THE INTERNET USING MOBILE DEVICES
Khandoker Asadul Islam, Yoshimichi Watanabe, Hidetoshi Mino, and Haruaki Yamazaki
Department of Information System Engineering, Division of Engineering,
Interdisciplinary Graduate School of Medicine and Engineering, University of Yamanashi.
4-3-11, Takeda, Kofu, Yamanashi, 400-8511 JAPAN
E-mail: [email protected]
ABSTRACT
This paper proposes a public anonymous message communication system between clients. The main goal was to develop a message
communication system with concealing sender, receiver and sender-receiver path information. The widespread uses of mobile devices
lead to focus on developing mobile-device-enable systems. To improve the quality of the anonymous communication, this paper proposes
a successful implementation of the anonymous communication system using mobile devices through the Internet, thus improves the
quality of the system by increasing widespread usability. In addition, this paper also proposes a procedure of minimizing traffic for the
mobile devices by using an intermediate intelligent MPFS. The implementation of this system can definitely give a rise in various
consulting and message sharing applications.
Keywords: Anonymous Communication, Internet Messaging, Mobile Internet
INTRODUCTION
This paper proposes a public anonymous message communication system between clients. The main goal is to develop a system which
controls message communication but fully unaware of a single message’s receiver and communication path – that is which message goes
to whom. The widespread use of mobile devices leads to focus on developing mobile-device-enable systems. To improve the quality of
the anonymous communication, this paper proposes a successful implementation of the anonymous communication system using mobile
devices through the Internet, thus improves the quality of the system by increasing widespread usability.
When someone sends a message to a receiver using the Internet, the message goes through ISPs, NSPs, and private networks until
it reaches its destination. The message packet contains the information of the destination and the sender using TCP/IP protocol suite for
transmitting message. Receiver can track back the message path. In this way it is possible to identify the complete path of the message
transferring. The goal of anonymous message communication is to make the message transferring path undetected between the receiver
and the sender. The possible uses of the system could include health consultancies, personal opinion sharing, or sharing information
without disclosing identity.
Reason for Anonymity
Anonymity is very useful when a person desires to protect their identity from discovery. Anonymity is desired by anyone who fears
retaliation, discrediting, unpopular sentiment, or simply desire’s privacy. Anonymity finds uses in corporations for whistle blower cases;
in law enforcement for anonymous crime tip lines; in universities for course and faculty evaluation; in government for political
discussion and voting; in restaurants for customer feedback; people giving advice; and many other uses.
The internet is critical part of our daily life, used by millions to communicate, however it is a shared medium. Spyware, un-trusted
routers, packet sniffers, Trojans, and wire tappers make any information transmitted over the Internet susceptible to capture and analysis.
Encryption may hide what is being said, anonymity hides who is saying it. The ultimate goal in anonymity is to make it appear to an
outside observer that no communication happened at all. We strive for sender anonymity, receiver anonymity, and sender-receiver
unlinkability. From an observer’s point of view, this is attained if he/she cannot identify the sender, identify the receiver, or link the
sender to the receiver.
BACKGROUND AND LITERATURE
The Internet, being a shared medium, does allow others to capture and analyze communications. However, by utilizing this shared
medium, forming groups, we can hide our identity within the group. Much as a single conversation is difficult to hear in a crowded room,
groups of participants form the driving force behind anonymity.
Anonymous communication was started with the Mix[1] based systems such as, Crowds[2], Anonymizer[3], Onion routing[9],
WebMIXes[4], and Hordes[5]. Broadcast protocols and DC-Nets including Herbivore[6], and P5[7] are also influenced in the literature
of anonymous communication. For the easy discussion, anonymous protocol classified here into two broad categories, those using Mixes,
and those using broadcasts or DC-Nets[8].
Mixes
David Chaum’s seminal paper in 1981 defined a method to anonymously send pieces of mail to other participants using “Mixes” [1]. A
Mix accepts pieces of encrypted e-mail for delivery from many sources, holds, re-sorts, possibly introduces null mail, rewrites the from
address, and possibly sends the mail to another mix for delivery. The end goal is that each piece of output mail is equally likely to have
come from any original sender. The following anonymous protocols base on their anonymity on his work.
Remailers
The aptly named “remailers” are directly based on David Chaum’s work and are the most direct implementation of his work. Cypherpunk
was the first remailer available and is commonly referred to as a “Type 1” remailer. Cypherpunk is the simplest of all remailers, and they
simply strip identifying information and forward the message to a recipient or another remailer in a first-in-first-out basis. If a sender
wants to send a message through a chain of remailers, it is up to the sender to form this chain. Type 1 remailers have a few problems.
They do not address return addresses and also do not provide message padding of fixed lengths. Type 2 remailers such as
“Mixmaster”[11] implements these features. To address sender anonymity, Mixmaster also uses “reply-blocks”. A reply-block is a set of
instruction about how to send a piece of e-mail back to the sender, by using a remailer, or a chain of remailers. Through they use reply
blocks, sender anonymity is guaranteed. However, type 2 remailers do not solve the problem of maintaining receiver anonymity. Senders
still address their e-mails to the recipient’s real e-mail address. Type 3 remailers address this problem through the use of
“Nymserver”[12]. Type 3 remailers mirror the functionality of Type 2 servers, with the important addition of Nymservers that act as
stores of virtual pseudonyms. They simply maintain a mapping of pseudonyms to return blocks. The return blocks specify how to send a
piece of e-mail back to some end point.
Anonymizer
Anonymizer[3] allows anonymous web surfing by acting as an intermediary between the user and the real world. Anonymizer
implements a one-hop HTTP proxy that strips identifying information from a request. In essence, it fetches web pages for the user. To
the contacted server, it appears that one of anonymizer’s servers contacted it. Anonymizer provides anonymity of the requester, but not
the server returning the web page. As only one proxy sits between the end user and the end server, it does not provide a high degree of
anonymity. Anonymizer is also vulnerable to many of the common attacks.
Crowds
Crowds[2] extends the idea of anonymizer by introducing many computers in the communication path between the initiator (web-surfer)
and the receiver (the web server). In this manner, no single point of failure compromises the sender’s anonymity. When an initiator
would like to make an anonymous request, they form a path of many proxies. They first contact a random Mix, called “jondo”, which
creates a random path through the network that this and all subsequent requests will make. “Crowds” provides sender anonymity, not
receiver, as the end server is contacted by the last random Mix directly. As long as the sender maintains his/her anonymity, and does not
reveal personal identifying information in a request, sender-receiver unlinkability is provided.
Hordes
Hordes[5] builds on the Crowds work, instead of serving as a proxy for a HTTP connection, the “jondo”s in Hordes serve as proxies for
UDP connections. Path creation works analogous to Crowds, however, a multicast return is used instead of the reverse path. When an
initiator sends a request, a multicast address is picked on which return responses should be broadcast. “Hordes” provides sender
anonymity, not receiver, at some points the last “jondo” makes a connection to the end receiver. Sender-receiver unlinkability is
guaranteed if the sender does not betray personal information to the receiver.
WebMIX
WebMIX[4] provides a system similar to Hordes and Crowds but addresses some of the vulnerably inherent in mix based systems. In
particular, a system to prevent DoS attacks is presented. In WebMIX, a ticket-based authentication system is presented, where
participants on the network are issued a ticket to use the network. If the participant desires to communicate anonymously, he/she redeems
his/her ticket and sends his/her message. This prevents users from flooding the network with traffic. Each Mix will digitally sign each
message as a sign that it did not tamper with the message.
Onion Routing and Tor
Onion routing[9] relies on a chain of Mixes, or onion routers, on which a participant created onion can travel. It is suggested that every
participant run an onion router so that at least one hop of the network is trusted. When a participant desires to send a message, they a
priori choose a set of onion routers, encrypt their message in the public keys of the onion routers and send the message or onion on its
way. Tor[10] is the next generation onion router which fixed many of the problems in the onion router specification. Tor separates the
line between anonymity and “data cleansing”. Data cleansing is the process of removing personal information (e.g. cookies, active X
objects, etc), from message such as requests to web servers. Many web servers will tag visitors with cookies to track user activity and
discover how often visitors come back. Removal of this information is important to maintaining anonymity. Tor suggests the use of
proxy, when using Tor to communicate anonymously. Tor implements a SOCKS proxy to support the idea of a generalized anonymous
communication protocol. A SOCKS proxy accepts requests for connections to other computers and decides whether to forward the
connection or not. Any application that can use a SOCKS proxy can communicate anonymously. Onion routing tries to make an
initiator’s request appear equally likely to come from any onion router, in this way sender anonymity is provided, as well as
sender-receiver unlinkability. Through the use and establishment of rendezvous points, receiver anonymity is established.
DC-Nets and Broadcast Protocols
This section discusses anonymous broadcast protocols including Herbivore which uses DC-Nets to create anonymity and P5 which uses
pure broadcasts. Herbivore is not a broadcast protocol in the sense that every node broadcasts every piece of information; it suffices to
assign one participant the job of collecting broadcasts and sending them back to nodes when all have been collected. DC-Nets can be set
up to work in broadcast node; however it is more efficient to run a fully-connected DC-Net in a star topology as shown by [6]. One
important difference between DC-Nets and Mixes is that DC-Nets provide perfect sender and receiver anonymity even under the
presence of a local eavesdropper.
Herbivore
Herbivore[6] relies on DC-nets (Dining Cryptographer Networks)[1] to create anonymity. In Herbivore, each participant shares a
different secret key with every other participant. This shared secret key is used as a seed in a random number generator that generates
only zeros and ones. To send anonymous bits, each participant uses the random number generator to generate a zero or one key with
every other participant. Each participant sums the keys along with a zero or one message that the participant would like to send. The
parity of this sum is broadcast to all other participants (zero for even, one for odd). Assuming only one person is communicating an
arbitrary message of one or zero and all others are transmitting a message of zero, the parity of the sum of all broadcasts will be that of
the sender’s message. This occurs because each key is summed twice; the sum of all keys will always have even parity (*0 mod 2).
Without knowing the keys, it is equally likely that any person is the initiator. However, the DC-net is not enough to run the network. The
DC-net does not address who sends a message, when is a message sent, or joining or leaving the network. Sender anonymity is
guaranteed by DC-nets. It is equally likely that any member of a clique in Herbivore lied about their broadcast. Herbivore provides a
method to address another Herbivore member through the use of broadcasts. Receiver anonymity is insured by these broadcasts. By
using them together, sender-receiver unlinkability is also guaranteed.
P5
A participant in P5[7] secretly choose a key which is then hashed to form a P5 key K. K is used to map a participant to a anonymity
group using the following protocol. Each group in P5 is defined by the terminology (b/m) where b is the string of zeros and ones, and m
is the length of that string. Suppose a participant has K = 011001, if he/she would like to join the group (01/2), he/she would choose m =
2, then taking the high bits of his/her key K, she would be placed in (01/2). By using this method, every participant is then mapped to an
anonymity group by their personal choice m, and the value of the high bits of their key K. The choice of m is illuminated in a moment.
The choice of m is determined by the user and should not be revealed. If a participant would like to initiate communication to another
participant of P5 without knowing where they are located in the broadcast tree, they could first try to send to (*/0), perhaps with little
success because of the large number of broadcasts that are dropped at this level. The initiator may try to recursively dig down one of the
tree branches, for example, (1/1), then (10/2), then (100/3), and so forth. Receiver anonymity is provided by the broadcast nature of P5.
To preserve sender anonymity and sender-receiver unlinkability, each node sends fixed amount of noise to uniformly distributed
locations.
MOTIVATING SCENARIO
The main goal of anonymous message communication is to maintain sender, receiver and sender-receiver link undeterminable. In general
scenario, there is a proxy between receiver and sender. All messages go to and from this proxy. There are a number of proposals and
models are presented based on this phenomenon. Our motivating scenario is also this kind of implementation we have done before. We
called the proxy ACS or Anonymous Communication Server.
The concept of the whole system is to build an anonymous communication between peoples that is message is being send and
receive complete anonymously. In summary, the work is like the following.

The consulting person needs to subscribe to become a member of the system before using the system.

ACS is responsible for collecting and receiving all messages. All messages are sending to the ACS.

Before sending message, sender locks the message with lock key. The message can only be unlocked with the corresponding
unlock key. The receiving person has the corresponding unlock key.

The receiving person get all messages from ACS, but can open only those message that can be unlocked by the unlock key.
ACS controls the whole anonymous message communication. Client sends messages to ACS anonymously. The ACS distributes all
the new messages to any receiver requests messages. The receiver can only read any messages specific to it. In this way of message
communication, the ACS is fully unaware of any message path between a sender and a receiver because it sends all new messages to any
receiver. The prototype of this system is implemented using normal PCs through the Internet.
We can start with the structure of the message being sent. The structure has two parts, one is the encrypted message and another is
the encrypted message key. The concept is to encrypt the message in such a way that only the specific recipient can decrypt the message.
Using the public key cryptography technique we can implement this using a private-public key pair. We can encrypt the message with
one key that can be opened by the corresponding other key kept by a specific recipient. But since a message can be large, it is not
desirable to encrypt it using any key in public-private key pair. Rather we encrypt with a random session key and encrypt this session key
with one of the key pair. Figure 1 shows a structure of message.
Ks
Message
Message
Encrypted with a
session key, Ks
Kpu
Ks
The Session Key
Ks is encrypted
with receiver’s
Public Key, Kpu
Figure 1: Structure of the message
The sender sends the message to ACS. The receiver requests message to ACS. ACS sends all new messages to the requester.
Receiver knows that the message which can open by his/her unlock key is his/her message, others are just discarded. The receiver can
make reply to the message. The reply message is also stored in ACS. The sender can request new messages and get his/her reply by the
same way. When sending message, the sender can lock (encrypt) the message in such a way that only the person holding the unlock key
can open the message. The actual address of the receiver is unknown to the sender. The receiver can check for his/her incoming mail by
trying to unlocking all the messages with his/her unlock key. Only those messages that unlocked by his/her unlock key are his/her
message. The sender actual address will be unknown to the receiver. The receiver can reply to the sender although the actual address of
the sender is unknown to him/her. All the receiving and sending to the correct receiver is done by ACS.
We have already implemented a client-server based application. A PC is configured as a communication server. The server
application is implemented in that server. Server application is responsible for registering, receiving messages and sending messages.
The user communication is done by a client application installed in user’s PC. The client application is responsible for sending request to
the server for registering new accounts, writing and sending messages, receiving messages and sending reply to the incoming messages.
The client application is communicating only with ACS using the server application’s open port.
The behavior of the anonymous message communication is as follows. A server named “anonymous communication server” is the
main part of the system which controls the anonymous message communication. Each and every user sends their message to the ACS.
The ACS distributes the message the receiver without disclosing any particular sender information.
Message from
User 1 to User 2
Message reply from
User 2 to User 1
ISP
ISP
Message
User 1
ISP
ISP
Anonymous
communication
server
Message
User 2
ISP
ISP
ISP
Figure 2: Anonymous message communication
In this way of message communication, the ACS is fully unaware of any message path between a sender and a receiver. It can be
said in other way that it is not possible to determine which message goes to whom. The prototype of this system is implemented using
normal PCs and mobile devices.
After successfully implementing the simulation of above model, we are considering improving the scalability of the system.
Nowadays communication through the mobile devices is most desirable. Considering this, we start working on implementing the system
in such a way that a mobile user can access the message. Unfortunately, the same model cannot be directly implemented in any mobile
device, because of its low bandwidth. For a large number of clients using the system, the new message stored in the ACS could be huge.
Sending this huge number of messages to a low bandwidth mobile device is not only costly but also very time consuming. This paper
proposes a Message Pulling and Forwarding Server (MPFS) between the ACS and client mobile devices to solve this problem.
APPROACHING TO MOBILE DEVICES FOR BETTER QUALITY
One of main parts of the anonymous communication is to send all new messages to all available clients including the actual recipient. In
such a scenario, there could be a possibility of a huge number of messages need to be sent to each client, in a very large group of active
users. This may not be a big problem with PC client. But in case of mobile client, this could really be a big headache. We are working on
to build a reasonable solution of this problem. Several implementation scenarios came ahead; we analyze each of them. We went for a
simulation implementation with the proposed idea. This section describes the solution of how we can achieve anonymous communication
with mobile client.
To maintain the anonymity, ACS needs to send all the new messages to each client. After getting each message, client can open
only the messages which are for his/her own, others will discard. We consider another node between ACS and client (here a mobile
device). We called this node MPFS or Message Pulling and Forwarding Server. This is specific to each client and maintained by each
client. The anonymous communication is done between ACS and MPFS of each client, just like the communication done in motivation
scenario between ACS and client PC. MPFS receives all new messages and identifies the messages of the client’s own. When mobile user
connects to the MPFS it is served those identified mail only.
Each client has his/her own MPFS which acts as a proxy for communication with the ACS. The ACS sends all new messages to the
MPFS or MPFS request ACS from time to time for new messages. Then MPFS finds clients messages and prepare an interface for the
client’s mobile devices. Client connects to the MPFS using secured connection, authenticate it and get the message. Figure 3 explains the
proposed model.
User
Internet
Anonymous
communication
server
MPFS
Figure 3: Anonymous message communication using mobile devices
The anonymous message communication is done between ACS and each client’s MPFS. The ACS considers MPFS as its
anonymous client that means each client in Figure 2 is replaced by its MPFS. For using our model, a client needs a MPFS of his/her own
to make anonymous communication from mobile devices.
As a possible implementation, we make MPFS as a web server which provides a web interface to the mobile device. For this
scenario, there is no need for installing any client program to the mobile devices. After registration to the system, the client has given
client program and the interface. The client program and the interface need to be installed in MPFS. The web server specified by the user
and also maintained by the user. It could be user’s home PC or any secured public web server the user chose. The client acts like a web
application. This application sends request for message from ACS. From the point of ACS view, this application is the anonymous client.
Sending an anonymous message
From the mobile device, the client sends the signal to its web application for sending a message and provide it with necessary
information like message text, sender identity etc. The whole message sending process is the duty of that web application. It prepares the
message with anonymous message structure and sends it to ACS. After successfully sending the message, it sends confirmation to the
mobile devices. Then, the client with the mobile device knows that the message has sent.
Receiving anonymous message
The simulation application and the proposed process have build in such a way that the web application periodically in short time intervals
send the request for new message to ACS. It gets all new messages from ACS. Subsequently, it gets the message specific to this client.
When client requests for new message from mobile device, this web application only shows messages specific to this client. In this way,
mobile devices with a very low bandwidth do not need to get all the new messages to have his/her message.
Mobile Interface
We propose and build mobile web pages for the interface of the application to mobile device. It is a big problem to build a mobile
application that can run on every mobile device. There is not any common operation system for all mobile devices. Thus, creating a
mobile application can lead us to build the application in several versions for different types of mobile devices. The development and
maintenance would be a very big headache. We should build web pages which can be browsed by any mobile devices using mobile
browser.
ANONYMITY ANALYSIS
A system provides receiver anonymity if and only if it is not possible to ascertain the receiver of a particular message (even though the
receiver may be able to identify the sender). Analogously, a system provides sender anonymity if and only if it is not possible for the
receiver of a message to identify the original sender. Sender-receiver anonymity or unlinkability can only be achieved when it is
impossible to identify the path of a message from its sender to receiver. In the following paragraphs, we describe how we can achieve all
of the anonymity with our proposed model. We consider the sender, receiver, and sender-receiver anonymity separately.
Sender Anonymity
A receiver who can only monitor their own links cannot determine the source of a packet since this information is never included in the
packet. The receiver gets all messages from ACS, without any information of actual sender. However, receiver can still reply to message
that will go the sender. But even the replied message goes to ACS. There is no way to identify a sender of a specific message for any
recipient. ACS can conduct each message and its sender, but since the message is encrypted, there is no way to identify the content or
any of the attribute of the message.
Receiver Anonymity
Every client gets each and every message. ACS sends all new messages to all clients upon request. From the perspective of an external
observer, the behavior of the system is exactly the same whether receives the packet or not. Thus receiver anonymity is exactly
0
equivalent to the set of all users who receive the message.
Sender-receiver anonymity
From an external observer, message path is to and from client and ACS. No communication between any two clients is seen and never
happened. By definition we achieve the sender-receiver anonymity.
CONCLUSION
Considering the current trend and increasing popularity of mobile devices for communication through the Internet, we proposed an
anonymous message communication system using mobile devices through the Internet. We expanded the scalability of general
anonymous message communication with the use of mobile devices as a client. The goal is to improve the quality of the system. Other
than the actual system, this paper also proposed a procedure of minimizing traffic for the mobile devices by using an intermediate
intelligent MPFS. The implementation of this system can definitely give a rise in various consulting and message sharing applications in
anonymous communication scenario.
REFERENCES
[1] David Chaum: Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms, Communications of the ACM, 24(2), 84–90, 1981.
[2] Reiter, M., Rubin, A.: Crowds: Anonymity for Web Transactions, ACM Transactions on Information and System Security 1(1), 66–92, 1998.
[3] Anonymizer, http://www.anonymizer.com/.
[4] Berthold, O., Federrath, H., Kospell, H.: Web MIXes: A System for Anonymous and Unobservable Internet Access, International workshop on
Designing privacy enhancing technologies: design issues in anonymity and unobservability, 115-129, 2001.
[5] Shields, C., Levine, B. N.: A Protocol for Anonymous Communication Over the Internet, ACM Conference on Computer and Communications
Security, 33–42, 2000.
[6] Goel, S., Robson, M., Polte, M., Gun Sirer, E. Herbivore: A Scalable and Efficient Protocol for Anonymous Communication, Cornell University
Technical Report 2003-1890, 2003.
[7] Sherwood, R., Bhattacharjee, B., Srinivasan, A.: P5: A Protocol for Scalable Anonymous Communication, 2002 IEEE Symposium on Security and
Privacy, 58–70, 2002.
[8] David Chaum.:The Dining Cryptographers Problem: Unconditional sender and recipient untraceability, Journal of Cryptology, 1(1), 65–75, 1988.
[9] Syverson, P., Goldschlag, D., Reed, M. Onion Routing Access Configurations, DARPA Information Survivability Conference and Exposition, 34-40,
2000.
[10] Dingledine, R., Mathewson, N., Syverson, P.: Tor: The Second-Generation Onion Router, 13th USENIX Security Symposium, 21–21, 2004.
[11] Mixmaster Protocol Version 2: http://www.ietf.org/internet-drafts/draft-sassaman-mixmaster-03.txt.
[12] Danezis, G., Dingledine, R., Mathewson, N.: Mixmion: Design of a Type III Anonymous Remailer Protocol, 2003 IEEE Symposium on Security and
Privacy, 2–15, 2003.