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@example.com 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 based systems such as, Crowds, Anonymizer, Onion routing, WebMIXes, and Hordes. Broadcast protocols and DC-Nets including Herbivore, and P5 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. Mixes David Chaum’s seminal paper in 1981 defined a method to anonymously send pieces of mail to other participants using “Mixes” . 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” 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”. 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 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 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 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 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 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 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 . 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 relies on DC-nets (Dining Cryptographer Networks) 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 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. Message Ks Message Encrypted with a session key, Ks The Session Key Ks is encrypted Kpu Ks 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 Message reply from User 1 to User 2 User 2 to User 1 ISP ISP ISP ISP Anonymous communication Message Message server User 2 User 1 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  David Chaum: Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms, Communications of the ACM, 24(2), 84–90, 1981.  Reiter, M., Rubin, A.: Crowds: Anonymity for Web Transactions, ACM Transactions on Information and System Security 1(1), 66–92, 1998.  Anonymizer, http://www.anonymizer.com/.  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.  Shields, C., Levine, B. N.: A Protocol for Anonymous Communication Over the Internet, ACM Conference on Computer and Communications Security, 33–42, 2000.  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.  Sherwood, R., Bhattacharjee, B., Srinivasan, A.: P5: A Protocol for Scalable Anonymous Communication, 2002 IEEE Symposium on Security and Privacy, 58–70, 2002.  David Chaum.:The Dining Cryptographers Problem: Unconditional sender and recipient untraceability, Journal of Cryptology, 1(1), 65–75, 1988.  Syverson, P., Goldschlag, D., Reed, M. Onion Routing Access Configurations, DARPA Information Survivability Conference and Exposition, 34-40, 2000.  Dingledine, R., Mathewson, N., Syverson, P.: Tor: The Second-Generation Onion Router, 13th USENIX Security Symposium, 21–21, 2004.  Mixmaster Protocol Version 2: http://www.ietf.org/internet-drafts/draft-sassaman-mixmaster-03.txt.  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.
Pages to are hidden for
"Quality approach of anonymous message communication through .doc"Please download to view full document