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 <sip:[email protected]> In this context, the paper at hand attempts to answer From: Geo <sip:[email protected]>;tag=... two basic questions: Is SIP over Tor affordable in terms Call-ID: [email protected] of service time? And if so, to which network hops CSeq: 314159 INVITE should be preferably Tor activated in order to achieve Contact: <sip:[email protected]> a fair balance between the level of anonymity and the Content-Type: application/sdp Content-Length: 142 time penalty introduced? Also, what is the additional delay if one considers to even anonymize network links that cannot be covered by Tor (think of the first hop between the caller and the outbound SIP proxy or the vacy problem. Previous work on these issues [3, 4] has registrar). shown that several header fields can provide private data To shed light on the aforementioned questions we im- to eavesdroppers. While for some data privacy protec- plement a proof-of-concept SIP over Tor system and tion is straightforward if the user selects not to provide conduct measurements to assess its performance in them, other header data cannot be omitted since they are terms of service times. Also, we combine this sys- needed for the correct routing of SIP messages to their tem with a purely application layer anonymization so- final destination. lution for SIP to make a decision whether an end-to-end Ideally, any complete anonymity solution for SIP preservation of anonymity is affordable. The results we should be designed and provided in a cross-layer man- obtained seem quite promising showing a latency in the ner. That is, while SIP operates at the application layer, vicinity of 2 secs across all scenarios. It should be noted several other sensitive information regarding its signal- here that our solution, as well as the aforementioned de- ing inevitably leak from lower layers. For example, lay, concerns SIP signaling only; thus, media protection while it is possible to conceal the IDs of the communi- should be considered separately. cating parties by applying, say, a pseudonymity scheme As discussed in a following section, previous work to Via and From headers, the IP addresses of both ends in the same topic is fragmentary and has only touched are available to an observer by just tracking the headers upon these issues not considering SIP at all. Therefore, of the IP packets conveying SIP messages. to our knowledge, this is the first work that elucidates on This fact motivated us to think of taking advantage the foregoing issues and provides real results that can be of the services of a generic anonymization system with used as a reference towards building truly anonymous the aim to apply an holistic anonymity solution for SIP. VoIP systems. On the one hand, such a solution seems promising as The rest of this paper is structured as follows. The anonymization systems like Tor [5] are self-reliant, i.e., next section briefly covers PrivaSIP [6, 7], an applica- normally their operation does not hinge on the pro- tion layer solution to preserve anonymity in SIP. Sec- tocols of upper layers, hence they can be straightfor- tion 3 offers a basic background on Tor operation. The wardly combined with them. Moreover, as discussed joint operation of Tor with PrivaSIP to achieve a high further in Section 4.3, such a system is able to protect level of user anonymity is addressed in Section 4. Sec- SIP signaling from a plethora of other type of attacks tion 5 reports on the experimental testbed, the scenar- including timing and collusionDRAFT ones. However, on the ios, and the results we obtained when running PrivaSIP negative side, taking Tor as an example, the problem over Tor. The last section concludes the paper and gives with SIP is that currently Tor only supports TCP for pointers to future work. its transport layer. As a result, although RFC 3261 [2] requires all SIP entities to mandatory implement both UDP and TCP, many real-world VoIP applications rely 2 PrivaSIP solely on UDP for latency reasons. So, at least for the time being, this is a serious impediment for VoIP users In the search of ways for establishing a system that to enjoy strong anonymity to real-time voice communi- would protect SIP end-users’ privacy, we chose Pri- 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.