End-to-End Detection of Caller ID Spoofing Attacks

Hossen Mustafa, Member, IEEE, Wenyuan Xu, Member, IEEE Ahmad-Reza Sadeghi, Member, IEEE and Steffen Schulz

Abstract—Caller ID (caller identification) is a service provided by telephone operators where the phone number and/or the name of the caller is transmitted to inform the callee who is calling. Today, most people trust the caller ID information and some banks even use Caller ID to authenticate customers. However, with the proliferation of and VoIP, it is easy to spoof caller ID information by installing a particular application on the or by using service providers that offer Caller ID spoofing. As the phone network is fragmented between countries and companies and upgrades of old hardware is costly, no mechanism is available today to let end-users easily detect Caller ID spoofing attacks. In this article, we propose a new approach of using end-to-end caller ID verification schemes that leverage features of the existing phone network infrastructure (CallerDec). We design an SMS-based and a timing-based version of CallerDec that works with existing combinations of landlines, cellular and VoIP networks and can be deployed at the liberty of the users. We implemented both CallerDec schemes as an App for Android-based phones and validated their effectiveness in detecting spoofing attacks in various scenarios.

Index Terms—End-user Security; Caller ID Spoofing; !

1INTRODUCTION the US government passed the legislation Truth in Caller ID Act of 2009 [5] making it illegal to transmit “What’s worse than a bad authentication system? misleading or inaccurate caller ID information with A bad authentication system that people have the intent to defraud. learned to trust” [1]. However, the legislation does not stop the misuse or Caller ID services transmit the phone number fraud, and today spoofing caller IDs has become much and/or the name of a caller to the recipient (callee) easier, because many VoIP providers allow anyone to as caller ID intending to provide informed consent to claim arbitrary caller IDs through VoIP client software the callee before answering calls. However, Caller ID (e.g., x-lite [6]), and fake ID providers allow their has been increasingly used to authenticate the iden- customers to claim any caller ID by simply dialing a tities of callers, or to verify their physical locations special phone number or by utilizing readily available in several systems, ranging from 9-1-1 emergency Apps on smartphones (e.g., Caller ID Faker [7]). Thus, services, automatic telephone banking systems, credit in this paper, we focus on detecting caller ID spoofing card activation systems, to voicemail services. Unfor- attacks. tunately, existing caller ID protocols do not provide Caller ID spoofing is possible because caller IDs real authentication and hence are untrustworthy for are transmitted in plaintext with no authentication authenticating callers’ locations or identities, because mechanisms in place. When a call is routed between caller IDs are vulnerable to spoofing attacks; i.e., an different carriers, the callee’s carrier will simply accept attacker can easily send a fake caller ID to a callee. the caller ID claimed by a caller’s carrier. Given the This vulnerability has already been exploited in a lack of authenticating the caller ID between carriers, variety of misuse and fraud incidents: In the US, caller IDs could be trustworthy if (a) the telephone thousands of people were victimized by credit card service providers do not manipulate caller IDs, (b) the fraud with the help of caller ID spoofing [2], causing telephone infrastructure is tightly controlled, and no a loss of more than $15 million dollars annually; caller intruders could tap into the infrastructure to create an ID spoofing is also a common technique used for arbitrary caller ID. These conditions were true in the , which is an attempt to trick an emergency early days as the telephone network used dedicated service with false reporting of an incident — for in- lines operated by a monopoly. Today, with current stance, police officers were tied-up in responding to a converging phone/data networks and diversity of non-existent robbery reported by pranksters [3]; drugs telephone service carriers, neither holds any more. were misused as a result of spoofed pharmacists’ Moreover, telephone carriers may not be able to solve phone numbers [4]; other incidents include identity the problem even if they can redesign the protocols. theft, purchase scams [1], etc. Due to the proliferation This is because the entire telephone infrastructure of detrimental incidents caused by caller ID spoofing, comprises several telephone carriers with their own 'LJLWDO2EMHFW,GHQWL¿HU7'6& ‹,(((3HUVRQDOXVHLVSHUPLWWHGEXWUHSXEOLFDWLRQUHGLVWULEXWLRQUHTXLUHV,(((SHUPLVVLRQ 6HH KWWSZZZLHHHRUJSXEOLFDWLRQV VWDQGDUGVSXEOLFDWLRQVULJKWVLQGH[KWPO IRU PRUH LQIRUPDWLRQ 2 trusteds domains, and a carrier can at most verify calls originated in its own network but not from other net-  works. To the best of our knowledge, no mechanism      is currently available to users for detecting caller ID      spoofing without answering the call first or without       a special interface (and agreement) provided by the  carrier, as used by commercial solution TrustID [8].

Challenges and contributions. We propose to de-    sign end-to-end solutions to detect caller ID spoofing.   Designing such a practical mechanism is challeng- ing: First, only limited information and resources are     available at end users. The route of call signalling is Figure 1: An example telephone network architecture, unknown. Second, a large deviation from the regu- where different carriers are connected using peering archi- lar calling procedure is unlikely to be accepted by tecture. Here, each telephone network follows there own most people. Thus, naive solutions such as rejecting protocol for internal communication, but uses SS7 or VoIP an incoming call and then calling back, are not an for inter-network communication. option. The detection mechanisms should be mostly networks, and Voice over Protocol (VoIP) automated and require little user input. Third, a few providers. In all these telephone networks, creating legitimate services provided by telephone compa- a phone call typically involves two types of channels: nies allow the caller IDs to be different from the an end-to-end control channel for signalling, and an calling numbers, making those caller IDs appear to end-to-end voice channel for transmitting voice data. be spoofed. However, those scenarios should not be In addition, all telephone carriers support caller ID classified as caller ID spoofing attacks. We address all which works as follows. When a caller dials a num- these requirements and design two end-to-end caller ber, the carrier first authenticates the caller, and then CallerDec ID verification schemes that we call : generates or looks up the associated caller ID. Finally, (1) SMS-based CallerDec uses SMS services, and (2) the caller ID is forwarded to the callee, possibly from Timing-based CallerDec utilizes a covert timing chan- one carrier to another. nel that is constructed between the caller and the In the following, we discuss the popular caller callee leveraging the traditional phone call services. ID standards used within each type of carrier and We summarize our contributions as follows: between different carriers with the goal of under- CallerDec i. We propose , end-to-end caller ID standing the feasibility of injecting spoofed caller IDs. verification schemes that require no modification to the existing telephone infrastructure. CallerDec can 2.1 Traditional Telephone Network detect spoofing even if a caller ID is not in the contact 2.1.1 Architecture list or is unreachable. Both the PSTN and cellular telephone networks gener- ii. We present two use cases of CallerDec, one for ally follow a hierarchical architecture [9], as illustrated an emergency call scenario (e.g., 9-1-1 call) and the in Figure 1. The upper level entities control the lower other for a regular call scenario. In both cases, the end level ones in both networks. users, (e.g., a 9-1-1 service or an individual customer) In PSTN when a customer subscribes for the tele- can utilize CallerDec to verify caller IDs. phone service, a switch port in the local exchange iii. We implement CallerDec as an App for Android- (LE) is assigned with the corresponding caller ID, based smartphones where we tackle several technical i.e., the customer’s phone number, possibly with a challenges caused by the limited API support for name. When a customer dials a number, the LE sends controlling calls. We examine the CallerDec per- the pre-configured caller ID in the outgoing call. On formance in various scenarios, and show that it can the other hand, in Cellular networks, each customer detect spoofed caller ID effectively and efficiently (i.e. gets a Subscriber Identity Module (SIM) and inserts incurring almost no extra energy overhead). We stress it in a mobile station (MS). An MS is authenticated that, while we implemented CallerDec on Android based on the SIM information. When an MS makes a smartphones as a case study, our solution can also be phone call, the call setup process always goes through integrated in any other telephone devices. BTS, BSC, and MSC. Then, the MSC obtains the caller The above contributions apply to both SMS-based ID associated with the MS from the Home Location and timing-based CallerDec. Both mechanisms use Register (HLR) and encodes it in a control packet for end-to-end principle but different communication call setup. channel and protocol for verification. 2.1.2 Protocols 2BACKGROUND There are several caller ID standards in PSTN, e.g., Three categories of telephone carriers are in service: Bellcore FSK, SIN227, DTMF, V23, ETSI FSK, etc. We Public Switched Telephone Network (PSTN), cellular introduce one popular standard, BellCore FSK [10], 3

30B of 55H 130+/-25ms 1B 1B 15-18B 4B (a) Channel Seizure Signal Carrier Signal Msg. Type Msg. Length Data Checksum Figure 2: Message formats for Bellcore where the caller ID is in the Data field. while skipping the rest, since they work in a similar 2.2.2 Protocols manner. Developed by Bell Communications Research, Both SIP and H.323 have built-in support for caller ID. Inc., Bellcore FSK is the most widely-used caller ID SIP uses the From field in the INVITE packet to send standard (e.g., North America). At the signal level, the the caller ID, and the caller ID can be any ASCII char- caller ID information is modulated using Frequency acters with an arbitrary length. For instance, the caller Shift Keying (FSK), and the signal is transmitted ID in SIP has the form sip:callerID@ip_address between the first and second phone ring, while the and is typically encapsulated in SIP packets in plain- telephone unit is still in an onhook state (i.e., still text. Although secured SIP is available to encrypt ringing). Figure 2(a) shows the message format of caller IDs, they are not authenticated [18]. Similar to Bellcore FSK, whereby the Data field contains the SIP, caller ID is also transmitted in plaintext in H.323 caller ID in an ASCII format. The first 8 bytes of during the call setup. the Data field record the time of the day, and the remaining 7-10 bytes are used for caller ID. 2.2.3 Feasibility of Caller ID Spoofing In Universal Mobile System Unlike PSTN or scenarios, in VoIP (UMTS) [11] and Wide-band Code-Division Multiple the caller ID originates at the client end; i.e., the clients Access (W-CDMA) [12], the caller ID is encoded in call could generate control packets with arbitrarily chosen setup packets (in the Calling Party BCD Number caller IDs. Most VoIP software provides an interface field) using the Binary Coded Decimal (BCD) format allowing a caller to specify his/her caller ID for each and has a variable length of 3-14 bytes [13]. It is phone call, making caller ID spoofing trivial, e.g., x- possible that a call is set up without caller ID, and the lite [6]. In fact, many VoIP carriers manipulate caller Presentation Indicator field is used to indicate ID to avoid long distance charge [19]. whether caller ID is present in the packet. 2.1.3 Feasibility of Caller ID Spoofing 2.3 Network Interconnection Protocols In addition to the aforementioned standards in PSTN, Two carriers are interconnected using a peering archi- all other standards transmit the caller ID informa- tecture (Figure 1) via Signaling System 7 (SS7) [20] or tion in plaintext. However, it is not easy to launch VOIP after agreements between the carriers [21] [22]. the attack inside PSTN because the caller ID signal In the following, we discuss how a call is routed and is generated automatically by the LE, based on the caller ID is forwarded between carriers. pre-configured information. Such information cannot Call Routing. In telephone systems, phone num- be changed by unauthorized entities, because the bers are assigned based on geographic locations to switches (LEs) are generally kept in secured cabinets, discriminate between local and long-distance calls. inaccessible to the general public. On the other hand, In the US, each carrier is assigned a unique prefix in Cellular Networks, 3GPP specification has security in each geographic location by the North American mechanisms which include MS authentication, ran- Numbering Plan Administration (NANPA) [23] and dom session keys and SIM security [14]. To the best the call routing is done based on prefix-matching. For of our knowledge, no caller ID spoofing attacks on example, in Washington, the 360-269 prefix is assigned 3GPP protocol have been reported. to AT&T and 360-270 to Sprint. When a customer calls 2.2 Voice over Internet Protocol 360-269-XXXX, the originating carrier must forward the call to AT&T1. 2.2.1 Architecture Caller ID Forwarding. When a caller and a callee VoIP technology takes advantage of IP where both have subscribed to different carriers, the call goes voice and control data are transmitted in IP pack- through either an SS7 or VoIP. The originating carrier ets. Unlike PSTN or cellular networks, VoIP usually sends the caller ID as part of the control packets. follows a flat/p2p architecture [15] where all the In both cases, the receiving carrier passes the caller clients and servers must be connected to the Internet. ID data to the callee without any modification or The control channel always follows the client-server validation. Hence, caller ID is not verified in either model but the voice channel between a caller and a case. callee may use a direct connection. For the call setup, VoIP uses protocols such as Session Initiation Proto- Feasibility of Caller ID Spoofing. In SS7 or VOIP, col (SIP) [16] or H.323 [17]. Irrespective of the used there is no caller ID verification mechanism between protocol, each customer is assigned a user name and carriers along with other vulnerabilities [24] [25]. So, a password for authentication and billing purposes, 1. Unless the phone number is ported, i.e., a customer of carrier A but the customer can often set up any caller ID for an switches service to carrier B and still uses the same phone number. outgoing call. In this case, the call will be routed to the carrier B instead of A. 4 it is possible for an attacker to get connected with   a carrier using either SS7 or VoIP, and then exploit        the lack of caller ID authentication between carriers to      spoof caller ID. Such an attack, while valid, is costly         and complex to carry out because the attacker has to           establish an SS7/VoIP connection with a carrier, which      requires the attacker to complete an interconnection     agreement with the carrier, to install necessary hard- ware and software, to pay a premium, etc. Thus, it is Figure 3: An illustration of how a fake ID provider spoofs a not for casual adversaries with a limited budget. caller ID leveraging the loophole in network interconnection protocols. 2.4 Summary Nuance Cafe [27]) allow their subscribers to select It is difficult to launch caller ID spoofing attacks their own caller IDs and will deliver the selected within PSTN or cellular networks, but it is possible caller IDs for their subscribers regardless of their by exploiting VoIP. Additionally, an adversary can intention. Because these providers connect to major spoof caller ID by exploiting the lack of caller ID telephone carriers via SS7 or VoIP protocols [28], the authentication between carriers. downstream telephone carriers will simply accept any caller IDs, including the spoofed ones. 3CALLER ID SPOOFING ATTACKS Caller ID spoofing is defined in the US legislation 3.3 Spoofing via VoIP Services act [5] as: A caller ID spoofing attack is a malicious Many VoIP carriers allow their customers to specify action that causes any caller identification service to their own caller ID, and will forward the caller ID knowingly transmit misleading or inaccurate caller to the callee’s carrier without modifications. An ad- identification information with the intent to defraud, versary can subscribe to a VoIP carrier that allows cause harm, or wrongfully obtain anything of value. caller ID manipulation and can either use VoIP client This definition makes it difficult to detect caller software or a VoIP phone to claim arbitrary caller IDs. ID spoofing, since there are a few standard, non- malicious telecommunication services that result in a 3.4 A Mismatched Caller ID but not Spoofing mismatch of the displayed number and should not be The caller ID blocking services and Primary Rate In- classified as caller ID spoofing. terface (PRI) lines generate a mismatched caller ID, In this section, we first discuss spoofing attacks that but should not be classified as caller ID spoofing. For can be carried out in different telephone setups, and caller ID blocking service, a carrier will transmit the then discuss scenarios that should not be identified as text BLOCKED or UNAVAILABLE instead of the real spoofing attacks. caller ID to the callee. 3.1 Spoofing via Fake ID Providers PRI lines are designed for business organizations that want to support multiple simultaneous calls (i.e., Fake ID providers offer caller ID spoofing services. 32 channels for an E1 line [29]) while sharing one They establish SS7/VoIP connections with various single caller ID for all their phone lines. In a PRI telephone carriers (e.g., AVOICS [22]), and act as system, each phone line inside an organization is intermediary between attackers and victims to relay connected to the PRI line through a Private Branch caller IDs specified by its customers (attackers in this Exchange (PBX), which assigns the same caller ID to case). Fig. 3 illustrates an example, where an attacker all outgoing calls. The mismatched caller IDs in PRI (Eve) tries to call the victim (Bob) faking Alice’s caller lines are different from caller ID spoofing because the ID. First, Eve calls the fake ID provider, and supplies caller ID associated with a PRI line is officially owned Bob’s phone number as the destination number and by the business organization and once assigned, and Alice’s phone number as the desired spoofed caller the caller ID cannot be changed without the permis- ID. Then, the fake ID provider establishes a call to Bob sion from telephone carriers. Our CallerDec will with Alice’s caller ID, and finally connects Eve with recognize both blocking services and PRI lines as non- Bob once the call is answered. Eve can subscribe to a spoofing cases. fake ID provider and launch spoofing attacks towards any victim from any type of phone, provided that the ALLER POOFING ETECTION fake ID provider is connected to the victim’s network. 4C ID S D 4.1 System Model 3.2 Spoofing via Automated Phone Systems We will refer to Alice as the caller, Bob as the callee, Automated phone systems provide Interactive Voice and Eve as the attacker who tries to spoof Alice’s Response (IVR) services for purposes of marketing, caller ID while calling Bob. We note that, Alice may survey, etc. Some service providers (e.g., Voxeo [26], not be in Bob’s contact list (unknown), and Alice’s 5 number could be invalid (unreachable). Since the over a control channel, and create a voice channel after verification operation is preformed automatically, we the call is answered. Control channel is ideal for caller expand our definition of the names and refer Alice, ID verification, since a caller cannot manipulate them Bob, and Eve to their devices as well. We envision that in a traditional telephone network but can acquire the Alice, Bob, and Eve can be a smartphone, a mobile status of the phone calls, e.g., through distinguishable phone, a PSTN phone, a VoIP phone, or an automated ringback tones (e.g., busy) or voicemail greetings. ii. system (e.g., bank), etc. Regardless of the type, we Short Message Service (SMS). SMS enables a user assume that Bob has a strong incentive to verify the to send short text messages to another user with a caller ID of a caller, e.g., he can be a bank that needs to mobile, VoIP [30], or a PSTN line [31], even though verify the caller ID of a customer. Thus, Bob integrates not all PSTN phones support SMS. Given a recipient CallerDec in his device (e.g., by installing an app number, the telephone operator will route SMS to the in a smartphone, or by upgrading the firmware of a intended destination via control channels, unless the PSTN phone, or by updating the software of a Private destination is unreachable. In such a case, the operator Branch Exchange (PBX)2, etc). In comparison, Alice can notify the sender of the failed SMS delivery. may or may not integrate CallerDec. Leveraging either SMS or the call setup proce- We consider that telephone carriers are trusted; they dure, we design two types of CallerDec for caller route outgoing calls to dialed numbers and do not ID verification, an SMS-based CallerDec and a collude with Eve in any way. Thus, Eve cannot capture Timing-based CallerDec. Overall, CallerDec or inject any type of packets into the telephone net- works as follows. When Bob receives a phone call, works. Neither can she answer or reject a call unless CallerDec will automatically initiate the caller ID she is the callee. Additionally, we assume that Alice verification by sending a challenge to Alice over one does not collude with Eve and will not help Eve with of the end-to-end communication services, e.g., either caller ID validation. Otherwise, we consider that Eve SMS or a phone call. Then, the challenge will be is authorized to use Alice’s caller ID. delivered to Alice if it is reachable. Once the chal- lenge reaches Alice, the CallerDec at Alice’s end 4.2 Requirements will respond to Bob whether she has indeed made Security. The detection scheme should guarantee that the phone call. Collaboratively, CallerDec on both an honest caller can prove the validity of his/her ends can achieve automated caller ID verification. We caller ID, and an adversary cannot pretend to be will discuss details of timing-based CallerDec in calling from an arbitrary number. Section 5 and SMS-based CallerDec in Section 6 . Compatibility. The detection solution should only change telephone terminals but not the existing tele- 5TIMING-BASED CALLERDEC phone infrastructure, because adding any extra hard- 5.1 An End-to-End Covert Channel ware to the existing infrastructure or introducing new The basic idea of timing-based CallerDec (hereafter protocols to the core telephone networks would be a T-CallerDec) is to create a trusted covert channel great expense to all telephone carriers. between Alice and Bob, i.e., the channel allows Al- Usability. The detection strategies should be user- ice and Bob to perform a challenge-response but it friendly, i.e., they should require almost no effort from is inaccessible to Eve. Forming such an end-to-end either a caller or a callee, and should not change covert channel is tricky as T-CallerDec considers a common procedures of phone calls. telephone network as a black box and the covert chan- Efficiency. The detection scheme should have low nel has to be compatible with all types of telephone computational overhead so that it can be integrated networks. Thus, we utilize the traditional phone call into telephone terminals that have limited resources. service to form an end-to-end covert channel between Alice and Bob. 4.3 End-to-End Detection Scheme Overview Essentially, the covert channel is built on top of How can CallerDec, a program running on a tele- the control channel that is used for call signaling in phone, verify who is indeed calling? Similar to the a traditional telephone network where no users can design principle of TCP in Internet, CallerDec con- manipulate control channels directly. Nevertheless, the siders a telephone network as a black box and rely on calling parties can acquire the status of the phone call the feedback of end-to-end communication services (e.g., answered/rejected). Since Eve cannot control or for verification. In total, we have identified two ser- access the calls between Alice and Bob, they form a vices as the basis for CallerDec. trusted covert channel by initializing, answering, or i. Traditional phone calls. Given a number, the rejecting phone calls between them. operator will try to establish a phone call for the caller When Bob receives a call from Alice, he will initi- ate a new call to Alice after a “starting verification” in- 2. Business organizations use PBX as phone exchanges using PRI. PBX offers internal phones service, multiple simultaneous calls with terval and Alice will respond to the new call according the same caller ID, etc. to whether she is indeed calling Bob. We refer to the 6

(a) normal scenario

Figure 4: Call establishment and verification process: Alice is calling Bob who starts verification call after τsv interval, and Alice rejects the call after τv interval to prove her caller (b) spoof a reachable user ID. We use the solid rectangles to indicate the original call operations conducted by a user or her phones, and use the dotted rectangles to represent the operations performed by T-CallerDec. We note that the messages exchanged between Alice, Bob, and carriers are triggered by the opera- tions and generated by the underlying telephone protocols. (c) spoof an unreachable user

first call from Alice to Bob as the original call denoted T-CallerDec Co Figure 5: Simplified protocol and outcomes by A→B and the second call from Bob to Alice as in a normal scenario, and in attack scenarios. Cv the verification call denoted by B→A. Bob determines Co whether the original call A→B is indeed from Alice when Alice dials Bob’s number, a SETUP request by examining the following information that is sent is sent to carrier-A. Then, carrier-A sends carrier- over the control channel: (a) how Alice responds to the BanInitial Address Message(IAM), which is Cv verification call B→A, and (b) how long Alice waits equivalent to SETUP. After carrier-B sends a SETUP before responding. For instance, if Alice is calling Bob, to Bob, he responds with an ALERTING message and Bob will observe that she rejects the verification call starts the ringing. The ALERTING message indicates Cv τ B→A after a predefined interval v. Because timing that Bob is available and the ringing has started. τ estimation of Alice’s waiting time v is performed at At this point, carrier-B sends carrier-A an Address Bob’s side and its accuracy depends on the packet Complete Message(ACM). Subsequently, carrier-A delivery delays inside telephone networks, we use sends Alice an ALERTING message, and Alice starts to a probabilistic classifier to achieve high estimation play the ringback tone. We note that all messages (e.g., accuracy. As we discuss in Section 5.4.3, we use a SETUP) are automatically generated by the underlying Bayesian classifier [32] that is suitable to resource telephone protocols. constrained phone terminals. The idea of forming a covert timing channel be- 5.2.2 T-CallerDec Verification Protocol tween Alice and Bob is simple. However, several open Continuing with the example shown in Fig. 4, we in- problems remain, such as: (a) Bob must be able to troduce T-CallerDec verification protocol using the τ estimate Alice’s waiting time v at his end, (b) the following scenarios: (a) normal scenario: Alice is indeed protocol must handle all possible scenarios, i.e., caller calling Bob and both of them installed T-CallerDec, ID is valid, caller ID is spoofed, Alice does not support (b) attack scenario - spoof a reachable user: Eve is T-CallerDec, Bob’s verification call goes to Alice’s spoofing Alice’s number, and Alice is reachable with voicemail, etc. We address all these issues in the T-CallerDec installed, (c) attack scenario - spoof an design of T-CallerDec. In the following, we first unreachable user: Eve is spoofing Alice’s number, and discuss regular call setup process in Section 5.2.1, Alice is unreachable, and (d) not-supported scenario: then present T-CallerDec protocol in Section 5.2.2, Alice does not install T-CallerDec. discuss two use cases of T-CallerDec in Section 5.3, Normal Scenario. As shown in Fig. 4, after receiv- and perform security analysis in Section 5.4. Co ing a phone call A→B from Alice, Bob will perform 5.2 Protocol Description verification as follows. i. After an interval T1 = τsv, Bob initiates o 5.2.1 Regular Call Setup: C → Cv A B a verification call B→A to Alice that triggers a Without loss of generality, we consider the case that sequence of six messages: SETUP, IAM, SETUP, Alice and Bob belong to carrier-A and carrier-B re- ALERTING, ACM, and ALERTING. Cv spectively, and the two carriers communicate through ii. When Alice receives the verification call B→A, SS7. We depict a regular call setup procedure in Fig. 4: she will reject it after an interval T2 = τv. As a result, 7

Bob will receive a REJECT message from carrier-B Cv indicating that B→A has been rejected. iii. After receiving a REJECT message, Bob will measure the time difference between the moment of sending the SETUP message and receiving the REJECT message (denoted as T3 in Fig. 4). Examining T3 using the classifier, Bob will verify whether Alice (a) emergency call scenario has waited for the expected time τv before rejecting Cv verification call B→A. Once the waiting time is ver- ified, Bob will further check the status of the original Co Co call A→B.If A→B is still active, Bob will conclude Co that the caller ID is VALID.If A→B is no longer active, then there is no need to continue with the verification process. (b) regular call scenario Both τv and τsv are predefined parameters and are used to differentiate whether Alice supports Figure 6: Two use cases of T-CallerDec; it follows the same T-CallerDec verification protocol for both cases, because the verification or not. When Alice (the phone) does procedure is independent to whether the original call is not support T-CallerDec, Alice (the person) may answered or not. answer the verification call. Thus, the values of τv τ and sv should be chosen so that a user is unlikely Spoof an Unreachable User. In this scenario, Eve τ to respond to a call after a v interval yet keeping the is calling Bob, and Alice is unreachable, e.g., her verification delay small. In addition, we define two phone can be powered off, out of the coverage range, τ τ parameters ( v and sv) to emphasize their indepen- or Alice is an invalid number. In such cases, as shown Cv dence. In practice, they can have the same values, e.g., in Fig. 5(c), the verification call from Bob B→A will τ = τ =0. v sv We postpone the discussion on why it be directed immediately to either Alice’s voicemail τ T3 Cv is feasible to estimate v based on in Section 5.4.3. or carrier’s voicemail. When B→A goes straight to As we discussed in Section 4.1, Eve cannot inject voicemail, it contradicts to the fact that “Alice” was packets to the traditional telephone networks, neither calling Bob. Based on the timing estimation Bob can can she reject or answer the verification call directed detect that the verification call went to voicemail and to Alice. Thus the verification process between Bob will terminate the verification call before it reaches the and Alice is protected, and the response from Alice is voice recording, and thus no voicemail is left. Finally, trusted. We show a simplified version of this scenario Bob concludes that the caller ID is SPOOFED. in Fig. 5(a). Not-supported Scenario. Now, we briefly discuss Spoof a Reachable User. Eve is calling Bob and the case when Alice does not support T-CallerDec. Cv Alice is reachable, as shown in Fig. 5(b). Similar to the In this case, the verification call B→A will be con- normal scenario, Bob will first initiate a verification sidered as a regular call. Since T-CallerDec is not Cv call B→A to Alice once he receives the call from installed, Alice (the person) may reject the call after a Cv Eve. Alice will treat Bob’s verification call B→A as random interval, answer the call, or even not respond Co a regular call B→A since she is not calling Bob. As a to the call. Regardless of the response, T-CallerDec result, instead of rejecting it, she will initiate a new can handle all cases. Detail analysis of not-supported Cv τ verification call A→B after an interval sv. When scenarios can be found in our previous work [33]. Bob identifies that Alice has initiated a verification We envision that after T-CallerDec is sup- Cv call A→B, he concludes that Alice was not calling ported by all telephone devices, we can eliminate him. Instead, Alice is trying to verify Bob’s verification NOTSUPPORTED. Cv call B→A. After confirming that Alice’s verification Cv τ 5.3 Use Cases call A→B was initiated after a duration of sv, Bob will conclude that the caller ID is SPOOFED. He will We envision two use cases of T-CallerDec: emer- Cv Co terminate his verification call B→A ( B→A for Alice) gency call, where calls need to be answered immedi- Cv and reject Alice’s verification call A→B after an in- ately, and regular call, where Caller IDs are expected τ 3 terval v . Consequently, from Alice’s point of view, to be verified before calls are answered. In both cases, Cv she detects that her verification call A→B has been T-CallerDec follows the same verification protocol, Co rejected and the original call B→A she received is because verification relies on an end-to-end covert terminated. Then, she concludes that Bob may have channel that is independent to whether the original received a call that had spoofed her caller ID and call is answered or not. terminates her own verification. 5.3.1 Emergency Calls

v 3. Bob rejects CA→B after τv to indicate that he did initiate the In emergency call cases, such as 9-1-1 services, caller v verification call CB→A. ID verification is performed in parallel to the voice 8 call. As shown in Fig. 6(a), the callee (e.g., an 9- 5.4.2 Special Cases 1-1 service) answers the call from Alice upon ring- We discuss three special cases whereby the claimed ing, and T-CallerDec starts the verification process caller ID is different from the true ID. Yet they should in the background. After the caller ID is verified, not be tagged as spoofed caller ID. T-CallerDec will notify the callee, and sensitive i. Blocked caller IDs. T-CallerDec depends on information may be exchanged thereafter. Since the the caller ID of an incoming call for verification and duration of 9-1-1 calls are reported to be between 1-2 T-CallerDec cannot initiate verification process if minutes on average [34] [35], the verification results caller ID is BLOCKED or UNAVAILABLE. However, shall be returned before the call is terminated. if Bob supports the mechanism to uncover caller 5.3.2 Regular Calls ID of such calls, then T-CallerDec can be inte- grated seamlessly. For instance, the commercial ser- Eve may spoof Alice’s caller ID with the goal of vice TrapCall5 claims to have the ability to unmask winning a chance talking to Bob, who would refuse blocked numbers, and T-CallerDec can utilize such otherwise (e.g., Eve may be an unknown number or a service to first unmask the blocked number, and is on Bob’s block list). Thus, in regular call scenarios, then perform caller ID verification if it is needed. T-CallerDec performs the verification before a call The 9-1-1 service also has such capability, and if is answered. As shown in Fig. 6(b), once Bob receives integrated, T-CallerDec can perform caller ID ver- an incoming call, T-CallerDec starts to verify the ification effectively. caller ID and notifies Bob after the verification com- ii. PBX systems. T-CallerDec can be integrated pletes. While T-CallerDec may introduce delay in easily in a PBX system of an organization, e.g., a answering phone calls, it allows users to answer or bank, where T-CallerDec is installed in the PBX reject spoofed calls. and can keep track of the ongoing calls as well as Although the verification protocol is independent their extension numbers. Since such systems generally on the use cases, the number of required concurrent have resources for multiple concurrent calls, they can calls for T-CallerDec depends on the type of use adopt parallel verification, as discussed in use case cases. For regular call cases, Bob only requires one 2 (Section 5.3). Furthermore, if Alice is reachable via call for verification. For emergency call cases, two an extension number of the PBX system and she calls concurrent calls are required since the verification Bob, Bob can verify the caller ID as usual. shall be performed in parallel to the original call. iii. Legitimate caller ID ‘spoofing’. It is possible that Alice intentionally spoofs her own caller ID when 5.4 Discussion calling Bob, e.g., Alice uses to call Bob, while pretending to call from her cell phone. In this case, 5.4.1 Security Analysis she can control T-CallerDec on her cell phone, and The security of T-CallerDec relies on the observa- thus can proof her identity. We consider this scenario tion that the verification call from Bob to Alice will be as a legitimate caller ID ‘spoofing,’ and T-CallerDec routed to Alice if she is available and to a voicemail will conclude VALID. if she is unavailable, and Eve cannot manipulate the verification call. Based on the choice of use cases, Bob 5.4.3 Race Conditions can determine when to answer a call, e.g., before the In a regular call scenario, both Alice and Bob may caller ID is verified or after. Regardless of when to try to call each other simultaneously. In such cases, T-CallerDec answer a call, Bob can utilize the same both calls will go straight to the voicemail. This is to verify caller ID. because most standards allow to signal at most one In case of spoofing a reachable user (Section 5.2.2), call at a time for each user, i.e., neither Alice nor T-CallerDec equipped with , Alice will treat Bob’s Bob can receive an incoming call while making an verification call as a new call and will initiate a new outgoing one [36]. In this scenario, T-CallerDec is verification call to Bob. Consequently, Bob concludes not triggered. In the case where one of the calling SPOOFED that the caller ID is and Alice will con- parties starts the call earlier than the other, at most SPOOFED clude that Bob received a call. Without one call will go through 6 and T-CallerDec handles T-CallerDec, when Alice receives the verification 4 the case as usual. The party that successfully receives call from Bob , she may answer the call and enter a the call will trigger its T-CallerDec to initiate the SPOOFED proper input which leads Bob to conclude . verification process, and validate the caller ID. If Alice rejects or ignores the call, Bob will conserva- When Eve tries to spoof both Alice and Bob simul- NOTSUPPORTED tively conclude , as discussed in non- taneously, both Alice and Bob will initiate verification supported scenario(b) of Section 5.2.2. The bottom line is that Eve cannot send any signal to convince Bob 5. www.trapcall.com that Alice is calling. 6. Alice can receive a second call while she is on another active call because the call signaling for the active call has ended and the 4. Alice will receive the verification call even if she is on a call already. call waiting protocol kicks in. 9

different users based on their location and time of the day and then, thresholds corresponding to various temporal and spatial combinations can be updated dynamically for better performance. For the training dataset, we recorded the values of T2, T3, time of day (Tday), and status of the verifica- tion call (Scall), i.e., rejected, answered or voicemail. We label each dataset with appropriate class: VALID, SPOOFED NOTSUPPORTED (a) (b) (c) ,or . For each test sample, we employ the following Bayes equation [32] to cal- Figure 7: Three outcomes of the CallerDec: the caller ID is culate the probability of each class, Ci. (a) VALID, (b) SPOOFED, and (c) NOTSUPPORTED.     p(T3,Tday,Scall Ci) p(Ci) p(Ci T3,Tday,Scall)= (1) call to each other. But these calls would go straight p(T3,Tday,Scall) to the voicemail and T-CallerDec will correctly Here, p(Ci) is the probability of Ci in the training conclude SPOOFED. dataset. T-CallerDec classifies the test sample as the class with the highest probability. Thus, based 5.5 Implementation on the estimated duration of T2 and Alice’s action, We implement T-CallerDec on Android smart- T-CallerDec detects caller ID spoofing attacks. phones as a case study. Fig. 7 shows three screenshots 5.5.2 Identify the Status of the Verification Call our implementation. We encountered several chal- lenges during T-CallerDec implementation. Partic- T-CallerDec scheme requires Bob to identify the ularly, T-CallerDec requires to estimate the ringing status of the verification call, i.e., whether the call has duration at the other end, to obtain the status of that been answered, rejected, or directed to the voicemail. call, and to automatically initiate a verification call. This task poses several challenges. Android does not However, Android does not contain APIs for identify- allow users to access call signalling messages during ing the status of an outgoing phone call or estimating call setup. So, to identify the status of the verification the ringing duration at the other end. Neither does call, we utilized system logs. Logs of each Android it allow two concurrent phone calls, and it hides the app are printed in the system shell and T-CallerDec APIs for automating phone calls. We discuss how we continuously monitors real-time logs using Runtime overcome these challenges in our previous work [33]. APIs to identify whether the verification call is rejected, We summarize our approach in the following. answered or went to voicemail. To differentiate between answered and voicemail, T-CallerDec can record 5.5.1 Verify Caller ID Using Timing Estimation voice data using the microphone and identify the pat- One key issue to verify Alice’s caller ID is to estimate terns of voicemail greeting using available tools [37]. her ringing duration (denoted by T2). As shown in If the pattern matches, T-CallerDec has reached the Fig. 4, T2 is the time difference between the mo- voicemail, otherwise the verification call is answered. ments when Alice sends an ALERTING message, and This process is summarized in Table 1. a REJECT message. We found that T3 can be used for estimating T2 and consequently choose it to classify 5.5.3 Initiate the Verification Call caller ID as VALID, SPOOFED,orNOTSUPPORTED. Depending on the number of concurrent phone calls, Unlike the Internet, the round trip time in a telephone two categories of phone services exist: (a) primary network is relatively stable due to the quality of ser- rate interface (PRI) [38] lines, and (b) regular lines vice (QoS) requirements of telephone standards [11] (e.g., a or a residential landline). PRI [12] and the circuit-switched nature of communica- supports multiple concurrent phone calls using the T tion. This makes it possible to estimate 2 using same caller ID. Thus, a second line can be used to T 3. Our experiments also confirm this hypothesis. To initiate the verification call while the first call may be make T-CallerDec compatible to devices with low in progress. Regular end users can dial a secondary computational power, e.g., mobile phones, we choose phone call but at most one call can be active at a Bayesian Classifier [32]. The Bayesian classifier time. For instance, UMTS requires to put an incoming is an efficient method for calculating posterior prob- ability based on prior probability and likelihood in Table 1: Identifying call status using Android system logs the training data. Although the classifier needs prior and matching voicemail patterns. training, our experimental results involving various Call System App & Search String VM geographic locations and time of the day show that Status CallNotifier AudioService Ringer Pattern? the same trained model can be used on different Rejected DISCONNECT - - - Answered - audioOn stopRing No phones for effective classification. We envision that Voicemail - audioOn stopRing Yes new training set will automatically be captured from 10

waiting for the response message. The timer ensures that the verification process does not wait indefinitely for the response SMS, and the verification session will be terminated after a while. We note that telephone operator returns SMS de- livery reports upon requests. For instance, Android phone users can select this option in the SMS settings or insert a special header in every SMS, e.g., *noti# Figure 8: SMS-CallerDec involves performing challenge- for T-Mobile. response between a caller and a callee before a call initiation 3. SMS Response. After receiving the SMS_CHAL in a regular scenario. SMS, Alice replies an SMS Response acknowledging or dis-acknowledging the challenge. In cases that Alice call on hold before initiating a new call [36] and does try to call Bob, she generates a positive-response Android enforces this requirement. As a result, when SMS with the following format. implementing CallerDec in Android, we have to put the incoming call from Alice on hold before initiating SMS_ACK = ACK; F (SMS_CHAL,ACK) (4) the verification call. Furthermore, Android provides Here F is a hash function that will return n-bit no official APIs for putting a call on hold. To overcome hash generated based on nonce, CallerNumber, and the problem, we leverage Android hidden APIs of ACK/NACK. For instance, F can be MD5 [39] or ITelephony interface using java reflection. SHA-1 [40]. In cases that Alice does not intend to call Bob, she generates a negative-response SMS with the 6 SMS-BASED CALLERDEC following format:

In this section, we discuss SMS-based CallerDec SMS_NACK = NACK; F (SMS_CHAL,NACK) (5) (hereafter SMS-CallerDec) which is designed for de- 4. Voice Call. After sending the Response SMS, vices with SMS capability. The idea is that in advance Alice checks SMS delivery status using SMS delivery of a phone call, Bob (the callee’s phone) will send report. If SMS is delivered successfully, she starts the a Challenge SMS to Alice (the owner of the claimed voice call to Bob. When Bob’s phone starts to ring, the caller ID), who will reply with a Response SMS to notification from SMS-CallerDec will be displayed prove her caller ID. so that Bob can make an informed decision, e.g., either answer or reject the call. 6.1 Protocol Description Algorithm 1 shows the pseudo code of As shown in Figure 8, making a phone call with the SMS-CallerDec running at the callee’s (Bob) SMS-CallerDec consists of 4 steps in regular call end. In particular, if the response SMS is received scenario. In emergency call scenarion, the verifica- before a timeout, then Bob checks the correctness tion can be done in parallel to the voice call using of the response by comparing the received response additional SMS channel. Similar to T-CallerDec, with locally calculated hash. He considers caller ID the verification outputs are: VALID, SPOOFED,and VALID for a correct SMS_ACK and caller ID SPOOFED NOTSUPPORTED. for SMS_NACK or an incorrect response SMS.Ifno 1. Call Intent. When Alice wants to make a voice response SMS is received prior to a timeout or ringing, call, she sends a special call-intent SMS to Bob, which then caller ID is considered NOTSUPPORTED. contains a header (IH), the caller ID of Alice (AN) and Bob’s phone number (BN): Algorithm 1 SMS-CallerDec SMS_INTENT = IH; AN; BN (2) Require: INPUT: CN = CallerNumer 2. SMS Challenge. Bob, upon receiving an OUTPUT: SMS_INTENT, sends a Challenge SMS to Alice consists verified ∈{V ALID, SPOOFED, NOTSUPPORTED} PROCEDURES: of a header (CH), Alice’s number (AN), Bob’s number 1: verified = NOTSUPPORTED (BN), and random nonce (N) of m bits (m =128in 2: C = GenerateChallenge(CN) 3: s = SendSMS(C, CN) our systems): 4: if s = failed then 5: verified = SPOOFED SMS_CHAL = CH; AN; BN; N (3) 6: return verified 7: end if If the caller ID is unreachable, e.g., it is an invalid 8: StartT imer(t) phone number, the phone is off or out of service 9: while true do 10: if timeout then region, then the SMS_CHAL will fail to be delivered. 11: return verified In this case, Bob will consider the caller ID SPOOFED, 12: else if ReceivedResponse then 13: verified = V erifyResponse(C, CN) since it contradicts to the fact that Bob just received an 14: return verified SMS_INTENT from ‘Alice’. If the SMS delivery report 15: end if confirms a successful delivery, Bob will start a timer, 16: end while 11

6.2 Security Analysis Phone Configuration: We selected three Android The SMS-CallerDec requires no secret exchange devices and classified them as fast devices or slow beforehand, rather it relies on trusted SMS delivery devices based on the configurations, and the device of the carriers. In a telephone system, when a user specifications are summarized in Table 2. requests to send an SMS, the SMS first goes to an Carriers: We chose some common telephone car- SMS Controller (SMSC) of the carrier through BTS, riers in the USA, which are AT&T, T-Mobile, and BSC, and MSC. Then, it is routed to the destination. SimpleMobile. We used two cases in the experimental Since the network devices are tightly controlled by op- setup: (a) Alice and Bob belong to the same carrier, erators and it is difficult for attackers to compromise, e.g., T-Mobile, and (b) Alice and Bob belong to differ- when Bob verifies Alice, the challenge SMS from Bob ent carriers, e.g., a T-Mobile user calls an AT&T user. will be delivered to Alice, instead of Eve. Time of Day: In total, we measured data at In the following, we discuss SMS-CallerDec se- six different times of the day in four experimental curity in various scenarios. setup: (a) DCFD: Different Carriers and using two Fast Devices, (b) DCSD: Different Carriers and using Normal Scenario. When Alice is equipped with one fast and one Slow Device, (c) SCFD: The Same SMS-CallerDec and calls Bob, she will participate Carrier and using two Fast Devices, and (d) SCSD: in the challenge-response procedure, and make Bob The Same Carrier and using one fast and one Slow conclude that her caller ID is VALID. Device. We set τv = τsv =0seconds in T-CallerDec Spoofing Scenario. When Eve sends a spoofed implementation to minimize verification delay. SMS_INTENT with Alice’s phone number, Bob will receive an SMS_NACK from Alice in response to 7.2 Experimental Data his SMS_CHAL. However, Eve can send a spoofed To analyze the performance of T-CallerDec, we col- SMS_ACK to Bob. Given that SMS_ACK is an n-bit lected more than 3000 instances of calls labelled with hash generated based on SMS_CHAL, the chance of 1 appropriate class, e.g., approximately 1100 VALID, creating a correct SMS_ACK is only n . Thus, Bob will 2 1100 SPOOFED, and 800 NOTSUPPORTED instances. In consider this caller ID SPOOFED. particular, the VALID samples were collected when Not-supported Scenario. If Alice does not sup- Alice was indeed calling Bob, and the SPOOFED sam- port the SMS-CallerDec, SMS-CallerDec at Bob’s ples were collected when Eve spoofed her caller ID. end can identify that the caller ID verification For the NOTSUPPORTED samples, we asked 10 volun- is NOTSUPPORTED at Alice’s end, since neither teers to reject or answer incoming calls at their will. SMS_INTENT nor SMS Response is received. From the mean and standard deviation of the user’s response time, we observed that the average response 5.9 6.3 Implementation time of an incoming call varied from seconds to 10.6 seconds, indicating that it is unlikely to confuse We implemented SMS-CallerDec in Android (ver- the user operation with T-CallerDec responses that sion 2.3.3) and automated all steps. In particular, are triggered with no delay. we used the standard Android SMS API which in- To analyze the performance of SMS-CallerDec, cludes an option to obtain a delivery report for we collected more than 1000 instances of calls labelled each SMS. We added a special HEADER field in with appropriate class, e.g., approximately 400 VALID, each verification SMS so that regular and 400 SPOOFED, and 200 NOTSUPPORTED instances. SMS-CallerDec SMSs are distinguishable. We set In each case, both the caller and callee are static the priority of our SMS-CallerDec app higher than and indoor in approximately 80% of the calls; one of built-in SMS app to make sure that a new SMS is the caller or the callee is mobile and outdoor in the delivered to it first. Upon matching the header, we rest 20% cases. suppress user notification for verification SMS and We divided both the datasets into training and test delete these SMSs from user inbox. We used SHA-1 sets at various proportions p, where p = [0.1 - 0.9]. For hash function to generate 32-bit hash in our imple- instance, with p = 0.1, 10% of the dataset was used mentation and used SMS encoding for transmission. for training and the rest 90% was used for testing. We use accuracy, precision, and recall as the 7EXPERIMENTS metrics for evaluating verification rate where 100% is 7.1 Experimental Setup the desired outcomes for each metric. To evaluate the performance of both CallerDec mecha- Table 2: Configurations of Android devices used in the experiments for CallerDec validation. nisms, we measured end-to-end verification delay and verification rate for the normal and attack scenarios. Device Name Processor RAM Class Additionally, we studied the impact of the phone Google Nexus One 1 GHz 512 MB Fast HTC Sense 1 GHz 576 MB Fast configuration, the carriers, and the time of the day MyTouch 528MHz 192 MB Slow in the verification delay. 12

1 DCSD DOSD 7.3 Performance: T-CallerDec 25 DCFD DOFD SCSD 0.8 SOSD 20 SCFD SOFD 7.3.1 End-to-end Verification Delay. 0.6 15

CallerDec Seconds 0.4 Detail analysis of end-to-end verification 10 Probability delay can be found in our previous work [33]. In the 5 0.2 following, we summarize the analysis. 0 0 8am11am 2pm 5pm 8pm11pm 0 5 10 15 20 In the normal scenario, when caller ID was valid Time of day Delay (sec) and the verification call was rejected after τv seconds, (a) total time during weekdays (b) CDF of delay during weekdays 1 DCSD DOSD the average verification delay was 8.40 seconds with 25 7 DCFD DOFD variance between 0.1-0.3 seconds . The call setup de- SCSD 0.8 SOSD 20 SCFD SOFD lay dominates the delays. For instance, a recent study 0.6 15

reported that call setup in 3G networks is between 4-7 Seconds 0.4 10 Probability seconds on average for various scenarios [41]. 5 0.2 In the spoofing a reachable user scenario, Alice ini- 0 0 8am11am 2pm 5pm 8pm11pm 0 5 10 15 20 tiated a verification call after τsv seconds in response Time of day Delay (sec) to Bob’s verification call. In this case, the verification (a) total time during weekends (b) CDF of delay during weekends was done in 8.35 seconds on average. with a variance Figure 10: Timing analysis for SMS-CallerDec. of 0.1 to 0.3 seconds. Similar to regular scenarios, the call setup delay dominates the end-to-end delay. 7.4 Performance: SMS-CallerDec In the spoofing an unreachable user scenario, Alice’s 7.4.1 End-to-end Verification Delay. phone was turned-off and the verification call went In regular scenario, when the caller and callee be- straight to the voicemail. In this case, the average ver- long to the same operator, the verification process ification delay was less than 2 seconds with a variance was completed within 13.8 seconds on average both less than 0.04 seconds. Note that verification delay is on weekdays and weekends. When the caller and low in this scenario because the call is not routed to the callee belong to different operators, the process its destination since the caller is unreachable. took 16.8 seconds on average on weekdays and 16.5 Although T-CallerDec takes a few seconds for seconds on weekends. As shown in Figure 10, the end-to-end verification, our analysis shows that such verification delay is between 10 and 20 seconds. delay is mainly caused by telephone networks, and However, our mechanism of not affected by such end devices or network loads have minor effects. variance because it relies on the content of the reply However, the verification delay can be hidden in case SMS. We note that SMS delivery delays dominate of emergency calls (Fig. 6(a)) because the verifica- the end-to-end verification delay. Typically, telephone tion is done in parallel to the phone call. Although operators allocate a limited number of channels for T-CallerDec adds delay overhead before a user SMS services, and thus besides the regular network may answer calls in case of regular calls (Fig. 6(b)), the delays, an SMS may be queued in the SMS controller actually experienced overhead should be lower since for an extended period of time, resulting in a long it generally takes a few seconds to answer a call [42]. delay. 7.3.2 Verification Rate. From the experiment results depicted in Figure 10, we observed that the end-to-end verification delay To verify caller ID, Bob estimates Alice’s waiting time was not affected by the specification of devices or τ v using a Bayesian classifier to decide whether a call the day of the week, rather it is affected by whether is VALID, SPOOFED or NOTSUPPORTED. the SMS have to traverse different operators and the As depicted in Fig. 9(a), the accuracy of the clas- network traffic load. sifier is more than 99% even when the percentage of the training dataset is only 10%, and 99.26% on 7.4.2 Verification Rate average. Furthermore, the precision and recall are In our experiments with SMS-CallerDec,we fairly constant: a 99.98% precision and a 98.91% recall achieved 100% accuracy, precision, recall for normal when caller ID is VALID, a 100% precision and recall and attack scenarios. As discussed in Section 6.3, we when caller ID is SPOOFED, and 95.62% precision and used 32-bit hash to generate SMS Response; thus an 99.93% recall when T-CallerDec is NOTSUPPORTED. 1 adversary has a chance of 232 to generate a fake The results also suggest that a small number of train- response. Even though there is a very low probability, ing data are sufficient for efficient classification. in our experiments, we could not generate a fake T-CallerDec In summery, can be used effectively response in spoofed scenarios, i.e., false positive of to detect caller ID spoofing. It provides high accuracy the system is zero in our evaluation. In summary, in caller ID spoofing detection. despite the short delay overhead, SMS-CallerDec 7. We attention that we don’t over claim that variance of all end- can be used effectively to detect caller ID spoofing to-end verification delay will less than 0.1-0.3 seconds attacks. 13

40 1 1 1 w/o CallerDec w CallerDec 0.9 0.9 0.9 30

0.8 0.8 0.8 20 Recall Accuracy 0.7 Precision 0.7 0.7 VALID VALID 10 0.6 0.6 SPOOFED 0.6 SPOOFED

NOTSUPPORTED NOTSUPPORTED Voltage Usage (mV/hour) 0.5 0.5 0.5 0 0 50 100 0 50 100 0 50 100 no incoming call 10 incoming calls Training data (%) Training data (%) Training data (%) Scenarios (a) accuracy (b) precision (c) recall (d) voltage usage Figure 9: Performance of our Bayesian spoof detection classifier where (a) shows the accuracy, (b) shows the precision and (c) shows the recall of the classifier. Analysis of voltage usage overhead for CallerDec in different scenarios in shown in (d). In voltage measurement experiments, the phone operated on batteries and the average millivolts used per hour was measured.

7.5 Power Usage Analysis network, the different deployed types of network Our analysis of battery usage shows that CallerDec technology succinctly manipulate the audio signal, almost consumes no extra power while idle. In active creating a characteristic watermark that can be used scenarios, CallerDec consumes little power, i.e., ap- to reconstruct and recognize the employed techniques, proximately 0.01 mV per call, compared to the case and thus also the path taken by a call. The approach is when it was not installed. closest to our work as it does not require cooperation of the involved network providers and can be realized 8RELATED WORK on an on-demand basis, by unilaterally modifying the While the problem of caller ID spoofing is gener- callee’s device software. However, PinDrop requires ally known, previously proposed solutions typically that the receiver answers the call before the source require the cooperation and modification of phone can be verified, and cannot by itself validate the origin provider networks, which imposes extra cost. For of a previously unseen caller ID. As such, PinDrop is instance, TrustID is a corporate service offered to complementary to our scheme. Their approach could banks or large institutions [8] and it leverages special be integrated with ours to increase the detection cer- interfaces with the carriers to detect caller ID spoofing. tainty once the call was answered, or warn if a known Cai [43] proposes a system to validate caller ID caller ID originates from an unusual network location. information based on “originating information” Piotrowski et al. [46] consider voice spoofing as an of the respective call. In his design, a phone network extension of caller ID spoofing and propose a water- provider should validate the claimed caller ID in- marking mechanism for mitigating the threat. How- formation based on additional meta-data associated ever, their approach requires modification of both the with the call. Several ways of comparing the call’s caller’s and callee’s devices and is therefore mainly meta-data with the claimed caller ID are proposed, useful for closed environments. In such scenarios, however, it does not address the problem of fake ID where arbitrary modifications to the caller as well as providers, which have both incentive and means to callee can be assumed, a wide range of well-known fake most of this meta-data. Additionally, customers cryptographic and steganographic approaches can be must rely on their respective phone providers to considered (e.g., CryptoPhone [47]). verify the claimed caller ID. Another approach is the RealName Registry by 9CONCLUSION Chow et al. [44]. They propose that telephone provi- In this article, we investigated caller ID spoofing ders establish authenticated name registries within attacks and identified that it is the network inter- their respective jurisdictions. Specifically, customers connection protocols that make caller ID spoofing should register to their providers and be issued cryp- possible. There is no evidence that telephone carriers tographic certificates that can then be validated by the will change their networks to support caller ID verifi- respective callee’s. Note that this mechanism also al- cation. Thus, we seek an end-to-end solution to detect lows the reverse authentication of the callee’s towards a spoofed caller ID. We designed CallerDec end- the caller. However, while spoofing is a serious issue to-end verification mechanisms: SMS-CallerDec and in many transactions, the cost imposed by introducing T-CallerDec, implemented both CallerDec in cryptographic authentication and a PKI is significant. Android-based phones. Our experimental analysis This is aggravated by the fact that the proposed au- validates that CallerDec can effectively verify caller thentication scheme is only useful if widely deployed, ID. Although the end-to-end delay for complet- so that unauthenticated calls can be rejected. ing a verification takes a few seconds, such delay PinDrop by Balasubramaniyan et al. [45] deter- can be hidden when a verification is performed mines the “provenance” of a call by evaluating audio in parallel to the voice call. Moreover, we studied artifacts introduced by digital encoding and analog CallerDec on Android-based phones as a case study, noise patterns. As the call is routed through the but CallerDec can be integrated to other types of 14 phone terminals to effectively protect end users from [39] R. Rivest, “The MD5 Message Digest Algorithm, Request for caller ID spoofing attacks. Comments (RFC)1321,” 1992. [40] N. W. Group, US Secure Hash Algorithm 1 (SHA1), tools.ietf.org/pdf/rfc3174.pdf. REFERENCES [41] QUALCOMM, “Circuit-switched fallback. the first phase of voice evolution for mobile LTE devices,” [1] B. Schneier, Caller ID Spoofing, www.qualcomm.com, Tech. Rep., 2012. http://www.schneier.com/blog/archives/- [42] F. Duffy and R. Mercer, “A study of network performance and 2006/03/caller_id_spoof.html. customer behavior during direct-distance-dialing call attempts [2] ABCNews, Caller ID Scam Solicits Personal Info, Money. in the usa,” Technical Journal, vol. 57, 1978. abcnews.go.com/GMA/Consumer/story?id=3305916, 2007. [43] Y. Cai, Patent Application: Validating Caller ID Information to [3] D. Cuellar, Pranksters Terrorize Delco Family in “swatting” Call. Protect Against Caller ID Spoofing, US Patent and Trademask WPVI-TV, , PA, 2010. Office, 2008. [4] Rep. Elliot L. Engel, Rep. Engel Anti-Spoofing Bill Passes [44] S. T. Chow, C. Gustave, and D. Vinokurov, “Authenticating House, http://engel.house.gov/latest-news1/rep-engel-anti- displayed names in telephony,” Journal, 2009. spoofing-bill-passes-house. [45] V. A. Balasubramaniyan, A. Poonawalla, M. Ahamad, M. T. [5] U. Congress, Truth in Caller ID Act of 2009, www.gpo.gov. Hunter, and P. Traynor, “Pindr0p: using single-ended audio [6] X-Lite, www.counterpath.com/x-lite.html. features to determine call provenance,” in Proceedings of the [7] CallerIDFaker, Caller ID Faker-Fake a Call!, 17th ACM conference on Computer and communications security. www.calleridfaker.com. ACM, 2010, pp. 109–120. [8] TrustID, Automated Caller Authentication, www.trustid.com. [46] Z. Piotrowski and P. Gajewski, “Voice spoofing as an im- [9] D. Livengood, J. Lin, and C. Vaishnav, Public Switched Tele- personation attack and the way of protection,” Journal of phone Networks: A Network Analysis of Emerging Networks, Information Assurance and Security, vol. 2, no. 3, 2007. ocw.mit.edu, 2006. [47] GSMK CryptoPhone, www.cryptophone.de. [10] Bell Communication Research, Bellcore Technical Specification, www.morehouse.org/hin/blckcrwl/telcom/callerid.txt, 1984. Hossen Mustafa received his PhD in Com- [11] ETSI, UMTS, www.etsi.org. puter Science and Engineering from Uni- [12] ——, W-CDMA, www.etsi.org. versity of South Carolina in 2014. He co- [13] 3GPP, TS 24.081, www.quintillion.co.jp/3GPP/Specs/, 2004. authored several publications in th field of [14] V. Niemi and K. Nyberg, UMTS Security. John Wiley & Sons, networking, security, and privacy. 2003. His research interests include wireless net- [15] O. Hersent, D. Gurle, and J.-P. Petit, IP Telephony: packet-based works, network security, and mobile comput- multimedia communications systems. Addison-Wesley, 2000. ing. He is currently an assistant Professor [16] IETF, SIP: Session Initiation Protocol, in the Institute of Information and Communi- www.ietf.org/rfc/rfc3261.txt. cation Technology, Bangladesh University of [17] ITU, H.323 : Packet-based multimedia communications systems, Engineering and Technology (BUET). www.itu.int/rec/T-REC-H.323/e. [18] K. Ono and S. Tachimoto, “SIP signaling security for end- Wenyuan Xu received her Ph.D. degree in to-end communication,” in The 9th Asia-Pacific Conference on Electrical and Computer Engineering from Communications (APCC), vol. 3. IEEE, 2003, pp. 1042–1046. Rutgers University in 2007. She is currently [19] J. Ellig, Regulatory Status of VoIP in the Post-Brand X World. an associate professor in the Department bepress Legal Series, 2006. of Computer Science and Engineering, Uni- [20] ITU-T, Q.700, www.itu.int/rec/T-REC-Q.700-199303-I/en, versity of South Carolina. Her research in- 1994. terests include wireless networking, network [21] C. H. Kennedy, An introduction to US law. security and privacy. Dr. Xu is a co-author Artech House, 2001. of the book Securing Emerging Wireless [22] AT&T, Voice Networking Solutions, www.business.att.com. Systems: Lower-layer Approaches, Springer, [23] North American Numbering Plan Administration, 2009. She received the NSF Career Award in www.nanpa.com. 2009. She is a member of the ACM and IEEE, and has served on the [24] H. Sengar, R. Dantu, D. Wijesekera, and S. Jajodia, “Ss7 over ip: technical program committees for several IEEE/ACM conferences. signaling interworking vulnerabilities,” Network, IEEE, 2006. [25] J. Song, H. Kim, and A. Gkelias, “ivisher: real-time detection Ahmad-Reza Sadeghi is a professor of of spoofing,” ETRI Journal, 2014. Computer Science at the Technische Univer- [26] Voxeo, Prophecy IVR Platform Software, www.voxeo.com. sitaet Darmstadt, Germany. He is the head of [27] Bevocal Cafe, Supercharge Your Portal, cafe.bevocal.com. the System Security and Secure Things Labs [28] J. Eisenzopf, “What you need to know about voice asps,” in and also the director of the Intel Collabora- www.datamation.com. Datamation, 2001. tive Research Institute for Secure Comput- [29] A. S. Tanenbaum, Computer Networks. Barnes & Noble, 2003. ing (ICRI-SC) at TU-Darmstadt. He holds a [30] ITU-T, Session Initiation Protocol (SIP) Extension for Instant Ph.D. in Computer Science from the Univer- Messaging, www.ietf.org/rfc/rfc3428.txt. sity of Saarland in Saarbruecken, Germany. [31] ETSI, ETSI ES 201 912, www.etsi.org, 2011. For his influential research on Trusted Com- [32] J. Han and M. Kamber, Data Mining: Concepts and Techniques. puting he received the renowned German Elsevier Inc, 2006. “Karl Heinz Beckurts” award. This award honors excellent scientific [33] H. Mustafa, W. Xu, A. R. Sadeghi, and S. Schulz, “You can achievements with high impact on industrial innovations in Germany. call but you can’t hide: Detecting caller id spoofing attacks,” in Dependable Systems and Networks (DSN), 2014 44th Annual Steffen Schulz is a Security Researcher IEEE/IFIP International Conference on. IEEE, 2014, pp. 168–179. at Intel Labs, currently situated at the Intel [34] Lincoln Emergency Communications Center, Lincoln Collaborative Research Institute for Secure Emergency Communications Center Annual Report, Computing (ICRI-SC) in Darmstadt. Steffen www.lincoln.ne.gov. received his Ph.D. in computer science from [35] D. County, Dauphin County Emergency Management Agency Year Macquarie University, Australia. Steffen co- Yearly Statistics, www.dauphincounty.org, 2011. authered a range of publications in network [36] IETF, ETSI TS 122 083, www.etsi.org. security, covert channel and trusted comput- [37] Carnegie Mellon University, CMU Sphinx, cmus- ing research. His current research focus is phinx.sourceforge.net. on new security architectures for low-cost [38] ITU, Q.431 Primary rate interface, www.itu.int/rec/T-REC- embedded systems, in particular lightweight I.431-199303-I/en. remote attestation, trusted execution and security management.