You Can Call But You Cant Hide:

Detecting Caller ID Spoofing Attacks

Hossen Mustafa1, Wenyuan Xu1, Ahmad-Reza Sadeghi2, and Steffen Schulz2,3

1 University of South Carolina2 Technische Universitt Darmstadt (CASED)

3 Ruhr-Universitt Bochum, Germany & Macquarie University, Australia

Abstract. Caller ID (caller identification) is a service provided by tele-phone carriers to transmit the phone number and/or the name of a callerto a callee. Today, most people trust the caller ID information, and itis increasingly used to authenticate customers (e.g., by banks or creditcard companies). However, with the proliferation of smartphones andVoIP, it is easy to spoof caller ID by installing corresponding Apps onsmartphones or by using fake ID providers. As telephone networks arefragmented between enterprises and countries, no mechanism is availabletoday to easily detect such spoofing attacks. This vulnerability has al-ready been exploited with crucial consequences such as faking caller IDsto emergency services (e.g., 9-1-1) or to commit fraud.In this paper, we propose an end-to-end caller ID verification mecha-nism CallerDec that works with existing combinations of landlines, cel-lular and VoIP networks. CallerDec can be deployed at the liberty ofusers, without any modification to the existing infrastructures. We im-plemented our scheme as an App for Android-based phones and validatedthe effectiveness of our solution in detecting spoofing attacks in variousscenarios.

1 Introduction

Whats worse than a bad authentication system? A bad authenticationsystem that people have learned to trust [1].

Caller ID services transmit the phone number and/or the name of a caller tothe recipient (callee) as caller ID intending to provide informed consent to thecallee before answering calls. However, Caller ID has been increasingly used toauthenticate the identities of callers, or to verify their physical locations in severalsystems, ranging from 9-1-1 emergency services, automatic telephone bankingsystems4, credit card activation systems, to voicemail services. Unfortunately,existing caller ID protocols do not provide real authentication and hence callerIDs are vulnerable to spoofing attacks; i.e., an attacker can easily send a fakecaller ID to a callee. This vulnerability has already been exploited in variety of

4For instance, Bank of America only requires a customer to enter a debit/credit card number toaccess account information when the caller ID matches their records.

2misuse and fraud incidents: In the US, thousands of people were victimized bycredit card fraud with the help of caller ID spoofing [2,3], causing a loss of morethan $15 million dollars annually; caller ID spoofing is also a common techniqueused for swatting, which is an attempt to trick an emergency service with falsereporting of an incident for instance, police officers were tied-up in respondingto a non-existent robbery reported by pranksters [4]; drugs were misused as aresult of spoofed pharmacists phone numbers [2]; other incidents include identitytheft, purchase scams [1], etc. Due to the proliferation of detrimental incidentscaused by caller ID spoofing, the US government passed the legislation Truth inCaller ID Act of 2009 [5] making it illegal to transmit misleading or inaccuratecaller ID information with the intend to defraud.

However, today spoofing caller IDs has become much easier, because manyVoIP providers allow anyone to claim arbitrary caller IDs through VoIP clientsoftware (e.g., x-lite [6]), and fake ID providers allow their customers to claimany caller ID by simply dialing a special phone number or by utilizing readilyavailable Apps on smartphones (e.g., Caller ID Faker [7]). Thus, in this paper,we focus on detecting caller ID spoofing attacks.

Caller ID spoofing is possible because caller IDs are transmitted in plaintextwith no authentication mechanisms in place. When a call is routed betweendifferent carriers, the callees carrier will simply accept the caller ID claimed bya callers carrier. Given the lack of authentication between carriers, caller IDscould be trustworthy if (a) the telephone service providers do not manipulatecaller IDs, (b) the telephone infrastructure is tightly controlled, and no intruderscould tap into the infrastructure to create an arbitrary caller ID.

These conditions were true in the early days as the telephone network useddedicated lines operated by a monopoly. Today, with current converging phone/datanetworks and diversity of telephone service carriers, neither holds any more.Moreover, telephone carriers may not be able to solve the problem even if theyare willing to redesign the protocols. This is because the entire telephone infras-tructure comprises several telephone carriers with their own trust domains, anda carrier can at most verify calls originated in its own network but not fromthe other networks. To the best of our knowledge, no mechanism is currentlyavailable to users for detecting caller ID spoofing without answering the call firstor without a special interface (and agreement) provided by the carrier.5

Challenges and contributions. We present an end-to-end detection mecha-nism against caller ID spoofing attacks. Our approach utilizes a covert channelbetween end users and does not require changing to the existing core telephonenetworks. Such a detection mechanism is challenging to realize: First, only lim-ited information and resources are available at end users. The route of call sig-nalling is unknown. Second, compatibility to different protocols (GSM, VoIP,PSTN) limits the design space. Third, any deviation from the regular callingprocedure is unlikely to be accepted by most people. Thus, naive solutions suchas rejecting an incoming call and then calling back, are not an option. The de-

5A commercial proprietary service (TrustID) claims to detect caller ID spoofing [8] for businesscustomers. However, it is closed source and we were unable to obtain/analyze its technical solution.

3tection mechanisms should be automated and require little user input. Fourth,a few legitimate services provided by telephone companies allow the caller IDsto be different from the calling numbers, making those caller IDs appear to bespoofed. However, those scenarios should not be classified as caller ID spoofingattacks. We address all these requirements and design an end-to-end caller IDverification scheme which we call CallerDec. We summarize our contributions asfollows:

We propose CallerDec, an end-to-end caller ID verification scheme that re-quires no modification to the existing telephone infrastructure and is appli-cable to calling parties using any telephone services. CallerDec can detectspoofing even if a caller ID is not in the contact list or is unreachable.

We present two use cases of CallerDec, one for an emergency call scenario(e.g., 9-1-1 call) and the other for a regular call scenario. In both cases,the end users, (e.g., a 9-1-1 service or an individual customer) can utilizeCallerDec to verify caller IDs.

We implement CallerDec as an App for Android-based smartphones wherewe tackle several technical challenges caused by the limited API support forcontrolling calls. We examine the CallerDec performance in various scenarios,and show that it can detect spoofed caller ID effectively and efficiently.

We stress that, while we implemented CallerDec on Android smartphones asa case study, our solution can also be integrated in any other telephone devices.

2 Caller ID Spoofing Attacks

Creating a phone call typically involves two types of channels: a control channelfor signalling, and a voice channel for transmitting voice data. Caller IDs aretransmitted in control channels: When a caller dials a number, the carrier firstauthenticates the caller, and then looks up the associated caller ID. Finally, thecaller ID is forwarded to the callee, possibly from one carrier to another.

It is difficult to spoof caller IDs by directly exploiting the Public SwitchedTelephone Network (PSTN, landlines) or cellular network protocols becausecaller IDs are automatically generated by landlines or cellular carriers, and con-trol channels are not easily accessible to customers. However, it is easy to spoofcaller IDs in VoIP, since VoIP transmits both voice and control data in IP pack-ets, and a caller can often set up any caller ID for an outgoing call. In addition,the protocols that interconnect carriers, which include Signaling System No. 7(SS7) [9] and VoIP, do not contain any caller ID verification mechanisms, anda carrier will simply accept and forward the claimed caller IDs. Thus, spoofingattacks require little effort in several ways. We discuss several attacks in thefollowing.

Spoofing via Fake ID Providers. Fake ID providers offer caller ID spoof-ing services. They establish SS7/VoIP connections with various telephone carri-ers (e.g., AVOICS [10]), and act as intermediary between attackers and victimsto relay caller IDs specified by its customers (attackers in this case). Fig. 1 illus-trates an example, where an attacker (Eve) tries to call the victim (Bob) faking

4

Fig. 1: An illustration of how a fake ID provider spoofs a caller ID leveraging theloophole in network interconnection protocols.

Alices caller ID. First, Eve calls the fake ID provider, and supplies Bobs phonenumber as the destination number and Alices phone number as the desiredspoofed caller ID. Then, the fake ID provider establishes a call to Bob with Al-ices caller ID, and finally connects Eve with Bob once the call is answered. Evecan subscribe to a fake ID provider and carry out spoofing attacks towards anyvictim from any type of phone, provided that the fake ID provider is connectedto the victims network.

Spoofing via VoIP Services. Many VoIP carriers allow their customers tospecify their own caller ID, and will forward the caller ID to the callees carrierwithout modifications. An adversary can subscribe to a VoIP carrier that allowscaller ID manipulation and can either use VoIP client software or a VoIP phoneto claim arbitrary caller IDs.

Spoofing via Automated Phone Systems. Automated phone systemsprovide Interactive Voice Response (IVR) services for purposes of marketing,survey collection, etc. Some service providers (e.g., Voxeo [11], Nuance Cafe [12])allow their subscribers to select their own caller IDs and will deliver the selectedcaller IDs for their subscribers regardless of their intention. Because these provi-ders connect to major telephone carriers via SS7 or VoIP protocols [13], thedownstream telephone carriers will simply accept any caller IDs, including thespoofed ones.

In this paper, we only evaluate our caller ID spoofing detection schemesutilizing a fake ID provider. We believe that our proposed solution is capableof detecting all aforementioned spoofing attacks since our detection scheme isindependent of how caller ID spoofing attacks are launched.

3 Assumptions and Requirements

3.1 System Model

For the rest of the paper, we will refer to Alice as the caller, Bob as the callee,and Eve as the attacker who tries to spoof Alices caller ID while calling Bob. Wenote that, Alice may not be in Bobs contact list (unknown), and Alices numbercould be invalid (unreachable). Since the verification operation is preformedautomatically, we expand our definition of the names and refer Alice, Bob, andEve to their devices as well. We envision that Alice, Bob, and Eve can be asmartphone, a mobile phone, a PSTN phone, a VoIP phone, or an automated

5(a) emergency call scenario (b) regular call scenario

Fig. 2: Two use cases of CallerDec.

system (e.g., bank), etc. Regardless of the type, we assume that Bob has a strongincentive to verify the caller ID of a caller, e.g., he can be a bank that needs toverify the caller ID of a customer. Thus, Bob integrates CallerDec in his device(e.g., by installing an app in a smartphone, or by upgrading the firmware of aPSTN phone, or by updating the software of a Private Branch Exchange (PBX)6,etc). In comparison, Alice may or may not integrate CallerDec.

We assume that telephone carriers are trusted; they route outgoing callsto dialed numbers and do not collude with Eve in any way. Thus, Eve cannotcapture or inject any type of packets into the telephone networks. Neither canshe answer or reject a call unless she is the callee. Additionally, we assume thatAlice does not collude with Eve and will not help Eve with caller ID validation.Otherwise, we consider that Eve is authorized to use Alices caller ID.

3.2 Requirements

Security. The detection scheme should guarantee that an honest caller can provethe validity of his/her caller ID, and an adversary cannot pretend to be callingfrom an arbitrary number.Compatibility. The detection solution should only change telephone terminalsbut not the existing telephone infrastructure, and it should be compatible tovarious telephone networks (e.g., GSM, VoIP, PSTN).Usability. The detection strategies should be user-friendly, i.e., they should beautomated, require almost no effort from either a caller or a callee, and shouldnot change common procedures of phone calls. Otherwise, the callee could justdial the displayed caller ID and verify verbally.Efficiency. The detection scheme should have low computational overhead sothat it can be integrated into telephone terminals that have limited resources,e.g., PSTN phones, mobile phones, etc.

3.3 Use Cases

CallerDec relies on a covert channel that is built on top of end-to-end communi-cation services in telephone networks for verification. Overall, CallerDec worksas follows (Fig. 2): When Bob receives a phone call, CallerDec will automati-cally initiate the caller ID verification by sending a challenge to Alice over the

6Business organizations use PBX as phone exchanges which offer internal phones service, multiplesimultaneous calls with the same caller ID, etc.

6end-to-end communication service. The challenge will be delivered to Alice if sheis reachable. Once the challenge reaches Alice, the CallerDec at Alices end willrespond to Bob with whether she has made the phone call. Collaboratively, theCallerDec clients on both ends can automate caller ID verification. Even if Aliceis unreachable, Bob can still identify the situation and verify the caller ID.

We present two use cases of CallerDec: emergency call, where calls need tobe answered immediately, and regular call, where Caller IDs are expected tobe verified before calls are answered. In both cases, CallerDec follows the sameverification protocol, because verification relies on an end-to-end covert channelthat is independent to whether the original call is answered or not.

Emergency Calls. In emergency call cases, such as 9-1-1 services, callerID verification is performed in parallel to the voice call. As shown in Fig. 2(a),the callee (e.g., an 9-1-1 service) answers the call from Alice upon ringing, andCallerDec starts the verification process in the background. After the caller IDis verified, CallerDec will notify the callee, and sensitive information may beexchanged thereafter. Since the duration of 9-1-1 calls are reported to be between1-2 minutes on average [14] [15], the verification results shall be returned beforethe call is terminated.

Regular Calls. Eve may spoof Alices caller ID with the goal of winning achance talking to Bob, who would refuse otherwise (e.g., Eve may be an unknownnumber or is on Bobs block list). Thus, in regular call scenarios, CallerDecperforms the verification before a call is answered. As shown in Fig. 2(b), onceBob receives an incoming call, CallerDec starts to verify the caller ID and notifiesBob after the verification completes. While CallerDec may introduce delay inanswering phone calls, it allows users to answer or reject spoofed calls. We notethat a user may use CallerDec to verify only pre-selected numbers and balancethe trade off between delays and trust.

4 CallerDec: Verifying Caller IDs

4.1 Overview

The basic idea of CallerDec is to create a trusted covert channel between Aliceand Bob, i.e., the channel allows Alice and Bob to perform a challenge-responsebut it is inaccessible to Eve. Forming such an end-to-end covert channel is diffi-cult as CallerDec considers a telephone network as a black box and hence onlythe services that are available to end systems can be used, e.g., Short MessageService (SMS), traditional phone call, etc. Additionally, there are incompati-bility and legacy issues in existing protocols. For instance, SMS is often notavailable in PSTN carriers, which limits its use. To make CallerDec independentof telephone networks, we utilize the traditional phone call service to form anend-to-end covert channel between Alice and Bob.

Essentially, the covert channel is built on top of the control channel that isused for call signalling in a traditional telephone network. Even though Alice andBob cannot manipulate control channels directly, they can acquire the status ofthe phone call (e.g., answered/rejected). Since Eve cannot control or access the

7Fig. 3: Call establishment and verification process: Alice is calling Bob who startsverification call after sv interval, and Alice rejects the call after v interval to proveher caller ID.

calls between Alice and Bob, they form a trusted covert channel by initializing,answering, or rejecting phone calls between them.

When Bob receives a call from Alice, he will initiate a new call to Aliceafter a starting verification interval sv and Alice will respond to the new callaccording to whether she is indeed calling Bob. We refer to the first call fromAlice to Bob as the original call denoted by CoAB and the second call from Bobto Alice as the verification call denoted by CvBA. Bob determines whether theoriginal call CoAB is indeed from Alice by examining the following informationthat is sent over the control channel: (a) how Alice responds to the verificationcall CvBA, and (b) how long Alice waits before responding. For instance, ifAlice is calling Bob, Bob will observe that she rejects the verification call CvBAafter a pre-defined interval v. Because timing estimation of Alices waiting timev is performed at Bobs side and its accuracy depends on the packet deliverydelays inside telephone networks, we use a probabilistic classifier to achieve highestimation accuracy. As we discuss in Section 5, we use a Bayesian classifier [16]that is suitable to resource constrained phone terminals.

We note that both v and sv are parameters used to differentiate whetherAlice supports CallerDec or not and should be the same in all CallerDec imple-mentation. The values of v and sv should be chosen so that a user will unlikelyto respond to a call after a v interval yet keeping the verification delay small.

The idea of forming a covert timing channel between Alice and Bob is sim-ple. However, several open problems remain, such as: (a) Bob must be able toestimate Alices waiting time v at his end, (b) the protocol must handle all pos-sible scenarios, i.e., caller ID is valid, caller ID is spoofed, Alice does not supportCallerDec, Bobs verification call goes to Alices voicemail, etc. We address allthese issues in the design of CallerDec. In the following, we first discuss regularcall setup process in Section 4.2, then present CallerDec protocol in Section 4.3,and perform security analysis in Section 4.4.

84.2 Regular Call Setup: CoAB

Without loss of generality, we consider the case that Alice and Bob belong tocarrier-A and carrier-B respectively, and the two carriers communicate throughSS7. We depict a regular call setup procedure in Fig. 3: when Alice dials Bobsnumber, a SETUP request is sent to carrier-A. Then, carrier-A sends carrier-B anInitial Address Message(IAM), which is equivalent to SETUP. After carrier-Bsends a SETUP to Bob, he responds with an ALERTING message and starts theringing. The ALERTING message indicates that Bob is available and the ring-ing has started. At this point, carrier-B sends carrier-A an Address CompleteMessage(ACM). Subsequently, carrier-A sends Alice an ALERTING message, andAlice starts to play the ringback tone.

4.3 CallerDec Verification Protocol

Continuing with the example shown in Fig. 3, we introduce CallerDec verificationprotocol using the following scenarios: (a) normal scenario: Alice is indeed callingBob and both of them installed CallerDec, (b) attack scenario - spoof a reachableuser: Eve is spoofing Alices number, and Alice is reachable with CallerDecinstalled, (c) attack scenario - spoof an unreachable user: Eve is spoofing Alicesnumber, and Alice is unreachable, and (d) not-supported scenario: Alice does notinstall CallerDec. Depending on the type of use cases, Bob may require differentnumber of concurrent calls. For regular call cases, Bob only requires one call.For emergency call cases, two concurrent calls are required since the verificationshall be performed in parallel to the original call.

Normal Scenario. As shown in Fig. 3, after receiving a phone call CoAB fromAlice, Bob will perform verification as follows.

1. After an interval T1 = sv, Bob initiates a verification call CvBA to Alice

that triggers a sequence of six messages: SETUP, IAM, SETUP, ALERTING,ACM, and ALERTING.

2. When Alice receives the verification call CvBA, she will reject it after aninterval T2 = v. As a result, Bob will receive a REJECT message from carrier-B indicating that CvBA has been rejected.

3. After receiving a REJECT message, Bob will measure the time difference T3between the moment of sending the SETUP message and receiving the REJECTmessage (Fig. 3). Examining T3 using the classifier, Bob will verify whetherAlice has waited for the expected time v before rejecting verification callCvBA. Once the waiting time is verified, Bob will further check the statusof the original call CoAB . If C

oAB is still active, Bob will conclude that

the caller ID is VALID. If CoAB is no longer active, then there is no need tocontinue with the verification process.

As we discussed in Section 3.1, Eve cannot inject packets to the traditionaltelephone networks, neither can she reject or answer the verification call directedto Alice. Thus the verification process between Bob and Alice is protected, andthe response from Alice is trusted. We show a simplified version of this scenarioin Fig. 4(a).

9(a) normal scenario

(b) spoof a reachable user

(c) spoof an unreachable user

Fig. 4: Simplified CallerDec protocol and outcomes in normal and attack scenarios.

Spoof a Reachable User. Eve is calling Bob and Alice is reachable, as shownin Fig. 4(b). Similar to the normal scenario, Bob will first initiate a verificationcall CvBA to Alice once he receives the call from Eve. Alice will treat Bobsverification call CvBA as a regular call C

oBA since she is not calling Bob. As

a result, instead of rejecting it, she will initiate a new verification call CvABafter an interval sv. When Bob identifies that Alice has initiated a verificationcall CvAB , he concludes that Alice was not calling him. Instead, Alice is tryingto verify Bobs verification call CvBA. After confirming that Alices verificationcall CvAB was initiated after a duration of sv, Bob will conclude that the callerID is SPOOFED. He will terminate his verification call CvBA (C

oBA for Alice)

and reject Alices verification call CvAB after an interval v7. Consequently,

Alice detects that her verification call CvAB has been rejected and the originalcall CoBA she received is terminated. Then, she concludes that Bob may havereceived a call that had spoofed her caller ID and terminates her own verification.

Spoof an Unreachable User. In this scenario, Eve is calling Bob, and Aliceis unreachable, e.g., her phone can be powered off, out of the coverage range, orAlice is an invalid number. In such cases, as shown in Fig. 4(c), the verificationcall from Bob CvBA will be directed immediately to either Alices voicemail orcarriers voicemail. When CvBA goes straight to voicemail, it contradicts to thefact that Alice was calling Bob. Based on the timing estimation Bob can detectthat the verification call went straight to voicemail and will conclude that thecaller ID is SPOOFED.

Not-supported Scenario. Now, we discuss the case when Alice does not sup-port CallerDec. In this case, the verification call CvBA will be considered as aregular call. Since CallerDec is not installed, Alice (the person) may reject thecall after a random interval, answer the call, or even not respond to the call.Regardless of the response, CallerDec can handle all cases:

(a) Normal Scenario. Without CallerDec, Alice may answer the verification callfrom Bob. To leverage Alices knowledge, Bobs CallerDec will play a pre-

7 Bob rejects CvAB after v to indicate that he did initiate the verification call CvBA.

10

initiate verification call

check call status

verification call after 2sv

reject after 2v SUHVVHG1

straight to voicemail

original call active? SUHVVHG2

VALID SPOOFED NOTSUPPORTED

end

yes

yes

yesyes

yes

no

no no

no nono

rejectanswer

voicemail new verification call

yes

Fig. 5: This flowchart shows how CallerDec handlesdifferent cases to detect caller ID spoofing. A newincoming call initiates verification process.

Fig. 6: CallerDec on smart-phone for VALID andSPOOFED caller ID.

recorded voice instruction which asks Alice to press 1# for confirming thecaller ID or to press 2# to reject the verification. To proof her Caller ID,Alice will press the proper keys, and Bob will conclude that the caller IDis VALID. Alternatively, Alice may press a random key, and then Bob willconclude that CallerDec is NOTSUPPORTED at Alices end. In addition, Alicemay ignore the call or may reject the call. For both responses, Bob willconclude NOTSUPPORTED.

(b) Spoof a Reachable User. Similarly, Alice may answer the verification call.After Alice enters the proper input (i.e., 2#), Bob will conclude that thecaller ID is SPOOFED. For all other key-press (except 1#), Bob will concludeNOTSUPPORTED. In cases that Alice rejects the verification call, Bob will usethe classifier to verify whether Alice has waited for an interval v beforerejecting the call. Since the value of v is chosen beforehand to ensure thatit is unlikely for a human to reject calls after v interval (e.g., v = 0), BobsCallerDec concludes NOTSUPPORTED. In cases that Alice ignores the call, Bobwill conservatively conclude that CallerDec is NOTSUPPORTED.

(c) Spoof an Unreachable User. The verification call will go to a voicemail, andBob can identify the situation utilizing the classifier and will conservativelyconclude that CallerDec is NOTSUPPORTED.

The overall decision process is illustrated in Fig. 5. We include NOTSUPPORTEDto address the cases when CallerDec is not installed. We envision that afterCallerDec is supported by all telephone devices, we can eliminate NOTSUPPORTED.

4.4 Discussion

Security Analysis. The security of this mechanism relies on the observationthat the verification call from Bob to Alice will be routed to Alice if she isavailable and to a voicemail if she is unavailable, and Eve cannot manipulate

11

the verification call. Based on the choice of use cases, Bob can determine whento answer a call, e.g., before the caller ID is verified or after. We stress that thecaller ID verification process is independent of when a call is answered. Hence,regardless of the use cases (Section 3.3), Bob can utilize the same CallerDec toverify caller ID.

In case of spoofing a reachable user (Section 4.3), equipped with CallerDec,Alice will treat Bobs verification call as a new call and will initiate a new veri-fication call to Bob. Consequently, Bob concludes that the caller ID is SPOOFEDand Alice will conclude that Bob received a SPOOFED call. Without CallerDec,when Alice receives the verification call from Bob, she may answer the call andenter a proper input which leads Bob to conclude SPOOFED. If Alice rejects orignores the call, Bob will conservatively conclude NOTSUPPORTED, as discussedin non-supported scenario(b) of Section 4.3. The bottom line is that Eve cannotsend any signal to convince Bob that Alice is calling.

Special Cases. (a) Blocked caller IDs. CallerDec depends on the caller IDof an incoming call for verification and CallerDec cannot initiate verificationprocess if caller ID is BLOCKED or UNAVAILABLE. However, if Bob sup-ports the mechanism to uncover caller ID of such calls, then CallerDec can beintegrated seamlessly. We note that 9-1-1 service has such capability, and if inte-grated, CallerDec can perform caller ID verification effectively. (b) PBX systems.CallerDec can be integrated easily in a PBX system of an organization, e.g., abank. Since such systems generally have resources for multiple concurrent calls,they can adopt parallel verification, as discussed in use case 2 (Section 3.3).Furthermore, if Alice is a PBX system and calls Bob, Bob can verify the callerID as usual. (c) Legitimate caller ID spoofing. It is possible that Alice inten-tionally spoofs her own caller ID when calling Bob, e.g., Alice uses skype to callBob, while pretending to call from her cell phone. In this case, she can controlCallerDec on her cell phone, and thus can proof her identity. We consider thisscenario as a legitimate caller ID spoofing, and CallerDec will conclude VALID.

Race Conditions. In a regular call scenario, both Alice and Bob may try tocall each other simultaneously. In such cases, both calls will go straight to thevoicemail. This is because most standards support call signalling for one activecall at a time, i.e., Alice or Bob cannot receive an incoming call while making anoutgoing one [17]. In this scenario, CallerDec is not initiated. In the case whereone of the calling party starts the call earlier than the other, one call will gothrough at the best and CallerDec handles the case as usual.

When Eve tries to spoof both Alice and Bob simultaneously, both Alice andBob will initiate verification call to each other. But these calls would go straightto the voicemail and CallerDec will correctly conclude SPOOFED.

5 Implementation and Validation

5.1 Implementation Challenges

When implementing CallerDec in Android, we encountered several challenges.Particularly, CallerDec requires to automatically initiate a verification call, to

12

obtain the status of that call, and to estimate the ringing duration at the otherend. However, Android does not allow two concurrent phone calls and hidesthe APIs for automating phone calls. Neither does Android contain APIs foridentifying the status of an outgoing phone call or estimating the ringing durationat the other end. We discuss how we overcome these challenges in the following.

Initiate the Verification Call. Depending on the number of concurrent phonecalls, two categories of phone services exist: (a) primary rate interface (PRI) [18]lines, and (b) regular lines (e.g., a mobile phone or a residential landline). PRIsupports multiple concurrent phone calls using the same caller ID. Thus, a sec-ond line can be used to initiate the verification call while the first call may bein progress. Regular end users can dial a secondary phone call but at most onecall can be active at a time. For instance, UMTS requires to put an incomingcall on hold before initiating a new call [17] and Android enforces this require-ment. As a result, when implementing CallderDec in Android, we have to put theincoming call from Alice on hold before initiating the verification call. Unfortu-nately, Android provides no official APIs for putting a call on hold. To overcomethe problem, we leverage Android hidden APIs of ITelephony interface usingjava reflection. We created an interface ITelephony in CallerDec App with thepackage name set as com.android.internal.telephony and added the func-tion definition from the original ITelephony interface with an empty body. As aresult, CallerDec is able to call the hidden functions from ITelephony at runtimeand can perform call control operations (e.g., initiate a new call).

Identify the Status of the Verification Call. CallerDec scheme requiresBob to identify the status of the verification call, i.e., whether the call has beenanswered, rejected, or directed to the voicemail. This task poses several chal-lenges. Android does not allow users to access call signalling messages duringcall setup. As a result, we cannot identify call status directly from call setupmessages, e.g., REJECT message. Neither does Android provide any API that re-turns whether the callees phone is ringing or the call is answered. The statusof an outgoing call is always OFFHOOK8. So, we seek alternatives to identify thestatus of an outgoing call.

To identify the status of the verification call, we utilized system logs. Logsof each Android app are printed in the system shell and CallerDec continuouslymonitors real-time logs using Runtime APIs. In particular, CallerDec monitorslogs of three built-in system apps: CallNotifier, AudioService, and Ringer.Once a DISCONNECT log is printed by CallNotifier, CallerDec concludes thatthe verification call is rejected. To identify the answer or voicemail status, Caller-Dec searches for an audioOn log entry from AudioService and a stopRing()log entry from Ringer. To differentiate between answered and voicemail, Caller-Dec can record voice data using the microphone and identify the patterns ofvoicemail greeting using available tools [19]. If the pattern matches, CallerDechas reached the voicemail, otherwise the verification call is answered.

8OFFHOOK traditionally indicates that the handset of a PSTN phone is off the base and the usercould be dialing a number or on an active call. It is used in the same context in Android.

13

08 11 14 17 20 2302468

1012

Time of day

Sec

onds

DCSDDCFDSCSDSCFD

08 11 14 17 20 2302468

1012

Time of day

Sec

onds

DCSDDCFDSCSDSCFD

08 11 14 17 20 2302468

1012

Time of day

Sec

onds

DCSDDCFDSCSDSCFD

(a) VALID (b) SPOOFED (reachable) (c) SPOOFED (unreachable)

Fig. 7: End-to-end verification delay in (a) the normal scenario when caller ID isVALID, and in the attack scenarios when caller ID is SPOOFED with Alice is (b)reachable and (c) unreachable.

Verify Caller ID Using Timing Estimation. Another key issue to verifyAlices caller ID is to estimate her ringing duration (denoted by T2). As shownin Fig. 3, the ringing duration (T2) is the time difference between the momentswhen Alice sends an ALERTING message, and a REJECT message.

We found that T4 (Fig. 3), which is the time difference between the momentwhen Bob receives an ALERTING and the one when he receives an ANSWER orREJECT message, is unable to estimate T2 because some carriers start playingthe ringback tone before receiving an ALERTING message. For instance, AT&Tstarts the ringback tone even when the callee is unavailable.

We found that T3 (as shown in Fig. 3), which is roughly the sum of T2 andthe round trip time from Bob to Alice, is independent of the types of carriers,since it does not depend on when the ringback tone starts. Hence we chose T3 forestimating T2. To make CallerDec compatible to devices with low computationalpower, e.g., mobile phones, we choose Bayesian Classifier [16]. Bayesian clas-sifier is an efficient method for calculating posterior probability based on priorprobability and likelihood in the training data. Although the classifier needsprior training, our experimental results suggest that the same trained model canbe used on different phones for effective classification.

For the training dataset, we recorded the values of T2, T3, time of day (Tday),and status of the verification call (Scall), i.e., rejected, answered or voicemail.We label each dataset with appropriate class: VALID, SPOOFED, or NOTSUPPORTED.For each test sample, we employ the following Bayes equation [16] to calculatethe probability of each class, Ci.

p(CiT3, Tday, Scall) =

p(T3, Tday, ScallCi) p(Ci)

p(T3, Tday, Scall)(1)

Here, p(Ci) is the probability of Ci in the training dataset. CallerDec classifiesthe test sample as the class with the highest probability. Thus, based on theestimated duration of T2 and Alices action, CallerDec detects caller ID spoofingattacks.

Fig. 6 shows two screenshots of CallerDec when the caller ID is VALID andSPOOFED. To save space, we omit the screenshot of NOTSUPPORTED.

14

Device Name Processor RAM Class

Google Nexus One 1 GHz 512 MB Fast

HTC Sense 1 GHz 576 MB Fast

MyTouch 528MHz 192 MB Slow

Table 1: Configurations of Androiddevices used in performance analysis

S. Carolina California Michigan Washington0

5

10

15

State of the callee

Seco

nds

VALIDSPOOFED (reachable)SPOOFED (unreachable)

Fig. 8: End-to-end verification delay ofCallerDec based on geographic locations.

5.2 Performance

To evaluate the performance of CallerDec, we measured time of day and end-to-end delay of completing caller ID verification for the following scenarios whichwe discussed in Section 4.3: (a) normal, (b) spoof a reachable user, (c) spoofan unreachable user, and (d) not-supported scenarios. Additionally, we studiedthe impact of the type of phones, the carriers, and the time of the day in theverification delay. We selected three Android devices and classified them as fastdevices or slow devices based on the configurations, and the device specificationsare summarized in Table 1. We chose some common telephone carriers in theUSA, which are AT&T, T-Mobile, and SimpleMobile. We used two cases in theexperimental setup: (a) Alice and Bob belong to the same carrier, e.g., T-Mobile,and (b) Alice and Bob belong to different carriers, e.g., a T-Mobile user calls anAT&T user. In total, we measured data at six different times of the day in fourexperimental setup: (a) DCFD: Different Carriers and using two Fast Devices,(b) DCSD: Different Carriers and using one fast and one Slow Device, (c) SCFD:The Same Carrier and using two Fast Devices, and (d) SCSD: The Same Carrierand using one fast and one Slow Device. We set v = sv = 0 seconds in ourimplementation to minimize verification delay. Note that other threshold valuescan be used depending on the network parameters.

End-to-end Verification Delay. We measure end-to-end verification delay asthe time difference between the moment when Bob receives an incoming call andthe one when he identifies Alices action. In the normal scenario, when caller IDwas valid (Fig. 7(a)), the verification was done in 8.40 seconds on average. Inthe worst case, when the caller and the callee were under different carriers, andone of them was using a slow device, the delay was 8.61 seconds. The call setupdelay dominates the delays. For instance, a recent study reported that call setupin 3G networks is between 4-7 seconds on average for various scenarios [20].

In the spoofing a reachable user scenario, Alice initiated a verification callafter sv seconds in response to Bobs verification call. As shown in Fig. 7(b), theverification was done in 8.35 seconds on average. Similar to regular scenarios,the call setup delay dominates the end-to-end delay.

In the spoofing an unreachable user scenario, Alices phone was turned-offand the verification call went straight to the voicemail. As shown in Fig. 7(c),the verification delay was less than 2 seconds on average and 2.13 seconds in theworst case. Note that verification delay is low in this scenario because the call isnot routed to its destination since the caller is unreachable.

15

0 50 1000.5

0.6

0.7

0.8

0.9

1

Training data (%)

Accu

racy

0 50 1000.5

0.6

0.7

0.8

0.9

1

Training data (%)

Prec

ision

VALIDSPOOFEDNOTSUPPORTED

0 50 1000.5

0.6

0.7

0.8

0.9

1

Training data (%)

Reca

ll

VALIDSPOOFEDNOTSUPPORTED

(a) accuracy (b) precision (c) recall

Fig. 9: Performance of our Bayesian spoof detection classifier where (a) shows theaccuracy, (b) shows the precision and (c) shows the recall of the 1classifier.

We also analyzed the latency of CallerDec based on the geographic locationsof the caller and the callee (Fig. 8). In our experiments, the caller was always inSouth Carolina and the callee was in one of the four states: California, Michigan,South Carolina, and Washington. The result indicates that geographic locationsof the caller and the callee have minor effects on the delay.

Although CallerDec takes a few seconds for end-to-end verification, our anal-ysis shows that such delay is mainly caused by telephone networks, and enddevices or network loads have minor effects. However, the verification delay canbe hidden in case of emergency calls (Fig. 2(a)) because the verification is donein parallel to the phone call. Although CallerDec adds delay overhead before auser may answer calls in case of regular calls (Fig. 2(b)), the actually experiencedoverhead should be lower since it generally takes a few seconds to answer a call.

Timing Estimation. To verify caller ID, Bob estimates Alices waiting timev using a Bayesian classifier to decide whether a call is VALID, SPOOFED orNOTSUPPORTED. To analyze the performance of our classifier, we collected morethan 2800 instances of calls labelled with appropriate class, e.g., approximately1100 VALID, 1100 SPOOFED, and 600 NOTSUPPORTED instances. For NOTSUPPORTEDclass, Alice rejected or answered the verification call at random time. We dividedthe dataset into training and test sets at various proportions p, where p = [0.1- 0.9]. For instance, with p = 0.1, 10% (approximately 280 instances) of thedataset was used for training and the rest 90% (approximately 2600 instances)was used for testing. We use the following metrics for evaluating CallerDec clas-sifier where 100% is the desired outcomes for each metric: (a) an accuracy whichis the percentage of correct outcomes of CallerDec, (b) a precision which is thepercentage of correct outcome for a class out of all CallerDec outcomes for thatclass (e.g., correct VALID outcomes out of all VALID outcomes), and (c) a recallwhich is the percentage of correct outcome out of all correct outcomes for a class.

As depicted in Fig. 9(a), the accuracy of the classifier is more than 99% evenwhen the percentage of the training dataset is only 10%, and 99.26% on average.Furthermore, the precision and recall are fairly constant: a 99.98% precisionand a 98.91% recall when caller ID is VALID, a 100% precision and recall whencaller ID is SPOOFED, and 95.62% precision and 99.93% recall when CallerDec isNOTSUPPORTED. The results also suggest that a small number of training data issufficient for efficient classification.

In summery, CallerDec can be used effectively to detect caller ID spoofing.It provides high accuracy in caller ID spoofing detection.

16

6 Related Work

While the problem of caller ID spoofing is generally known, previous solutionstypically require the cooperation and modification of phone provider networks.For instance, Cai [21] proposes several ways to validate caller ID informationbased on the available meta-data of a call. However, the scheme does not copewith fake ID providers, which can fake most of this meta-data. Additionally,customers must rely on their respective phone providers to verify the claimedcaller ID. In the RealName Registry [22], phone providers establish authenti-cated name registries within their respective jurisdictions. Customers are issuedcryptographic certificates by their providers and can verify each others callerIDs. Unfortunately, the cost of globally upgrading equipment for cryptographicauthentication and PKI is prohibitive, and providers that sell fake caller IDsmay still provide spoofed certificates.

PinDrop [23] evaluates audio artifacts introduced by digital encoding andanalog interference. As the call is routed through the network, the differentdeployed types of network technology succinctly manipulate the audio signal,creating a characteristic watermark that can be used to reconstruct and recognizethe path taken by a call. Similar to our approach, PinDrop does not requirecooperation of the network providers and can be realized on an on-demand basis,by unilaterally modifying the callees device software. However, PinDrop focuseson detecting whether a known caller ID originates from an unusual networklocation. Instead, we focus on detecting any caller IDs, including previouslyunseen callers. We believe CallerDec and PinDrop can complement each other.

Piotrowski et al. [24] consider voice spoofing as an extension of caller IDspoofing and propose a watermarking mechanism to mitigate the threat. How-ever, their approach requires modification of the caller and callees devices. Inthis case, when arbitrary modifications to the caller and callee can be assumed,well-known cryptographic approaches can be employed (e.g., CryptoPhone [25]).

7 Conclusion

In this paper, we investigated caller ID spoofing attacks and designed an end-to-end solution, which we call CallerDec, to detect a spoofed caller ID. CallerDecverifies the caller ID using a covert channel, which is built on top of the ver-ification call from the callee to the claimed caller, and CallerDec uses timingestimation together with the call status for verification. We implemented Caller-Dec in Android-based phones and validated that CallerDec can effectively verifycaller ID. Although the end-to-end delay for completing a verification takes a fewseconds, such delay can be hidden when the verification is performed in parallelto the voice call.

We studied CallerDec on Android-based phones as a case study, but Caller-Dec can be integrated to other types of phone terminals to protect end usersfrom caller ID spoofing attacks. In addition, the current CallerDec will concludeNOTSUPPORTED when CallerDec is not implemented by a phone terminal. We en-vision that NOTSUPPORTED can be eliminated once the CallerDec is supported onall telephone terminals.

17

References

1. Schneier, B. http://www.schneier.com/blog/archives/2006/03/caller_id_spoof.html2. Rep. Engel Anti-Spoofing Bill Passes House. http://engel.house.gov/latest-

news1/rep-engel-anti-spoofing-bill-passes-house3. ABCNews: Caller ID Scam Solicits Personal Info, Money.

abcnews.go.com/GMA/Consumer/story?id=3305916 (2007)4. Cuellar, D.: Pranksters Terrorize Delco Family in swatting Call. WPVI-TV,

Philadelphia, PA (2010)5. US Congress: Truth in Caller ID Act of 2009. www.gpo.gov6. X-Lite. www.counterpath.com/x-lite.html7. Caller ID Faker-Fake a Call! www.calleridfaker.com8. TrustID. www.trustid.com9. ITU-T: Q.700. www.itu.int/rec/T-REC-Q.700-199303-I/en10. AT&T: Voice Networking Solutions. www.business.att.com11. Voxeo: Prophecy IVR Platform Software. www.voxeo.com12. Bevocal Cafe: Supercharge Your Portal. cafe.bevocal.com13. Eisenzopf, J.: What You Need To Know About Voice ASPs. www.datamation.com14. Lincoln Emergency Communications Center Annual Report. www.lincoln.ne.gov15. Dauphin County Emergency Management Agency Year Yearly Statistics.

www.dauphincounty.org (2011)16. Han, J., Kamber, M.: Data Mining: Concepts and Techniques. Elsevier Inc (2006)17. IETF: ETSI TS 122 083. www.etsi.org18. ITU: Q.431 Primary rate interface. www.itu.int/rec/T-REC-I.431-199303-I/en19. Carnegie Mellon University: CMU Sphinx. cmusphinx.sourceforge.net20. QUALCOMM: Circuit-switched fallback. the first phase of voice evolution for

mobile LTE devices. Technical report, www.qualcomm.com (2012)21. Cai, Y.: Patent Application: Validating Caller ID Information to Protect Against

Caller ID Spoofing. (2008)22. Chow, S.T., Gustave, C., Vinokurov, D.: Authenticating displayed names in tele-

phony. Bell Labs Journal (2009)23. Balasubramaniyan, V.A., Poonawalla, A., Ahamad, M., Hunter, M.T., Traynor,

P.: Pindr0p: Using single-ended audio features to determine call provenance. In:CCS. (2010)

24. Piotrowski, Z., Gajewski, P.: Voice spoofing as an impersonation attack and theway of protection. Journal of Information Assurance and Security (2007)

25. GSMK Crypto Phone. www.cryptophone.de26. ETSI: UMTS. www.etsi.org27. ETSI: W-CDMA. www.etsi.org28. 3GPP: TS 24.081. www.quintillion.co.jp/3GPP/Specs/29. Niemi, V., Nyberg, K.: UMTS Security. John Wiley & Sons (2003)30. Biryukov, A., Shamir, A., Wagner, D.: Real time cryptanalysis of A5/1 on a PC.

In: FSE. (2000)31. Meyer, U., Wetzel, S.: A Man-in-the-Middle Attack on UMTS. In WiSe (2004)32. Livengood, D., Lin, J., Vaishnav, C.: Public switched telephone networks: A net-

work analysis of emerging networks. Technical report, mit.edu (2006)33. Bell Communication Research: Bellcore Technical Specification.

www.morehouse.org/hin/blckcrwl/telcom/callerid.txt34. British Telecomm: SIN 227. www.btwebworld.com35. Hersent, O., Gurle, D., Petit, J.P.: IP telephony: packet-based multimedia com-

munications systems. Addison-Wesley (2000)

18

Fig. 10: An example telephone network architecture, where different carriers are connected usingpeering architecture.

36. IETF: SIP: Session Initiation Protocol. www.ietf.org/rfc/rfc3261.txt37. ITU: H.323 : Packet-based multimedia communications systems.

www.itu.int/rec/T-REC-H.323/e38. Ono, K., Tachimoto, S.: Sip signaling security for end-to-end communication. In:

APCC. (2003)39. SipDroid. code.google.com/p/sipdroid/40. Ellig, J.: Regulatory Status of VoIP in the Post-Brand X World. Bepress Legal

Series (2006)41. North American Numbering Plan Administration. www.nanpa.com42. Berg, R.V.D.: The Future of Interconnection. 9th Global Symposium for Regula-

tors (GSR). (2009)

A Background

Three categories of telephone carriers are in service: cellular networks, PublicSwitched Telephone Network (PSTN), and Voice over Internet Protocol (VoIP)providers. In the following, we give an overview of the popular caller ID standardsused within each type of carrier and between different carriers with the goal ofunderstanding the feasibility of injecting spoofed caller IDs.

A.1 Cellular Network

Architecture. Universal Mobile Telecommunications System (UMTS) [26] andWide-band Code-Division Multiple Access (W-CDMA) [27] are the two mostpopular technologies for providing cellular telephone services. Despite whichtechnology is used, a cellular telephone network follows a hierarchical structure.As illustrated in Fig. 10, the simplest cellular network consists of the follow-ing entities for voice services (from the top to bottom levels): Mobile SwitchingCenters (MSC), Base Station Controllers (BSC), and Base Transceiver Stations(BTS). The HLR stores all necessary data for caller ID services, authenticationand billing purposes and interacts with MSC directly.

Each mobile station (MS) has a Subscriber Identity Module (SIM) and amobile carrier authenticates an MS based on the SIM information. When an MSmakes a phone call, the call setup process always goes through BTS, BSC, andMSC. Then, the MSC obtains the caller ID associated with the MS from theHLR and encodes it in a control packet for call setup.

19

Protocols. In UMTS and W-CDMA, the caller ID is encoded in call setuppackets (in the Calling Party BCD Number field) using the Binary Coded Dec-imal (BCD) format and has a variable length of 3-14 bytes [28]. It is possiblethat a call is set up without caller ID, and the Presentation Indicator fieldis used to indicate whether caller ID is present in the packet.

Feasibility of Caller ID Spoofing. 3GPP specification has security mech-anisms which include MS authentication, random session keys and SIM secu-rity [29]. Although the communication between MS and BTS is encrypted witha session key, cracking the session key [30] and man-in-the-middle attacks [31]have been reported. An attacker can take advantage of such vulnerabilities tospoof caller IDs. However, to the best of our knowledge, no such caller ID spoof-ing attacks have been reported.

A.2 Public Switched Telephone Network

Architecture. The PSTN is a circuit-switched telephone network, known aslandline telephone. The PSTN generally has a hierarchical architecture [32] withCentral Exchanges (CEs) at the top level of the hierarchy (Fig. 10). Local Ex-changes (LEs) consist of several PSTN switches and one switch port is assignedto one customer configured with caller ID. When a customer dials a number, theLE sends the pre-configured caller ID in the outgoing call.

Protocols. There are several caller ID standards in PSTN, e.g., Bellcore FSK,SIN227, DTMF, V23, ETSI FSK, etc. Among these, Bellcore [33] and SIN227 [34]are the most popular. Most of the protocols use Frequency Shift Keying (FSK)for transmission and transmit caller ID in plain text.

Feasibility of Caller ID Spoofing. All other standards transmit the callerID information in plaintext. However, it is not easy to launch the attack in-side PSTN because the caller ID signal is generated automatically by the LE,based on the pre-configured information. Such information cannot be changed byunauthorized entities, because the switches (LEs) are generally kept in securedcabinets, inaccessible to the general public.

A.3 Voice over Internet Protocol

Architecture. VoIP technology takes advantage of IP where both voice andcontrol data are transmitted in IP packets. Unlike PSTN or cellular networks,VoIP usually follows a flat/p2p architecture [35]. The control channel alwaysfollows the client-server model but the voice channel between a caller and acallee may use a direct connection. For the call setup, VoIP uses protocols suchas Session Initiation Protocol (SIP) [36] or H.323 [37].

Protocols. Both SIP and H.323 have built-in support for caller ID. SIP usesthe From field in the INVITE packet to send the caller ID, and the caller ID canbe any ASCII characters with an arbitrary length. For instance, the caller IDin SIP has the form sip:callerID@ip_address and is typically encapsulated

20

in SIP packets in plaintext. Although secured SIP is available to encrypt callerIDs, they are not authenticated [38]. Similar to SIP, caller ID is also transmittedin plaintext in H.323.

Feasibility of Caller ID Spoofing. Unlike PSTN or cellular network sce-narios, in VoIP the caller ID originates at the client end; i.e., the clients couldgenerate control packets with arbitrarily chosen caller IDs. Most VoIP softwareprovides an interface allowing a caller to specify his/her caller ID for each phonecall, making caller ID spoofing trivial; e.g. x-lite [6], sipdroid [39], etc. In fact,many VoIP carriers manipulate caller ID to avoid long distance charge [40].

A.4 Network Interconnection Protocols:

Different telephone networks are interconnected using a peering architecture, asshown in Fig. 10. In the following, we discuss how a call is routed and caller IDis forwarded between carriers.

Call Routing. In telephone systems, phone numbers are assigned based ongeographic locations to discriminate between local and long-distance calls. Inthe US, each carrier is assigned a unique prefix in each geographic location bythe North American Numbering Plan Administration (NANPA) [41] and thecall routing is done based on prefix-matching. For example, in Washington, the360-269 prefix is assigned to AT&T and 360-270 to Sprint. When a customercalls 360-269-XXXX, the originating carrier must forward the call to AT&T9.

Caller ID Forwarding. Signaling System No.7 (SS7) [9] is the de facto stan-dard for interconnecting carriers, even though many regulators have suggestedusing VoIP [42]. When a caller and a callee have subscribed to different carriers,the call has to go through either an SS7 or VoIP connection. The originatingcarrier sends the caller ID as part of the control packets. In both cases, the re-ceiving carrier passes the caller ID data to the callee without any modificationor validation. Hence, caller ID is not verified in either case.

Feasibility of Caller ID Spoofing. Since there is no verification mechanismsbetween carriers, it is possible for an attacker to get connected with a carrierusing either SS7 or VoIP, and then exploit the lack of authentication betweencarrier networks to spoof caller ID. Such an attack, while valid, is costly andcomplex to carry out because the attacker has to establish an SS7/VoIP connec-tion with a carrier, which requires the attacker to complete an interconnectionagreement with the carrier, to install necessary hardware and software, to pay apremium, etc. Thus, it is not meant for casual adversaries with a limited budget.

Summary. It is difficult to launch caller ID spoofing attacks by exploitingthe caller ID protocol within PSTN or cellular networks, but it is possible byexploiting VoIP. Additionally, an adversary can spoof caller ID by exploiting thelack of caller ID authentication between carriers.

9Unless the phone number is ported, i.e., a customer of carrier A switches service to carrier B butkeeps the same phone number. In this case, the call will be routed to the carrier B instead of A.

Detecting Caller ID Spoofing AttacksIntroductionCaller ID Spoofing AttacksAssumptions and RequirementsSystem ModelRequirementsUse Cases

CallerDec: Verifying Caller IDsOverviewRegular Call Setup: CoABCallerDec Verification ProtocolDiscussion

Implementation and ValidationImplementation ChallengesPerformance

Related WorkConclusionBackgroundCellular NetworkPublic Switched Telephone NetworkVoice over Internet ProtocolNetwork Interconnection Protocols: