Attacking Mobile Privacy 2
Attacking Mobile Privacy 2
Attacking Mobile Privacy 2
MSISDN Location
Problem description:
The MSISDN (or the phone number) is normally associated with a single mobile
device linked to one person. Moreover, the phone number is used by many personal
services and situations, such as registrations, communications, tickets and receipts,
notifications, two-factor authentication, physical identification, geographical locations,
and much more. Hence a mobile phone number can be considered to be personal
information, and can be used to violate personal privacy.
Starting out with the idea and use of an IMSI Catcher, this master thesis work
will investigate the possibilities of building an "MSISDN Catcher": a system that
detects and links MSISDN with people and locations, without having direct access
to the mobile device nor the mobile operator network and registries. However, the
MSISDN Catcher can combine several information sources, including broadcasts and
side channels that may be available, and try to exploit various technical and social
attack mechanisms. A particular focus should be kept on the 4G mobile networks,
where experimentation can be based on the OpenAirInterface open source software
and USRP B200mini radio devices in our Wireless Security Lab.
The MSISDN also known as the phone number, is used by many personal
services and situations. Hence a mobile phone number can be considered
to be personal information, and can be used to violate personal privacy.
Interestingly, there is not yet made MSISDN Catchers. Consequently, this
master thesis investigates the possibility of building an MSISDN Catcher.
With the main focus on the 4G LTE mobile network, the presence and
security of the phone number in the architecture and relevant services
were studied. Also, an open source IMSI Catcher was built based on the
OpenAirInterface software and the USRP B200mini radio device. The
IMSI Catcher was used in an experiment where the goal was to catch the
IMEI identity of mobile phones camping near the base station.
I dag finner vi trådløs teknologi nesten over alt. Med enkelhet, kan vi
kommunisere med personer som befinner seg på andre siden av jordkloden
ved hjelp av mobiltelefoner. I juni 2017, er det over 5 milliarder unike
mobilabonnenter. Det faktum at nesten alle bærer på en mobiltelefon
kombinert med teknologiske sikkerhetshull, resulterer i en kritisk situa-
sjon. Som en konsekvens har ulike parter med mer eller mindre lovlige
intensjoner utført angrep på denne mobilteknologien. En IMSI Catcher
er en populær innretning som utnytter sårbarhet i nettverkene.
Det ble avdekket at det ikke fantes noe enkel måte å bygge en MSISDN
Catcher basert på prinsippene fra en IMSI Catcher. Dessuten klarte ikke
IMSI Catcheren å fange IMEI identiteten fra telefoner i nærheten under
eksperimentet. Derfor viser disse funnene at begge identitetene er godt
beskyttet mot tradisjonelle angrepstaktikker.
Preface
This report is the result of my work during the Master period, which is
the last semester of the 5-year Master of Science degree in Communication
Technology at the Department of Information Security and Communi-
cation Technology at Norwegian University of Science and Technology
(NTNU).
Also, I would like to thank all the people that have contributed to the
OpenAirInterface project, Wireshark software, and the USRP B200mini.
Trondheim, 2017
List of Figures ix
List of Tables xi
1 Introduction 1
1.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 LTE 3
2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 The Evolved Packet Core (EPC) . . . . . . . . . . . . . . . . 4
2.1.2 MME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Serving Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4 Packet Data Network Gateway . . . . . . . . . . . . . . . . . 5
2.1.5 Home Subscriber Server . . . . . . . . . . . . . . . . . . . . . 5
2.1.6 The access network - E-UTRAN . . . . . . . . . . . . . . . . 6
2.1.7 Circuit Switching (CS) . . . . . . . . . . . . . . . . . . . . . . 8
2.1.8 Packet Switching (PS) . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Numbering, addressing and identification . . . . . . . . . . . . . . . 9
2.2.1 International Mobile Subscriber Identity - IMSI . . . . . . . . 9
2.2.2 International Mobile Equipment Identity - IMEI . . . . . . . 10
2.2.3 Mobile Station International Subscriber Directory Number -
MSISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4 Globally Unique Temporary ID - GUTI . . . . . . . . . . . . 11
2.3 Numbering, addressing and identification within the IP multimedia
core network subsystem . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Home network domain name . . . . . . . . . . . . . . . . . . 12
2.3.2 Private User Identity . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3 Public User Identity . . . . . . . . . . . . . . . . . . . . . . . 13
v
2.4 LTE attach procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 IP Multimedia Subsystem - IMS . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Voice over LTE . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2 VoLTE Architecture . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 VoLTE Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.1 IMS Registration . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Tools 29
3.1 Open source IMSI Catcher . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 OpenAirInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1 OpenairCN - Core Network . . . . . . . . . . . . . . . . . . . 30
3.2.2 Openair5G - Access Network . . . . . . . . . . . . . . . . . . 30
3.2.3 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . 30
3.2.4 Computer used for experiments . . . . . . . . . . . . . . . . . 31
3.3 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 USRP B200mini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 IMEI 35
4.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Experiment description . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Change requested identity type . . . . . . . . . . . . . . . . . 37
4.3.2 Change definition of identity type . . . . . . . . . . . . . . . 38
4.3.3 IMSI Catcher Setup . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 My Own Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.1 Sending modified identity request . . . . . . . . . . . . . . . . 43
4.4.2 Modified identity request with most significant bit = 1 . . . . 44
4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 MSISDN Catchers 49
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Security in LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.1 The User Equipment . . . . . . . . . . . . . . . . . . . . . . . 50
5.3.2 Field Test Feature on iOS . . . . . . . . . . . . . . . . . . . . 52
5.4 Security of the MSISDN in VoLTE . . . . . . . . . . . . . . . . . . . 55
5.5 Leaks of private information in HTTP headers . . . . . . . . . . . . 55
5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6 Conclusion 61
6.1 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
References 63
Appendices
A OAI Installation 67
A.1 Kernel Configurations . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.2 Download OAI software . . . . . . . . . . . . . . . . . . . . . . . . 69
A.3 Installation of OAI EPC and eNB . . . . . . . . . . . . . . . . . . 69
ix
List of Tables
xi
List of Algorithms
xiii
List of Acronyms
AS Application Servers.
CC Country Code.
CD Check Digit.
CN Core Network.
CS Circuit Switched.
E-CSCF Emergency-CSCF.
xvii
EF Elementary File.
GW Gateway.
I-CSCF Interrogating-CSCF.
IPSec IP Security.
MITM Man-In-The-Middle.
MS Mobile Station.
OAI OpenAirInterface.
OS Operating System.
P-CSCF Proxy-CSCF.
PI Presentation Indicator.
PS Packet Switched.
S-CSCF Serving-CSCF.
SD Spare Digit.
SI Screening Indicator.
SN Subscriber Number.
UE User Equipment.
Importantly, I early prioritised to become familiar with the open source LTE imple-
mentation by OpenAirInterface (OAI), the documentation found on their website2 ,
and installation/operation of the software. In that way, knowledge about the experi-
mental possibilities was gathered early. Making it easier to think of possible relevant
experiments as I evolved my understanding of the problem area.
1.2 Outline
Chapter 2 gives an introduction to the essential parts of the LTE standard related
to the problem area of the thesis. Specifically, the overall architecture of the LTE
Evolved Packet System (EPS) as well as the involved entities, are explained. Also,
the IP Multimedia Subsystem (IMS) architecture is described with its respective
entities as well as the Voice over LTE (VoLTE) technology and security. Addressing
and Identification principles used in LTE and IMS are also covered.
1 http://www.3gpp.org/specifications/specification-numbering
2 http://www.openairinterface.org
1
2 1. INTRODUCTION
Chapter 3 presents the tools used in the experimental part of the thesis. Including
the open source LTE implementation by OAI, Universal Software Radio Peripheral
(USRP), and system information about the desktop computer used in the experiment.
Chapter 5 presents the work done related to the possibility of catching the Mobile
Station International Subscriber Directory Number (MSISDN) number. Specifically,
the chapter looks into the security of the MSISDN storage locations and procedures
involving the MSISDN. In the end, the findings are discussed.
Chapter 6 contains the overall conclusion of the thesis and a section about further
work.
Chapter
2 LTE
2.1 Architecture
This section will present the overall architectural design of the EPS. Interestingly,
the EPS is fully based on IP using Packet Switched (PS) connections for all com-
munication. Consequently, the network architecture has evolved from the solutions
we find in the legacy mobile networks. Basically, the EPS is divided into two parts:
the core network (Evolved Packet Core (EPC)) and the access network (E-UTRAN).
The following subsections will present the overall architecture and types of switching
in mobile networks. Including details about the entities found in both the EPS as
well as E-UTRAN part.
3
4 2. LTE
2.1.2 MME
The Mobile Management Entity (MME) can be seen as a control entity in the
architecture. Briefly, the role of the MME is to support functions for the control
plan in the EPS. Importantly, the MME is the termination point for the Non
Access Stratum (NAS) and is responsible for handling mobility signalling as well
as the security of the E-UTRAN access. Necessarily, the MME offers the listed
functionalities below as described in the 3GPP specification document [9] section
4.1.4.1:
– Inter Core Network (CN) node signalling for mobility between 3GPP access
networks
– Packet Data Network Gateway (PDN GW) and Serving Gateway (Serving
GW) selection
– Roaming
2.1. ARCHITECTURE 5
– Authentication
– User Location information at inter-system level: the HSS supports the user
registration, and stores inter-system location information
contains subscription details for IMS services like VoLTE. Basically, the HSS supplies
these subscription details to responsible entities during attach procedure and IMS
registration. In the attach procedure, the subscription details are provided to the
MME. Moreover, in the IMS registration procedure, subscription details are provided
to the Serving-CSCF (S-CSCF).
eNB is the type of base station used in E-UTRAN. It is responsible for providing the
user plane and control plane terminations towards the UE [5]. In detail, according
to [5], the eNB offers the following functionality:
2.1. ARCHITECTURE 7
– Functions for Radio Resource Management: Radio Bearer Control (RBC), Radio
Admission Control (RAC), Connection Mobility Control (CMC), Dynamic
allocation of resources to UEs in uplink, downlink, and sidelink
The S1 interface connects the eNB to the EPC via the MME.
– Mobile Network Code (MNC) consisting of two or three digits. MNC identifies
the home Public Land Mobile Network (PLMN) of the mobile subscriber.
Where the usage of two or three digits depends on the value of the MNC [10].
The MCC combined with a MNC identifies a specific mobile network.
– Mobile Subscriber Identification Number (MSIN) consisting of 9 or 10 digits,
identifies the mobile subscriber within a PLMN. MNC combined with the MSIN
is known as National Mobile Subscriber Identity (NMSI) and is allocated by
the national authority.
Conventionally, the allocation of IMSIs should be such that not more than the digits
MCC + MNC of the IMSI have to be analysed in a foreign PLMN for information
transfer [10].
The IMEI is a unique number for every mobile device using GSM, UMTS and LTE.
It is usually found printed on the phone underneath the battery and can also be
found by dialling the sequence *#06# [16]. Especially, the IMEI is used to validate
UE’s connecting to the mobile network. As a result, if the phone of a subscriber
is stolen, the subscriber can report the IMEI number of the stolen phone to his or
her network operator. Hence, the IMEI of the phone will be banned and it will not
be able to connect to the mobile network. Making it useless, independent of what
SIM-card the thief tries to use.
The Globally Unique Temporary ID (GUTI) provides the network with a distinct
identification type of the UE that does not reveal the UE or the permanent identity
in the EPS. Additionally, it permits identification of the network and the MME.
Specifically, the GUTI is composed of two main components:
– The first component uniquely identifies the MME that allocated the GUTI
– The second component uniquely identifies the UE within the MME that allo-
cated the GUTI
12 2. LTE
1. Take the first 5 or 6 digits (depending on the use of 2 or 3 digits in the MNC)
and separate them into MCC and MNC. In scenarios, where the MNC is 2
digits, a zero shall be added at the beginning.
2. Now, use the MCC and MNC derived in the first step to create the
"mnc<MNC>.mcc<MCC>.example.com" domain name.
To demonstrate this, the home network domain name example from [10] is shown in
2.1:
Home network domain Name 2.1 Derive Home Network Domain Name from
IMSI
IMSI in use: 234150999999999;
Then:
- MCC = 234
- MNC = 15
- MSIN = 0999999999
Which gives:
Home network domain name = ims.mnc015.mcc234.example.com
Note that when the phone number or MSISDN is used as a private user identity, and
the SIP URI form is used, a URI parameter (user=phone) must be added to the end,
specify that the phone number is used.
2. Attach request. Then, eNB reads the MME address from the RRC parameters
that holds the old GUMMEI and the selected network, which the UE included
in the Attach Request Message. Second, the eNB checks if the MME address is
associated with the eNB. If there are no association, the new MME is selected
by the MME selection function explained in [7] section 4.3.8.3. Finally, the
attach request message is forwarded to the MME. In addition, the eNB informs
the MME of the coverage level of the UE to help the location services [7].
– The old node type is MME. Initially, the new MME sends an identification
request (carrying the old GUTI + the complete attach request message)
to the old MME asking for IMSI. Then the old MME verifies the attach
request message by NAS MAC before responding with and identification
response including the IMSI.
– The old node type is SGSN.Just in the same way, the new MME sends
an identification request (carrying the old GUTI + the complete attach
request message). This time, the identification request is sent to the old
SGSN. Then, the old SGSN verifies the attach request message by the
P-TMSI signature. Lastly, the old SGSN responds with an identification
request containing the MM context. Specifically, the MM context holds
the IMSI number together with security related information [7].
16 2. LTE
In any event, if the old MME or SGSN do not recognise the UE or the verification
fails, they respond with a suitable error message back to the new MME. In
the situation of an emergency attachment, and the UE identifies itself with a
temporary identity unknown to the MME, the MME shall instantly ask the
UE for the IMSI. Whereas, if the UE identifies itself with IMEI, the MME will
skip the IMSI request [7].
4. Identity Request. Whenever, the UE is not known by the old MME, old
SGSN and new MME, an Identity Request is sent to the UE by the new MME.
In that case, the UE shall answer with an Identity Response carrying the IMSI
number. A timer named T3470 is used in case of a missing identity response. If
an identity response is not received after the timer expires, the original identity
request is re-transmitted to the UE and the timer is restarted. This process is
repeated four times. Besides, the parameter "identity type 2" contained in the
identity request message, specifies what type of identity the UE shall respond
with.
6. Ciphered Options Request. In the case where the UE has set the Ciphered
Options Transfer Flag (COTF) in the initial Attach Request message in (1), the
ciphered options shall be retrieved from the UE. These ciphered options could
be Protocol Configuration Options (PCO), Access Point Name (APN) or both.
Basically, they are used to handle scenarios where the UE has subscriptions
2.4. LTE ATTACH PROCEDURE 17
to multiple Packet Data Network (PDN)s. The UEs credentials and password
contained in the PCO + the APN are then needed in the MME.
7. Delete Session Request. If the UE re-attaches to the same MME without
completing the proper detach procedure, there can exist active bearer context
in the new MME for the UE. Consequently, the new MME deletes these bearer
contexts by sending Delete Session Request messages to the relevant Gateway
(GW)s. Further, the new MME receives an acknowledgement from the GWs
when the Delete Session Response messages are received. Finally, if Policy and
Charging Rules Function (PCRF) is used, the PDN GW initiate an IP-CAN
session termination procedure to indicate that resources have been released [7].
8. Update Location Request. An Update Location Request is sent to the HSS
in these cases:
9. Cancel Location. In this step, the HSS sends a Cancel Location message to
the old MME. The Cancel Location message contains the IMSI of the UE +
the cancellation type. Further, the old MME responds back to the HSS with a
Cancel Location Ack message and tear down the old UE context.
10. Delete Session Request. Then, if the old MME or SGSN has active bearer
contexts for the connecting UE, these bearer contexts are deleted by sending
Delete Session Request messages to the GWs involved. Next, Delete Session
Response messages are sent back from the involved GWs. Just in the same
way as seen in step (7), if PCRF is deployed, an IP-CAN Session Termination
procedure is executed.
11. Update Location Ack. After the old bearer contexts are deleted, the HSS
now acknowledges the received Update Location Ack Message (from step 8) by
sending an Update Location Ack message that carries the IMSI number and
subscription data of the connecting UE. Importantly, this response message
tells the new MME if the UE are allowed to attach to the network. If the
subscription data of the UE violate the actual access restrictions (e.g. regional
subscription restrictions), the UE can be denied access. Equally important, if
the UE connects in emergency mode, the MME shall ignore a negative received
Update Location Ack message and continue the attachment procedure.
18 2. LTE
12. Create Session Request. This step and step 12, 13, 14, 15 and 16 are only
initiated in the case where an EPS Session Management (ESM) container was
included in the attach request. Specifically, the ESM container includes these
parameters; Request Type, PDN Type, PCO, COTF and Header Compres-
sion Configuration [7]. In the case of an emergency attachment, parameters
from MME Emergency Configuration Data are applied for emergency bearer
establishment [35].
13. Create Session Request. At this point, a new entry in the EPS Bearer table
is made by the Serving GW. Further, the Serving GW sends a Create Session
Request message to the PDN GW
16. Create Session Response. A Create Session Response message is sent from
the Serving GW to the new MME.
18. RRC Connection Reconfiguration. In this step, the eNB sends the RRC
Connection Reconfiguration Message including the EPS Radio Bearer Identity
to the UE. Additionally, the Attach Accept message is sent to the UE.
20. Initial Context Setup Response. The eNB sends the Initial Context Setup
Response message to the new MME. Included in this message are the eNBs
corresponding Tunnel Endpoint Identifier (TEID) together with the eNB address
used for downlink traffic.
21. Direct Transfer Next, a Direct Transfer message is sent from the UE to the
eNB. The Attach Complete message is contained in the message.
22. Attach Complete Now, the eNB forwards the Attach Complete message
received from the UE in the previous step, to the new MME.
2.4. LTE ATTACH PROCEDURE 19
23. Modify Bearer Request At this point, the new MME has received both the
Initial Context Setup Response and the Attach Complete message from the
UE. Subsequently, the new MME sends a Modify Bearer Request message to
the Serving GW.
24. Modify Bearer Response Further, the Serving GW acknowledges the re-
ceived Modify Bearer Request from step 23, by sending a Modify Bearer
Response message to the new MME.
25. Notify Request The new MME sends a Notify Request message to the HSS,
holding the APN and PDN GW identity.
26. Notify Response Finally, the HSS saves the received identities and answer
the MME with a Notify Response message.
20 2. LTE
Basically, the IMS part connects to the PDN GW, PCRF, HSS and the Public
Switched Telephone Network (PSTN) or PLMN. The responsibilities of these entities
are as follows:
– The PDN GW is the EPC terminating point against the IMS part. Two bearers
are established, running from the IMS through the PDN GW, the core network
and out to the UE over the radio interface. Specifically, a signalling bearer +
a dedicated bearer for transportation of media content such as data, video or
voice are created.
– The PCRF is responsible for controlling the media flow. Briefly, typical tasks for
the PCRF can be to make policy decisions for active subscribers in the network
based on defined sets of rules or allocate needed bandwidth to dedicated call
bearers used in VoLTE. This functionality, is valuable seen from the point of the
Mobile Network Operator (MNO)s since the PCRF facilitates for differentiation
2.5. IP MULTIMEDIA SUBSYSTEM - IMS 21
The entities located in the IMS-part of Figure 2.8 are explained below. A more
detailed overview of the IMS architecture can be seen in Figure 2.11.
◦ Proxy-CSCF (P-CSCF). Seen from the UE side, the P-CSCF is the first
interaction point with the IMS network. Basically, the functionality is
similar to a proxy server. Requests from UEs or S-CSCF is transferred
to S-CSCF or S-CSCF or UE. Other important tasks is establishment
of IP Security (IPSec) association with UE during registration, resource
availability checks, making information used to charge users and transfer
emergency calls to Emergency-CSCF (E-CSCF).
◦ S-CSCF offers session control services. In case of an incoming call, the
S-CSCF forwards the received SIP INVITE message from Interrogating-
CSCF (I-CSCF) to AS or P-CSCF depending on the service required.
Further, the URI derived from the SIP INVITE message is replaced with
the IP address of the called UE.
◦ I-CSCF performs tasks on requests received from P-CSCF or S-CSCF.
Specifically, when the first SIP REGISTER request is received, an S-
CSCF is assigned to the UE and the message is forwarded there. This
functionality also demands some exchanges of DIAMETER messages with
the HSS [37]. When the second SIP REGISTER request and the first SIP
INVITE message (incoming call), the I-CSCF sends a query to the HSS
asking for the IP address of the S-CSCF associated with the UE before
transferring the message to that S-CSCF.
22 2. LTE
◦ MRF is responsible for controlling all media resources of the MRF Proces-
sor (MRFP). Also, it process information received from the S-CSCF and
use this to facilitate the controlling of the MRFP.
◦ MRFP is responsible for the generation of media flows within the regu-
lations controlled by MRF Controller (MRFC). Moreover, it can work
directly on the content of the media flows. e.g transcoding of audio media.
1. They can implement VoLTE, an IMS-based solution for carrying voice over a
PS LTE network.
VoLTE utilises the IMS technology for supporting voice traffic in the PS domain.
The 3GPP developed many of the main components used in VoLTE a long time
before it was implemented. The event that really started the collaboration towards
deployment of VoLTE was when GSM Association (GSMA) announced the VoLTE
initiative for driving the global mobile industry towards a standard way of delivering
voice and messaging services for LTE on 15 February 2010 [1]. Leading MNOs and in
total over 40 organisations from the mobile ecosystem backed the initiative. Already
Marc 2010, the reference document on IMS profile for voice and SMS was published
under the name IR.02 [28]. IR.92 is intended to ensure interoperable SIP-based
IMS Voice Over IP (VoIP) and SMS for UE’s and the LTE EPC [42]. Briefly, IR.92
specify the capabilities of the IMS technology. Additionally, supplementary services
for telephony, transport, codecs, media negotiation, LTE radio, Quality Of Service
(QOS) and bearer establishment is defined. Definitions of scenarios regarding roaming
were defined in a separate document named IR.88 [27].
2.5. IP MULTIMEDIA SUBSYSTEM - IMS 25
1. VoLTE UE
4. IMS core network. Responsible for providing the needed service layer for
multimedia telephony. Specifically, the entities making up the IMS core are
presented in Section 2.5.
Figure 2.11 shows a more detailed picture of the overall VoLTE architecture presented
earlier in Figure 2.8. The respective entities inside the IMS domain, described in
Section 2.5, can be seen in Figure 2.11 as well as the connections between them.
Figure 2.13: VoLTE UE Attachment and IMS Registration message sequence from
[13]
Chapter
3Tools
This chapter presents the tools used in this master thesis. Specifically, the principle
of an open source IMSI Catcher is explained. Followed by a brief presentation of the
OpenAirInterface software, the specifications of the computer used in the experiment,
and information about the USRP B200mini radio device.
1 http://openbts.org
2 http://openlte.sourceforge.net
3 http://www.openairinterface.org
4 http://openbsc.osmocom.org/trac/
29
30 3. TOOLS
implementation by OAI, together with a USRP B200mini radio device. These tools
will be explained next.
3.2 OpenAirInterface
The implementation of the LTE network used in this thesis is made by EUROCOM.
More specifically, the software is made by OpenAirInterface Software Alliance (OSA).
A separate entity from EUROCOM that specialises in providing an open source
ecosystem for the EPC and E-UTRAN protocols of 3GPP cellular systems [22].
The open source model has been a huge success and aims to be a tool used by
academia and the industry. Importantly, in the wireless industry, the major industrial
professional’s controls many of complex real-world systems. Therefore, the OSA is a
great contributor for building a stronger relationship between the academia and the
controlling industry part. Consequently, their knowledge and experiences can merge
into a strong foundation that the 5th generation mobile network can be specified
from.
The OAI LTE network implementation is divided into two parts; the core network
(EPC) and the access network (E-UTRAN). In the source code, the core network
part is named openairCN. On the other hand, the access network part is named
openair5G.
– USB 3.0 port is required for using hardware such as BladeRF, LimeSDR
and Ettus USRPs together with the OAI software. Since a USRP is used in
this thesis, the USB 3.0 port is essential on the computer dedicated to the
experimentation.
Moreover, the OAI software requires computers based on Intel architecture for eNB
or UE targets. Specifically, the software is well tested on the following processor
families:
3.3 Wireshark
In the mission of analysing the generated traffic from UEs connecting to the open
source IMSI Catcher, Wireshark is used5 in this master thesis. Wireshark is the
world’s foremost and widely-used network protocol analyser [45]. During the setup
of the open source IMSI Catcher explained in Section 4.3.3 in Chapter 4, a tcpdump
session is started. After completing an experiment, the tcpdump session was stopped,
and the captured traffic is saved to a Packet Capture (PCAP)-file. Wireshark is used
to open this PCAP-file, offering deep inspection of all the involved protocols.
5 https://www.wireshark.org
3.4. USRP B200MINI 33
4IMEI
In the process of building an MSISDN Catcher, the IMEI identity can be useful
additional information. E.g. imagine a scenario where an IMSI Catcher modified to
retrieve both IMEI and MSISDN identities is placed in an open area. The person
operating the IMSI Catcher has two persons in sight. One of the persons holds a
Samsung phone, the other person holds an iPhone. For simplicity, assume that only
these two phones connect to the IMSI Catcher. Now, the IMSI Catcher provides the
attacker with two identity pairs holding the MSISDN and the IMEI number. Then
the attacker uses an online IMEI lookup service, which returns information about
the brand or model of the mobile device1 . The first searched IMEI number, turns
out to belong to the Samsung phone. With that information, the attacker can link
one of the caught telephone numbers to the person that holds the Samsung phone.
Further, a lot of side channels can be used to find information tied to this specific
telephone number. Motivated by this, an experiment with the goal of revealing the
IMEI using an open source IMSI Catcher is presented in this chapter. A thorough
explanation of the IMSI Catcher setup as well as all the changes in the source code
are included. The experimentation was done in our Wireless Security Lab at times
when there were few people on campus.
35
36 4. IMEI
4.3 Configurations
The code shown in 4.1, is the relevant part to specify what identity type the core
network should ask the UE for. Normally, the requested identity type is IMSI. To
change this to IMEI, the ’type’ parameter on the last line in 4.1 must be changed
from ’type’ to ’2’. Where ’2’ corresponds to the index where "IMEI" is located in the
array named "*_emm_identity_type_str" shown at the beginning of 4.1. After this
change is done, next time a mobile phone attaches to the IMSI Catcher, the identity
request message will ask the UE to provide the IMEI.
/*
* Set the type of the requested identity
*/
data->type = type;
38 4. IMEI
In order to change the bit encoding of the identity types from 3-bit to 4-bit encoding,
the following was done:
1. First, specify IMEI as the requested identity. This is done in the same way as
explained in Section 4.3.1.
2. Modify the encoding of the identity type definition to use 4-bit instead of
3-bit. Firstly, the file where the identity type definition is coded must be found.
Searching the CN part of the OAI source code, the definition was found in the file
IdentityType2.c in the file path "openair-cn/SRC/NAS/IES/IdentityType2.c".
The working changes in this file to allow 4-bit encoding are shown in 4.2
3. Now, the source code allows specifying 4 bits in the definition of the iden-
tity types. In the file "IdentityTYpe2.h" located in the file path "openair-
cn/SRC/NAS/IES/IdentityType2.h" in the source code, the definition of the
identity types can be changed on bit-level. Change the definition of the IMEI
identity from "0b010" to "0b1010". The way to do this is shown in 4.3.
4.3. CONFIGURATIONS 39
Line 64:
change
"*identitytype2 = *buffer & 0x7;"
to
"*identitytype2 = *buffer & 0xF;"
Line 88:
change
"*(buffer + encoded) = 0x00 | (iei & 0xf0) | (*identitytype2 & 0x7);"
to
"*(buffer + encoded) = 0x00 | (iei & 0xf0) | (*identitytype2 & 0xF);"
Line 105:
change
"*(buffer + encoded) = 0x00 | (iei & 0xf0) | (*identitytype2 & 0x7);"
to
"*(buffer + encoded) = 0x00 | (iei & 0xf0) | (*identitytype2 & 0xF);"
2. Next, connect the USRP B200mini to the desktop computer with a USB 3.0
cable.
3. Further, the OAI eNB, EPC and HSS is built. To do this, automated build
scripts included in the OAI source code need to be executed. This is done by
running the code below in a terminal window:
$ cd ~/openairinterface
$ source oaienv
$ cd cmake_targets
$ ./build_oai -I --eNB -x --install-system-files -w USRP
$ ./build_oai -I --eNB -x --install-system-files -w EXMIMO
$ ./build_oai -I --eNB -x --install-system-files -w BLADERF
Note: Since the USRP B200mini is used in this experiment, only the first
./build command needs to be executed (for USRP). For explanation about the
options used in the command, run ’./build_oai -h’ to show the explanation
of each option. Importantly, the build process takes some time and will ask
for a password that will be used to access the MySQL database as a root user.
The HSS entity is preconfigured with ’linux’ as the password for accessing
the MySQL database. Consequently, it is recommended to use ’linux’ as the
password to simplify the configuration process.
Similarly, to run and build the automated scripts for the openair-cn part of
the OAI source code, run the following code in the terminal:
$ cd openair-cn
$ cd SCRIPTS
$ ./build_mme -i
$ ./build_hss -i
$ ./build_spgw -i
NOTE: These commands only needs to be executed one time for installing the
missing packages [19].
4.3. CONFIGURATIONS 41
Parameters Value
Tracking Area Code (TAC) 1 (Incremented)
Mobile Country Code (MCC) 242
Mobile Network Code (MNC) 06
Table 4.2: TAC, MCC, and MNC values
The value of TAC was incremented by one each time the eNB was restarted.
This was done because the tracking area update request message is not sent
from phones near the base station unless the observed TAC of the eNB has
changed.
By doing so, it is not necessary to restart the mobile phones between each
attempt. The MCC of Norway (242) was used [41].
5. Running eNB together with EPC and HSS. This is the last step and now the
LTE core network + eNB is started. First, required certificates are installed as
follows:
$ cd ~/openair-cn/SCRIPTS
$ ./check_hss_s6a_certificate /usr/local/etc/oai/
freeDiameter/hss.openair4G.eur
$ ./check_mme_s6a_certificate /usr/local/etc/oai/
freeDiameter/example.openair4G.eur
NOTE: On the last line, ’example’ need to match the chosen hostname/Fully
Qualified Domain Name (FQDN) explained in Appendix A.
Next, the HSS is compiled and started. It is important to always run the HSS
first:
$ cd ~/openair-cn
$ cd SCRIPTS
$ ./build_hss -c
$ ./run_hss -i ~/openair-cn/SRC/OAI_HSS/db/oai_db.sql
#Run only once to install database
$ ./run_hss #Run for all subsequent runs
$ cd ~/openair-cn/SCRIPTS
$ ./build_mme -c
$ ./run_mme
$ cd ~/openair-cn
$ cd SCRIPTS
$ ./build_spgw -c
$ ./run_spgw
Finally, the eNB (USRP) is started, providing radio access to our OAI EPC
for UEs near the base station:
$ cd ~/openairinterface5g
$ source oaienv
$ ./cmake_targets/build_oai -w USRP -x -c --eNB
$ cd cmake_targets/lte_build_oai/build
$ sudo -E ./lte-softmodem -O $OPENAIR_DIR/targets/PROJECTS
/GENERIC-LTE-EPC/CONF/enb.band7.tm1.usrpb210.conf -d
$ sudo tcpdump -i lo -w
/home/wlab/Desktop/docs/logs/capture.pcap
Now, all the necessary parts of the software are compiled and started. One green
and one red light will be visible in the front of the USRP B200mini, indicating that
all is working correctly. From this point, UEs inside the coverage area of the eNB
will be able to see the mobile network and can connect to it.
4.4. MY OWN RESULTS 43
Just in the same way, the requested identity type was changed to IMEI, following
the steps explained in Section 4.3.1. Figure 4.3 shows the captured identity request
message that is sent to the UE. Considering that the requested identity type now is
IMEI (seen on the last line in Figure 4.3), it can be concluded that the approach
described in Section 4.3.1 works.
In comparison to the attempt using the original source code and requesting the IMSI,
this attempt where the network asks the UE to provide its IMEI identity, results in
a different exchange of messages between the UE and the eNB. Figure 4.4 shows the
messages when the network asks for the IMEI. We can see that the identity response
message is missing. The UE is not willing to answer the identity request message
asking for the IMEI and ignores the multiple attempts from the network side. On the
OAI website, they state that hosting both the EPC + eNB on the same computer
can reduce real-time performance [19]. In step 4 of the attach procedure in Chapter
2, the timer T3470 is explained. Basically, this timer specifies how long the EPC
must wait before re-transmitting the identity request message in case of no identity
44 4. IMEI
response from the UE. To ensure that delays in the communication between the
UE and EPC are not the cause of no received identity response, different values for
the T3470 timer was tested. The original value is 6 seconds and can be changed as
explained in Appendix B. The experiment was then tested with T3470 values of 12
and 18 seconds. Still, the UE did not answer the network with an identity response.
Studying the information of Figure 4.5, the line on the bottom with blue outline shows
that the most significant bit now actually is 1 (1010 = Identity type 2: Unknown
(10)) and 4-bit encoding is working. Additionally, the corresponding decimal value
equal to 10 is given in parentheses in the end of the line. Therefore, we are now
sure that we have the same successful settings as used in the experiment from [33].
With that said, it seems like the trick with the most significant bit does not work
4.4. MY OWN RESULTS 45
in this case. As Figure 4.6 shows, the mobile network (IP address = 127.0.1.10)
sends multiple identity request messages to the UE (IP address = 127.0.0.1) without
receiving any identity response message from the UE. The same situation as when the
requested identity type was set to 2 (IMEI). This experiment was repeated multiple
times and no identity response messages were observed.
46 4. IMEI
4.5 Discussion
Motivated by the extra identification information the IMEI can give about the UE
as well as the successful experiment in the related work [33], a whole chapter was
dedicated for the IMEI experiment. The fact that no academic papers in my knowledge
have tried this using the OAI implementation of the EPS was also a motivation for
this experiment. The experiment description shows that the needed change of code
for manipulating the identity request procedure was relatively small. Interestingly,
the results show that specifying the IMEI as wanted identity in the identity request
procedure did not work. Captured traffic going between the connecting UE and the
eNB shows that the identity request messages actually ask for the IMEI. Moreover,
the length of the T3470 timer specifying how long the network shall wait for the
identity response from the UE was tested up to triple as long as the standard
value. Excluding the possibility of the identity response message being lost due to
delays. Therefore, the possibility for wrong code manipulation inside the EPC in the
experiment can most likely be excluded. The reason that the UE does not respond
with an identity response containing its IMEI number, may be located on the UE
side. This assumption is strengthened by the security specifications from 3GPP.
The serving network may request the UE to send the IMEI of the terminal, but the
UE shall only respond with the IMEI identity after the serving network has been
authenticated with exception of emergency calls [2]. This can explain why the UE
does not respond to the IMEI requests in this experiment since the serving network is
not authenticated by the UE. Importantly, this result is good news for the privacy of
LTE subscribers. On the other side, if the possibility of revealing the IMEI number
depends on the modem contained in the UE, then the security may vary in different
mobile phones. Therefore, it would be valuable to test a range of different UE types
for the potential IMEI reveal vulnerability. Moreover, the specification document
on how the UE should handle IMEI requests from the serving network states that
the UE shall provide the IMEI during an emergency call [2]. Hypothetically, the
emergency feature can be used to trick the modem in the UE to provide the IMEI
without authenticating the serving network. However, as explained in step 1 in the
LTE attach procedure from Chapter 2, the emergency mode is initiated by the UE.
Consequently, it may be impossible to trigger the emergency mode feature from the
attacker side, using an IMSI Catcher.
Chapter
MSISDN Catchers
5
5.1 Overview
Interestingly, there are not yet developed catchers for the MSISDN also known as a
telephone number. The telephone number is used in a range of different contexts
and can reveal much information about a person. This motivates for looking into the
possibilities of an MSISDN Catcher. This chapter is going to answer the research
questions (i) ’Is it possible to extends an IMSI Catcher to be an MSISDN Catcher?’
and (ii) ’How strong is the MSISDN number protected?’. The context for these
questions is a study of the security in the LTE standard regarding the MSISDN.
Considering the LTE standard is relatively new, some shortcuts were made during
the transition from UMTS to LTE. Based on the fact that LTE is purely IP-based,
voice and data traffic would be transported over packet switched connections.
Many network operators that were eager to implement the LTE standard, used a
solution called CSFB for voice transport in the beginning. Including Telenor in
Norway [43]. Because the voice part of LTE named VoLTE was delayed, CSFB
was used as a temporary solution. Basically, what CSFB does is downgrading the
connection to UMTS or GSM when a call is made or received on an LTE-connected
UE. In that way, the voice traffic is carried over the circuit switched architecture
used in the older standards. More details about the CSFB can be found in the
specification document at [12]. Consequently, the protection of the MSISDN in
the UMTS standard most also be considered when analysing how good MSISDN is
secured in LTE.
49
50 5. MSISDN CATCHERS
The paper ’Privacy Leaks in Mobile Phone Internet Access’ studies if and how private
mobile subscriber information is leaked through mobile phone-based web access [34].
Specifically, the paper focus on how private information is leaked from mobile phones
through Hypertext Transfer Protocol (HTTP) headers. The author used his own
website to log all the HTTP headers from the traffic generated by the mobile phone
users connecting to the website. From the analysis of the logged traffic, they collected
1183 phone numbers. By studying the CC part of the collected MSISDN (explained
in the LTE chapter), the nationality of the phone numbers can be identified. From
the total collected phone numbers, they found that they came from 67 different
countries. The fact that MSISDN actually was leaked through the HTTP headers
makes this work relevant for this chapter.
The paper ’Detection of Side Channel Attacks Based on Data Tainting in Android
Systems’ analyses 100 Android applications for possible leakage of sensitive data
through side channels [26]. Interestingly, they found that 35% of the applications
leaked private information through side channels. Side channel attacks can potentially
leak private info, including the MSISDN. These findings make the paper relevant for
this chapter, as an alternative attack strategy compared to the principle of an IMSI
Catcher.
new smart card used in UMTS and LTE, SIM refers only to the software. Specifically,
the software part holding information used for identification and authentication was
named USIM. The terminology of the hardware part is UICC. The ISIM application
is used for access to IMS services [3]. Practically, the ISIM application also allows
secure access to other independent services like payment.
TS 31.102 by 3GPP specifies that the MSISDN of the subscriber registered to the
UICC can be stored in the USIM application [4] residing on the UICC. Figure 5.1
shows the Elementary File (EF) MSISDN contained in the USIM application. The
EF can hold multiple MSISDNs related to the subscriber. In addition to the MSISDN,
the file holds information such as identifiers of associated network bearer capabilities.
Interestingly, the access restrictions on the EF for reading the MSISDN is set to PIN
(see Figure 5.1). Which means that the user of the phone must type their PIN-code
to read the MSISDN stored in the USIM application. Motivated by this, the next
section will explain a way to read the MSISDN stored on the UICC on an iPhone
running iOS 10.
Let us take a look at the EF MSISDN in Figure 5.1. The MSISDN itself is found
in the Dialling Number or SSC String parameter with a length of 10 bytes. The
Type of Number (TON) with length of 1 byte is the last byte before the MSISDN.
Basically, as the name describes, the TON tells the type of the number. According
to the GSM specification document 03.40 from [18], TON can have these values:
1. Unknown
52 5. MSISDN CATCHERS
2. International number
3. National number
5. Subscriber number
6. Alphanumeric number
7. Abbreviated number
In our case, we want to see if we can retrieve the MSISDN stored on the UICC. To
do this, you shall navigate to the SIM info choice in the main menu in Figure 5.2.
That will bring up the menu shown in Figure 5.3.
5.3. SECURITY IN LTE 53
Figure 5.3: Screenshot of the SIM Info page showing the EF-MSISDN
54 5. MSISDN CATCHERS
Of privacy reasons the actual values of the different parameters are removed in
Figure 5.3, but the MSISDN was actually readable in this menu on the line holding
the ’EF-MSISDN’ parameter. With that said, the MSISDN is stored in a special
manner. Specifically, the format is like this: ’FFF....FFF’. Where the dots represent
the fields listed in Figure 5.1. The MSISDN can be found in inverted Binary Coded
Decimal (BCD) format. Subsequently, the conversion back to the default form can
be illustrated by a short example:
From a security perspective, the MSISDN was relatively easy to retrieve from the
UICC when you have access to the phone and the phone is powered on. The phone
did not ask for the PIN-code during the Field Test procedure. This means that the
USIM application authenticates the user for reading privileges after the PIN-code has
been entered successfully when powering on the phone. After that, the only security
mechanism protecting the information stored on the UICC including the MSISDN
is the eventual personal password the user of the phone has activated. Considering
that most regular users never will access this part of the UICC, it is few or none
arguments for not requesting the PIN when using this special feature. That will add
an additional layer of security, especially important in cases where the user does
not have a personal password at all on the phone. With that said, this method
of revealing the MSISDN requires the attacker to have physical access to the UE.
Maybe, social engineering can be an option also, but it is no obvious way of using a
modified IMSI Catcher to retrieve the MSISDN from this storage location.
5.4. SECURITY OF THE MSISDN IN VOLTE 55
1 https://www.1881.no
2 https://www.gulesider.no
5.6. DISCUSSION 57
5.6 Discussion
The way we use telephone numbers today has definitely evolved from the beginning.
In addition to identification during call setup, the telephone number is often used in
eg. mobile authentication where a secret code is sent to the phone number. Also,
phone numbers are often used as identification for additional mobile services and
often presented on social media. As a consequence of the huge digitisation during
the past decades on many platforms, services previously offered in written format is
now available online offering efficient searching mechanisms. E.g. the traditionally
physical telephone books holding the telephone numbers to all subscribers in a
geographic area was eventually digitised and published online. Gulesider and 1881
are examples of online telephone books in Norway3,4 . Importantly, this trends of
pushing increasing amounts of information online implicate a change of vulnerabilities
and threats. With online telephone books presenting the affiliation between MSISDN
and the subscriber, a reverse lookup can in many cases be conducted on caught
MSISDNs with little effort. In that way, the attacker can easily find the owner
of the telephone number. Further, the name of the subscriber can again be used
in searches towards social media, institutions, news and more. Dramatically, the
ability of catching the phone numbers of UEs near the base station, will expand
the amount of privacy invasion channels available for unlawful attackers. Earlier,
these information channels were restricted to the authorities and the MNOs because
reverse lookup services on IMSI numbers are not available to the public.
using a traditional IMSI Catcher may be impossible. Hence, the only way to reveal
the MSISDN by going after the stored value on the UICC is by physical access to
a powered on mobile telephone with no personal password activated. Thus, this
storage location of the MSISDN may seem less important to secure since the only
exploit possibility is by physical access to the phone. With that said, permissions
for subscriber related information stored in UICC applications should be protected.
As found in the paper ’Detection of Side Channel Attacks Based on Data Tainting
in Android Systems’, mobile applications can leak private information through side
channels, including the MSISDN [26]. On one hand, the traditional IMSI Catcher
may not be able to retrieve the MSISDN directly from the UICC. On the other hand,
a mobile application specified to leak the MSISDN through side channels back to the
developer can be a possibility.
Moving over to the network procedures involving the MSISDN, voice communication
is essential. The solution for voice communication in LTE is mainly provided by
VoLTE or CSFB. Thinking of the behaviour of an IMSI Catcher, the ability of
monitoring or intercepting the traffic going between the UE and eNB seems like
a good strategy. Specifically, intercepting a voice call during setup and then try
to extract the MSISDN. However, all VoLTE subscribers are forced to initiate the
IMS registration procedure after the ordinary LTE attach. Involving establishment
of IPSec encryption of all subsequent communication. Which makes it difficult to
decrypt potential captured voice traffic. If a call is made on a mobile network which
has implemented CSFB technology for voice communication, then the connection
falls back to solutions implement in legacy networks. The needed signalling inside the
EPS to support CSFB are actually protected by the LTE security mechanisms [23].
However, the security of the legacy part that actually offers the CS voice service, may
not be secured in the same way as inside the EPS. Interestingly, the act of browsing
the Internet over HTTP can reveal the MSISDN of the MS. The way HTTP proxies
operated by MNOs, inject additional HTTP headers holding private information is
known as the HTTP header enrichment feature. Basically, MNO uses this feature for
operational purposes, but also to assist advertising programs to identify subscribers
responsible for generating the traffic [44]. This is a serious privacy concern and
the HTTP traffic can by this technology be linked to the telephone number of the
visitor. Subsequently, side channels of information previously discussed, can be used
to harvest even more detailed information about the visitor. By using the more
secure communication protocol Hypertext Transfer Protocol Secure (HTTPS), the
problem is solved. In order to perform header injection in HTTPS traffic, the Internet
Service Provider (ISP) have to execute Transport Layer Security (TLS) interception
of the traffic [44]. After all, the subscriber should be aware of the private information
that may be leaked from HTTP traffic, originating from their phones.
5.6. DISCUSSION 59
Considering the first research question defined in chapter 1; "Can an IMSI Catcher
be extended to catch MSISDN?", the findings point in another direction.
Software and tools used for the IMEI experiment were shown in Chapter 3.
Chapter 5 investigates the security of where the telephone number is stored in the
network, as well as the procedures that include the MSISDN. It was found that the
MSISDN primarily was stored in the HSS. Optionally, the MSISDN could be stored
in the USIM application located on the UICC. Besides, it was found that there is
no implemented request procedure meant for asking the UE about providing the
MSISDN to the network. Another essential point was that IMS initiate encryption
of traffic during the mandatory IMS registration process. As a result, revealing
MSISDNs by interception of voice calls (VoLTE) becomes very difficult. These
61
62 6. CONCLUSION
findings contribute to the conclusion that it is no obvious way of using the principle
of an IMSI Catcher to build an MSISDN Catcher.
Despite this, related work shows that MSISDN can be leaked in HTTP headers and
through side channels of Android applications. Furthermore, it was shown how to
read the MSISDN from the USIM application using the field test feature in iOS.
Considering these findings, it can be concluded that there are possibilities for building
an MSISDN Catcher. In summary, this master thesis found that the MSISDN and
IMEI are well protected against open source LTE IMSI Catchers. However, the
secrecy of the telephone number may not resist social attacks nor mobile applications
exploiting information leakage through side channels.
[5] 3GPP. Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved
Universal Terrestrial Radio Access Network (E-UTRAN); Overall description;
Stage 2. TS 36.300, 3rd Generation Partnership Project (3GPP), April 2017.
[6] 3GPP. Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment
(UE) radio transmission and reception. TS 36.101, 3rd Generation Partnership
Project (3GPP), April 2017.
[7] 3GPP. General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access. TS 23.401, 3rd Generation
Partnership Project (3GPP), March 2017.
[11] 3GPP. Policy and charging control architecture. TS 23.203, 3rd Generation
Partnership Project (3GPP), March 2017.
63
64 REFERENCES
[12] 3GPP. Technical Specification Group Services and System Aspects; Circuit
Switched (CS) fallback in Evolved Packet System (EPS); Stage 2 (Release 14).
TS 23.272, 3rd Generation Partnership Project (3GPP), March 2017.
[13] GSM Association et al. Volte service description and implementation guidelines
version 2.0, 2014.
[15] Adrian Dabrowski, Nicola Pianta, Thomas Klepp, Martin Mulazzani, and Edgar
Weippl. Imsi-catch me if you can: Imsi-catcher-catchers. In Proceedings of the
30th annual computer security applications Conference, pages 246–255. ACM,
2014.
[18] GSM ETSI. 03.40. Digital cellular telecommunications system (Phase 2+), 1.
[23] Dan Forsberg, Günther Horn, Wolf-Dietrich Moeller, and Valtteri Niemi. Security
for voice over lte. LTE Security, Second Edition, pages 215–232, 2010.
[25] 3GPP MCC Frédéric Firmin. The Evolved Packet Core. http://www.3gpp.
org/technologies/keywords-acronyms/100-the-evolved-packet-core, 2017. [Online;
accessed 29-May-2017].
REFERENCES 65
[26] Mariem Graa, Nora Cuppens-Boulahia, Frédéric Cuppens, Jean-Louis Lanet, and
Routa Moussaileb. Detection of side channel attacks based on data tainting in
android systems. In IFIP International Conference on ICT Systems Security and
Privacy Protection, pages 205–218. Springer, 2017.
[28] GSMA. IR.92 IMS profile for voice and SMS V10.0. http://www.gsma.com/
newsroom/all-documents/ir-92-ims-profile-for-voice-and-sms/, 2016. [Online;
accessed 27-May-2017].
[30] ITU-T. The international identification plan for public networks and subscrip-
tions. Recommendation E.212, ITU Telecommunication Standardization Sector,
September 2016.
[33] Benoit Michau and Christophe Devine. How to not break LTE crypto.
https://www.sstic.org/media/SSTIC2016/SSTIC-actes/how_to_not_break_
lte_crypto/SSTIC2016-Article-how_to_not_break_lte_crypto-michau_
devine.pdf, 2016. [Online; accessed 20-April-2017].
[34] Collin Mulliner. Privacy leaks in mobile phone internet access. In Intelligence in
Next Generation Networks (ICIN), 2010 14th International Conference on, pages
1–6. IEEE, 2010.
[35] RCR Wireless News. LTE Attach Procedure Call Flow. http://www.rcrwireless.
com/20140509/wireless/lte-attach-procedure-call-flow, 2014. [Online; accessed
11-May-2017].
[36] Christopher A Parsons and Tamir Israel. Gone opaque? an analysis of hypothetical
imsi catcher overuse in canada. 2016.
[37] Andre Perez. Voice over LTE: EPS and IMS networks. John Wiley & Sons, 2013.
[38] Miikka Poikselkä, Harri Holma, Jukka Hongisto, Juha Kallio, and Antti Toskala.
Voice over LTE (VoLTE). John Wiley & Sons, 2012.
[40] Torjus Bryne Retterstøl. Base station security experiments using usrp. Master’s
thesis, NTNU, 2015.
[41] SMScarrier.EU. Mobile Country Codes (MCC) and Mobile Network Codes
(MNC). http://www.mcc-mnc.com, 2017. [Online; accessed 2-May-2017].
[42] SPIRENT. IMS Architecture - The LTE User Equipment Per-
spective. https://www.spirent.com/~/media/White%20Papers/Mobile/IMS_
Architecture_White_Paper.pdf, 2014. [Online; accessed 27-May-2017].
[43] tek.no. Telenor åpner 4G for mobiltelefoner. https://www.tek.no/artikler/
telenor-apner-4g-for-mobiltelefoner/115029, 2012. [Online; accessed 21-April-
2017].
[44] Narseo Vallina-Rodriguez, Srikanth Sundaresan, Christian Kreibich, and Vern
Paxson. Header enrichment or isp enrichment?: Emerging privacy threats in
mobile networks. In Proceedings of the 2015 ACM SIGCOMM Workshop on Hot
Topics in Middleboxes and Network Function Virtualization, pages 25–30. ACM,
2015.
[45] Wireshark. Wireshark. https://www.wireshark.org, 2017. [Online; accessed
10-june-2017].
[46] RF Wireless World. LTE tutorial. http://www.rfwireless-world.com/Tutorials/
LTE-tutorial.html, 2017. [Online; accessed 12-May-2017].
Appendix
OAI Installation
A
A.1 Kernel Configurations
Before installing the OAI software, the system requirements presented in chapter 3
must be fulfilled. Then the right OS must be installed. In this thesis, the standard
64-bit Ubuntu 14.04 version is used. After the installation is done, the correct kernel
configuration must be applied. The kernel version used is kernel 3.19 low-latency.
The kernel is installed as follows:
To check that the installation was correct, restart the computer and the command
’uname -a’ in the terminal should give the following output:
1 https://askubuntu.com/questions/523640/how-i-can-disable-cpu-frequency-scaling-and-set-
the-system-to-performance
67
68 A. OAI INSTALLATION
$ GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_pstate=disable"
$ "processor.max_cstate=1 intel_idle.max_cstate=0 idle=poll"
Then run the command "update-grub". Further, the intel_powerclamp module must
be blacklisted by appending "blacklist intel_powerclamp" to the end of the black-
list.conf file located in /etc/modprobe.d/. Finally, hyperthreading, CPU frequency
control, P-states and C-states are disabled from BIOS. To check that the disablement
of the power management features was successful, a CPU utility named i7z can be
useful. Do the following to install i7z:
The output from i7z is shown in figure A.1. Check that hyperthreading is off, that
only C-state C0 is active and that the CPU do not change its frequency with more
than 1-2 Hz
The last step in the kernel configuration process is to disable CPU frequency scaling
in Linux. Install the tool cpufrequtils for this task:
The repository named Ooenairinterface5g contains the source code for the implemen-
tation of eNB RAN and UE RAN. The openair-cn repository holds the source code
of the EPC part. To download the repositories from the gitLab server, go to the
terminal and type the following:
2 https://gitlab.eurecom.fr/oai
70 A. OAI INSTALLATION
Change the hostname to the one you want and then save the file. The computer may
need to restart, before the updated hostname/FQDN take effect [19]. Further, the
correct FQDN must be updated in the file /etc/hosts. Let us say that the correct
FQDN is ’example’. Then the correct content of the /etc/host file should be:
127.0.0.1 localhost
127.0.1.1 example.openair4G.eur example
127.0.1.1 hss.openair4G.eur hss
OAI eNB Machine Configuration
Appendix
B
This appendix, presents the correct configuration to use in an experimental setup run-
ning eNB and EPC on the same host computer. After the installation steps explained
in appendix A, configuration files included in the source code must be updated. First,
check that the right parameters are given in the eNB configuration file located in the
"openairinterface5g" folder (~/openairinterface5g/targets/PROJECTS/GENERIC-
LTE-EPC/CONF/enb.band7.tm1.usrpb210.conf):
tracking_area_code = "1";
mobile_country_code = "208";
mobile_network_code = "92";
ENB_INTERFACE_NAME_FOR_S1U = "lo";
ENB_IPV4_ADDRESS_FOR_S1U = "127.0.6.2/8";
ENB_PORT_FOR_S1U = 2152; # Spec 2152
};
71
72 B. OAI ENB MACHINE CONFIGURATION
The three top lines are important for the experimental configurations. Here, the
TAC, MCC and MNC is configured. mme_ip_address shall be configured to the
IP address of the network interface of the OAI EPC. NETWORK_INTERFACES
holds network interface details of the OAI eNB.
The next step is to copy the configuration files provided in the OAI software over
to local storage on the host computer (/usr/local/etc/oai):
REALM = "openair4G.eur";
S6A :
{
S6A_CONF = "/usr/local/etc/oai/freeDiameter/mme\_fd.conf";
HSS_HOSTNAME = "hss";
};
GUMMEI_LIST = (
{MCC="208" ; MNC="92"; MME_GID="4" ; MME_CODE="1"; }
);
TAI_LIST = (
{MCC="208" ; MNC="92"; TAC = "1"; }
);
NETWORK_INTERFACES :
{
MME_INTERFACE_NAME_FOR_S1_MME = "lo";
73
MME_IPV4_ADDRESS_FOR_S1_MME = "127.0.1.10/8";
S-GW :
{
# S-GW binded interface for S11 communication (GTPV2-C),
if none selected the ITTI message interface is used
SGW_IPV4_ADDRESS_FOR_S11 = "127.0.8.1/8";
};
GUMEI_LIST and TAI_LIST holds the MCC and MNC. When specifying
the MCC and MNC, both the MME configuration file (mme.conf) and the eNB
configuration file (enb.band7.tm1.usrpb210.conf) must be updated with the correct
values.
S-GW :
{
NETWORK_INTERFACES :
{
SGW_INTERFACE_NAME_FOR_S11 = "lo";
SGW_IPV4_ADDRESS_FOR_S11 = "127.0.8.1/8";
SGW_INTERFACE_NAME_FOR_S1U_S12_S4_UP = "lo";
SGW_IPV4_ADDRESS_FOR_S1U_S12_S4_UP = "127.0.6.1/8";
SGW_IPV4_PORT_FOR_S1U_S12_S4_UP = 2152;
...
}
P-GW =
{
NETWORK_INTERFACES :
{
# P-GW binded interface for S5 or S8 communication
PGW_INTERFACE_NAME_FOR_S5_S8 = "none";
PGW_IPV4_ADDRESS_FOR_S5_S8 = "0.0.0.0/24";
Identity = "hss.openair4G.eur";
Realm = "openair4G.eur";
Identity = "example.openair4G.eur";
Realm = "openair4G.eur";
ConnectPeer= "hss.openair4G.eur" { ConnectTo = "127.0.33.1";
No_SCTP ; No_IPv6; Prefer_TCP; No_TLS; port = 3868;
realm = "openair4G.eur";};
MYSQL_user = "root";
MYSQL_pass = "linux";
OPERATOR_key = "1006020f0a478bf6b699f15c062e42b3";
To change the timer from the standard value of 6 seconds, change the number on the
last line from 6 to the desired value.
Appendix
USRP B200mini Series
Architecture C
77