E: AÑO ACADÉMICO:

In this section, we specify the system model and discuss design requirements and give an overview of our end-to-end detection scheme.

System Model

For the rest of the chapter, we will refer to Alice as the caller, Bob as the callee, and Eve as the attacker who tries to spoof Alice’s caller ID while calling Bob. We note that, Alice may not be in Bob’s contact list (unknown), and Alice’s number could be invalid (unreachable). Since the verification operation is preformed automatically, we expand our definition of the names and refer Alice, Bob, and Eve to their devices as well. We envision that Alice, Bob, and Eve can be a smartphone, a mobile phone, a PSTN phone, a VoIP phone, or an automated 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)4_{, etc). In comparison, Alice may or may not integrate}

CallerDec.

We consider 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.

4

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

Requirements

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, because adding any extra hardware to the existing infras- tructure or introducing new protocols to the core telephone networks would be a great expense to all telephone carriers. Additionally it should be compatible to vari- ous telephone networks (e.g., GSM, VoIP, PSTN).

Usability

The detection strategies should be user-friendly, i.e., they should be automated, re- quire 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.

End-to-End Detection Scheme Overview

How can CallerDec, a program running on a telephone, verify who is indeed calling? Similar to the design principle of TCP in Internet, CallerDec considers a telephone network as a black box and rely on the feedback of end-to-end communication services supported by this black box for verification. In total, we have identified two services as the basis for CallerDec.

i. Short Message Service (SMS). SMS enables a user to send short text mes-

sages to another user with a mobile, VoIP [65], or a PSTN line [43], even though not all PSTN phones support SMS. Given a recipient number, the telephone op- erator will route SMS to the intended destination via control channels, unless the destination is unreachable. In such a case, the operator can notify the sender of the failed SMS delivery.

ii. Traditional phone calls. Given a number, the operator will try to establish

a phone call for the caller over a control channel, and create a voice channel after the call is answered. We choose to use control channels for caller ID ver- ification, since a caller cannot manipulate the control channels in a traditional telephone network but can acquire the status of the phone calls, e.g., through distinguishable ringback tones (e.g., busy) or voicemail greetings.

Leveraging either SMS or the call setup procedure, we design two types of CallerDec for caller ID verification, anSMS-based CallerDecand aTiming-based CallerDec. Overall, CallerDec works as follows. When Bob receives a phone call, CallerDec will automatically initiate the caller ID verification by sending a challenge to Alice over one of the end-to-end communication services, e.g., either SMS or a phone call. Then, the challenge will be delivered to Alice if it is reachable. Once the challenge reaches Alice, the CallerDec at Alice’s end will respond to Bob whether she has indeed made

Figure 3.4 SMS-based CallerDec involves performing challenge-response between a caller and a callee before a call initiation.

ID verification. There are, however, several challenges to be addressed: How should Alice respond? How should Bob infer the response based on the feedback of the end- to-end communication channel? Is it possible to automate the verification process? Is it possible to use a second end-to-end communication channel while there is an incoming call? We address all these challenges in the design of CallerDec. We will discuss details of SMS-based CallerDec in Section 3.5 and timing-based CallerDec in Section 3.6.