Complete SIP message obfuscation: PrivaSIP over Tor
Georgios Karopoulos Alexandros Fakis Institute for the Protection and Dept. of Information and Security of the Citizen Communication Systems Engineering Joint Research Centre University of the Aegean [email protected] [email protected] Georgios Kambourakis Dept. of Information and Communication Systems Engineering University of the Aegean [email protected]
Abstract 1 Introduction
The demand for private communications is high Anonymity on SIP signaling can be achieved either by among businesses, activists, journalists, military, and the construction of a lower level tunnel (via the use of law enforcement [1]. Nowadays, telecommunication SSL or IPSec protocols) or by employing a custom- providers increasingly shift their business model to- tailored solution. Unfortunately, the former category wards Voice over IP (VoIP) communications which are of solutions present significant impediments including more flexible and inexpensive, but with more security the requirement for a PKI and the hop-by-hop fash- and privacy issues compared to traditional communica- ioned protection, while the latter only concentrate on tions. One of the most prominent protocols support- the application layer, thus neglecting sensitive informa- ing multimedia services is the Session Initiation Proto- tion leaking from lower layers. col (SIP) [2], which is an application layer, text-based, To remediate this problem, in the context of this pa- signaling protocol responsible for session management. per, we employ the well-known Tor anonymity system Despite its popularity, SIP still suffers from privacy is- to achieve complete SIP traffic obfuscation from an at- sues, two of the most notable of which are (a) user iden- tacker’s standpoint. Specifically, we capitalize on Tor tity, and (b) IP address disclosure. Since SIP signaling for preserving anonymity on network links that are con- messages are in plaintext, an eavesdropper can acquire sidered mostly untrusted, i.e., those among SIP prox- sensitive data such as: communicating parties’ names ies and the one between the last proxy in the chain and and affiliations, IP addresses and hostnames, and SIP the callee. We also, combine this Tor-powered solution Uniform Resource Identifiers (URIs). The SIP header with PrivaSIP to achieve an even greater level of pro- fields that reveal these details are mainly From, To, tection. By employing PrivaSIP we assure that: (a) the Contact, and Call-ID. An example of a SIP mes- DRAFTsage header format is presented in Table 1; here some first hop in the path (i.e., between the caller and the out- bound proxy) affords anonymity, (b) the callee does not data like branch and tag values were omitted for know the real identity of the caller, and (c) no real iden- readability. tities of both the caller and the callee are stored in log Apart from SIP signaling messages, the architecture files. We also evaluate this scheme in terms of perfor- of the protocol per se is also another source of problems. mance and show that even in the worst case, the latency That is, SIP can be employed in either client/server or introduced is not so high as it might be expected due to Peer-to-Peer (P2P) architectures; in both cases the par- the use of Tor. ticipation of intermediary servers complicates the pri-
1 cation. Tunneling of the UDP traffic through Tor does Table 1: SIP message header format not really solve this issue because the traffic would be INVITE sip:[email protected] SIP/2.0 encapsulated in TCP. The latency induced by Tor is also Via: SIP/2.0/UDP pc8.agn.org;branch=... known to be quite heavy as the system relays and mixes Max-Forwards: 70 its traffic via multiple nodes. To: Al
2 vaSIP [6, 7], an identity protection framework for SIP. Proxy share a password, which is used for Digest au- An alternative method could be [8], which was pub- thentication, this password can also be used as a key lished after we finished our work and we did not had (or as a key seed or master key) for the encryption of the time to evaluate it. the user ID with AES. PrivaSIP-RSA uses the Caller PrivaSIP is an application-layer protocol, whose Proxy’s and the Callee Proxy’s public keys to encrypt main idea is that each end-user’s real ID should be in- the caller user ID and Digest username, and the callee dividually encrypted in a way that it can be recovered user ID respectively. PrivaSIP-ECIES works in a simi- only by entities that need to do so in order for SIP pro- lar way with the difference of using Elliptic Curve cryp- tocol to operate correctly. In this way, untrusted proxies tography. or malicious users performing traffic analysis, will not The cost that comes along with PrivaSIP is negligi- be able to eavesdrop or even recover from the corre- ble concerning the privacy features offered, when sym- sponding ciphertext the real ID of the user. This way, metric cryptography is used. Nonetheless, as argued a basic level of unlinkability (of SIP transactions made in [6, 7], a user may perceive a latency ranging between by the same user in the course of time) can be retained 0.5 to 2 secs for the first SIP message when asymmetric as well. There are two versions of PrivaSIP one can use, cryptography is chosen, depending on the server load. depending on his needs for privacy: In subsequent SIP messages this time penalty can be minimized provided that some caching method is used • PrivaSIP-1: providing caller identity privacy for the correspondence between real and encrypted IDs. • PrivaSIP-2: providing caller and callee identity In any case, the aforementioned latency occurs only privacy. during the setup phase of the call.
The first version, PrivaSIP-1, provides only identity privacy for the person making the call. This is achieved 3 Tor operation by encrypting the username of the caller and using the created ciphertext on every SIP message that will be ex- The Onion Router (Tor) [5] capitalizes on the onion changed between the caller and the callee. To avoid routing [9] mechanism to deliver a low-latency Inter- personal information leakage, the display name field net networking protocol designed to anonymize the data on the SIP message is removed. The second version, relayed through it. As a result, Tor is also employed as PrivaSIP-2, provides identity privacy for both the caller a powerful weapon against Internet censorship carried and the callee. In PrivaSIP-2 the caller’s SIP application out by governments or by private organizations on be- encrypts his username and the username of the callee, half of others. BitTorrent and HTTP are well-known while removing the display names that appear in all SIP to use Tor services to enhance their level of anonymity. messages. PrivaSIP also varies in the encryption meth- Tor traffic passes through a large number (more than ods that it employs; a user can choose between symmet- 5,000) of relays that are distributed globally and op- ric or asymmetric cryptography. To highlight this flex- erated by volunteers. Instead of directly communicat- ibility, different implementations have been previously ing with a network entity (e.g., a web server), a “Tori- presented involving symmetric, traditional asymmetric fied” application channelizes its traffic through other and Elliptic-curve cryptography: Tor nodes (also known as circuit), thus hiding the end- user’s IP address from externals as well as intermedi- • Symmetric cryptographic algorithm ate Tor nodes. Note that due to the use of encryption along the virtual pathway all the intermediary Tor nodes – PrivaSIP-1 using AES DRAFTare only aware of their predecessor and successor in the • Asymmetric cryptographic algorithms path, but no other nodes in the circuit. In this respect, Tor’s main purpose is to protect users’ location and us- – PrivaSIP-1 or -2 using RSA age data from eavesdropping and/or traffic analysis at- – PrivaSIP-1 or -2 using ECIES tacks. Tor architecture includes three main entities: The In PrivaSIP-AES, a symmetric cryptographic algo- first one is called Onion Proxy (OP) and runs locally by rithm is utilized, more specifically AES, for the encryp- the end-user whenever a Tor-enabled connection is de- tion of the caller ID. Since the caller and his Home sired. An OP is in charge of administering connections
3 triggered by “Torified” user applications and setting up 4 SIP Torification circuits. On the other hand, the Onion Router (OR) has the role of an intermediary node in the circuit. There- In this section we explain how the combination of Pri- fore, it is responsible for relaying information arriving vaSIP with Tor can be highly profitable in terms of pre- from other onion proxies or routers. The communica- serving end-users’ privacy. tion between ORs (as well as between OPs and ORs) is protected by means of a TLS tunnel. OPs and ORs 4.1 Issues with PrivaSIP share a session key used to protect the exchanged data. That is, an OP creates a circuit gradually by establish- PrivaSIP provides a more advanced level of privacy ing a symmetric key with each OR in the circuit. Thus, compared to plain SIP; however, due to its application- a circuit is built hop-by-hop, always commanding the oriented nature it is not a complete solution. The main currently endmost node in the circuit to add one more issue is that, while real user IDs are concealed, IP ad- hop. The third entity is that of the Directory Server (DS) dresses of communicating users are still visible since used to support Tor network by providing proxies with they are needed for the proper SIP message routing. An- a current list of the available routers as well as the short- other issue is that end-users’ domains are visible for the term onion keys that must be used per router to manage same reason, but this is rather minor since domains can the establishment of circuits. also be derived from IP addresses. After an OP retrieves from the DS the list of avail- able ORs it proceeds by randomly selecting a set of ORs 4.2 PrivaSIP over Tor forming the circuit between the sender and destination node. Given that each OR owns a public/private key The aforementioned issues of PrivaSIP led us to employ pair (onion key), the OP will establish an ephemeral Tor to alleviate them. In the rest of the text when we session key with each OR in the circuit by means of use the term “PrivaSIP”, we refer to PrivaSIP-2 which a Diffie-Hellman handshake. After that, the sender is obfuscates both the caller and the callee’s real IDs. The ready to initiate anonymous communications with the advantages of using PrivaSIP over Tor are briefly the receiver. All information entering a circuit is in fixed- following (we will further elaborate on them later in this size cells (data-packets) of 512 bytes. Tor operation section): mandates all the cells transmitted from an OP toward the receiver to be repeatedly enciphered under the ses- • third parties cannot mount traffic analysis attacks sion keys shared with ORs consisting the circuit. This • real user IDs are not leaked to intermediate SIP means that each OR in the path only removes a single proxies layer of encryption by decrypting the incoming cell us- ing the session key shared with the initial sender. As • log files in intermediate SIP proxies do not contain soon as the cell content is being validated it is forwarded real user IDs to the subsequent OR in the path. This way no individ- ual relay is aware of the complete path a given cell has • the real caller ID is unknown to the callee followed. The OR lying in the edge of the circuit will eventu- • the real caller ID is unknown to the callee’s proxy ally remove the last layer of encryption having the cell • the real callee ID is unknown to the caller’s proxy containing the original application data forwarded to the receiver. Similarly, the reverse path is followed in the • user authentication and accountability (e.g., for opposite direction. EachDRAFT cell arriving from the previous billing purposes) are still supported OR in the path, gets enciphered under the session key shared with the destination (sender) and is transmitted A prototype architecture of our proposed scheme is to the next hop in the circuit. The destination needs to shown in Figure 1. Here we assume that Client A re- repeatedly decrypt the cell to acquire the original data. sides in a corporate network and his SIP proxy is placed To increase its performance, Tor is also known to em- in the same local network as well. Thus, it is not nec- ploy the same circuit for sessions that take place within essary to protect this communication with Tor; we do the same 10 mins. This quality is of certain significance protect, however, the real IDs of the end-users from in our case and it is discussed further in Section 5. other corporate users by employing PrivaSIP. The traffic
4 data (a) between Proxy A and Proxy B, and (b) between Another point of discussion is related to the deploy- Proxy B and Client B, are protected from third parties ment of the proposed solution and its compatibility by Tor. To avoid the Tor exit node eavesdropping issue, with existing SIP infrastructures. Regarding PrivaSIP, it is required that Proxy B and Client B act as Tor re- some modifications are needed in SIP proxies and user lays, so that no plaintext SIP messages are transmitted clients in order to properly encrypt/decrypt obfuscated through the Internet. user IDs; more information on this point can be found in [6, 7]. Tor, on the other hand, acts as a proxy so it can be transparently utilized by end-users and servers; it is, however, needed to be installed and configured so that the callee’s SIP proxy and client act as Tor relays.
4.3 Privacy analysis As discussed in the previous section, the qualities of Tor can be of great value in SIP. More specifically, enabling SIP over Tor communications can lead to a robust cross- layer privacy preserving system capable of dealing with a variety of major privacy attacks [5, 10, 11]. First off, message size types of attack are avoided. This is be- cause Tor mandates the use of fixed-length cells. As a result, an observer is unable to infer any usable in- Figure 1: Prototype PrivaSIP over Tor architecture formation when examining a cell’s length. Moreover, due to the use of encryption, no one is in position to One major question related to our choice of proto- change a cell’s coding when in transit through the Tor cols is why someone would use PrivaSIP over Tor and network. This particular quality also works in favor of not plain SIP. The short answer is because PrivaSIP of- protecting from packet context oriented attacks. Sim- fers a more advanced level of privacy. First of all, since ply put, the IP address, application port, etc., included the first hop in the path (i.e., between the caller and the in the TCP header remain well-hidden. In any case, all proxy in the corporate network) is not protected by Tor, connections in Tor use TLS link encryption based on PrivaSIP assures that the real IDs of the communicating ephemeral keys. This way, connections between entities parties are not revealed to the rest of the corporate users. enjoy perfect forward secrecy, preventing medication of Tor protects the traffic data from third parties; with Pri- data while in transit. For the same reason, attacks aim- vaSIP we also hide the real ID of the caller from the ing on masquerading an OR are also considered unprac- callee. Last but not least, SIP messages are delivered tical. as plaintext to intermediate SIP proxies; by employing Also, observers are blocked from spying on which PrivaSIP we allow their proper routing while protecting circuit a given cell is intended for. Periodical and in- the real IDs of the communicating parties at the same dependent rekeying of TLS ephemeral keys imposed by time. This also has an implication on proxies’ log files, Tor reduces the impact of a potential key leak. Attacks where no real user IDs are stored. This works in favor of based on collusion of nodes are also considered highly unlinkability as well, i.e., certain SIP transactions can- unpractical. This stands true as all information enter- not be correlated in such a way that can be traced back ing the Tor network is routed through a private network to the same user. DRAFTpathway of ORs (circuit) where each relay only knows Apart from the aforementioned advantages, the main the previous and the next relay. Lastly, Tor is known to benefit of our proposal is the protection of traffic data generally defeat privacy attacks based on message tim- offered by Tor. Essentially, Tor solves the inherent is- ing. In fact, to our knowledge, this issue has been al- sues of PrivaSIP as presented in the previous section. ready investigated in [12, 13, 14, 15]. Specifically, the Thus, it prevents traffic analysis attacks by obfuscating work in [12] argues that a timing attack in Tor is fea- traffic data like SIP end-users’ IP addresses and domain sible under the global attacker model. However, to be names. A more detailed analysis of Tor’s benefits can profitable, this attack requires the attacker to be able to be found in the next section. eavesdrop on all network nodes. Moreover, the authors
5 in [13, 14] bring into the foreground some viable attacks and server traffic and cannot be directly compared with under the weaker threat model (no global adversary). the present results. These attacks however are known to be repelled if using supportive protection schemes such as adaptive 5.1 Architecture padding or the insertion of cover traffic in a way that the network cannot perceive between the different network The architecture used for the experiments is a simplified streams [13, 14, 15]. Last, but not least, Tor gives the interpretation of a real case, described in the following opportunity to the end-user to also join Tor and become and depicted in Figure 1. Alice (Client A) wants to call an OR by itself (either a relay or a bridge). This case Bob (Client B). Note that Alice is registered to a domain presents two significant advantages. First, it is antic- served by SIP Proxy A which is situated within a cor- ipated to gradually reduce the latency perceived by all porate network. Since Alice and SIP Proxy A belong the nodes, and also results to a safer network. Secondly, to the same network, which is considered trusted in the it would end up in a situation in which a malicious user normal case, we avoid using Tor on this link. However, would not be able to distinguish which connection is Tor is employed outside the corporate network, that is, initiated as a user and which as an OR. both between the two SIP proxies, and SIP Proxy B and A last remark here, also succinctly pointed out in the Bob. previous sections, is that the boundaries of the system First, we describe the underlying hardware used in do not enjoy protection by Tor. That is, the endmost our testbed. All servers and clients were hosted on Vir- communication link between the last OR and the callee tual Machines. To host those VMs we chose Okeanos1, cannot be protected, and thus an ill motivated entity a cloud service provided for the Greek Research and could eavesdrop on the packet content. In our case, this Academic Community. With Okeanos, we had the abil- problem is tackled by requiring the callee’s SIP proxy ity to create VMs with dual core processors, 4 GB of and client to act as Tor relays so that the packet con- RAM, and 60 GB storage. Okeanos provides high speed tent is not revealed to third parties. For the other end of Internet connection to its users which can reach up to the communication path, i.e., between the sender and 520 Mbps. There is also the possibility to choose be- the OP, it is argued that no protection is required as tween numerous operating systems; for our scenarios an OP runs locally in the caller’s machine. Overall, we chose CentOS 6 for the servers, and Ubuntu 12.04 we can say that the synergistic operation of PrivaSIP for the clients. with Tor assembles a powerful solution that achieves the Both SIP proxies are based on SER 0.9.62, and mod- protection of end-users’ privacy in a cross-layer fash- ified accordingly as in [6, 7] to support PrivaSIP. For ion. Of course, PrivaSIP could be easily co-work with traffic generation on the caller side, SIPp3 was used, other privacy solutions for TCP/IP layer including Mor- along with sipsak4. On the callee side, a modified User phMix [16] and Tarzan [17] ones. Agent (UA) that supports PrivaSIP was used, based on Twinkle software phone5.
5 Performance evaluation 5.2 Results Since Tor is known to cause long delays, our biggest In this section we describe the procedures followed and concern is whether the latency in the proposed system the metrics used during the experiments, as well as the is affordable from the user viewpoint. In the follow- results obtained. First off, Bob’s UA acting as the caller ing sections we present the architecture used in our sends an INVITE message using PrivaSIP-2 to conceal experiments and show thatDRAFT the delay perceived by the both the caller’s and the callee’s IDs using RSA. As a end-users is relatively low, within the range of 1.8 to consequence, the caller first receives back a 100 (TRY- 2 seconds in the worst case. This time penalty is of ING) message followed by a 180 (RINGING) signi- course in absolute relation with the protection of users’ fying that Alice’s phone is ringing. In this context, privacy and more specifically the preservation of their anonymity. As a reference, in previous works [6, 7] the 1https://okeanos.grnet.gr 2 delays were approximately 0.5 second for plain SIP and http://www.iptel.org/ser 3http://sipp.sourceforge.net 1.2 second for PrivaSIP-2-RSA. Those measurements, 4http://sourceforge.net/projects/sipsak.berlios however, were taken with a different hardware setup 5http://www.twinklephone.com
6 we measure the time starting from when the INVITE was send until the RINGING message is being received back on the caller side. This time includes the opera- tions needed for PrivaSIP, as well as delays imposed by Tor. We should note here that we take the worst case scenario for Tor delay. Since Tor utilizes the same cir- Table 2: Range of call delays for plain SIP over Tor cuit for sessions that take place within the same 10 mins Delay (sec) Frequency or so, we force each new call to be placed over a new circuit. 0.6 3 0.7 5 For the sake of comparison, we measured call delays 0.8 2 for two scenarios: (a) plain SIP over Tor, and (b) Pri- 0.9 27 vaSIP over Tor. These two scenarios do not have the 1 43 same level of privacy protection, so they cannot be di- 1.1 18 rectly compared. The reason we chose them is to iden- 1.2 1 tify the sources of delays since more than one protocols 1.3 0 are involved. In each scenario we followed the afore- 1.4 1 mentioned procedure and 100 calls were sequentially produced with the help of SIPp tool. Using Wireshark on the caller’s side we were able to compute all call de- lays. The derived values were rounded to one decimal digit and the frequency per value was counted. For the plain SIP scenario, the results are summa- rized in Table 2 and graphically presented in Figure 2. As it is easily observed from the table, the majority of the delays span between 0.9 and 1.1 seconds. On the other hand, for the PrivaSIP scenario, the results are presented in Table 3 and Figure 3. In this case, the Table 3: Range of call delays for PrivaSIP over Tor majority of the delays are between 1.8 and 2 seconds, leading to the conclusion that the perceived delay from Delay (sec) Frequency the end-users while waiting for the call to be established 1.5 1 is relatively low. What these results show us is that Pri- 1.6 0 vaSIP together with SIP operations adds a delay of ap- 1.7 3 proximately 1 sec to the whole scheme, and the rest is 1.8 26 caused by Tor. Even if the plain SIP scenario has better 1.9 37 performance, the one employing PrivaSIP is preferred, 2 27 since it comes with more advanced privacy preserving 2.1 0 features. In any case, both of these methods can be be 2.2 1 offered to the end-users in an opt-in fashion. 2.3 0 2.4 2 6 Related work 2.5 2 2.6 0 There is one group of mechanisms based on PGPfone 2.7 0 DRAFT6 and its successor, Zfone. Zfone is a software for secure 2.8 0 VoIP communications, using the ZRTP protocol. Zfone 2.9 0 works on top of existing SIP and RTP programs and the 3 1 security it offers is limited to encrypting and decrypting voice packets only. Moreover, it seems that since 2009 its development has stopped.
6http://zfoneproject.com
7 If one of the two users is not a subscriber then the re- spective connection is not encrypted. Its operation is 50 based on the ZRTP protocol and it mostly protects from 40 Man-in-the-Middle (MiTM) attacks without taking care of end-users’ identity privacy. 30 RedPhone9 uses a signaling protocol that is custom 20 to RedPhone and the voice traffic is encrypted using Frequency 10 ZRTP. Its signaling protocol is similar to HTTP and pro- 0 tected by TLS. However, since TLS is used between 0.60.81.01.21.4clients and relay servers, the communicating parties Delay (sec) are identifiable by their IP addresses. Jitsi10, formerly known as SIP Communicator, supports many protocols including SIP, Jabber/XMPP (GoogleTalk and Face- book), MSN, ICQ etc., and offers call encryption to SIP Figure 2: Frequency of call delays for plain SIP over and those protocols that are based on Extensible Mes- Tor saging and Presence Protocol (XMPP) through ZRTP. For SIP, secure signaling with the use of TLS is also supported. Nevertheless, the same problem still stands; the communicating end-users are identifiable by their IP 40 addresses. The Open {Secure, Source, Standards} Tele- 11 30 phony Network (OSTN) project is foreseen to provide an end-to-end secure VoIP service based on open stan- 20 dards. SIP signaling is protected with SSL, while voice Frequency 10 traffic is secured by ZRTP. As with other solutions, the issue with this system is that end-users are not protected 0 1.51.71.92.12.32.52.72.9 by traffic analysis attacks. Delay (sec) There is also a group of solutions that are based on proprietary protocols and/or are unsupported, like Speak Freely12 (since 2002) and the “I Hear U” (IHU) project13 (since 2008). GSMK CryptoPhone14 provides Figure 3: Frequency of call delays for PrivaSIP over Tor a range of hardware and software products including mobile, landline and satellite phones, softphones, and even a crypto PBX. It is a proprietary solution and the The system that is closer to our proposal is TOR- source code is offered for download; however, it seems Fone7, which is a product that is independent from the outdated since the last version is from 2003, and no safe Tor Project. It is based on Tor and PGPfone and since claims can be made about its secure operation. Mum- 15 the connection between users passes through six tran- ble is an open source, voice chat software mainly in- sit nodes located anywhere in the world the voice la- tended for use while gaming. Communication to and tency can reach 4-5 secs. Apart from that, the main from the server is protected through encryption which is issue with TORFone is that it is based on outdated se- mandatory and cannot be disabled. The voice as well as curity software (PGPfone is unmaintained since 1999) the control channel, which transports chat messages and and it does not use standardDRAFT protocols, like SIP. Silent other non-time critical information, are both encrypted. Circle8 is a company offering secure communications to The latter is protected by TLS making IP address dis- its subscribers. The connection between the caller and 9 the Silent Network, as well as the connection between https://github.com/WhisperSystems/RedPhone/wiki 10https://jitsi.org the Silent Network and the callee, are both encrypted 11https://ostel.me provided that both users are subscribers of the service. 12http://www.speakfreely.org 13http://ihu.sourceforge.net 7http://torfone.org/index.html 14http://www.cryptophone.de 8https://silentcircle.com 15http://mumble.sourceforge.net
8 covery of end-users possible. brings along compensate for this penalization (which Nautilus Secure Phone16 protects only voice traf- after all concerns the establishment of the call and not fic and does not deal at all with traffic analysis at- the multimedia session itself). tacks. Web Real-Time Communication (WebRTC)17 is This work can be used as a reference towards build- an API definition from the W3C Consortium to enable ing anonymization solutions that consider privacy in a browser-to-browser applications including voice calling cross-layer fashion. This is not only bound to VoIP and video chat. It does not explicitly tackle with IP pri- applications but also for other protocols as that in vacy since in “WebRTC Security Architecture”18 it is [18], where its authors have already identified this need stated that it is out of scope. and provide the necessary background towards a full- fledged solution. Our intention is to extend this work by conducting 7 Conclusions further experiments approximating real SIP traffic and finding ways to lessen this ∼ 2 secs overhead through Few will argue that the preservation of user anonymity proper optimizations. Future work could also consider is an important issue which pertains to almost any pro- more complex VoIP infrastructures and scenarios with tocol or technology deployed in the wired or wireless more users, services and intermediate SIP elements. internet. When it comes to VoIP, it is for sure that not only a broad category of users would highly ap- preciate anonymous communications, but also several Acknowledgment providers would value such a service towards expand- ing their market share. Unfortunately, all works pro- This paper is part of the 5179 (SCYPE) research posed so far in the literature - either standardization ef- project, implemented within the context of the Greek forts or custom-made solutions - tackle this problem in Ministry of Development-General Secretariat of Re- an unsatisfactory way. Some of them focus solely on the search and Technology (GSRT) funded program “Ex- application layer, thus neglecting sensitive data leaking cellence II/ Aristeia II”, co-financed by the Euro- from lower layers, while others propose inflexible or pean Union/European Social Fund - Operational pro- difficult to deploy mechanisms that either require ex- gram “Education and Life-long Learning” and National ternal infrastructures or are in direct contrast with user funds. accountability. On the other hand, secure tunneling of VoIP traffic by means of, say, an SSL connection is con- sidered mostly unpractical. References Compelled by this fact we came with the idea of taking advantage of the well-known Tor anonymization [1] G. Kambourakis, “Anonymity and closely related system to achieve complete SIP message privacy. While terms in the cyberspace: An analysis by example,” this may be seem straightforward it is quite tricky be- Journal of Information Security and Applications, cause the majority of SIP apps are designed to operate 2014. over UDP for increased performance. Tor on the other hand works solidly over TCP and introduces additional [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, delays due to the use of public-key cryptography, and A. Johnston, J. Peterson, R. Sparks, M. Handley, complex segmentation, encryption, and routing of its and E. Schooler, “SIP: Session Initiation Proto- messages via a random set of nodes. Therefore, the col.” RFC 3261 (Proposed Standard), June 2002. main impediment here is performance in terms of ser- Updated by RFCs 3265, 3853, 4320, 4916, 5393, vice times. In this context,DRAFT our experiments employing 5621, 5626, 5630, 5922, 5954, 6026, 6141, 6665, different setups showed that SIP over Tor is quite af- 6878. fordable as it adds a time penalty that fluctuates between [3] J. Peterson, “A Privacy Mechanism for the Ses- 1.8 and 2 secs in the vast majority of cases. Overall, we sion Initiation Protocol (SIP).” RFC 3323 (Pro- think that the extra security and privacy gains that Tor posed Standard), Nov. 2002. 16http://nautilus.berlios.de 17http://www.webrtc.org [4] C. Shen and H. Schulzrinne, “A VoIP privacy 18http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-08 mechanism and its application in VoIP peering for
9 voice service provider topology and identity hid- [14] R. Wiangsripanawan, W. Susilo, and R. Safavi- ing,” arXiv e-print 0807.1169, July 2008. Naini, “Design principles for low latency anony- mous network systems secure against timing at- [5] R. Dingledine, N. Mathewson, and P. Syverson, tacks,” in ACSW Frontiers, pp. 183–191, 2007. “Tor: The Second-generation Onion Router,” in Proceedings of the 13th Conference on USENIX [15] J. Feigenbaum, A. Johnson, and P. F. Syverson, Security Symposium - Volume 13, SSYM’04, “Preventing active timing attacks in low-latency (Berkeley, CA, USA), pp. 21–21, USENIX Asso- anonymous communication,” in Privacy Enhanc- ciation, 2004. ing Technologies, pp. 166–183, 2010.
[6] G. Karopoulos, G. Kambourakis, S. Gritzalis, and [16] M. Rennhard and B. Plattner, “Practical E. Konstantinou, “A framework for identity pri- anonymity for the masses with morphmix,” vacy in SIP,” Journal of Network and Computer in Financial Cryptography, pp. 233–250, 2004. Applications, vol. 33, pp. 16–28, Jan. 2010. [17] M. J. Freedman and R. Morris, “Tarzan: a peer-to- [7] G. Karopoulos, G. Kambourakis, and S. Gritzalis, peer anonymizing network layer,” in ACM Confer- “PrivaSIP: ad-hoc identity privacy in SIP,” Com- ence on Computer and Communications Security, puter Standards & Interfaces, vol. 33, pp. 301– pp. 193–206, 2002. 314, Mar. 2011. [18] F. Pereniguez-Garcia,˜ R. Marin-Lopez, G. Kam- bourakis, A. Ruiz-Martinez, S. Gritzalis, and [8] N. Vrakas, D. Geneiatakis, and C. Lambri- A. Skarmeta-Gomez, “Kamu: providing advanced noudakis, “Obscuring users’ identity in voip/ims user privacy in kerberos multi-domain scenar- environments,” Computers & Security, vol. 43, ios,” International Journal of Information Secu- no. 0, pp. 145 – 158, 2014. rity, pp. 1–21, 2013. [9] P. Syverson, G. Tsudik, M. Reed, and C. Landwehr, “Towards an analysis of onion routing security,” in Designing Privacy Enhanc- ing Technologies (H. Federrath, ed.), vol. 2009 of Lecture Notes in Computer Science, pp. 96–114, Springer Berlin Heidelberg, 2001.
[10] N. Hopper, E. Y. Vasserman, and E. Chan-tin, “How much anonymity does network latency leak?,” in Proceedings of the 14th ACM Confer- ence on Computer and Communications Security, pp. 82–91, ACM, 2007.
[11] O. Berthold, H. Federrath, and M. Kohntopp,¨ “Project “anonymity and unobservability in the in- ternet”,” in Proceedings of the Tenth Conference on Computers, Freedom and Privacy: Challeng- ing the Assumptions, CFP ’00, (New York, NY, USA), pp. 57–65, ACM,DRAFT 2000. [12] G. Danezis, “The traffic analysis of continuous- time mixes,” in Privacy Enhancing Technologies, pp. 35–50, 2004.
[13] V. Shmatikov and M.-H. Wang, “Timing analy- sis in low-latency mix networks: Attacks and de- fenses,” in ESORICS, pp. 18–33, 2006.
10