Caller Id Spoofing Detection
Caller Id Spoofing Detection
Caller Id Spoofing Detection
1 Introduction
“What’s worse than a bad authentication system? A bad authentication
system that people have learned to trust” [1].
Caller ID services transmit the phone number and/or the name of a caller to
the recipient (callee) as caller ID intending to provide informed consent to the
callee before answering calls. However, Caller ID has been increasingly used to
authenticate the identities of callers, or to verify their physical locations in several
systems, ranging from 9-1-1 emergency services, automatic telephone banking
systems4 , credit card activation systems, to voicemail services. Unfortunately,
existing caller ID protocols do not provide real authentication and hence caller
IDs are vulnerable to spoofing attacks; i.e., an attacker can easily send a fake
caller ID to a callee. This vulnerability has already been exploited in variety of
4
For instance, Bank of America only requires a customer to enter a debit/credit card number to
access account information when the caller ID matches their records.
2
misuse and fraud incidents: In the US, thousands of people were victimized by
credit card fraud with the help of caller ID spoofing [2,3], causing a loss of more
than $15 million dollars annually; caller ID spoofing is also a common technique
used for swatting, which is an attempt to trick an emergency service with false
reporting of an incident — for instance, police officers were tied-up in responding
to a non-existent robbery reported by pranksters [4]; drugs were misused as a
result of spoofed pharmacists’ phone numbers [2]; other incidents include identity
theft, purchase scams [1], etc. Due to the proliferation of detrimental incidents
caused by caller ID spoofing, the US government passed the legislation Truth in
Caller ID Act of 2009 [5] making it illegal to transmit misleading or inaccurate
caller ID information with the intend to defraud.
However, today spoofing caller IDs has become much easier, because many
VoIP providers allow anyone to claim arbitrary caller IDs through VoIP client
software (e.g., x-lite [6]), and fake ID providers allow their customers to claim
any caller ID by simply dialing a special phone number or by utilizing readily
available 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 plaintext
with no authentication mechanisms in place. When a call is routed between
different carriers, the callee’s carrier will simply accept the caller ID claimed by
a caller’s carrier. Given the lack of authentication between carriers, caller IDs
could be trustworthy if (a) the telephone service providers do not manipulate
caller IDs, (b) the telephone infrastructure is tightly controlled, and no intruders
could tap into the infrastructure to create an arbitrary caller ID.
These conditions were true in the early days as the telephone network used
dedicated lines operated by a monopoly. Today, with current converging phone/data
networks and diversity of telephone service carriers, neither holds any more.
Moreover, telephone carriers may not be able to solve the problem even if they
are willing to redesign the protocols. This is because the entire telephone infras-
tructure comprises several telephone carriers with their own trust domains, and
a carrier can at most verify calls originated in its own network but not from
the other networks. 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.5
Challenges and contributions. We present an end-to-end detection mecha-
nism against caller ID spoofing attacks. Our approach utilizes a covert channel
between end users and does not require changing to the existing core telephone
networks. 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 calling
procedure is unlikely to be accepted by most people. Thus, naive solutions such
as rejecting an incoming call and then calling back, are not an option. The de-
5
A commercial proprietary service (TrustID) claims to detect caller ID spoofing [8] for business
customers. However, it is closed source and we were unable to obtain/analyze its technical solution.
3
tection mechanisms should be automated and require little user input. Fourth,
a few legitimate services provided by telephone companies allow the caller IDs
to be different from the calling numbers, making those caller IDs appear to be
spoofed. However, those scenarios should not be classified as caller ID spoofing
attacks. We address all these requirements and design an end-to-end caller ID
verification scheme which we call CallerDec. We summarize our contributions as
follows:
– 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 detect
spoofing 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 utilize
CallerDec to verify caller IDs.
– We implement CallerDec as an App for Android-based smartphones where
we tackle several technical challenges caused by the limited API support for
controlling calls. We examine the CallerDec performance in various scenarios,
and show that it can detect spoofed caller ID effectively and efficiently.
Alice’s caller ID. First, Eve calls the fake ID provider, and supplies Bob’s phone
number as the destination number and Alice’s phone number as the desired
spoofed caller ID. Then, the fake ID provider establishes a call to Bob with Al-
ice’s caller ID, and finally connects Eve with Bob once the call is answered. Eve
can subscribe to a fake ID provider and carry out spoofing attacks towards any
victim from any type of phone, provided that the fake ID provider is connected
to the victim’s network.
Spoofing via VoIP Services. Many VoIP carriers allow their customers to
specify their own caller ID, and will forward the caller ID to the callee’s carrier
without modifications. An adversary can subscribe to a VoIP carrier that allows
caller ID manipulation and can either use VoIP client software or a VoIP phone
to claim arbitrary caller IDs.
Spoofing via Automated Phone Systems. Automated phone systems
provide 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 selected
caller IDs for their subscribers regardless of their intention. Because these provi-
ders connect to major telephone carriers via SS7 or VoIP protocols [13], the
downstream telephone carriers will simply accept any caller IDs, including the
spoofed ones.
In this paper, we only evaluate our caller ID spoofing detection schemes
utilizing a fake ID provider. We believe that our proposed solution is capable
of detecting all aforementioned spoofing attacks since our detection scheme is
independent of how caller ID spoofing attacks are launched.
system (e.g., bank), etc. Regardless of the type, we assume that Bob has a strong
incentive to verify the caller ID of a caller, e.g., he can be a bank that needs to
verify 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 a
PSTN 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 calls
to dialed numbers and do not collude with Eve in any way. Thus, Eve cannot
capture or inject any type of packets into the telephone networks. Neither can
she answer or reject a call unless she is the callee. Additionally, we assume that
Alice does not collude with Eve and will not help Eve with caller ID validation.
Otherwise, we consider that Eve is authorized to use Alice’s caller ID.
3.2 Requirements
Security. The detection scheme should guarantee that an honest caller can prove
the validity of his/her caller ID, and an adversary cannot pretend to be calling
from an arbitrary number.
Compatibility. The detection solution should only change telephone terminals
but not the existing telephone infrastructure, and it should be compatible to
various telephone networks (e.g., GSM, VoIP, PSTN).
Usability. The detection strategies should be user-friendly, i.e., they should be
automated, require almost no effort from either a caller or a callee, and should
not change common procedures of phone calls. Otherwise, the callee could just
dial the displayed caller ID and verify verbally.
Efficiency. The detection scheme should have low computational overhead so
that it can be integrated into telephone terminals that have limited resources,
e.g., PSTN phones, mobile phones, etc.
Fig. 3: Call establishment and verification process: Alice is calling Bob who starts
v erification call after τsv interval, and Alice rejects the call after τv interval to prove
her 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 Alice
after a “starting verification” interval τsv and Alice will respond to the new call
according to whether she is indeed calling Bob. We refer to the first call from
o
Alice to Bob as the original call denoted by CA→B and the second call from Bob
v
to Alice as the verification call denoted by CB→A . Bob determines whether the
o
original call CA→B is indeed from Alice by examining the following information
that is sent over the control channel: (a) how Alice responds to the verification
v
call CB→A , and (b) how long Alice waits before responding. For instance, if
v
Alice is calling Bob, Bob will observe that she rejects the verification call CB→A
after a pre-defined interval τv . Because timing estimation of Alice’s waiting time
τv is performed at Bob’s side and its accuracy depends on the packet delivery
delays inside telephone networks, we use a probabilistic classifier to achieve high
estimation 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 whether
Alice 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 unlikely
to 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 to
estimate Alice’s 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 support
CallerDec, Bob’s verification call goes to Alice’s voicemail, etc. We address all
these issues in the design of CallerDec. In the following, we first discuss regular
call setup process in Section 4.2, then present CallerDec protocol in Section 4.3,
and perform security analysis in Section 4.4.
8
o
4.2 Regular Call Setup: CA→B
Without loss of generality, we consider the case that Alice and Bob belong to
carrier-A and carrier-B respectively, and the two carriers communicate through
SS7. We depict a regular call setup procedure in Fig. 3: when Alice dials Bob’s
number, a SETUP request is sent to carrier-A. Then, carrier-A sends carrier-B an
Initial Address Message(IAM), which is equivalent to SETUP. After carrier-B
sends a SETUP to Bob, he responds with an ALERTING message and starts the
ringing. The ALERTING message indicates that Bob is available and the ring-
ing has started. At this point, carrier-B sends carrier-A an Address Complete
Message(ACM). Subsequently, carrier-A sends Alice an ALERTING message, and
Alice starts to play the ringback tone.
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 shown
in Fig. 4(b). Similar to the normal scenario, Bob will first initiate a verification
v
call CB→A to Alice once he receives the call from Eve. Alice will treat Bob’s
v o
verification call CB→A as a regular call CB→A since she is not calling Bob. As
v
a result, instead of rejecting it, she will initiate a new verification call CA→B
after an interval τsv . When Bob identifies that Alice has initiated a verification
v
call CA→B , he concludes that Alice was not calling him. Instead, Alice is trying
v
to verify Bob’s verification call CB→A . After confirming that Alice’s verification
v
call CA→B was initiated after a duration of τsv , Bob will conclude that the caller
v o
ID is SPOOFED. He will terminate his verification call CB→A (CB→A for Alice)
v 7
and reject Alice’s verification call CA→B after an interval τv . Consequently,
v
Alice detects that her verification call CA→B has been rejected and the original
o
call CB→A she received is terminated. Then, she concludes that Bob may have
received 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 Alice
is unreachable, e.g., her phone can be powered off, out of the coverage range, or
Alice is an invalid number. In such cases, as shown in Fig. 4(c), the verification
v
call from Bob CB→A will be directed immediately to either Alice’s voicemail or
v
carrier’s voicemail. When CB→A goes straight to voicemail, it contradicts to the
fact that “Alice” was calling Bob. Based on the timing estimation Bob can detect
that the verification call went straight to voicemail and will conclude that the
caller ID is SPOOFED.
Not-supported Scenario. Now, we discuss the case when Alice does not sup-
v
port CallerDec. In this case, the verification call CB→A will be considered as a
regular call. Since CallerDec is not installed, Alice (the person) may reject the
call 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 call
from Bob. To leverage Alice’s knowledge, Bob’s CallerDec will play a pre-
7 v v
Bob rejects CA→B after τv to indicate that he did initiate the verification call CB→A .
10
original no yes no
SUHVVHG ³2´
call active?
yes
end
Fig. 5: This flowchart shows how CallerDec handles Fig. 6: CallerDec on smart-
different cases to detect caller ID spoofing. A new phone for VALID and
incoming call initiates verification process. SPOOFED caller ID.
recorded voice instruction which asks Alice to press “1#” for confirming the
caller 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 ID
is VALID. Alternatively, Alice may press a random key, and then Bob will
conclude that CallerDec is NOTSUPPORTED at Alice’s end. In addition, Alice
may ignore the call or may reject the call. For both responses, Bob will
conclude 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 the
caller ID is SPOOFED. For all other key-press (except “1#”), Bob will conclude
NOTSUPPORTED. In cases that Alice rejects the verification call, Bob will use
the classifier to verify whether Alice has waited for an interval τv before
rejecting the call. Since the value of τv is chosen beforehand to ensure that
it is unlikely for a human to reject calls after τv interval (e.g., τv = 0), Bob’s
CallerDec concludes NOTSUPPORTED. In cases that Alice ignores the call, Bob
will conservatively conclude that CallerDec is NOTSUPPORTED.
(c) Spoof an Unreachable User. The verification call will go to a voicemail, and
Bob can identify the situation utilizing the classifier and will conservatively
conclude that CallerDec is NOTSUPPORTED.
4.4 Discussion
Security Analysis. The security of this mechanism relies on the observation
that the verification call from Bob to Alice will be routed to Alice if she is
available 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 when
to answer a call, e.g., before the caller ID is verified or after. We stress that the
caller 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 to
verify caller ID.
In case of spoofing a reachable user (Section 4.3), equipped with CallerDec,
Alice will treat Bob’s verification call as a new call and will initiate a new veri-
fication call to Bob. Consequently, Bob concludes that the caller ID is SPOOFED
and Alice will conclude that Bob received a SPOOFED call. Without CallerDec,
when Alice receives the verification call from Bob, she may answer the call and
enter a proper input which leads Bob to conclude SPOOFED. If Alice rejects or
ignores the call, Bob will conservatively conclude NOTSUPPORTED, as discussed
in non-supported scenario(b) of Section 4.3. The bottom line is that Eve cannot
send any signal to convince Bob that Alice is calling.
Special Cases. (a) Blocked caller IDs. CallerDec depends on the caller ID
of an incoming call for verification and CallerDec cannot initiate verification
process if caller ID is BLOCKED or UNAVAILABLE. However, if Bob sup-
ports the mechanism to uncover caller ID of such calls, then CallerDec can be
integrated 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., a
bank. 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 caller
ID 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 call
Bob, while pretending to call from her cell phone. In this case, she can control
CallerDec on her cell phone, and thus can proof her identity. We consider this
scenario as a legitimate caller ID ‘spoofing,’ and CallerDec will conclude VALID.
Race Conditions. In a regular call scenario, both Alice and Bob may try to
call each other simultaneously. In such cases, both calls will go straight to the
voicemail. This is because most standards support call signalling for one active
call at a time, i.e., Alice or Bob cannot receive an incoming call while making an
outgoing one [17]. In this scenario, CallerDec is not initiated. In the case where
one of the calling party starts the call earlier than the other, one call will go
through at the best and CallerDec handles the case as usual.
When Eve tries to spoof both Alice and Bob simultaneously, both Alice and
Bob will initiate verification call to each other. But these calls would go straight
to the voicemail and CallerDec will correctly conclude SPOOFED.
obtain the status of that call, and to estimate the ringing duration at the other
end. However, Android does not allow two concurrent phone calls and hides
the APIs for automating phone calls. Neither does Android contain APIs for
identifying the status of an outgoing phone call or estimating the ringing duration
at the other end. We discuss how we overcome these challenges in the following.
12 12 12
DCSD DCSD DCSD
10 DCFD 10 DCFD 10 DCFD
Seconds
Seconds
Seconds
8 SCSD 8 SCSD 8 SCSD
6 SCFD 6 SCFD 6 SCFD
4 4 4
2 2 2
0 0 0
08 11 14 17 20 23 08 11 14 17 20 23 08 11 14 17 20 23
Time of day Time of day Time of day
(a) VALID (b) SPOOFED (reachable) (c) SPOOFED (unreachable)
Fig. 7: End-to-end verification delay in (a) the normal scenario when caller ID is
VALID, and in the attack scenarios when caller ID is SPOOFED with Alice is (b)
reachable and (c) unreachable.
Seconds
Device Name Processor RAM Class 10
Google Nexus One 1 GHz 512 MB Fast
5
HTC Sense 1 GHz 576 MB Fast
MyTouch 528MHz 192 MB Slow
0
S. Carolina California Michigan Washington
State of the callee
Table 1: Configurations of Android Fig. 8: End-to-end verification delay of
devices used in performance analysis CallerDec based on geographic locations.
5.2 Performance
1 1 1
0.9 0.9 0.9
Accuracy
Precision
Recall
0.8 0.8 0.8
6 Related Work
While the problem of caller ID spoofing is generally known, previous solutions
typically require the cooperation and modification of phone provider networks.
For instance, Cai [21] proposes several ways to validate caller ID information
based on the available meta-data of a call. However, the scheme does not cope
with fake ID providers, which can fake most of this meta-data. Additionally,
customers must rely on their respective phone providers to verify the claimed
caller ID. In the RealName Registry [22], phone providers establish authenti-
cated name registries within their respective jurisdictions. Customers are issued
cryptographic certificates by their providers and can verify each others’ caller
IDs. Unfortunately, the cost of globally upgrading equipment for cryptographic
authentication and PKI is prohibitive, and providers that sell fake caller IDs
may still provide spoofed certificates.
PinDrop [23] evaluates audio artifacts introduced by digital encoding and
analog interference. As the call is routed through the network, the different
deployed types of network technology succinctly manipulate the audio signal,
creating a characteristic watermark that can be used to reconstruct and recognize
the path taken by a call. Similar to our approach, PinDrop does not require
cooperation of the network providers and can be realized on an on-demand basis,
by unilaterally modifying the callee’s device software. However, PinDrop focuses
on detecting whether a known caller ID originates from an unusual network
location. Instead, we focus on detecting any caller IDs, including previously
unseen callers. We believe CallerDec and PinDrop can complement each other.
Piotrowski et al. [24] consider voice spoofing as an extension of caller ID
spoofing and propose a watermarking mechanism to mitigate the threat. How-
ever, their approach requires modification of the caller and callee’s devices. In
this 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. CallerDec
verifies 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 timing
estimation together with the call status for verification. We implemented Caller-
Dec in Android-based phones and validated that CallerDec can effectively verify
caller ID. Although the end-to-end delay for completing a verification takes a few
seconds, such delay can be hidden when the verification is performed in parallel
to 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 users
from caller ID spoofing attacks. In addition, the current CallerDec will conclude
NOTSUPPORTED when CallerDec is not implemented by a phone terminal. We en-
vision that NOTSUPPORTED can be eliminated once the CallerDec is supported on
all telephone terminals.
17
References
1. Schneier, B. http://www.schneier.com/blog/archives/2006/03/caller_id_spoof.html
2. Rep. Engel Anti-Spoofing Bill Passes House. http://engel.house.gov/latest-
news1/rep-engel-anti-spoofing-bill-passes-house
3. 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.gov
6. X-Lite. www.counterpath.com/x-lite.html
7. Caller ID Faker-Fake a Call! www.calleridfaker.com
8. TrustID. www.trustid.com
9. ITU-T: Q.700. www.itu.int/rec/T-REC-Q.700-199303-I/en
10. AT&T: Voice Networking Solutions. www.business.att.com
11. Voxeo: Prophecy IVR Platform Software. www.voxeo.com
12. Bevocal Cafe: Supercharge Your Portal. cafe.bevocal.com
13. Eisenzopf, J.: What You Need To Know About Voice ASPs. www.datamation.com
14. Lincoln Emergency Communications Center Annual Report. www.lincoln.ne.gov
15. 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.org
18. ITU: Q.431 Primary rate interface. www.itu.int/rec/T-REC-I.431-199303-I/en
19. Carnegie Mellon University: CMU Sphinx. cmusphinx.sourceforge.net
20. 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 the
way of protection. Journal of Information Assurance and Security (2007)
25. GSMK Crypto Phone. www.cryptophone.de
26. ETSI: UMTS. www.etsi.org
27. ETSI: W-CDMA. www.etsi.org
28. 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.txt
34. British Telecomm: SIN 227. www.btwebworld.com
35. 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 using
peering architecture.
A Background
Three categories of telephone carriers are in service: cellular networks, Public
Switched Telephone Network (PSTN), and Voice over Internet Protocol (VoIP)
providers. In the following, we give an overview of the popular caller ID standards
used within each type of carrier and between different carriers with the goal of
understanding the feasibility of injecting spoofed caller IDs.
A.1 Cellular Network
Architecture. Universal Mobile Telecommunications System (UMTS) [26] and
Wide-band Code-Division Multiple Access (W-CDMA) [27] are the two most
popular technologies for providing cellular telephone services. Despite which
technology 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 Switching
Centers (MSC), Base Station Controllers (BSC), and Base Transceiver Stations
(BTS). The HLR stores all necessary data for caller ID services, authentication
and billing purposes and interacts with MSC directly.
Each mobile station (MS) has a Subscriber Identity Module (SIM) and a
mobile carrier authenticates an MS based on the SIM information. When an MS
makes a phone call, the call setup process always goes through BTS, BSC, and
MSC. Then, the MSC obtains the caller ID associated with the MS from the
HLR and encodes it in a control packet for call setup.
19
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.
Protocols. Both SIP and H.323 have built-in support for caller ID. SIP uses
the From field in the INVITE packet to send the caller ID, and the caller ID can
be any ASCII characters with an arbitrary length. For instance, the caller ID
in SIP has the form sip:callerID@ip_address and is typically encapsulated
20
Caller ID Forwarding. Signaling System No.7 (SS7) [9] is the de facto stan-
dard for interconnecting carriers, even though many regulators have suggested
using 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 originating
carrier 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 modification
or validation. Hence, caller ID is not verified in either case.