A message comes in from the anonymous user's UAC to the Anonymizer's UAS. The message is then anonymized: the From header is changed, among others, and sent out from the Anonymizer's UAS to the remote UAC.
sipanon: A SIP Anonymizer
AbstractThe expanding popularity of the Internet presents new possibilities for communication, but also new implications for the users' privacy. In this paper, we present a software program for anonymizing media exchanges made with SIP (Session Initiation Protocol). |
Note: in this
document, we universally employ the male pronoun "he" to refer to
humans. This is to avoid awkward locutions as "s/he" or "they", not to
imply that all users of SIP or sipanon need be male.
There are many reasons why a user on the Internet might wish to remain anonymous. Perhaps he is reporting on illegal activities of his employer, or wishes to avoid some restriction placed on his network activity, or simply wishes a new identity unlinked to "real life." Whatever the reason, the apparently faceless nature of the Internet has created a desire in many individuals for anonymous communication.
However, to even the casual investigator, it is often possible to determine the identity of an Internet user. Every email message or request on the World Wide Web carries with it a number of identifying data. Included among these are the Internet Protocol (IP) address of the user and the version of client software he is using. For this reason, many Internet developers and entrepreneurs have set up anonymizing services designed to hide the identity of their users.
Perhaps the most sophisticated is the network of anonymous remailers
for Internet e-mail. A fairly detailed high-level introduction to the
topic is available in the FAQ for the
alt.privacy.anon-server
newsgroup. The basic idea is to take an email message and encrypt it
with several "layers" of encryption, each layer decryptable only by
one particular remailer. The message is then passed through each
remailer in turn, only being finally decrypted at the last remailer in
the "chain," which then sends it on to the final recipient, any
identifying details of the original sender having been long since
removed.
There are two main problems with directly adapting this approach to other types of Internet services. The first is the high degree of latency involved. This is not a significant problem for e-mail, where delays of several hours or even days are often acceptable, but would presumably make more interactive services all but useless. The second is the one-way nature of communication. With the anonymous remailer network, the anonymity of the sender is total: there is no way for anyone to respond to his messages. With most other Internet services, however, there must be some way for a second-party user or server to get information back to the anonymous user.
Another set of anonymity-providing services are the "proxy servers" which grant anonymity on the World Wide Web. A list of these is available from the Open Directory Project. Two of the best known are Anonymizer.com and SafeWeb (which recently folded). These services generally work either through the proxy mechanism specified in HTTP (RFC 2616), or by rewriting URLs such that a link to, e.g., http://www.example.com might be rewritten as https://anonproxy.net/get/www.example.com. In almost all cases, SSL encryption is used so that the contents of connections cannot be intercepted between the user and the proxy.
SIP, the Session Initiation Protocol, is specified by RFC 2543 as a way for users and devices to share telephone calls and other forms of media. It is described as a:
control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution.
In this paper, we will present a system for anonymizing calls signaled with SIP.
The SIP anonymizer is basically two user agents (a User Agent Client
and User Agent Server) coupled back to back (a "B2BUA"). Signaling
data flows as in the diagram:
A message comes in from the anonymous user's UAC to the Anonymizer's
UAS. The message is then anonymized: the From header is changed, among
others, and sent out from the Anonymizer's UAS to the remote UAC.
The Anonymizers maintains a store of mappings between "real" SIP addresses and "anonymous" ones. Thus, whenever a request comes in destined for an "anonymous" address, the translation is the reverse of the normal case and the From address is maintained, while the To address is set to the corresponding "real" address.
Whenever a response is received to a previously forwarded request, it is of course forwarded in the proper direction. The anonymizer also sometimes must generate responses of its own; for example, a remote address might be unresolvable, in which case the user will be notified.
sipanon
sipanon is a pure Java application, and relies on Pallavi
Nayak's Java SIP library. If you have not already done so, you must
first obtain and compile this library and make sure that
siplib.jar is in your CLASSPATH.
Then, unpack the sipanon source and change to the
directory which will be created. Execute the build.sh
shell script which you will find there. (A build.bat is
provided for compilation under Windows; however, that script does not
have the additional options described below.)
If you wish to create Javadoc class documentation in order to
compiling the code, pass the -d option to
build.sh. The -c option cleans output files,
the -p option pretty-prints the source code, and the
-h displays a terse summary of these options.
Once you have compiled the code, you must customize the
sipanon.properties file to your liking. This file
contains a number of parameters which control the behavior of
sipanon, including the port on which sipanon
will listen and the backend which will be used to store the anonymous
data (choice of in-memory HashMap-based or SQL-based
using JDBC).
If you select the SQL/JDBC backend, you must first install and
configure the proper JDBC driver. See the documentation of your driver
for the precise format of the JDBC URL which you must give to
sipanon. Please also make sure that the JDBC Driver class
is available; this can be accomplished by putting the JDBC .jar file
in the jre/lib/ext/ subdirectory of your JDK
installation. Also, a file sipanon.sql is provided to
help you create the requisite database table.
Then, to run the code, make sure that sipanon.jar,
siplib.jar, and sipanon.properties are in
the same directory, and write at the command prompt:
$ java -jar sipanon.jar
Assuming you did not make any mistakes in configuration,
sipanon will then be running and ready to provide
anonymous SIP service!
Currently, the only way to stop sipanon is to press ^C at
the terminal or kill the java process with some other signal.
sipanon From The User's Perspective
From the perspective of an end-user, sipanon is very easy
to use once some admin has set it up. In the simplest configuration,
the user simply sets his SIP UA to use the anonymous server its
default proxy. In this case, sipanon automatically
generates a random SIP address of the form
anon-xxxx@hostname, where
xxxx are four random letters. sipanon is
careful to make sure that no two different users accidentally end up
with the same randomly-generated address.
After setting up his UA, the user may then proceed to make calls (SIP
INVITE request) or terminate them (BYE) as usual, with the knowledge
that his IP address and "real" SIP address are hidden from his
peer. sipanon also supports the sending and receiving of
Instant Messages using the MESSAGE command, though there is no support
for presence applications. An example of receiving a call from an
anonymous user is shown here:
Note: Because sipanon does not yet have
the capability to anonymize RTP streams, it is not yet possible to
actually converse through sipanon except by using Instant
Messages. Only the call setup/teardown is fully supported. However,
SDP session descriptions are anonymized by having all identifying IP
addresses removed.
Sometimes, a user will wish to hide his IP address but still use a
"known" SIP address to communicate with another
party. sipanon supports a mode of operation to facilitate
this.
If a client UA sends a REGISTER message to sipanon, the
address in the REGISTER message will become the client's new anonymous
ID, replacing the default randomly-generated address. In addition,
sipanon can be configured to forward notice of these
registrations to some central directory server. So, a user who wishes
to use a publicly-known SIP address without revealing his IP address
can do so.
Some suggestions for further work on sipanon are
presented here. We pay special attention to "attacks" that might be
used to compromise a user's anonymity, and how they might be defeated
in the future.
Perhaps the most critical piece of work remaining to be done is the
implementation of a RTP forwarded/anonymizer, so that actual
conversations can be held, not just connections and
disconnections. This could be integrated with the existing code in the
NewCallHandler.anonymizeSDP() method.
It may be useful in some applications to have sipanon
communicate with the "outside world" (i.e., non-anonymous users)
through another proxy server. However, while the Java SIP library does
support the use of a proxy, it only does so in an "all-or-nothing"
sense -- i.e., all packets must be sent through a proxy, or none can
be. If the communication with anonymous clients goes through the
proxy, then the proxy will obviously be able to trivially spy on the
identities of those clients. So, we choose to never use a proxy. In
future implementations, perhaps this problem could be remedied by
overriding the Call class of siplib.
Currently, it is trivial for anyone who has access to the network
segment containing sipanon to spy on the network traffic
and guess the identity of any anonymous users. The easiest way to do
so would be to compare messages coming into sipanon with
those coming out, and note any similarities. Since SIP messages are
not encrypted, this is trivially easy to do. A possible remedy to this
problem would be to examine the work being done on TLS/SSL over SIP and
integrate with it when that work is complete.
A related problem is that since so few users currently use SIP in
general, and even fewer use sipanon, it may be possible
to simply guess who is who. The solution to this problem is not as
obvious, and probably can best be remedied only by increasing the
total volume of calls.
The debug output of sipanon compromises all users'
identities. It is thus recommended that the DEBUG
constant in the SipAnon class be set to
false for production use.
It should also be noted that, when using the database backend for
sipanon, anyone who can read the database has immediately
compromised all users' identities. Solutions to this problem are not
obvious and should be examined.