encrypting imsi to improve privacy in 5g networks1095875/fulltext01.pdf · 2017-05-16 · this...

IN DEGREE PROJECT ELECTRICAL ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2017

Encrypting IMSI to improve privacy in 5G NetworksDouble Degree Program KTH-UPM

ENRIQUE COBO JIMÉNEZ

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

Master Thesis Report

Title: Encrypting IMSI to improve privacy

in 5G networks

Author: Enrique Cobo Jiménez

Supervisors: Christian Schaefer

Prof. Mats Näslund

A�liation 1: School of Information and

Communication Technology

School of Electrical Engineering

KTH Royal Institute of Technology

A�liation 2: ETS de Ingenieros de Telecomunicación

UPM Technical University of Madrid

TRITA: ICT-EX-2017:19

Thesis Committee

President: Prof. Elena Dubrova

Member: Prof. Mark T. Smith

AcademicAdvisor: Sha Tao

Opponent: Vicent Molés Cases

SCORE:

Stockholm, 23rd of March, 2017

Abstract

Nowadays, the long-term identi�er of a user in a mobile network, namely Interna-tional Mobile Subscriber Identity or IMSI, is transmitted in clear text over the radiointerface. Given that this interface is used as a shared medium, anyone with a radiotransceiver and processing software can thus read such identi�er.

This fact constitutes a threat to user privacy, considering that the user is traceableby following the presence of the identi�er in the network. Moreover, the menace hasbeen known in the literature for the last 25 years, but no countermeasures have beendeployed because the severity was judged not to be su�ciently high.

However, the current situation is di�erent. One the one hand, the user is mademore vulnerable: the needed equipment for catching IMSIs over the radio interfaceis becoming cheaper, while user-related connected devices are arising in the form ofInternet of Things. On the other hand, mobile devices are now computationally morepowerful, and the upcoming standardization of 5G represents an opportunity to addresssuch issues.

This dissertation presents a proposal to encrypt the IMSI based on Elliptic CurveIntegrated Encryption Scheme, a public-key approach in which the long-term subs-cription identi�er is concealed over the radio interface. By doing so, the IMSI is neverpublicly disclosed, and thus privacy is enhanced.

Besides, research was conducted to show the technical feasibility of the proposal.First, the impact of the encrypted identi�er on the network was studied. Secondly,the execution time needed for Android devices to perform encryption operations wasmeasured. In both cases, the results were favorable, drawing the conclusion that thereare no impediments to the adoption of the presented solution.

The Thesis was developed in cooperation with Ericsson AB, Security Research.

KEY WORDS : 5G ; Privacy ; IMSI ; Security ; ECIES ; Android.

v

Sammanfattning

Den långsiktiga identi�eraren för en användare i ett mobilt nätverk, IMSI (Interna-tional Mobile Subscriber Identity), överförs i klartext via radiogränssnittet. Med dettagränssnitt som delat medium kan någon med en radiomottagare och mjukvara läsasåna identi�erare.

Detta utgör ett hot mot användarnas personliga integritet med tanke på att använ-daren kan spåras genom att följa förekomsten av identi�erare i nätverket. Dessutomhar hotet varit känt under de senaste 25 åren, men inga åtgärder har använts eftersomatt risken bedömdes inte vara tillräckligt hög.

Däremot är den nuvarande situationen annorlunda. Å ena sidan är användarenmer sårbar: den utrustning som behövs för att fånga IMSI över radiogränssnittet blirbilligare medan antalet användarrelaterade anslutna enheter ökar. Å andra sidan kanmoderna mobila enheter utföra mycket mer beräkningar, och den kommande standar-diseringen av 5G utgör en möjlighet att lösa sådana problem.

Rapporten presenterar ett förslag för att kryptera IMSI baserat på ECIES (EllipticCurve Integrated Encryption Scheme), en asymmetrisk-kryptogra� algoritm där denlångsiktiga identi�eraren är dold över radiogränssnittet. Genom att göra så avslöjasaldrig IMSI, och därmed förbättras den personliga integriteten.

Dessutom har forskning bedrivits för att visa den tekniska genomförbarheten avförslaget. Först studerades e�ekten av den krypterade identi�eraren i nätverket. Sedanmättes exekveringstiden som krävs för Android-enheter för att utföra krypteringsope-rationer. I båda fallen var resultaten gynnsamma, och därav dras slutsatsen att detinte �nns några hinder för antagandet av den presenterade lösningen.

Denna rapport framställdes i samarbete med Ericsson AB, Security Research.

NYCKELORD : 5G ; Personlig Integritet ; IMSI ; Säkerhet ; ECIES ; Android.

vii

Resumen

En la actualidad, el identi�cador �jo de un usuario en una red móvil, denomina-do IMSI (International Mobile Subscriber Identi�er), se envía en texto plano sobrela interfaz radio. Puesto que dicha interfaz es un medio compartido, cualquiera consu�ciente equipamiento radio y software de procesamiento puede por tanto obtener elidenti�cador.

Este hecho reduce la privacidad de los usuarios en la red móvil, puesto que cual-quier usuario es por tanto localizable siguiendo el rastro de su identi�cador. Además,esta vulnerabilidad es bien conocida desde hace 25 años, pero no se adoptaron contra-medidas debido a que la amenaza no fue considerada como su�cientemente severa.

Sin embargo, la situación está cambiando. De un lado, el usuario es cada vez másatacable: el equipamiento necesario para obtener IMSIs desde la interfaz radio es cadavez más barato, mientras que emergen nuevos terminales en el denominado Internet delas Cosas que también exponen al usuario que los porta. Del otro lado, los terminalesmóviles actuales son cada vez computacionalmente más potentes, y la inminente estan-darización de 5G representa una oportunidad para solventar estas vulnerabilidades.

Este Trabajo Fin de Máster presenta una propuesta para cifrar el identi�cador IMSIque se basa en ECIES (Elliptic Curve Integrated Encryption Scheme), un sistema decriptografía asimétrica en el que el IMSI se oculta en la interfaz radio. De esta manera,dicho identi�cador no se revelaría nunca en un canal público, mejorando de esta manerala privacidad del usuario en redes 5G.

Además, se llevaron a cabo estudios para demostrar la viabilidad técnica de lapropuesta. En esta línea, se evaluó el impacto que tendría el uso del identi�cadorcifrado en la red, así como el tiempo requerido para completar el cifrado en dispositivosAndroid. Los resultados en ambos casos fueron favorables, concluyendo por tanto queno hay impedimentos técnicos para la implementación de la misma.

Este trabajo fue desarrollado en colaboración con Ericsson AB, Security Research.

PALABRAS CLAVE : 5G ; Privacidad ; IMSI ; Seguridad ; ECIES ; Android.

ix

Acknowledgements

After Jaén, Madrid, and now Stockholm; after a Bachelor's Degree, a Master'sDegree and a Double Degree; in short, after 24 years, 5 months and some days, itis time to move. Now we say goodbye to the student stage to put into practice theknowledge and the skills acquired with e�ort and dedication during these years, andto face new challenges and problems in the real world.

But, of course, I have never been alone in this journey. I would like to dedicatesome words to all these people that have walked with me during all this time.

First, I would like to thank all the people at Ericsson, Security Research. It wasvery nice to do the thesis with them, I have learned a lot from this experience. Tobe honest, I must say that I always found a helping hand whenever I needed. I wouldespecially acknowledge Christian and Mats, my supervisors, for their implication inthe work and for their valuable advises; and Prajwol, who really acted as an advisorin the shade, for all the dedication and support he put in the Thesis.

What to say about all the people I met during this experience in Stockholm andLappis: Alfonso, Viktor, Mathilde, Pablo, Clara, Hamza, Giorgos, Rasines, Diego, Car-los, Vicent, Atsushi, Marie, Irene, Mikael, Masuma,... (sorry, but I had to stop at somepoint): you made it special. I wish I gave you at least half of what I received from you.In�nite thanks.

I can not fail to acknowledge my people from Spain: my whole-life friends la manadade Jaén NP, my colleagues in su�ering los pencos de la ETSIT, and my dorm-matesmendelianos. I am aware that I have been a bit disappeared during this year and ahalf, but precisely here is where the secret of friendship lies: �True friends are like stars,you can't always see them, but you know they're always there�.

Last but not least. To my family: my parents, sister, grandparents, cousins, uncles,and aunts. First, the chaval decided to go to the University in Madrid, and �ve yearslater he decided to move to Sweden (½con el frío que hace! ). And yes, I am using thecorrect verb, because you never put any obstacle throughout this journey, although Isuppose this has been di�cult for you. At least I hope that the Telecommunications,whose development I would like to contribute in the future, worked well and you feltme close, despite the distance. Today, I am who I am thanks to you.

And, �nally, to you...

Enrique Cobo Jiménez

xi

Table of Contents

Abstract; Sammanfattning; Resumen v

Acknowledgements xi

1. Introduction 1

1.1. Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3. Report Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Background 7

2.1. 4G Architecture model . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.1. Network elements . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2. Network architecture . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Identi�cation of Mobile Subscribers . . . . . . . . . . . . . . . . . . . . 92.2.1. IMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2. GUTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3. Others: MSISDN and IMEI . . . . . . . . . . . . . . . . . . . . 10

2.3. Control signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1. General overview . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2. The Attach procedure . . . . . . . . . . . . . . . . . . . . . . . 132.3.3. Lawful Interception . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4. Fundamentals on cryptography . . . . . . . . . . . . . . . . . . . . . . 162.4.1. Asymmetric cryptography . . . . . . . . . . . . . . . . . . . . . 162.4.2. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . . . . 182.4.3. Other cryptographic tools . . . . . . . . . . . . . . . . . . . . . 19

3. Review Study 25

3.1. Traditional public-key schemes . . . . . . . . . . . . . . . . . . . . . . . 253.2. Attribute-based encryption . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.1. Key-Policy Attribute-Based Encryption . . . . . . . . . . . . . . 273.2.2. IBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3. Pseudonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4. Enhancing Long-Term Identi�er Privacy 33

4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

xiii

xiv Table of Contents

4.2. KP-ABE implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.1. Length analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.2. Local-AuS implementation . . . . . . . . . . . . . . . . . . . . . 37

4.3. Traditional public-key scheme (RSA) . . . . . . . . . . . . . . . . . . . 384.4. Elliptic Curve Integrated Encryption Scheme . . . . . . . . . . . . . . . 404.5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5. Encrypted IMSI based on ECIES 455.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1.2. Suggested Elliptic Curves and Software implementation . . . . . 48

5.2. Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2.1. Modi�cations on equipment . . . . . . . . . . . . . . . . . . . . 505.2.2. Protocol modi�cations . . . . . . . . . . . . . . . . . . . . . . . 50

6. Evaluation and Analysis 536.1. Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1.1. Size analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.1.2. Delay introduced by ECIES . . . . . . . . . . . . . . . . . . . . 54

6.2. Remaining vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . 586.3. Ethical, societal and sustainability aspects . . . . . . . . . . . . . . . . 59

7. Conclusions 617.1. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.2. Future lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Appendices 65

A. ECIES implementations 67A.1. NIST P-256 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A.2. Curve25519 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

B. Test results 71

References 75

List of Acronyms 81

List of Figures

1.1. Evolution and forecast of number of worldwide mobile subscriptions . . 21.2. Eavesdropping on a shared medium . . . . . . . . . . . . . . . . . . . . 3

2.1. Simpli�ed 4G network architecture . . . . . . . . . . . . . . . . . . . . 82.2. Structure of IMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3. 4G control plane protocol stack and interfaces . . . . . . . . . . . . . . 112.4. Attach procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5. Di�erent elliptic curves . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6. Elliptic Curve addition and scalar multiplication . . . . . . . . . . . . . 202.7. Evaluated AES mode of operation . . . . . . . . . . . . . . . . . . . . . 22

3.1. Attribute-based encryption architecture . . . . . . . . . . . . . . . . . . 27

4.1. RSA with Optimal Asymmetric Encryption Padding . . . . . . . . . . 394.2. ECIES encryption functional diagram . . . . . . . . . . . . . . . . . . . 414.3. ECIES decryption functional diagram . . . . . . . . . . . . . . . . . . . 42

5.1. Using ECIES to encrypt the IMSI . . . . . . . . . . . . . . . . . . . . . 465.2. Using ECIES to decrypt the IMSI . . . . . . . . . . . . . . . . . . . . . 475.3. NIST P-256 and Curve25519 representation . . . . . . . . . . . . . . . 495.4. Attach procedure with E-IMSI . . . . . . . . . . . . . . . . . . . . . . . 51

6.1. Total execution time (KG + KA) in the tested devices . . . . . . . . . 58

xv

List of Tables

4.1. Comparison between analyzed solutions . . . . . . . . . . . . . . . . . 43

6.1. Cipher text size, in bits, as a function of the solution . . . . . . . . . . 546.2. Android devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.3. Execution time, in ms, for NIST P-256 (KG and KA) . . . . . . . . . 576.4. Execution time, in ms, for Curve25519 (KG and KA) . . . . . . . . . . 576.5. Execution time, in µs, for the Common Operations (KD, AES and XOR) 57

xvii

Chapter 1

Introduction

De cada pregunta, de cada respuesta;de cada persona, de cada planeta;de cada recuerdo, de cada cometa;

de cada deseo, de cada estrella.

Mariposa, La Oreja de Van Gogh

Abstract: In this chapter, the motivations for the Thesis are presented. Privacy is

even more important nowadays, and breaches on it must be �xed. This thesis focuses

on one issue in mobile networks: the disclosure of the long-term identi�er IMSI over the

radio interface; and how to solve it in the framework of the future 5G network. Moreover,

this chapter details the objectives of the Thesis and the organization of this report.

1.1. Problem statement

In the so-called information society, where almost everything is just a click awayfrom wherever one is, people are increasingly concerned about the value of privacy.Therefore, those failure points that represent a privacy thread are of vital importance,and e�orts are put to solve them as soon as possible.

Mobile devices have a focus on them. We must not forget that, according to [1],there are around 7,5 billion subscriptions worldwide, following a positive trend thatmay end with 8,9 billion subscriptions in 2022, as depicted in Figure 1.1.

Moreover, the introduction of IoT (Internet of Things) devices may also impacton the system by incorporating new elements to the mobile network. In this sense, wesee that the paradigm is moving, so that, for the future, if something bene�ts from aconnection, it will be connected.

Therefore, security and privacy pitfalls in mobile networks have a particular im-portance, due to the potential number of attackable subjects. One of these points offailure is the disclosure of the subscriber's long-term identi�er, so-called IMSI (Inter-national Mobile Subscriber Identity), sent unencrypted over the Radio Interface. Thus,an eavesdropping attack can be deployed, as depicted in Figure 1.2: anyone with accessto some radio equipment can listen to the channel and catch the users' identi�er [2].Such radio devices receive the name of IMSI Catchers [3].

1

2 Chapter 1. Introduction

Figure 1.1: Evolution and forecast of worldwide mobile subscriptions, obtained from [1].

Nowadays, the 3GPP (Third Generation Partnership Project) [4] represents themain standardization body for mobile networks, since it joints several telecommuni-cations standard organizations formed by network operators and equipment manufac-turers. The standardization activity is split into di�erent working groups within threeTechnical Speci�cation Groups. The reference group for Security is called Services andSystems Aspect 3. (SA3).

Following is the standardization process at 3GPP. First, its members submit theirproposals, namely contributions, to the relevant working group. The contribution isthen analyzed and discussed in the working group meeting. If it passes this �lter, theproposal is �nally addressed in the Technical Speci�cation Group Plenary, responsibleof the standards redaction.

The IMSI-Catching attack is not a new issue for these bodies. Already 25 years ago,when the second generation of the mobile network 2G was standardized, it was decidedto assign a short-term identi�er TMSI (Temporary Mobile Subscriber Identity) aftersuccessful authentication, to minimize the times that the IMSI was sent in clear text.Nevertheless, the IMSI was still transmitted in some cases. In [5] some enhancementswere already proposed.

Several ideas arose to overcome this problem in 3GPP when moving to the thirdgeneration 3G. One solution [6] proposed to implement one-time pseudonyms, in whichthe IMSI was anonymized by replacing it by a derived pseudonym. In [7], it wassuggested to use pre-shared group keys for encrypting the IMSI. However, none ofthese solutions was accepted [8] mainly because the threat was judged not to be sosevere. Besides, it was unclear that the proposed solutions were compatible with the

1.1. Problem statement 3

Figure 1.2: Eavesdropping on a shared medium. If anything is sent unprotected over a sharedmedium, such as the radio interface, it might be intercepted (eavesdropped) by non-authorizedthird parties.

actual system. Some privacy issues related to IMSI disclosure for 3G networks were aswell summarized in [9].

Again, when 4G standardization process started, the problem was revisited in theTR (Technical Report) 33.821 [10]. This time, the solutions included group key en-cryption of the IMSI, public-key cryptography, and the digital signature of IMSI-basedrequests. Once more, the proposals were rejected due to several reasons. For the �rstone, a group key approach does not ensure perfect privacy, since all members of thegroup can decrypt. For the second one, the cost of implementing a public-key systembetween the user and the serving network was judged to be too high. Finally, the di-gitally signed IMSI-based requests were not able to solve the fact that the IMSI wasstill sent in clear text, and therefore the passive IMSI-Catcher attack was not solved.

The situation nowadays has changed in di�erent ways. First, the mobile devicesare now more powerful, regarding computation capabilities, which makes some of thesolutions easier to implement. Second, the equipment needed for performing IMSIcatching is becoming cheaper due to the development of software-de�ned radio [11].Finally, and as we stated in the beginning, the arising of personal IoT devices wouldimply that a user would have associated more IMSIs, which makes him more exposedto this privacy threat.

In this scenario is where 5G comes into play [12]. However, �rst, the �fth generationof the mobile network have to deal with the new paradigm of lots of elements connectedto the network and faster connections: it is expected that the speed would increase upto 5Gbps.

The deployment calendar for 5G states that it has to be launched by 2020, butalready there should be some pilots by 2018. To this end, the privacy issues introducedin this section has to be addressed before that, so some proposals are now beingdiscussed in 3GPP, in TR 33.899 [13], which will be object of analysis of this Thesis

4 Chapter 1. Introduction

work.

In this Thesis, we are going to focus on the privacy issues related to the disclosureof the IMSI in the Radio Interface. However, there are other issues worth consideringfor the development of 5G. In this sense, the European project 5G-ENSURE [14] wasborn to address and propose solutions for enhancing future 5G systems. The projectresults from a joint e�ort between mobile network operators, vendors and academicinstitutions. The work is also done in the framework of this project.

Note that 5G is not standardized yet, this process is about to start. Due to this,during this dissertation we will refer to the 4G standard, more speci�cally to its Re-lease 14. Nevertheless, this does not represent a major issue since the equipment andprocedures relevant for the work will technically be migrated from 4G to 5G.

1.2. Objectives

The main goal of this Thesis work is to e�ciently conceal the subscriber long-termidenti�er IMSI in the Radio Interface, while transmitting it to those network nodesthat need it for its operation. Such goal can be divided into sub-objectives, listedbelow:

Literature review : As stated before, IMSI disclosure has been a problem for thelast 25 years. Therefore, and intensive e�ort has to be done for analyzing presentand past solutions to the problem:

• First, the proposals for legacy mobile generations (2G-4G) will serve as abasis for understanding the problem and as a context for real solutions.

• In this sense, academic papers will also be reviewed.

• We will deeply analyze the proposals from 3GPP discussed in [13] and inthe 5G-ENSURE project.

Deployment of a proposal for concealing the IMSI : As a result of the literaturereview, some objective indicators can be used for choosing a technically feasiblesolution.

• As a �rst step, a high-level solution will be proposed, in which the keyfeatures are highlighted.

• Then, we will move from a general perspective to a more detailed proposal.In this process, important factors to take into account will be the new iden-ti�er size, computation overhead, or required changes in real networks andequipment.

Evaluation of the proposed scheme: The proposal has to be analyzed to ensurethat the constraints are ful�lled. Some of the aspects to be discussed are:

• Computation e�ort: the time that the suggested proposal takes for comple-ting the task.

• Network performance: a study to see how the new system would impact onthe network, concerning bandwidth or protocol modi�cations.

1.3. Report Organization 5

• Remaining vulnerabilities: we must not forget what the main goal of theThesis is. Therefore, an analysis of the situation after the proposed schemeis adopted has to be carried out, to see that the goal is ful�lled.

Documentation generation: Writing the dissertation and other related documents,such as papers and contributions; and presentation of the results. The report willbe elaborated using LATEX[15].

The work will be focused on the transmission of the IMSI from the user whenattaching a network, which represents the main vulnerability of the system, and whatis intercepted by IMSI-Catchers.

1.3. Report Organization

The report is organized as follows:

Chapter 2 o�ers a review of the main concepts to be known for the correctunderstanding of the work, from a description of 4G networks to an introductionto cryptography.

Chapter 3 discusses the solutions proposed for IMSI concealment in 5G in both3GPP and 5G-ENSURE.

Chapter 4 presents the high-level solution from this work. Some preliminary ideasare analyzed and compared.

Chapter 5 details our proposal for encrypting the IMSI.

Chapter 6 analyzes the solution we propose regarding performance and remainingvulnerabilities.

Chapter 7 concludes the work and presents some future lines.

Chapter 2

Background

Le bonheur, pourquoi le refuser? En l'acceptant,on n'aggrave pas le malheur des autres et mêmeça aide à lutter pour eux. Je trouve regrettablecette honte qu'on éprouve à se sentir heureux.

Albert Camus

Abstract: This chapter presents the key concepts for the understanding of the Thesis

work. First, we present our reference architecture model, and we de�ne the subscriber

identi�ers. We then continue introducing some basics on control signaling for 4G, with a

particular interest in the Attach procedure. Finally, the cryptographic basis for the work

is introduced. A reader with knowledge about 4G Systems and Cryptography may decide

to skip the chapter.

2.1. 4G Architecture model

In this Section, the network architecture is presented, in the reference frameworkof 4G. First, the nodes are separately presented, and afterward, it is shown how theyare connected.

2.1.1. Network elements

The most important nodes that conform the 4G network are introduced. The TS(Technical Speci�cation) 23.401 [16] was used as the main reference for this section.

The USIM (Universal Subscriber Identity Module) is a mobile application thatstores user-related information, such as identi�ers or keys, and includes compu-tation capabilities that are used for cryptographic purposes, as de�ned in TS31.102 [17]. It is usually embedded on a chip-card called UICC (Universal Inte-grated Circuit Card).

The UICC is inserted into the ME (Mobile Equipment), which provides radiocapabilities. The ME is what is commonly known as the mobile phone, but ina broad sense, it is every mobile device that connects to the 3GPP networks.Note that, for a user to communicate, he would need both a valid subscription

7

8 Chapter 2. Background

(i.e., USIM) and device (i.e., ME). This union is what de�nes the UE (UserEquipment).

The eNB (Evolved Node B) is the radio element to which an UE is wirelesslyconnected. It thus represents the entity that moves the communication from theradio channel to the back end of the network. Usually, this element is also denotedas Base Station.

The MME (Mobility Management Entity) is the network equipment responsiblefor managing users within a network, hence it constitutes the main control devicein the network. It manages authentication and mobile services from the networkto the UE and vice versa, and it is reachable from a user through the eNB.

The HSS (Home Subscriber Server) represents a database in which the corres-ponding keys and identi�ers of the USIM are stored. It is necessary, for instance,for authenticating a user within a network, and thus it has to be in touch withthe MME to which the user is attached.

The gateway, presented for completeness, is the interface between the 3GPPnetwork and the Internet. It is the network element in which the data tra�c isrouted, separating the control �ow from the data plane. An UE reaches it froman eNB.

2.1.2. Network architecture

From a network perspective, like the one presented in Fig. 2.1, we can divide itaccording to two factors:Background: 4G Architecture

IMSI = MCC | MNC | MSIN

2017-03-23 5Encrypting IMSI to improve privacy in 5G networks Enrique Cobo Jiménez - Master Thesis

Serving Network (V-PLMN)

Home Network (H-PLMN)

Rad

io A

cces

s N

etw

ork

(RA

N)

Cor

eN

etw

ork

(CN

)

HSS

MEeNB

MME

ME

HSS

Figure 2.1: Simpli�ed 4G network architecture.

Depending on the nature of the devices on it, the RAN (Radio Access Network)and the CN (Core Network) emerge: The RAN is made up of those devices withradio capabilities, such as UE and eNB. On the other hand, the CN consists ofthe central nodes: MME and HSS.

2.2. Identi�cation of Mobile Subscribers 9

According to the home operator for a given user, the network is divided in PLMN(Public Land Mobile Network): the home network (or H-PLMN), the one to whicha user belongs; and the serving (or visited) network, so-called V-PLMN, theone to which the user is attached, if di�erent from its H-PLMN. A user alwaysauthenticates using its home HSS, but the other network elements would varyaccording to which V-PLMN it is attached.

Figure 2.1 depicts a simpli�ed 4G network, in which the user on the left is connectedto a network which does not belong to its home operator. This situation receives thename of roaming. Meanwhile, for the user on the right, the serving and home networkis the same (non-roaming situation).

2.2. Identi�cation of Mobile Subscribers

In this section, the most important user identi�ers are introduced, as presented inthe TS 23.003 [18].

2.2.1. IMSI

The IMSI is the identi�er that uniquely de�nes a subscriber within all networks. Itis stored in the USIM and in the HSS to which it belongs. It is formed by the followingelements, as shown in Figure 2.2:

3GPP

3GPP TS 23.003 V14.2.0 (2016-12)16Release 14

The LMSI may be allocated by the VLR at location updating and is sent to the HLR together with the IMSI. The HLR makes no use of it but includes it together with the IMSI in all messages sent to the VLR concerning that MS.

2.2 Composition of IMSI IMSI is composed as shown in figure 1.

MCC

Not more than 15 digits

3 digits 2 or 3

MNC MSIN PLMN

IMSI

9 or 10 digits

Figure 1: Structure of IMSI

IMSI is composed of three parts:

1) Mobile Country Code (MCC) consisting of three digits. The MCC identifies uniquely the country of domicile of the mobile subscriber;

2) Mobile Network Code (MNC) consisting of two or three digits for GSM/UMTS applications. The MNC identifies the home PLMN of the mobile subscriber. The length of the MNC (two or three digits) depends on the value of the MCC. A mixture of two and three digit MNC codes within a single MCC area is not recommended and is outside the scope of this specification.

3) Mobile Subscriber Identification Number (MSIN) identifying the mobile subscriber within a PLMN.

The National Mobile Subscriber Identity (NMSI) consists of the Mobile Network Code and the Mobile Subscriber Identification Number.

2.3 Allocation principles IMSI shall consist of decimal digits (0 through 9) only.

The number of digits in IMSI shall not exceed 15.

The allocation of Mobile Country Codes (MCCs) is administered by the ITU-T. The current allocation is given in the COMPLEMENT TO ITU-T RECOMMENDATION E.212 [44].

The allocation of National Mobile Subscriber Identity (NMSI) is the responsibility of each administration.

If more than one PLMN exists in a country, the same Mobile Network Code should not be assigned to more than one PLMN.

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.

2.4 Structure of TMSI Since the TMSI has only local significance (i.e. within a VLR and the area controlled by a VLR, or within an SGSN and the area controlled by an SGSN, or within an MME and the area controlled by an MME), the structure and coding of it can be chosen by agreement between operator and manufacturer in order to meet local needs.

The TMSI consists of 4 octets. It can be coded using a full hexadecimal representation.

Figure 2.2: Structure of IMSI, adapted from TS 23.003 [18].

The MCC (Mobile Country Code) is a 3-digit number that identi�es the countryto which the user belongs, and de�ned by the ITU (International Telecommuni-cation Union).

The MNC (Mobile Network Code) is a 2-or-3-digit number which refers to a spe-ci�c operator within a country and is allocated by a country-dependent authority.

The MSIN (Mobile Subscriber Identity Number) is a 10-digit-maximum numberwhich uniquely identi�es a user on its home network.

Note that MNC and MSIN are de�ned by its maximum length since the wholeIMSI cannot be more than 15 digits. The consequence is that, for a country that usesa 2-digit MNC (typically the European case), the maximum MSIN would be 10 digits;


and the other way around: for a country that uses 3-digit MNC (usually in NorthAmerica), the maximum MSIN would be 9 digits.

It is also worth mentioning that a user's H-PLMN can be identi�ed by the conca-tenation of MCC and MNC.

The IMSI is encoded using BCD (Binary-Coded Decimal), which implies that everydigit needs 4 bits. Therefore, the MCC is always 12 bits long, the MNC between 8 and12 bits long, and the MSIN requires 40 bits at maximum. It is important to recall thatthe whole IMSI cannot be larger than 60 bits.

2.2.2. GUTI

Since the IMSI represents the long-term identi�er of the user, a temporal identityTMSI was introduced to anonymize the user. Such identi�er is called GUTI (GlobalUnique Temporary Identity) in 4G, and it is used whenever available in place of IMSI,either entirely or just a part of it. Although it has global signi�cance, it is allocatedby the V-PLMN's MME. The GUTI consists of:

GUMMEI (Global Unique MME Identity): It uniquely de�nes the MME to whicha user is attached. In turn, the GUMMEI is de�ned by:

• The MCC and MNC (i.e., the PLMN) where the MME is located. Its lengthis the same as introduced before.

• MME Group id, of 16 bits length; and MME code, of 8 bits length. All thisidenti�es a particular MME within a network.

M-TMSI, of 32 bits, is freely allocated by the MME; and uniquely identi�es anUE attached to a V-PLMN's network. As its name indicates, it has temporarysigni�cance.

2.2.3. Others

In this section, some other used identi�ers are presented for completeness.

2.2.3.1. MSISDN

The MSISDN (Mobile Station Integrated Services Digital Network) is nothing elsethan the phone number of a given subscriber, i.e., the number one needs to dial forsetting a call, for instance.

It is noteworthy to say that this identi�er is not used in the Core Network: onlyIMSI and GUTI are internally used. Furthermore, an USIM (and thus an IMSI) cantheoretically be linked with more than one MSISDN. There are mechanisms in thenetwork, which are out of the scope of this Thesis, whose task is to translate from oneidenti�er to the other.

2.2.3.2. IMEI

The IMEI (International Mobile Equipment Identity) is a number that identi�esthe ME. It is used, for instance, for emergency services where no IMSI is available, orto block a device in the case it was stolen.

2.3. Control signaling 11

2.3. Control signaling

This section analyzes how the network elements communicate between themselvesto share the needed information for a correct operation. First, a general overview of themost relevant protocols for the Thesis is introduced. Then, the Attach procedure, whichrepresents our battle�eld, is detailed. Finally, the Lawful Interception requirements arepresented, since they constitute a constraint for the solutions.

2.3.1. General overview

The Control plane is the set of protocols that allows the exchange of control signalsbetween elements in the system. Fig. 2.3 shows the control plane stack for the mostrelevant nodes in the 4G system, together with the formal names of the interfaces.

L2 L2

L1 L1

MME S10 MME

GTP GTP

SCTP SCTP

IP IP

MME S11

GTP

SCTP

IP

L2

L1

SGW

GTP

SCTP

IP

L2

L1

S1-MME

PDCP

RLC RLC

NAS

RRC RRC

PHY

MAC L2

L1

LTE-Uu

PDCP

L2

L1

SCTP

IP

S1AP

SCTP

IP

L2

L1

DIAMETER

UE eNB MME HSS

NAS

S6a

DIAMETER

SCTP

IP

L2

L1

S1AP

SCTP

IP

L2

L1

Figure 2.3: 4G control plane protocol stack and interfaces.

The speci�c protocols, highlighted in the Figure, are brie�y summarized. Generalprotocols, such as IP or SCTP, are therefore skipped in this Thesis.

RRC (Radio Resource Control): Protocol that connects the UE with the eNB onthe radio interface. Its main function is to allocate radio resources to the UE andto adjust them on demand. For 4G it is described in TS 36.331 [19].

PDCP (Packet Data Convergence Protocol): Responsible for the transfer of bothuser and control plane data, ciphering and integrity protection. Standardized inTS 36.323 [20] for 4G.


RLC (Radio Link Control): It is a data link layer protocol, and thus responsiblefor error-free transfer and data units management. The version for 4G is in theTS 36.322 [21].

S1AP (S1 Application Protocol): As shown in Fig. 2.3, S1 represents the interfacebetween the MME and eNB. So, this protocol is responsible for carrying messagesbetween these two entities. De�ned in TS 36.413 [22].

GTP (GPRS Tunnelling Protocol): Based on IP, it carries GPRS (General PacketRadio Services) between the network elements, both control (GTP-C, TS 29.274[23]) and user data (GTP-U, TS 29.281 [24]).

Two of them were left unaddressed on purpose, due to that they require extraattention for the Thesis: NAS (Non-Access Stratum) and DIAMETER.

2.3.1.1. NAS

NAS, as shown in the �gure, allows the direct communication between UE andMME, with its messages encapsulated into the RRC protocol in the path UE-eNB,and in the S1AP between eNB and MME. Here, the eNB acts as a simple relay. NASis de�ned in TS 24.301 [25].

Formally, it consists of two protocols: the EMM (EPS Mobility Management) andthe ESM (EPS Session Management). We are more interested in the �rst one, which de-�nes access, authentication, and security procedures. ESM handles user data betweenthe UE and the packet data domain using bearers.

Going deeper into the EMM protocol, it de�nes the following procedures:

GUTI allocation and management.

Attach and detach procedures.

Paging: a mechanism to inform the UE that it has pending network services (i.e.,termination call or SMS).

As mentioned, authentication and security procedures.

2.3.1.2. DIAMETER

DIAMETER is a network protocol that provides Authentication, Authorizationand Accounting services, typically used in applications that involve network accesses.

Standardized by the RFC (Request For Comments) 6733 [26], it was thought asan improvement of the successful RADIUS protocol (RFC 2865 [27]) concerning moresecure communications and better scalability.

For its use in 3GPP networks, some particularities need to be considered. The TS29.272 [28] details the procedures that use DIAMETER between network nodes. Inparticular, in this Thesis we are interested in the communications between MME andHSS, with the following services:

Location Management Procedures: to inform the HSS about the network cu-rrently serving a given UE.


Subscriber Data Handling Procedures: to update the serving network with infor-mation about the user.

Authentication Procedures: to request authentication support to the HSS.

Fault Recovery Procedures: in the case of synchronization failure.

Noti�cation Procedures: to exchange updates between the MME and the HSS.

2.3.2. The Attach procedure

The following �gure shows the Attach procedure, i.e., UE connecting to the net-work. Several reasons can trigger such procedure, e.g., on the very �rst attach of auser within a speci�c network, or as a recovery mechanism.

Fig. 2.4 shows the complete attach procedure. It is split into three main sub-procedures or stages: identi�cation, authentication and update location.

Upd

ate

Loc.

Aut

hent

icat

ion

Iden

tific

atio

n

Core Network (CN)Radio Access Network (RAN) HSSUE MME

[NAS] Attach RequestIMSI or GUTI

[NAS] Identity Request

[NAS] Identity ResponseIMSI

[DIAMETER] Authentication Info. RequestIMSI

[DIAMETER] Authentication Info. AnswerKASME, AUTN, RAND, XRES

[NAS] Authentication RequestAUTN, RAND

[NAS] Authentication ResponseRES

[DIAMETER] Update Location RequestIMSI

[DIAMETER] Update Location AnswerMSISDN,…

Serving Network (V-PLMN) Home Network (H-PLMN)

Figure 2.4: Attach procedure.

2.3.2.1. Identi�cation stage

It represents the �rst stage, in which the UE would need to send its long-termidenti�er IMSI over the radio interface without any protection. If the UE had a GUTI,it would be transmitted in the (NAS) Attach Request message. Otherwise, this messagewould include the clear-text IMSI.


There is a failure recovery mechanism in case that the GUTI is no longer recogni-zable by the network. The MME would forward a (NAS) Identity Request, in whichthe UE is requested to reply with its clear-text IMSI. The UE does so in the (NAS)Identity Response.

In the sequel, and for simplicity, we are going to refer to the case in which the UEis attaching as if it was its �rst time, i.e., UE sends the IMSI in the (NAS) AttachRequest. There is no loss of generality when doing this simpli�cation.

As we introduced in Section 1.1, since the IMSI is sent in clear text, it is possiblefor a passive attacker, nmaley passive IMSI catcher, to just listen to the radio channeland to wait until an IMSI appears. Besides, note that there is still no security contextavailable so that the UE cannot check if it is attaching to an actual MME, or to anactive attacker that is impersonating a legit network. This kind of attack, since itrequires speci�c actions from the attacker side, is called active IMSI catcher.

We must also introduce, for completeness, the scenario in which a ME is attachingto a network following an emergency procedure. In this case, it should be possible forthe user to connect the network even without a subscription (USIM). Therefore, theME can also be identi�ed using its IMEI when attaching the network on an emergency.

2.3.2.2. Authentication stage

After the UE has identi�ed itself with its IMSI, the network has to authenticate thatit is whom it is supposed to be. Note that this step is crucial, since otherwise, anyonecould impersonate anyone else by just sending its IMSI to the network. Moreover, aswe saw in the previous paragraph, it is relatively easy to get someone's IMSI.

Such procedure also receives the name of AKA (Authentication and Key Agree-ment), because it lets the parties involved on it generate a session shared secret key asa consequence of the parties being authenticated. Speci�c details on the needed cry-ptographic functions are out of the scope of the Thesis but standardized in TS 33.401[29].

The sub-procedure starts with the MME sending a (DIAMETER) AuthenticationInfo. Request to the HSS. This query nowadays includes the IMSI in clear text. Ne-vertheless, the S6a interface runs over a secure channel (typically IPSec), so it shouldnot be possible for an attacker to sni� the IMSI from this communication.

The HSS, from the IMSI and its associated long-term key K, generates a so-calledAV (Authentication Vector), which includes the following �elds:

KASME (Key Access Security Management Entity): The secret session key that UEand MME will share after successful authentication. The UE can derive it usingother �elds of the AV.

AUTN (Authentication Token): It serves several purposes: acting as a freshnesscheck (the UE may decide to reject the AKA procedure if some �eld on the AUTNis not within a given range) and allowing network authentication from the UEside.

RAND (Random Challenge): Needed for the UE to compute the KASME and RES(Response), the latter used to authenticate the user to the serving network.


XRES (Expected Response): The MME authenticates the UE by checking the XRESfrom the HSS and the RES from the UE.

The AV is sent from the HSS to the MME in the (DIAMETER) AuthenticationInfo. Answer. Then, the MME keeps the KASME and XRES parts of it, and forwardsAUTN and RAND to the UE in the (NAS) Authentication Request.

Afterward, the UE is capable of computing KASME and RES from the received para-meters and the long-term key K, provided that the security checks be passed. At thispoint, the network has been authenticated to the UE.

Then, the UE forwards in the (NAS) Authentication Response message its RES. Asalready mentioned, the MME checks the expected response with the received versionof it, and if both match the UE is authenticated.

2.3.2.3. Update Location stage

In this �nal stage, the visited PLMN informs the home PLMN that the UE isattached to its network. To do so, the MME sends a (DIAMETER) Update LocationRequest message to the UE's home PLMN. In this message, the MME includes theIMSI together with a network identi�er.

The HSS keeps this information, and provides the visiting network with some otheruseful information about the user through (DIAMETER) Update Location Answer.Among other parameters, the MSISDN is sent to the MME in this message.

At this point, (i) the UE has successfully attached the network, (ii) the MME knowsall it needs for delivering network services to the UE, and (iii) the HSS keeps track ofthe network in which the user is. For the following steps, the MME will provide theUE with a bearer between UE and SGW (Serving Gateway) when needed.

2.3.3. Lawful Interception

LI (Lawful Interception) is a legal mechanism, used by Authorities, to request net-work usage information about the targeted users, suspected criminals, for its analysisor to serve as evidence. For the 3GPP case, it is described in the standards TS 33.106[30] and TS 33.107 [31].

Some of the information that can be obtained by this procedure includes:

The content of a private conversation between two parties. In this case, theAuthority is listening to a conversation or reading an SMS, as if it were partof the conversation.

A relation of network services demanded by the target. A list is sent to theAuthorities including information about, for instance, number and recipients ofcalls or data connections.

Information about the physical locations of the target. Based on the informationcollected by the eNB, the network gathers data about where a user was at agiven time. Such information can afterward be shared with the Authorities, uponrequest.


According to TS 33.107 [31], a user must be interceptable by one of the followingidenti�ers: MSISDN, IMEI, or IMSI. Since in this Thesis we will modify the way theIMSI is sent, we need to consider that the modi�ed system is still LI-compliant.

Furthermore, the TS 33.106 [30] states that a roaming user shall also be a possibletarget, no matter to which network it is attaching. Such interception needs to bedone without the knowledge or the visibility of the home network. Therefore, it hasto be possible to perform LI without being dependent on the user's home network forassistance.

Hence, the IMSI is forced to be known in the serving network from the very begin-ning. Proposals to conceal the IMSI that do not consider this fact into account mightbe technically invalid, because of such regulatory impositions. This implies that theproposals will always need to consider a mechanism for which the IMSI is always putto the serving network's knowledge.

2.4. Fundamentals on cryptography

In this section, we present some basics on cryptographic functions and primitiveswhose knowledge is relevant for understanding the Thesis. It is mainly focused onasymmetric cryptography and Elliptic Curve cryptography, since they represent themost important points of this work. Also, other useful cryptographic functions usedin the document, such as Di�e-Helmann, symmetric ciphers, and hash functions, arealso presented.

The book [32] served as a basic reference for this section. It is one of the de-factomanuals in cryptography used in Academia for the teaching of Security courses.

2.4.1. Asymmetric cryptography

Asymmetric cryptography lies on the fact that encryption and decryption processesrequire di�erent keys. It also receives the name of public-key cryptosystems. It consistsof the following elements:

Plain text: The original message that needs to be concealed.

Ciphertext: The encrypted, hidden version of message.

Public key: Accessible key that, on a public-key cryptosystem, acts as the en-cryption key.

Private key: Hidden key that, on a typical asymmetric system, is necessary fordecrypting the ciphertext message.

Encryption algorithm: Responsible for transforming the plain text to a cip-hertext, as a result of some key-dependent mathematical functions.

Decryption algorithm: Retrieves the original message from the ciphertext andthe corresponding key used in the encrypting process, by reverting the processapplied by the encryption algorithm.

Note that the public and private keys are somehow related, which implies that whatis done by one of the keys is complemented by the other one.

2.4. Fundamentals on cryptography 17

Some of the applications of public-key cryptosystems include:

Traditional message concealing: The sender encrypts a message using the re-cipient's public key, and then the latter decrypts the ciphertext employing itsprivate key.

Digital signature: If an individual uses its private key for signing the message,anyone with the complementary public key will be able of checking that the signergenerated the message.

Key exchange: It will be analyzed in the next Section 2.4.3.

One of the main points of failure that public-key cryptosystems have is the provisionof the public key in the recipients. Note that it is not only valid to put it in anaccessible folder, because this scheme is vulnerable to the MitM (Man-in-the-Middle)attack, as now described. A malicious user could just locate itself in the middle ofthe communication by exchange its public key to both parties in the communication,pretending to be the others' recipient. Under this attack, all the communications arevisible to the attacker.

To avoid such situations, other elements are required. A PKI (Public Key Infrastruc-ture) is used to manage public-key cryptosystems employing the so-called certi�cates:they are issued by trusted authorities, proving that the identity associated with a givenpublic key corresponds to the actual owner of the key.

However, there are other means of securely exchanging public keys. The easiestone is receiving it from its owner directly, i.e., without checking any public folder. Theproblem of such costless solution is its lack of scalability: it is unpractical to do it whenit turns to be a considerably large number of users.

We now analyze the most used public-key system so far: The RSA (Rivest, Shamir,and Adleman) algorithm. As its name indicates, it was developed by Ronald Rivest,Adi Shamir, and Leonard Adleman at MIT in 1978 [33]. It is based on exponentiationin modular arithmetic, and its security relies on the factoring problem, considered tobe hard to solve. The working principle is now summarized:

The public-private key pair is generated as follows:

1. Two prime numbers p 6= q are chosen at random.

2. Calculate n = p · q, and φ(n) = (p− 1) · (q − 1).

3. Select integer e such that gcd(φ(n), e) = 1 and 1 < e < φ(n).

4. Calculate d = e−1 mod φ(n)

5. The public key will be the combination of {n, e},whereas the private key will be {n, d}.

The encryption primitive, given the public parameters {n, e} and the messageM <n is as follows:

C =M e mod n (2.1)

Finally, the decryption primitive, given the public parameters {d, e} and the cip-hertext C is:


M = Cd mod n (2.2)

Note that, for the RSA algorithm, it is perfectly feasible that the private key isused to sign the message. Of course, in this case, the message will be recoverable byusing the public key.

2.4.2. Elliptic Curve Cryptography

The main issues that asymmetric cryptography present are its key length andcomputation time. According to several studies [34], [35], for a system to be secure,the RSA key length should be greater than 2048 bits. Instead, the use of ECC (EllipticCurve Cryptography) may overcome such issues, as will be explained in this section.

ECC, as its name indicates, is based on EC (Elliptic Curve) over a �nite �eld. AnElliptic Curve is de�ned by the following expression, namely Weierstrass equation:

y2 + axy + by = x3 + cx2 + dx+ e (mod p) (2.3)

Note that both the constants (a, b, c, d, e) and the variables (x, y) are restricted tothe given �nite �eld, determined by p. However, for its use in cryptography, curves onthe following reduced form are used:

y2 = x3 + cx2 + dx+ e (mod p) (2.4)

The name �Elliptic� comes from the fact that it is a cubic equation (i.e., order 3),which are as well used for de�ning the circumference of an ellipse. Figure 2.5 showsthe appearance of various elliptic curves.

The curve is de�ned by points (x, y), satisfying equation (2.4). Note that, whentalking about Elliptic Curves, we follow the notation of naming points on the curveusing capital, calligraphic letters; whereas scalars are lower case letters.

An Elliptic curve needs of a special point, called �point at in�nity� and denoted O,for being de�ned. However, it is not properly a point on the curve: it is de�ned in theprojective plane. The point at in�nity has an important signi�cance, because it de�nesthe identity element of the addition operation, which is explained in the following.

Two operations are de�ned within this context: addition and multiplication. TheEC addition takes two points on the curve to generate another: (T = R+S); whereasEC multiplication takes a point and a scalar, and can be seen as a repeated additionon the same point: (S = n ·R = R+R+ ...+R, n times). Figure 2.6 shows a geometricinterpretation of these operations.

Together with O, there is yet another point that needs special treatment. Thegenerator point, denoted G, serves as a basis anchor for generating points on the curvevia multiplication. The resulting points, {G, 2G, 3G, . . . , nG}, form a cyclic subgroup.Following is an example in which the relevance of the generator point is highlighted.

A public key is represented as a point on the curve, whereas a private is just ascalar. Let P be the public key associated with the private key k. Then, the followingequation holds:

P = k · G (2.5)


Figure 2.5: Di�erent elliptic curves.

To retrieve k from P and G, i.e., to obtain the private key from the public parame-ters is known as the EC-DLP (Discrete Logarithm Problem). This problem is thoughtto be more di�cult than the one for inverting RSA, hence key size can be reduced forthe same level of security.

A technique called PC (Point Compression) is used to lessen the need for memoryspace, especially when transmitting EC points. It is based on the fact that, for the cur-ves presented in equation (2.4), the y coordinate can be obtained from the x coordinateas follows:

y = ±√x3 + cx2 + dx+ e (mod p) (2.6)

So, a whole point can be recovered from its x-coordinate plus one bit of sign indica-tion. The saving in bandwidth is at the expense of extra computation at the recipient'sside, which needs to include a modular square root algorithm.

Also, compared to traditional public-key schemes such as RSA, speed is also en-hanced, in�uenced by both key length reduction and EC construction. These factsrepresent an advantage when implementing EC-based schemes in constrained equip-ment such as smartphones or IoT devices.

2.4.3. Other cryptographic tools

This section presents other tools that are going to be used during the Thesis. Forfurther details, the reader may be interested in reference texts such as the alreadypresented [32].


R-S = -(2R)

S = 2R

-T =-(R + S)

R + ST =

Figure 2.6: Elliptic Curve addition (green, T = R + S) and scalar multiplication (blue,S = 2R). The solid blue line is tangent to R, and the solid green line is formed by the unionof R and S. Note also that T = R+ S = 3R.

2.4.3.1. The Di�e-Hellman key exchange primitive

The main idea behind the Di�e-Hellman primitive, as introduced by Whit�eld Dif-�e and Martin Hellman in 1976 [36], is that the two parties involved in communicationcan independently derive a secret key from a combination of public parameters anduser-dependent private parameters.

In the beginning, the primitive was implemented using exponentiation in modulararithmetic, but it can be generalized to any �nite group, such as EC. The example wepropose is based on it, and we will use some of the concepts explained in Section 2.4.2.

Let us consider the basic scenario in which Alice and Bob are our parties in thecommunication. They both agree on a curve to use, and each has a public-private keypair, as follows from equation (2.5): A = a · G, and B = b · G, respectively. We alsoconsider that the public keys are securely provisioned at the other side, i.e., no MitMattack is possible.

If Alice wants to derive a shared value between her and Bob, she will take Bob'spublic key B and her private key a, which in the EC world are a point on the curve anda scalar, respectively. EC multiplication is thus valid, and thus Alice obtains a point,namely secret S, on the curve. Note that the process is identical from Bob's side, butusing Alice's public key A and his private key b:

S = b · A = b · (a · G) = a · (b · G) = a · B (2.7)


This secret value can then be utilized for the encryption of messages through sym-metric ciphers, as explained in the following section.

2.4.3.2. Symmetric cryptography

Symmetric cryptography is based on that the same key is used both for encryptingand decrypting. It consists of the following basic elements, some of them shared withpublic-key systems:

Plain text: The original message that needs to be concealed.

Ciphertext: The encrypted, hidden version of the message.

Secret key: A shared value that determines how the ciphertext will look like.

Encryption algorithm: Responsible for transforming the plain text to a cip-hertext, using some key-dependent transformations on the plain text.

Decryption algorithm: Retrieves the original message from the ciphertext andthe secret key, by reverting the process applied by the encryption algorithm.

Let P,C, κ be the plaintext, ciphertext, and secret key, respectively. The symmetriccryptographic primitives are denoted as:

C = Eκ(P ) (2.8)P = Dκ(C) = Dκ(Eκ(P )) (2.9)

One of the key features that symmetric cryptography has to ful�ll is that it hasto be strong, in the sense that the knowledge of the construction details must notbe enough to break the system. We must assume that it is possible for a potentialattacker to build the same system, and thus impractical to hide the security of thesystem there.

So, it is noteworthy to mention that the security of the cryptosystem has to relyonly on the secrecy and strength of the key, which of course cannot be widespread forobvious reasons: the full communication would be readable.

There are various symmetric ciphers to be chosen, but we will focus on two of themin this Thesis: XOR and AES (Advanced Encryption Standard). The former representsthe most elemental one, whereas the latter constitutes the de-facto symmetric cipher.

The XOR cipher, as its name indicates, performs a bitwise XOR operation (denotedas ⊕) between the key and the plaintext to generate the ciphertext; and the same inthe other direction, since XOR is an involutory function. Hence, for any bit stringB, B ⊕ B = 0, where 0, the zero string, is the identity element. Mathematically, thecryptographic primitives become:

C = Eκ(P ) = P ⊕ κ (2.10)P = Dκ(C) = C ⊕ κ = (P ⊕ κ)⊕ κ (2.11)

Despite its simplicity, it is not very used because the system forces the secret keyto be used just once, due to the vulnerability of XOR to the known plaintext attack:


the knowledge of the plain text and the ciphertext encrypted with XOR recovers thekey: C ⊕ P = κ. Nevertheless, it serves as a basis for more complex ciphers.

AES is a symmetric cipher standardized by NIST (National Institute of Standardsand Technology) in 2001, and since then it has been the referential symmetric cipher,widely used and accepted. It was initially developed by Joan Daemen and VincentRijmen, and thus also known as Rijndael. The details of how AES is built are out ofthe scope of the Thesis.

There are various modes in which AES can run, depending on the feature one wantsto optimize. We are going to highlight two of them: CBC (Cipher Block Chaining) andCTR (Counter). CBC works with blocks of data, which implies that the output ofthe cipher is as well constant. Meanwhile, CTR mode is a stream cipher, as XOR,encrypting the data on the go, not necessarily over a block of data. This feature alsoenables the length preservation between the plain text and the ciphertext. Figure 2.7depicts both modes of operation.

(a) CBC mode encryption.

(b) CTR mode encryption.

Figure 2.7: Evaluated AES mode of operation, obtained from [37].

2.4.3.3. Hash functions

A Hash is a function that takes as an input a non-�xed-length bit string andconverts it into a �xed-length bit string. For a Hash function, denoted as H(), to beuseful, it has to ful�ll these two properties:

One-way: Given H(x), it has to be di�cult to retrieve the original x.

Collision-resistant: For any bit string x, it has to be di�cult to �nd another,di�erent bit string x′ 6= x such thatH(x) = H(x′), i.e., produces the same output.


Hash functions have several cryptographic applications, being the two most impor-tant (i) the generation of message digests, and (ii) the creation of one-way passwords�le. For the former, since these functions admit input data blocks of variable length,sometimes large, and it produces a �xed-length, deterministic output, it can be con-sidered as if the input was digested. The digest can be later used for, i.e., integritycheck or digital signature.

The second application, the one applied in the Thesis, lies in the one-way propertyof hash functions, which implies that it is hard to �nd the original input given theoutput. So, hash functions are one of the basis for the generation of keying material.

One of the most used hash families is SHA-2. Standardized by NIST in 2001, itde�nes four functions, which vary on its output length: SHA-224, SHA-256, SHA-384,and SHA-512. Details on the construction are not considered.

Chapter 3

Review Study

Fantasie ist wichtiger als Wissen,denn Wissen ist begrenzt.

Albert Einstein

Abstract: In this chapter, the solutions that are being discussed nowadays for the

concealment of the IMSI are presented and evaluated. We will focus mostly on these

proposals in 3GPP since it represents the main standardization body for mobile net-

works. Three main high-level solutions will be analyzed: traditional public-key schemes,

attribute-based encryption, and pseudonyms.

3.1. Traditional public-key schemes

As it was explained in Section 2.4, a public-key scheme has the particularity ofbeing formed by a public key and a private key, so that what is encrypted with thepublic one can only be decrypted using the private element, and the other way around.

When applying this scheme to protecting IMSI, the keys are used as follows:

1. The private key belongs to the element of the network which is in charge ofpeeforming the decryption.

2. The UE will know the public key of such element by the time it has to generatethe ciphertext.

Several solutions propose the usage of such schemes, but we are going to focuson the solution discussed in [38]. Researchers suggest implementing a system basedon DHIES (Di�e-Hellman Integrated Encryption Scheme), which consists of severalfunctions and relies on the Di�e-Hellman primitive as explained in Section 2.4.

Their solution consists on encrypting the IMSI on the RAN part, i.e., from the UEto the MME. The problem comes from the fact that all the possible MMEs' publickeys cannot be stored on the UE. The proposal includes two variants to overcome thisissue: one in which additional network infrastructure such as PKI is required, and asecond that does not need extra elements.

25

26 Chapter 3. Review Study

For the PKI variant, the (NAS) Identity Request message includes the MME'sCerti�cate with its public key. Such can (and must) be of course validated by the PKI.The UE derives the keying material from its private key and the received public key,and it responds in the (NAS) Identity Response with its public key, its symmetrically-encrypted IMSI and a MAC (Message Authentication Code). Upon reception, the MMEfollows the same proceeding to derive the keying material, being thus able to decryptthe IMSI and validate the MAC.

On the other hand, the no-PKI solution includes further messages to be exchanged:Instead of sending (NAS) Identity Response right after (NAS) Identity Request, the UE�rst transmits its public key to the MME in a separate message. The MME respondswith its (untrusted) public key so that now UE can compute the keying material fordoing symmetric encryption and MAC. Finally, the UE sends (NAS) Identity Responsewith the encrypted IMSI and MAC, and the MME can decrypt it as described above.

The present proposal has the following characteristics:

It allows the whole IMSI to be encrypted (i.e., MCC, MNC, and MSIN),due to the MME would be responsible for the decryption, and hence it would�nd the right HSS from there.

Therefore, it allows LI.

Comparing both variants, the former requires the introduction of new networkelements (and possible extra signaling to it, to validate the certi�cates), whe-reas the latter does not o�er security against MitM attacks, and introduces newmessages in the Attach procedure.

The (NAS) Attach Request message is still sent, even though now it wouldnever include the IMSI, because the UE has to wait for the V-PLMN's publickey for the encryption. However, it would include GUTI if available.

It is left unaddressed the speci�cs on which scheme to use. Thus, it is impossibleto do an analysis regarding bandwidth overload.

For the sake of completeness, both variants introduce a nonce in the keyingmaterial derivation, which needs to be exchanged between both entities and thenincreasing the bandwidth requirements.

Before concluding, authors in [39] suggest the usage of public-key encryption basedon RSA but for non-3GPP accesses, e.g. WLAN (Wireless Local Area Network). Weevaluate a similar solution for 3GPP accesses in Section 4.3.

3.2. Attribute-based encryption

Attribute-based encryption is a special kind of public-key scheme in which otherparameters are used in the process, de�ning which elements on the network will beable to decrypt. Fig. 3.1 shows how this kind of scheme works.

Two main implementations will be discussed: KP-ABE (Key-Policy Attribute-BasedEncryption) and IBE.

3.2. Attribute-based encryption 27

Figure 3.1: Attribute-based encryption architecture implementing IBE, obtained from [40].Note that, in a broad sense, the identity can be replaced by any representative attribute ofthe recipient.

3.2.1. Key-Policy Attribute-Based Encryption

KP-ABE [41] is a public-key scheme in which a single public key can be associatedwith several private keys, so that the attributes (a descriptive piece of informationlinked to its holder's identity) used in the encryption process will determine whichkeys will be able to decrypt. This is because each private key is associated with anAccess Structure, which is nothing else than a logic combination of valid attributes.

It consists of these functions:

setup. It is executed once and takes as inputs the Master Key and, optionally,the whole universe of valid attributes. As a result, it produces the public key.

keygen. Used for generating private keys. The inputs of the function are theMaster Key and a given Access Structure, and it outputs a private key.

encrypt. It generates the ciphertext. It needs the public key, the message to beencrypted, and a set of valid attributes.

decrypt. It obtains the message from a ciphertext. It takes as inputs the PublicKey, a private key and the ciphertext, and will output the message in clear textif the attributes used when encrypting satisfy the access structure of the privatekey.


3.2.1.1. Usage

As analyzed in [42], this scheme applied in our case has the following features:

It allows the encryption of the whole IMSI, since a V-PLMN attribute willbe included. Therefore, the V-PLMN will always be able to decrypt and canafterward forward the identi�er, encrypted or not, to the correct H-PLMN. Werecall, from Section 2.3, that the communications between MME and HSS aresent over an encrypted channel.

The public elements, such as the public key and the attribute of the home net-work, can be provisioned in advance, given the fact that they are static.

There is no need for extra infrastructure for key validation, such as PKI. If aprivate key is applied to a ciphertext encrypted with attributes which are not inthe private key's access structure, it will result in error.

The attribute of the visited network can be derived from the sent information,since it depends on the actual network the user is attaching to. So, no othermessages are needed.

Since the visited network is decrypting the IMSI, this solution allows LI.

Authors in [43] suggest an implementation in which there is one global entity,namely AuS (Authentication Server) for all operators. Such entity has to generate thepublic key and a private key for each operator. The process is as follows:

0. As a previous step, the global entity runs setup once and keygen as many timesas keys are needed. After this, the public key is provisioned in all UE and theprivate keys in the networks. Note that all UEs worldwide will share the samepublic key, and will be used for attaching to whichever network.

1. UE receives information of the network over a public channel and can derive theattribute to use.

2. UE perform encrypt using the public key, the given attribute, and its IMSItogether with a random number. Changes in NAS are not needed.

3. The visited network perform decrypt using its private key, the public key, andthe received message. Since the attribute used during encryption was valid forthe private key, it recovers the IMSI.

4. It forwards the identi�er in clear text to the home network for continuing withthe AKA procedure. Thus, DIAMETER protocol is left untouched.

This option relies on a secure channel between home and visited network, typicallyusing IPsec. If this is not possible, or to relax trust between networks, UE may usethe attribute of the home network for encrypting, together with the one derived fromthe serving network. Upon reception and decryption at the V-PLMN, the message willbe forwarded to the home network, which will decrypt it using its private key. Giventhat the visited network has to recognize the home network of the user, it will need todecrypt in any case.

3.2. Attribute-based encryption 29

3.2.1.2. Implications

This method allows the full IMSI encryption by the use of descriptive attributes re-lated to the entities that should be able to read it. On the other side, some practicalitiesneed to be studied before implementing this scheme. Some of them are:

Size of ciphertext. According to [41], the encrypted message resulted fromencrypt grows linearly with the number of attributes used in this process.

Leakage of a private key. In this case, a stolen private key could be used bymalicious parties by broadcasting the corresponding attribute within an area.Then, the user may accept the attribute and thus reveal itself.

Key management. When a key and an attribute need to be revoked because ofhaving been compromised, or when there is a lack of attributes for new operators,all the keys need to be updated consequently. This would imply either to re-runstep 0 described above and securely provision new keys to all parties involvedin the communications (UEs and operators worldwide); or to create a sort of�revocation list� that includes a exhaustive list of all revoked attributes, and thathas to be accessible to the UE even in the very �rst attach.

Master key. It represents a trap door to the system since everything encryptedusing this scheme can be decrypted by someone with the Master key, no matterwhichever attributes were used at the encryption stage. This is because the Mas-ter key is located on the top of all Access Structures, being this the reason whythe private keys are derived from it.

Need of global entity for key management. All operators need to agreeon an independent and external entity responsible for generating the public andprivate keys, and for holding the Master key, given that all UEs share the samepublic key which can be used to connect to every single network.

A more detailed size analysis can be found in section 4.2, together with some otherproposals regarding this scheme.

3.2.2. IBE

IBE can be seen as a form of Attribute-Based Encryption in which the attributedused in the system is directly the identity of the recipient. Then, certain similarities canbe established between KP-ABE and IBE, as they rely on the same scheme depictedin 3.1.

Contribution [44] proposes to use an IBE scheme based on the SAKKE (Sakai-Kasahara Key Encryption) algorithm [45]. Details on the mathematics behind thescheme are out of the scope of the Thesis.

In contrast to what was proposed for the KP-ABE scheme, the solution in [44]considers that the parameters are network-dependent, i.e., there is no need of a globalAuS in charge of managing generic operations. However, it has some implications thatwill be analyzed in this section.

The solution proposes to encrypt the IMSI until some node at the V-PLMN's. Inthis case, the eNB broadcasts the identity of such element, which will be used for


the UE to encrypt its IMSI. Since the public parameters have only local signi�cance,several public keys need to be securely provisioned on the UE, so that it can roam, aprocess that has to be done before the UE leaves its home network.

As happened with other contributions, analysis on the size of the public parameters,or the ciphertext is left unaddressed, which makes the comparison di�cult. In any case,the fact that the public key needs to be provisioned on demand, as a function of thenetworks that the UE plans to visit, makes this solution less attractive.

3.3. Pseudonyms

In TR 33.899 [13], some of the solutions propose the implementation of pseudonym-based approaches, which pursue the concealment of the IMSI just by sending an ephe-meral identi�er that changes every time the UE need to use it. Such identi�er can beeither generated at random by the HSS and then shared with the UE, or independentlyderived by both parties from some shared information.

Those proposals [46], [47] can be reduced to the following technical Papers, whichare going to be analyzed in this section.

Van der Broek et al. [48] proposed to use a random Pseudonym generated at theHSS and then communicated to the UE by the RAND �eld in the AKA procedure(explained in Section 2.3.2). Such identi�er is sent encrypted using a special shared,symmetric key between each USIM and the HSS, and would be on the size of theMSIN that it replaces. Note that the MCC and MNC have to be sent inclear text so that the serving network can route it to the correct HSS.

On the UE side, more precisely on the USIM, two Pseudonyms are maintained tominimize the risk of getting out of sync because of, e.g., hardware failure or third-parties attacks: the used and the next one. According to some policy, the user mightdecide to use the previously sent one, or the new one. In this way, no matter if the UEis under attack because it will always send the same identi�er, without exhausting thesystem.

For the HSS to generate a new Pseudonym, it �rst needs to check which ones arein use, because since it is replacing the actual IMSI, collisions are not admissible: twousers sharing the same identi�er would make it impossible for the network to distin-guish between them. Furthermore, since two pseudonyms are allocated to one user, itautomatically reduces the pool of uniquely identi�able users in a network byhalf.

Authors in [49] presented two proposals: one of them is similar to the alreadydescribed, while the second one consists of a set of prede�ned Pseudonyms, beingallocated from a very beginning on the USIM. It is not stated which could be a secure�gure of pre-allocated Pseudonyms. However, it is important to emphasize that, still,a given pseudonym is only assigned to one user, which means that there would still besome privacy issues. Furthermore, the number of valid users will be drastically reducedwith the number of Pseudonyms pre-allocated in the users.

Finally, in [50], authors suggest to dynamically allocate the Pseudonym according tothe value of KASME, a session-dependent key. By doing so, there is just one Pseudonymassigned to a user at a time. Therefore the solution does not exhaust the IMSI poolnor reduce the number of possible subscribers within a network. On the other hand,

3.4. Conclusions 31

it is not stated which function can be used for deriving a Pseudonym from the KASME,and hence the �nal size of it.

This work also introduces the importance of having a recovery mechanism as aconsequence of varying the identi�er on a regular basis. To avoid possible locking-outsituations, they suggested adding, in parallel, a public-key based approach, in whichthe IMSI is encrypted in the rare event that there is a synchronization failure betweenthe UE and the HSS. Nevertheless, it is important to highlight the fact that, eventhough the risk is low, not treating this situation would make the user unreachable.

To sum up, Pseudonym-based approaches would presumably have a reduced im-pact on the bandwidth compared to public-key solutions, since their size would beon the order of the IMSI they replace. However, on the other size, they require thedevelopment of a recovery mechanism to cover the malfunctioning situations, whichwould consist of either sending the plain-text IMSI (and thus vulnerable to attacks)or an encrypted one. In any case, the solution works �ne in parallel with anotherpublic-key-based approach.

It is important to consider that, since the Pseudonyms have local signi�cance (theycan be seen as a sort of GUTI between the UE and its HSS), they need to �nd asolution in which the IMSI is still visible to the MME. In [49], they state that:

�If the home network is required to do so by its regulatory environment, e.g.to support lawful interception, it can maintain a log of all the IMSIs assignedto a particular subscriber for however long is required.�

Nevertheless, as we analyzed in Section 2.3.3, this does not ful�ll LI requirements,since it should be done without the support nor visibility of the Home Network. Noother mechanism has been proposed in these papers.

3.4. Conclusions

In this chapter, the most discussed solutions for concealing the IMSI have beenanalyzed. Some conclusions are extracted from such analysis:

Public-key schemes seem to be a good option, since it allows the concealment ofat least the MSIN, the most critical part of the IMSI, over the radio interface.

Nevertheless, it seems not to be a good option to use traditional public-keyschemes, such as the one discussed in Section 3.1, in which the termination pointis located in the serving network. Hence, some issues arise as a consequence ofhaving the serving network to send its public parameter upon request, since itvaries between operators.

Attribute-based options, more speci�cally KP-ABE, present some strengths thatare worth considering, such as the complete encryption of the IMSI. However,some particularities were not addressed, which is the reason why we will godeeper on it in the following chapter.

Pseudonyms represent a good option regarding length preservation and ease ofuse. However, on the other hand, they require another mechanism for recoverypurposes, due to the lack of them might cause that the UE is unreachable. Suchmechanisms would be based on public-key approaches.


It is also worth considering that, since the IMSI is the actual identity of the user,the short-term identi�er GUTI, introduced in Section 2.2, is used whenever available.Hence, IMSI is only used when a GUTI is not available, which only happens in theideal case when a user attaches for the �rst time to a network. Hence, it should nothappen very often, and then to have two systems in parallel (e.g., Pseudonyms andPublic key) seems not to be reasonable.

Thus, in this Thesis, we will focus on the evaluation and development of a public-key based crypto scheme for concealing the IMSI, since it is versatile and does notneed of other schemes in parallel. In the following chapter, some public-key systemsare analyzed for determining which is the technically best option.

Chapter 4

Enhancing Long-Term Identi�er

Privacy

Tσαµπα ξυδι,γλυκo σα µελι.

Eλληυικη παρoιµια

Abstract: We will present in this chapter some preliminary work done for choosing

a method for encrypting the IMSI. First, the KP-ABE implementation is analyzed from

several points of view, playing around its variants and how to deploy it. Then, it will be

turn for traditional RSA, and afterward, Elliptic Curve approaches. After such analysis,

we draw the conclusion that Elliptic Curve Integrated Encryption Scheme represents a

good option in our case.

4.1. Introduction

As we saw in Chapter 3, some enhancements discussed in TR 33.899 include tra-ditional public-key schemes, attribute-based encryption and Pseudonym-based iden-ti�ers. We analyzed that Pseudonyms are a good option, but needs of a recoverymechanism, usually based on public key cryptography. This fact would mean that twosystems need to run in parallel: one for common operation (Pseudonyms, which de-mand less bandwidth and computation resources), and one for recovery purposes (forrare situations, but in need for the risk for the user to get locked out of the system).

Therefore, to implement a recovery mechanism would represent a signi�cant costfor small pro�t. However, since Pseudonym-based approaches are not perfect, it has tobe implemented. So, we propose to focus on developing an asymmetric cryptographybased solution, which is su�cient for all the cases.

It is also worth recalling that a TMSI was indeed introduced used for anonymizingthe user, but IMSI-based procedures were left for special cases when i.e. the user doesnot have a temporary identi�er. Then, IMSI-based procedures play an essential rolein network operations, and thus cannot be discontinued. Nevertheless, the fact thatIMSI-based procedures are rarely used does not imply that the situation is less critical,because an attacker can trigger an Attach procedure in which IMSI is forced to be used,as stated in Section 2.3.2.

33

34 Chapter 4. Enhancing Long-Term Identi�er Privacy

Hence, we will focus our attention on concealing the IMSI, enhancing in this sensethe long-term identi�ers privacy, by encrypting the IMSI using public-key cryptosys-tems. To this end, in this chapter, we analyze three solutions: (i) other architecturesbased on KP-ABE, (ii) a solution based on the de-facto public-key system RSA, and(iii) Elliptic Curve approaches, with a focus on Elliptic Curve Integrated EncryptionScheme.

4.2. KP-ABE implementation

To evaluate the impact that KP-ABE causes in our case, mostly regarding key andciphertext size, some additional research was conducted. We analyze here two variantson how KP-ABE can be used, together with their practicalities.

Here it is also presented another implementation we suggest that overcomes partof the issues identi�ed in the solution [43] and discussed in Section 3.2.1.

4.2.1. Length analysis

As discussed before, the size of the ciphertext increases linearly with the numberof attributes used in the encryption procedure [41]. However, how this is translatedinto bits, together with an analysis of the public key size, were left unaddressed. Thosetwo aspects have signi�cant importance, due to keys need to be deployed and storedin UE, and ciphertext has to be transmitted over the radio interface.

KP-ABE can run in two di�erent construction, depending on the universe of attri-butes: the small universe and the large universe construction. Both of them are in thefollowing analyzed.

4.2.1.1. Small universe construction

The small universe construction has the particularity that, for generating the publickey, all the attributes in the universe have to be explicitly declared. This fact impliesthat the size of the public key grows with the number of valid attributes in the system,so it is mostly intended for applications that require a small number of attributes.

This variant shows a very nice property: the fact that the user at the encryptioncan recognize if the received attribute is valid. On the other hand, if new attributesare added to the network, then the public key needs to be consequently updated.

We are now interested in knowing what the impact on the size is. To give some�gures, we used a third-party KP-ABE library [51], which implements the small uni-verse construction over Elliptic Curves. It consists of four Linux shell commands, oneper KP-ABE function:

1. kpabe-setup for creating a new public key together with the attributes on it.

2. kpabe-keygen for generating private keys associated with the public key and to(one or more) attributes.

3. kpabe-enc for encrypting a message using the public key and a set of attributes.

4. kpabe-dec for decrypting a ciphertext provided that the used private key hasthe correct rights.

4.2. KP-ABE implementation 35

For installing such library, we needed to compile and install PBC (Pairing-BasedCryptography) [52] and GMP (GNU Multiple Precision Arithmetic Library) [53] as aprevious step.

The underlying Elliptic Curve for this implementation is in the form:

y2 = x3 + x(mod p)

where p is 512 bits long. Therefore, it has the same security level as a 15630-bit RSAscheme [35].

Let N be the number the attributes in the universe. Following is the KP-ABEpublic key length, empirically obtained by running kpabe-setup several times whilevarying the number of valid attributes in the universe.

PKP-ABE, small(N) ≈ 5024 + 1096 ·N [bits] (4.1)

For the ciphertext analysis, we de�ne n as the number of used attributes whenencrypting. To simplify the equation, is was only considered a 8-byte message, whichcorresponds to a 60-bit IMSI, as we saw in Section 2.2. The ciphertext size is as follows:

CKP-ABE, small(n) ≈ 1312 + 1096 · n [bits] (4.2)

So, for the scenario analyzed in Section 3.2 and described in [42], N ≈ 1000,considering around 1000 operators, each of which with its attribute; and n = 1, thescenario in which only the MME is decrypting. Hence, the size of the public key thathas to be provisioned in all UEs will be on the order of 1096 Kb; and the size of theciphertext to be transmitted on the order of 2400 b.

Here is a short discussion about the results.

These formulas were just obtained as a �gure of merit, to represent what couldbe the cost, regarding size, of implementing a KP-ABE for concealing the IMSI,and are implementation dependent, i.e., these values are only signi�cant is thesame library is used.

Analysis on the size of the Master Key and Private Keys was not done, based onthe supposition that the storage of such keys does not suppose a problem either inthe AuS nor the MMEs. Furthermore, the communication between these elementsfor key provisioning (once every time a new public key is generated) is done usinghigh-speed links.

As a sanity check, it was veri�ed that the obtained ciphertext could be perfectlydecrypted using the proper private key, and the original message was recovered,being this of the same size.

It was also observed that the ciphertext was probabilistic, i.e., it was di�erentevery time it was re-encrypted using the same message, public key, and attribu-te(s).

4.2.1.2. Large universe construction

On the other hand, for the large universe construction, it is not necessary to declarethe attributes when generating the keys. Instead, every bitstring can be reduced to


a valid attribute using a special one-way function. So, the public key is stationary, itdoes not vary with the number of attributes in the universe, and then they can beadded without modifying the pre-allocated public key.

However, the problem here comes in the form of revocation. Since every bitstring isa valid attribute, then there is no prior information on the encryption side about if theattribute is valid or not. In the small universe construction, it was enough removingthe part of the public key associated with the a�ected attribute. In here, a sort ofrevocation list has to be created, list that has to be available to the user even in thevery �rst use.

To regenerate all the keys is always a valid option for both variants, since then thecompromised attribute (together with the compromised key) are no longer usable ineither of the cases. However, this process is certainly costly, given that the public keysneed to be securely re-provisioned in all the UEs.

Hence, the di�erence between the large and the small universe constructions canbe seen as, whereas the small universe de�nes the set of valid attributes, the largeuniverse needs to keep track of those attributes that are invalid.

The contribution [54] proposes to use the large universe variant over EC. However,they do not make explicit what is the resulting public key and ciphertext size. Somework has to be done on the de�nition paper [41] to derive this information.

We start with the public key size. First, let nMAX be a constant de�ning the ma-ximum number of attributes that can be used when encrypting. Second, since staticEC points are stored in memory, it is not worth compressing them since it wouldimply that every time that the UE has to do a encryption, the points needs to bedecompressed.

Then, the size of the public key is:

PKP-ABE, large(nMAX) = 2 · lpoint + nMAX · lpoint= (2 + nMAX) · lpoint [bits]

(4.3)

where lpoint denotes the bit size of a point on the curve.

Continuing with the ciphertext, in [54] they state that the IMSI is protected byapplying bitwise XOR with a derived secret. This is indeed possible, considering thatextra information has to be sent to the network for them to decrypt. Such extrainformation is at most three points: one that can be seen as the user's ephemeralpublic key, and then one point per attribute used. In this case, they are going to besent over the radio interface, and they vary between encryptions, so our proposal is touse point compression PC. As discussed in Section 2.4.2, it will be at maximum oneextra bit for sign indication.

CKP-ABE, large(n) = lIMSI + lpoint + n · lpoint= lIMSI + (n+ 1) · (lcurve + PC) [bits]

(4.4)

where lcurve denotes the bit size of the curve.

4.2. KP-ABE implementation 37

4.2.2. Local-AuS implementation

In Section 3.2.1, some practical issues regarding the use of a global AuS werediscussed. To overcome part of them, it is now analyzed the scenario in which eachoperator acts as AuS of its users, using a KP-ABE-based implementation. The HSScan take this role. By doing so, the system is considerably simpli�ed, since now apublic key is restricted to cover only those networks that have a roaming agreementwith the home operator.

Now, it is �rst analyzed how to implement this scheme, regarding the number ofattributes that need to be used when encrypting, and then solutions will arise.

4.2.2.1. Analysis and solutions

Let us �rst assume that we want to encrypt using just one attribute. We can thinkof three possibilities:

Only the home network's HSS can decrypt: In this situation, the systemis like a traditional asymmetric scheme, in which one recipient is encrypting amessage that can only be decrypted by the other party in the communication(thus o�ering the same functionality as traditional public-key encryption). Furt-hermore, and because the attribute is static and known in advance, it can behard-coded on the UE together with the public key.

Both the visited network's MME and the home network's HSS candecrypt: Provided that only one attribute be being used, it implies that HSShas to have MME's private key. However, this is not an issue, given that it isHSS who generates private keys. The main problem is related to the fact thatthe MME cannot be known in advance (a user can be attaching to networks allaround the world). So:

• Either all possible MMEs share the same attribute (and thus private key),which implies that the attribute can be hard-coded on the UE. This solutionis highly exposed to the risk of key leakage since all MMEs share the samekey, and thus not being a good solution from a security perspective.

• Or there is one attribute per MME. In this case, it must be derived fromMME's sent information.

Only the visited network's MME is able to decrypt: Same scenario asbefore, because HSS can always decrypt. The only di�erence is that, in this case,we are not expecting it to do so.

Let us now consider the case in which more than one attribute is used. The �rstarising question is if we need more than two attributes, whose answer is no: if an attri-bute represents a network, a user needs to communicate at most to two di�erent ones,the serving and the home networks (which are not the same in a roaming scenario).

As analyzed before, it is also known that HSS can always decrypt using MME'skey, as it is the AuS in this implementation. So, in this solution we propose, there isno scenario in which two attributes are in need: one is always enough.


4.2.2.2. Discussion

The solution we have presented have following features compared to the Global-AuSproposal:

For the small universe construction, it considerably reduces the size of the publickey, because now it just includes attributes from those networks to which a givenuser can attach. On the other hand, the public key size is not a�ected in whicheverthe solutions if the large universe variant is used,

The ciphertext size is not impacted in either of the scenarios.

Each network needs to be provisioned with a private key from every operator withwhich it has a roaming agreement. This contrasts with the global-AuS scheme,in which one key per network was enough. However, this does not constitute aproblem for CN nodes.

To let the visited network know which key to use, or which operator to send thequery, the MCC and MNC have to be transmitted in cleartext. This di�ers fromthe global-AuS solution, that was encrypting the whole IMSI.

In our solution, the process of refreshing public parameters, such as the publickey or the revocation list is done in a more e�cient way since it now involvesfewer devices.

So, to sum up, we can conclude that KP-ABE's main strength is the fact that a UEcould contact whichever serving network without requesting public keys every time ithas to attach. However, it presents key management and deployment problems thatcannot be neglected, considering that it would a�ect to every mobile device.

KP-ABE suits those cases in which a message has to be sent to several recipients(i.e., more than one attribute is used for encrypting), and thus the usage of this schemewith only one attribute per ciphertext is not justi�ed, from our point of view.

4.3. Traditional public-key scheme (RSA)

From the analysis done for KP-ABE, we know that (i) it is hard to think about aglobal entity used for authentication, and (ii) if the authentication server is network-dependent, then it is su�cient if just one element in the network performs the decry-ption.

Hence, we present in this section a scheme based on a traditional public-key sche-me is used, as introduced in 2.4. As suggested in [39], a RSA-based scheme, namelyRSAES-OAEP, will be utilized. RSAES-OAEP stands for RSA Encryption Scheme,Optimal Asymmetric Encryption Padding.

Now we describe how this works, according to its speci�cation in [55] and as shownin Fig. 4.1. Let us think in what happens if Alice wants to communicate with Bob:

0. Before this communication, Bob has securely sent his public key to Alice. Let kdenote the length of the key. They also agreed on a Hash function to use, whoseoutput length is denoted by h. Optionally, they would have agreed on a sharedstring, namely Label L. Otherwise, L = 0, or zero string.

4.3. Traditional public-key scheme (RSA) 39

Figure 4.1: RSA with Optimal Asymmetric Encryption Padding, obtained from [56].

1. Alice computes the hash of the label, using the pre-agreed hash function.

2. She generates a data block by concatenating the hash of the label, a paddingstring, a 0x01 octet and the plain-text message. The padding string is a zerostring whose length is such that those of the data block is k − h− 1.

3. A h-bits random number is generated and used as a seed.

4. The seed is extended to match the data block's length through a MGF (MaskGenerator Function). This function consists of hashing the input together witha counter repeated times until the resulted length is greater or equal the desiredone.

5. The data block is XORed with the extended seed to generate the masked datablock.

6. The masked data block is then adapted to the seed's length using the MGF again,and this string is XORed with the seed, generating the masked seed.

7. Alice constructs an encoded message by concatenating a 0x00 octet, the maskedseed, and the masked data block. The length of such message is 1+h+(k−h−1) =k, i.e., the maximum length that the encryption primitive can accept.

8. Finally, Alice retrieves Bob's public key and perform the RSA encryption primi-tive, as described in Section 2.4, over the encoded message.

Bob, with his private key, follows the inverse procedure for decrypting. As an extrafeature, Bob would compare and check if the received and the expected hash of Lmatch.

Applying this to 3GPP networks, the role of Alice would always be played by theUE, whereas the decryption side would be done in the home network's HSS. Thissolution has the following features:


By setting HSS as the decryption part, its (static) public key can be provisionedin advance on the UEs, so that no additional infrastructure (such as PKI) isrequired.

The MCC and MNC parts of the IMSI need to be sent in clear text; otherwise itwould be impossible for the MME in the visited network to identify which is theUE's home network.

Control signaling from UE to MME (NAS protocol) requires no changes: insteadof sending the IMSI in clear-text in the (NAS) Attach Request or (NAS) IdentityResponse, now the UE would send the encrypted version.

To be LI-compliant, the HSS would need to inform MME about the real identityof the user. This requires a small change in DIAMETER protocol.

However, the main issue with this technique would be the key length. A minimumsecure value would be k = 2048 bits [34], [35], which implies that the message to besent over the radio interface is of the same length. It is worth noting that, nowadays,the IMSI requires 64 bits, which represents a signi�cant increase. Nevertheless, thescheme consistent in HSS performing the decryption have reported several advantagesthat will be used as a basis for other implementations.

4.4. Elliptic Curve Integrated Encryption Scheme

As described in Section 2.4.2, the usage of ECC reduces the impact both in band-width and in process time. A 256-bit EC is comparable to be at least as secure as2048 bits for RSA [34], [35]. Such level is security have been chosen to be secure in themid-term (until 2030).

ECC needs a scheme running over it, being this one the responsible of the encryptionprocedure. One example of such scheme could be ECIES (Elliptic Curve IntegratedEncryption Scheme). This Section describes how it works from a high-level point ofview.

ECIES, as its name indicates, is an integrated scheme that encapsulates encryptionand message authentication, and is one of the most employed EC-based scheme [57].Due to that, it has been standardized by several entities, such as ANSI (AmericanNational Standards Institute) [58], IEEE (Institute of Electrical and Electronics En-gineers) [59], NIST [60] and SECG (Standards for E�cient Cryptography) [61]. Thelatest standard will be used in the sequel.

It constitutes of the following functions:

KG (Key Generation): Used to generate a new key pair following the curverequirements.

KA (Key Agreement): It returns a point on the curve, namely secret or sharedpoint, resulted from the combination of the public key of one of the parties invol-ved in the communication with the private key of the other party. Primitives suchEC-DH (Di�e-Hellman) or EC-DHC (Di�e-Hellman Cofactor) can be used.

KD (Key Derivation): Responsible for generating keying material from theshared point. Examples of these functions are ANSI X9.63-KDF or NIST-800-56.

4.4. Elliptic Curve Integrated Encryption Scheme 41

Hash: Part of the KD function. Lots of hash functions can be implemented:SHA-1, SHA-2* serve as examples.

Symmetric encryption: Performs actual encryption of the message, taking assymmetric key the result of KD. AES or XOR are examples of valid ciphers.Note that format-preserving modes are compatible with this scheme, which arerespectful with the original plaintext size.

MAC: It veri�es that the encrypted message was not altered during transmis-sion, employing an integrity tag. Examples of functions that produces MAC areHMAC-SHA-1, HMAC-SHA-2* and CMAC-AES.

Figure 4.2 summarizes the encryption process, which is now analyzed from a generalperspective: Let us consider that Alice securely wants to communicate with Bob:

(2) Key Agreement

Sender’sPrivate Key

(1) Key Generation

Recipient’sPublic Key

EphemeralSecret Point

(3) Key Derivation MAC Key

EncryptionKey

(4) Symmetric

CipherMessage

Encryptedmessage

(5) MAC

MAC TagSender’sPublic Key

(6) Send cryptogram

Figure 4.2: ECIES encryption functional diagram.

0. Before this communication, Bob has securely sent his public key B to Alice, andthey have both agree in which functions to use.

1. Alice generates a fresh, ephemeral key pair to be used in this communication,using a KG function. According to equation (2.5), A = a · G, where A, a,Gdenote Alice's public and private key, and the generator point respectively.

2. By running KA, the secret point S is obtained. In the case of EC-DH, the secretkey in Alice's side is computed by multiplying her private key with Bob's publickey: S = a · B.

3. Alice obtains the keying material by running the pre-agreed KD function togetherwith the Hash. This material is split into two parts: the encryption key and theMAC key.


4. The former key and the message to be protected are fed in the symmetric cipher,giving the ciphertext as a result.

5. Such ciphertext, together with the MAC key are used to generate a so-called tag,utilizing the MAC function.

6. Alice sends her ephemeral public key, the ciphertext and the tag to Bob.

After successful transmission, Bob proceeds as indicated in Figure 4.3 and as fo-llows:

Encryptedmessage MAC TagSender’s

Public Key

(1) Receive cryptogram

(2) Key Agreement

Recipient’sPrivate Key

EphemeralSecret Point

(3) Key Derivation

MAC Key

EncryptionKey

(5) Symmetric

Cipher

Message (4) MAC

?

Figure 4.3: ECIES decryption functional diagram.

1. Bob receives Alice's cryptogram, consisting of her public key, the ciphertext andthe integrity tag.

2. Bob derives the secret point using his private key b and Alice's ephemeral publickey: S = b · A. Note that it is the same that Alice generated since they used theDi�e-Hellman primitive as explained in Eq. (2.7)

3. Hence, Bob obtains the same encryption and MAC keys by running the same KDfunction and Hash.

4. Before decryption, Bob executes the MAC function using the ciphertext and thekey from KD, and checks if the obtained tag matches with what was received.Otherwise, it would reject the communication.

5. Upon successful tag validation, the original message is retrieved by symmetricallydecrypting the ciphertext using the encryption key.

4.5. Conclusions 43

4.5. Conclusions

Based on the analysis driven in this chapter and the previous one, we can objectivelycompare all the described proposals. Six factors are going to be taken into account:

Concealment of the IMSI or MSIN: It is desirable to protect a user's identityas much as possible. Then, a whole IMSI encryption would be better comparedto just its MSIN.

Size impact: Provided that the new identi�er has to be sent on the radio inter-face, it is also desirable not to increase it.

LI-compliance: The solution ful�lls the Lawful Interception requirements asstated in Section 2.3.3.

Need of extra (and new) network nodes: Some of the solutions need toinclude new elements in the network architecture for being feasible.

Pre-provision of (new) elements in the UE: Examples of such elementscould be a static public key.

Changes in protocols: Not only if there are new message �ows, but if some ofthe existing protocols now have to add other elements.

Since a table comparing all the items would be too large, Table 4.1 summarizes themost important features of the comparison, and the items that need extra explanationand afterward discussed, referenced with a number. Note that + means increment, anda concatenation of them is used to classify the solutions according to that. Pseudonymsolutions are presented for completeness.

IMSI/ Size LI- Extra ChangesMSIN impact compliance nodes UE Prot.

DHIES (Sec. 3.1) IMSI N/D1 Yes PKI2 No Yes3

KP-ABE (Secs. 3.2.1, 4.2) IMSI4 ++ Yes AuS4 Yes5 No

RSA (Sec. 4.3) MSIN +++ Yes6 No Yes5 Yes6

ECIES (Sec. 4.4) MSIN + Yes6 No Yes5 Yes6

Pseudonyms (Sec. 3.3) MSIN ∅7 NO!8 No N/D1 No8

Table 4.1: Comparison between analyzed solutions

1. This parameter depends on the actual implementation, so it cannot be pre-determined.

2. Depending on the variant, there may be new network elements, such as PKI. Onthe other hand, the lack of such element makes the scheme vulnerable to activeattacks.

3. There are changes in the protocols in whichever of the variants. In one of them, ithas to include communications to the PKI, whereas in the other there are morestages in the Identi�cation procedure.


4. Depending on the KP-ABE solution, there may be new network elements, such asthe Global AuS. Furthermore, as discussed, the Master key held by it representsa trap door of the system.

5. The public key can be provisioned on the UEs, before the very �rst initial Attach.

6. It will be LI-compliant if there are changes in the protocol: The HSS has to informthe MME about the user's IMSI.

7. Even though the size is not a�ected, there might be some issues in the case thereis a mismatch between the UE and the HSS, main reason why there has to be arecovery mechanism.

8. It is NOT LI-compliant, but it could be if changes in protocols are considered.Nevertheless, none of the evaluated solutions suggest this change.

So, we can conclude that the ECIES proposal reduces the size of the ciphertextand public key, and the use of ECC also decreases the computational resources to beused. Not without reason, ECC arises to be the alternative to traditional public-keyschemes such as RSA [62].

Therefore, and as we have seen, ECIES results very advantageous in several aspects,and thus it is chosen to be the proposed scheme as a result of this Thesis dissertation.However, it needs of more explanations, regarding how to use it in 3GPP networksand its implications, together with some speci�cs. This is explained in Chapter 5.

Chapter 5

Encrypted IMSI based on ECIES

Drunknat? Åh nej! Det är lika omöjligt för migatt sjunka som för en kamel att trä på en synål.

Jag �yter på �äsket!

Astrid Lindgren, Pippi Långstrump

Abstract: This chapter presents our proposal to encrypt the IMSI: Elliptic Curve

Integrated Encryption Scheme. First, some details on how to use it for concealing the

IMSI are stated, together with a software realization of the scheme. Then, the implications

of the implementation of Encrypted IMSI based on ECIES are analyzed.

5.1. Usage

In Chapter 4 it was presented, after an analysis comparing some alternatives ofpublic-key systems, that ECIES is advantageous concerning computational performan-ce and bandwidth requirements. Thus, it was chosen to be implemented for concealingthe IMSI on the radio channel. This proposal was also presented as a contribution forTR 33.899 in 3GPP [63].

However, ECIES for this usage presents some speci�cs that are going to be discussedin this Chapter. First, in this Section, some features are presented, and then a Softwareimplementation is detailed.

5.1.1. Features

The proposed scheme for concealing the IMSI using ECIES is now detailed, andsummarized in �g. 5.1 for the encryption procedure:

0. Prior to IMSI encryption, the static, public key of the home network's HSS,denoted asH, has been provisioned in the UE. This could be done by, for instance,pre-provisioning it on the USIM, before it is sent to the user. Furthermore, thefunctions and elliptic curve to be used are as well known by the UE. Both aspectsare implementation dependent.

45

46 Chapter 5. Encrypted IMSI based on ECIES

EN

CR

YP

TIO

N


EncryptedMSIN

UE’s Public Key

UE’s Private Key

MCCMNC MSIN MCC

MNCMSIN

KG

Network’sPublic Key

Network’s Private Key

ECIES in use…

DE

CR

YP

TIO

N

EphemeralEncryption Key

KD

Ephemeral Shared Point

KA

ENC

Figure 5.1: Using ECIES to encrypt the IMSI, highlighted on the left.

1. When the UE needs to attach to a network, and no GUTI is available, the IMSIneeds to be sent. Its encryption starts by generating an ephemeral key pair (KG):U = u · G, from equation (2.5).

2. The secret point is obtained by the UE, according to the EC-DH primitive, asfollows: S = u · H. This is KA.

3. Such point is used for deriving (i.e., KD) key material, denoted as sκ. Suchfunction is decided to be ANSI X9.63-KDF with SHA-256 [58].

4. The key is used to symmetrically encrypt the MSIN part of the IMSI, denoted asE-MSIN. MCC and MNC are left untouched. We propose to use either AES-128in CTR mode or XOR.

5. Finally, the UE sends an encrypted IMSI (denoted as E-IMSI in the sequel)whichconsists of (‖ denotes concatenation, and EK an symmetric encrypting primitiveusing the key K):

E-IMSI ≡ MCC ‖ MNC ‖ E-MSIN ‖ U≡ MCC ‖ MNC ‖ Esκ(MSIN) ‖ U

(5.1)

The MCC and MNC are used by the serving network for routing the encryptedIMSI to the correct HSS. Note that the serving network does not need to do anythingelse than this. For the HSS, the decryption process is as follows (see Fig. 5.2):

1. The HSS retrieves the ephemeral public key from the encrypted IMSI and obtainsthe same secret point, by means of KA and its private key h: S = h · U .

5.1. Usage 47

EN

CR

YP

TIO

N


UE’s Private Key

MCCMNC MSIN MCC

MNCMSIN

Network’sPublic Key

Network’s Private Key

C S use

DE

CR

YP

TIO

NKG

EphemeralEncryption Key

KD

Ephemeral Shared Point

KA

ENCEncrypted

MSIN

UE’s Public Key

Figure 5.2: Using ECIES to decrypt the IMSI, highlighted on the right.

2. Thus, KD will return the same symmetric key sκ.

3. HSS recovers the plain-text IMSI by symmetrically decrypting E-MSIN and con-catenating MCC and MNC:

IMSI = MCC ‖ MNC ‖ Dsκ(E-MSIN) (5.2)

4. The protocol continues as nowadays. At some point, HSS must need to informthe MME about the IMSI of the user, according to LI. This process is suggestedto be done after successful authentication, i.e., piggy-backed to the (DIAME-TER) Update Location Answer message, together with some other long-termuser identi�ers such as MSISDN.

The rationale behind this implementation was introduced in Section 2.3.2. After(DIAMETER) Update Location Request, the HSS saves in its database that theUE is attached to the network that is forwarding the query. If the IMSI weresent in (DIAMETER) Authentication Info. Answer, a honest-but-curious MMEwould get the long-term identi�er without leaving a mark.

The reader may have noticed that in contrast to the de�nition of ECIES presentedin 4.4, the MAC tag was not used. The reason why this tag is not in need for ourpurpose is that, currently, there are mechanisms for which non-authorized users arerejected. As described in Section 2.3, after a user is identi�ed, an AKA procedure isinitiated. If a user is trying to attach a network using an IMSI which does not belongto him, it would be infeasible for the user to give correct answer to this procedure,provided that he lack the USIM's keys.


In the solution we are proposing, a non-valid used could try to attach the networkusing another IMSI. Thus, he would run all the steps described above for IMSI en-cryption, and �nally, he would obtain an encrypted IMSI. Naturally, the HSS wouldbe able to decrypt such, and hence initiate the AKA procedure. However, this userwould get stuck at the same point, according to the reasons described in the previousparagraph.

So, we see that, in our case, MAC function does not serve any purpose, and thuswe propose to skip it. Furthermore, this implies that the total amount of requiredbandwidth is reduced, given that, as presented in equation (5.1), we would just needto send the public key U as an extra �eld for enabling the encryption. This constitutesa useful feature, since minimizing the overload in bandwidth was one of the objectivesof the thesis.

Regarding this aspect, we can see that the total length of an encrypted IMSI, asan ECIES cryptogram, is:

CECIES = lMCC + lMNC + lE-MSIN + lU

≈ lMCC + lMNC + lMSIN + (lcurve + PC)= lIMSI + (lcurve + PC)

(5.3)

Provided that, as explained in Section 4.4, a length-preserving cipher is used. (lcurvedenotes the curve bit size. For PC, it would be either 0 or 1 bit, depending on how itis implemented on the given curve.

5.1.2. Suggested Elliptic Curves and Software implementation

According to [34] and [35], a bitsize of 256 is considered to be, at least, as secure as2048-bit RSA encryption. Then, we propose to use curves of this bitsize. Two 256-bitcurves are evaluated in this Thesis dissertation: NIST P-256 and Curve25519. Theformer, NIST P-256 [64], represents the reference curve for 256-bit ECC, and is widelyused. It is de�ned by the following equation:

y2 = x3 − 3x+ b (mod p)

where b is a �xed, large constant and p = 2256 − 2224 + 2192 + 296 − 1. Thus, its size is256 bits.

PC on this curve needs extra computation, as described in Section 2.4.2, and a bitrepresenting the sign of the point needs to be sent. Thus, for NIST P-256, a point (andtherefore a public key) is de�ned by its x-coordinate plus sign indication.

Curve25519 [65] has become the de-facto alternative to NIST P-256, given its highspeed and integrated PC [66]. Curve25519 is de�ned as follows:

y2 = x3 + 486662x2 + x (mod p)

where p = 2255 − 19, where it takes its name from. Hence, the bitsize is 255.

As introduced above, PC is natively implemented in Curve25519. This is becausethe internal calculations are always reduced to the x-coordinate, which implies thatthere is no need of sending sign indication: a Curve25519 point is perfectly de�nedwith its x-coordinate.

5.1. Usage 49

(a) NIST P-256.

(b) Curve25519.

Figure 5.3: Elliptic curves under study.

Figure 5.3 depicts both curves under study.

To demonstrate the feasibility of the system, a software implementation of ECIESwas carried out. To this end, an ECIES implementation based on Nettle was developed.Nettle [67] is a C-language, open-source cryptographic library widely used. It dependson GMP library [53] for public-key calculations.

Appendix A contains output logs on how ECIES is done for encrypting and de-crypting the IMSI, for both NIST P-256 and Curve25519. The reader might want tocheck the following details:

To show the suitability of both AES and XOR, the former is used for encryptingthe MSIN with the NIST P-256 curve, while XOR is used for the Curve25519-based implementation.

Points on the NIST P-256 curve are represented by their both coordinates (x, y),or the x coordinate plus sign indication (PC).


To compute the whole point after transmission, the HSS has to perform a modularsquare root. The Shanks-Tonelli algorithm [68] is used for this purpose.

As introduced before, Curve25519 does not need point compression.

Curve25519's bit size is 255. Therefore, the value of the most signi�cant bit isignored.

5.2. Implications

As a consequence of moving from the non-encrypted scenario to the new identi�er,some changes in the network need to be done. These changes are classi�ed accordingto if they are related to Hardware or Protocols.

5.2.1. Modi�cations on equipment

There might be some variations in the USIM or ME, depending on where theencryption stage is decided to be done; and in the HSS, responsible for decrypting inany case.

If it is decided to add the encryption stage in the USIM, then all the SIM cardsneed to be replaced so that they now implement this new feature. This deploymentseems to be very expensive, regarding delivering new cards to all users. However, onthe other hand, this procedure may enable some useful features:

Including the HSS's public key in all these new cards.

Hardware-based ECIES implementation, which might speed up the encryptingprocedure.

The possibility of refreshing IMSIs, so that the previous, exposed one is no longerrelated to a given user.

However, another possibility is that the ME takes the responsibility of performingthe encryption. This is not a problem and can be considered as a transitory solution(for example, while the SIMs are being redistributed) or a permanent solution. In theworst case, in which no hardware acceleration is done, such devices are becoming moreand more powerful, so that this process can be done in reasonable time. Results of realmeasurements on Android-based devices can be found in Section 6.1.

For the HSS, the decryption stage should not represent a problem. ECIES also hasthe characteristic of being faster for decrypting than for encrypting, due to it does notneed to generate an ephemeral key pair every time it has to perform a decryption,i.e., there is no KG stage. This, together with the fact that the HSS is already a verypowerful machine compared to MEs, the decryption part should take negligible e�ort.

5.2.2. Protocol modi�cations

The modi�cations that a�ect protocols have already been introduced above whendiscussing how the encrypted IMSI goes from the UE to the HSS. Nevertheless, andfor a detailed treatment, is now presented. Figure 5.4 presents how the protocols looklike after E-IMSI adoption.

5.2. Implications 51

Upd

ate

Loc.

Aut

hent

icat

ion

Iden

tific

atio

nCore Network (CN)Radio Access Network (RAN) HSSUE MME

[NAS] Attach RequestE-IMSI or GUTI

[NAS] Identity Request

[NAS] Identity ResponseE-IMSI

[DIAMETER] Authentication Info. RequestE-IMSI

[DIAMETER] Authentication Info. AnswerKASME, AUTN, RAND, XRES

[NAS] Authentication RequestAUTN, RAND

[NAS] Authentication ResponseRES

[DIAMETER] Update Location RequestE-IMSI

[DIAMETER] Update Location AnswerIMSI, MSISDN,…

Serving Network (V-PLMN) Home Network (H-PLMN)

Figure 5.4: Attach procedure with E-IMSI. Changes with respect to Fig. 2.4 are highlightedin bold when new identi�ers are sent, and in gray when the message is left unchanged.

(NAS) Attach Request or (NAS) Identity Response. In case the UE needs toidentify itself with IMSI, it will include it in one of these two messages. The NASprotocol allows the increase on elements to be sent.

(DIAMETER) Authentication Info Request. The encrypted IMSI is transmittedin place of the plain-text IMSI, using the same DIAMETER �eld. Again, thisdoes not require extra actions.

(DIAMETER) Authentication Info Answer, (NAS) Authentication Request and(NAS) Authentication Response. This part of the protocol is not altered at all.

(DIAMETER) Update Location Request. Again, the encrypted IMSI takes theplace of the plain-text IMSI.

(DIAMETER) Update Location Answer. To be LI-compliant, the HSS forwardsthe long-term identi�er to the MME. To do so, a new �eld containing this needsto be sent. This step is done here because, now, the MME has con�rmed thatthe user associated with a given encrypted IMSI is on its network.

Furthermore, MME has to implement some changes. For instance, it must be ableto use the new identi�er at least up to the long-term one is received; and it has toexpect to receive it in the (DIAMETER) Update Location Answer message.

Chapter 6

Evaluation and Analysis

Most ugrik a majom a vízbe.

Magyar közmondás

Abstract: ECIES is evaluated in this chapter concerning total identi�er size and

execution time for encryption, the latter through tests ran on Android devices, obtaining

good results in both studies. Remaining vulnerabilities are also discussed. We �nish the

chapter presenting the ethical, societal and sustainable implications of the work.

6.1. Performance

In this section, several implementations discussed in previous chapters are compa-red regarding the size overhead of the encrypted IMSI. Besides, for the chosen scheme(i.e., for ECIES), the delay overhead is measured to determine the feasibility or not ofthis solution.

6.1.1. Size analysis

As already mentioned, the size of the encrypted IMSI is an important parametersince it has to be sent over the radio interface. A comparative between the analyzedschemes (Pseudonyms, KP-ABE, RSA, and ECIES) concerning �nal identi�er lengthis now presented.

In Section 2.2, we saw that: (i) the IMSI is at most 15 BCD digits; and (ii), followingthe European convention, 2 digits (8 bits) are allocated to the MNC. Therefore, wewill assume for our calculations that the MSIN is 10 BCD digits, or 40 bits.

For the case of traditional public-key schemes, such as RSA, the MCC and MNCparts of the IMSI are sent in clear text, so that the visiting network can route theidenti�er to the correct PLMN. The MSIN is concealed using the RSA primitive.Assuming that a 2048-key is used, as discussed in Section 4.3, the MSIN would be ofthe same size. No other parameters are needed. Hence,

CRSA = lMCC + lMNC + lRSA

= 12 + 8 + 2048 = 2068 [bits](6.1)

53

54 Chapter 6. Evaluation and Analysis

The KP-ABE case was analyzed in Section 4.2. Considering the best-case situation,in which the large universe construction based on a 256-bit Elliptic Curve is used, andonly one attribute is going to be used for encrypting, the equation (4.4) is then:

CKP-ABE, large(n = 1) = lIMSI + 2 · (lcurve + PC)= 60 + 2 · (256 + 1) = 574 [bits]

(6.2)

Finally, for the ECIES case analyzed in Section 5.1, the equation (5.3) summarizesthe impact of ECIES in the encrypted IMSI. We recall that the MCC and MNC aresent in clear text, and then the MSIN is encrypted using a length-preserving cipher.In addition, a point on the curve representing the ephemeral UE's public key has tobe sent as well. Therefore, for a 256-bit curve, the total size would be as follows:

CECIES = lMCC + lMNC + lMSIN + (lcurve + PC)= 12 + 8 + 40 + 256 + 1 = 317 [bits]

(6.3)

Pseudonym-based approaches, as it was discussed in Section 3.3, are here presentedfor completeness. One of the advantages of these schemes is that the length of thePseudonym is that of the MSIN, and no extra elements need to be sent.

CPseudonym = lMCC + lMNC + lMSIN

= 12 + 8 + 40 = 60 [bits](6.4)

The Table 6.1 compares these four solutions. Note that, for KP-ABE, the wholeIMSI is encrypted, so it makes no sense to talk about encrypted MCC, MNC andMSIN separately.

Solution MCC MNC MSIN Others TOTAL

RSA 12 8 2048 0 2068

KP-ABE 60 514 574

ECIES 12 8 40 257 317

Pseudonyms 12 8 40 0 60

Table 6.1: Cipher text size, in bits, as a function of the solution

If we compared them only regarding bandwidth, the most advantageous solutionwould be Pseudonyms, but in Section 3.4 was already stated that the Pseudonyms onitself did not constitute a full solutions due to the extra need for a recovery mechanism.After this, our implementation of ECIES results in the best option according to totalidenti�er length.

6.1.2. Delay introduced by ECIES

So far, it has been shown that ECIES constitutes a very �exible solution, and itsimpact on bandwidth is the smallest of the analyzed public-key schemes. Now, we willevaluate the increment on execution time due to ECIES encryption and decryption.

6.1. Performance 55

Nevertheless, we focus on encryption, since it requires more time than decryption(because of KG), and it has to be done in portable and constrained devices. To eva-luate the performance di�erence, the tests included both NIST P-256 and Curve25519Elliptic Curves.

It was decided to develop a second application test based on another crypto libraryto compare their performance. The second library was decided to be OpenSSL [69],one of the reference implementations in the cryptographic world. Not without reason,it serves as a basis for several applications, such as OpenSSH.

On the �rst implementation, the low-level API (Application Programming Interfa-ce) (i.e., functions starting with EC_) was used, since it was considered to be more ver-satile than the high-level API (i.e., functions starting with EVP_). However, Curve25519is not compatible with the low-level API, since the curve operations are not compatiblebetween NIST curves and Curve25519. After contacting the OpenSSL team [70], theysuggested us to use the high-level API, which is compatible with all the supportedcurves in OpenSSL.

6.1.2.1. Experiments on Android

Given the fact that our test applications were written in C-language, it was decidedto run the test on Android-based devices, which admit cross-compilation from C-�leson a host computer. In addition, the Nettle library and its dependent GMP needed tobe cross-compiled as well. We used Ubuntu v14.04 (kernel v4.4) as a host machine.

We ran the tests in four Android devices with di�erent computational capabilities,representing a sample of the actual market of UE. The table summarizes their maincharacteristics:

Market name System-on-chip Clock rate Android version Ref.

Sony Xperia Z1 Compact Qualcomm MSM8974 2.2 GHz 5.1.1 Lollipop [71]

BQ Aquaris E10 MediaTek MT6592 1.7 GHz 4.4.4 KitKat [72]

BQ Aquaris E5 HD MediaTek MT6582 1.3 GHz 5.0 Lollipop [73]

Nexus 1 Qualcomm QSD8250 1.0 GHz 2.3.7 Gingerbread [74]

Table 6.2: Android devices

In the sequel, we are going to refer to these devices using its processing capabilities,since they represent the most relevant parameter that will a�ect the results.

The test application measures the elapsed time of each ECIES encryption function,as described in Section 4.4: KG, KA, KD; and two symmetric ciphers: AES and XOR.Note that ECIES follows a serial execution, which implies that we need for the previoustask to �nish before starting the new one. Thus, there is a compromise between totaltest execution time and accuracy. To this end, two kinds of measurement schemes wereimplemented, depending on the desired accuracy:

The high-accurate method consisted of measuring several times from the be-ginning to the end of the desired stage. Then, an average value was obtained, andthe di�erence between it and the previous ones represents this stage's executiontime. The scheme is repeated for every stage.


Let us explain it better with an example. On ECIES, the �rst batch of mea-surements would be from the beginning to the end of KG, which gives us ahigh-accurate value for a normal KG operation. Then, we can add KA, so themeasurement goes from the beginning to the end of KA. Provided that we ha-ve the average time for KG, the di�erence between the measured time and theprevious average gives us the high-accurate value for KA.

The drawback of the high-accurate method is the test execution time since forevery newly added stage, the time it takes is longer due to we are concatenatingmore and more ECIES functions. Then, a low-accurate method was written,mainly for the less relevant stages. It consisted on executing the whole ECIESencryption procedure, measuring each stage with a di�erent clock. As a result,after one execution, we had values for the time of all stages in much less time.

For measuring the time, the C function clock_gettime() from the standard librarytime.h was used. This function provides several �ags that de�ne the time actually mea-sured. In our case, we decided to use CLOCK_PROCESS_CPUTIME_ID, which returns theelapsed time of e�ective CPU usage of the process. In contrast, the CLOCK_MONOTONIC�ag measures as a wall-clock: the elapsed time between the process started and �nis-hed, including thus the possible periods of time in which the CPU was busy with otherprocesses.

To download the test applications, run them, and retrieve the results in Androiddevices, we used the so-called Android Debug Bridge [75]. It provides an interface tothe Linux kernel of Android, consisting of a Linux command terminal, from the user'smachine to which the Android device is connected.

6.1.2.2. Observations

The following tables show the observation measurements on the Android devices,for NIST P-256 and Curve25519 curves, and for Nettle and OpenSSL implementations.Table 6.3 and 6.4 include the measurements for KG and KA, i.e., the most signi�cantones; whereas Table 6.5 details the other measured functions, so-called common ope-rations, since they do not depend on the used curve (KD, AES and XOR). They arepresented for completeness, as they are at least 100, 150 and 300 faster than KG,respectively.

The core measurements, KG and KA, were obtained by running the high-accurateprocedure over 10K times. Tests were also done with 100K times, but no noticeabledi�erence was observed, and thus it was decided to run it less times. The standarddeviation in the results was at most 0.4 ms for all tested implementations and devices.In addition, the results for KD, AES and XOR were obtained by the secondary method.Nevertheless, the di�erence between methods is minimal.

In Appendix B we present the raw outputs from the test in the Android devices. Asthe reader may check, the time measuring function for Nexus 1 (Qualcomm QSD8250)was not sensitive enough so that no data could be obtained for the fastest operations.

Benchmarked results are included in the tables to put the measures in context.The reference for them is eBACS [76], a cryptographic benchmark that measures timeperformance of various public-key systems, symmetric ciphers and hash functions.eBACS is part of the European ECRYPT project [77], which joints several researchinstitutes and companies for the evaluation and development of cryptographic systems.

6.1. Performance 57

Nettle OpenSSL BenchmarkKG KA KG KA KG KA

2.2 GHz Qualcomm MSM8974 1.39 1.56 4.62 4.69 0.62 2.11

1.7 GHz MediaTek MT6592 2.36 2.94 6.37 6.5 1.01 3.43

1.3 GHz MediaTek MT6582 3.22 4.03 8.73 8.9 1.33 4.49

1.0 GHz Qualcomm QSD8250 3.16 4.38 10.28 10.47 1.37 4.65

Table 6.3: Execution time, in ms, for NIST P-256 (KG and KA)

Nettle OpenSSL BenchmarkKG KA KG KA KG KA

2.2 GHz Qualcomm MSM8974 1.31 1.24 0.43 1.18 0.19 0.19

1.7 GHz MediaTek MT6592 2.10 2.23 0.97 2.77 0.55 0.54

1.3 GHz MediaTek MT6582 2.87 3.06 1.34 3.79 0.72 0.71

1.0 GHz Qualcomm QSD8250 2.93 3.51 1.27 3.51 0.42 0.41

Table 6.4: Execution time, in ms, for Curve25519 (KG and KA)

Nettle OpenSSLKD AES XOR KD AES XOR

2.2 GHz Qualcomm MSM8974 10.94 4.37 1.51 3.80 2.91 1.41

1.7 GHz MediaTek MT6592 19.15 6.54 1.31 5.63 4.15 1.23

1.3 GHz MediaTek MT6582 21.76 7.38 1.62 10.61 8.32 1.92

1.0 GHz Qualcomm QSD8250 N/D

Table 6.5: Execution time, in µs, for the Common Operations (KD, AES and XOR)

Since the precise Android devices used for our analysis were not available in eBACS,we selected the most similar ones to them, scaled by the actual CPU frequency of eachdevice. For Qualcomm (Snapdragon) MSM8974 and Qualcomm QSD8250, Qualcomm(Snapdragon) S3 was selected; and for MediaTek MT6592 and MT6582, the Broad-comm Cortex A7 was targeted.

The �gure 6.1 shows the total execution time of the KG and KA for the selecteddevices. As can be seen, for the worst-case scenario, i.e., 1.0 GHz Qualcomm QSD8250running NIST P-256 over OpenSSL, the extra delay caused by ECIES encryption is20.75 ms. This represents a good mark, given that the user would not experience it andthe encryption procedure is not expected to be done very often, as discussed in 3.4.On the other hand, for the device that performed the best, i.e., 2.2 GHz QualcommMSM8974 running Curve25519 over OpenSSL, the total delay was as little as 1.61 ms.

Note that these measures should be considered as an upper bound. Compared tothe performance measured in eBACS, there is still room for enhancements that wouldimprove these marks. But, already with the current state of the art, we consider thatECIES encryption in mobile devices is perfectly feasible from a technical perspective.

6.1.2.3. Remarks on decryption

Some notes about decryption are presented before �nishing the section. No mea-surements were done on actual HSS since such machines are not as common as MEs.However, and as introduced in Section 5.2, the decryption procedure should not re-


ECIES measurements


0,00

5,00

10,00

15,00

20,00

25,00

Tota

l tim

e (K

G +

KA)

in m

s

NIST-P256 Curve25519

2.2 GHz Qualcomm MSM89741.7 GHz MediaTek MT65921.3 GHz MediaTek MT65821.0 GHz Qualcomm QSD8250

Figure 6.1: Total execution time (KG + KA) in the tested devices.

present a problem for the HSS because (i) decryption is by construction faster thanencryption, and (ii) HSS is a very powerful machine regarding computation resources,compared to MEs.

6.2. Remaining vulnerabilities

In this section, some problems with the use of the encrypted IMSI are analyzed.

First of all, it is important to recall the fact that the encrypted IMSI is usedunder very speci�c circumstances, such as the very �rst attach to a network or asa recovery mechanism. In the normal operation, the GUTI is used, and thus theuntraceability and privacy mechanisms evaluated for the case of the encryptedIMSI must hold as well for this temporary identi�er. Issues related to the lack ofGUTI update and subscriber linkability are out of the scope of this Thesis.

Furthermore, since the encrypted IMSI is not sent very often, it is not pro�tableto use Pseudonyms. As already discussed, they require of a recovery mechanismfor the case in which the home network and the UE get out of synchronizationbecause there is risk for the UE to be locked-out of the system. Such recoverymechanism is based on public-key cryptography, which implies that two solutionswould have to co-exist at the same time.

The long-term identi�er IMSI is not only used over the radio interface in the(NAS) Attach Request or (NAS) Identity Response. The UE can in 4G be pagedby the network using the IMSI, which implies that the IMSI is sent in clear textin the Paging channel over a certain area, which the subsequent privacy issues.

This problem is treated in detail in [78]. The discussed solutions rely on sendingparts of an ephemeral identi�er, such as an encrypted IMSI or a Pseudonym, asPaging identi�ers. Then, the UE re-attaches to the network by sending a newencrypted IMSI, so that it is untraceable.

6.3. Ethical, societal and sustainability aspects 59

In our ECIES solution, the MCC and MNC parts of the IMSI are still sent inclear text over the radio interface, since it has to be possible for the MME torecognize the home network's HSS. This is not an issue for non-roaming users,since most of them in the network share the same combination of MCC andMNC and the MSIN is sent encrypted. But, for the roaming scenario, a user ison a visited network; thus the MCC and MNC are di�erent from those of thenetwork's native users.

Hence, there would be some privacy issues when the number of roaming usersfrom a given network is signi�cantly small. On the extreme, if there were onlyone roaming user within a network, it would be identi�able from its MCC andMNC, provided that this combination is unique to him.

Nevertheless, it is important to argue that such extreme situation is very unlikely.In fact, perfect privacy is never achievable because of these cases (e.g., if thereis just one user in a network, there is no possible privacy since every action islinked to it).

Regarding backward compatibility, we must highlight that none of the evaluatedsolutions covered in this Thesis dissertation (i.e., Pseudonyms, public-key sche-mes or identity-based schemes) are backward compatible, because of the LawfulInterception requirements. Current networks (up to 4G) expect to receive thelong-term identi�er IMSI in cleartext from the UE in one of the presented mes-sages, which implies that if the UE does not send it anymore, the solution cannever be backward compatible unless the LI requirements change.

As discussed, some solutions suggest other ways of sending it to the visited net-work to ful�ll the LI requirements. But, since the MME does not expect to receivesuch identi�er from other channels, it would require some changes, and then thesolution is not backwards compatible.

Finally, we consider the scenario where a 5G user has to connect to a 4G network,for instance. In the previous paragraph, it is analyzed that it is simply forced touse the long-term identi�er, given the actual regulatory framework. This wouldimply that one possible attack could be a Denial of Service on the 5G networkso that the attacked user has to send its IMSI in cleartext.

6.3. Ethical, societal and sustainability aspects

When moving from cleartext IMSI to encrypted IMSI, there would be some ethical,societal and sustainability aspects that needs to be considered.

First of all, it would be necessary to re-adapt all users'USIMs, if for example newIMSIs are allocated to users, to unlink them from the previous ones; or if the ECoperations are decided to be done on the smart card. This would imply that new UICCsneed to be sent to every single user, which would result in costs for the operators.

Besides, this increment of privacy is transparent to the user, who will never noticethat such protection is being used: the subscriber will continue accessing the networkservices as before. This could be on the other hand disadvantageous for a user sinceit will impossible to distinguish if there is an attack (e.g. malicious 4G handover) andtherefore if its IMSI has been compromised.


Second, and from an ethical perspective, privacy is seen as a good feature for societysince it empowers the user, making him the owner of his information, and thus havingthe ability to share the desired amount of information with those of his choice.

For good reasons, nowadays more and more companies are interested in gatheringdata from their users that afterward can be sold to third parties. In fact, when anInternet service is o�ered as free, then in most of the cases we are paying with ourinformation. Recalling what we said in the previous paragraph, by doing so we areindirectly empowering the providers of these services.

This is actually how the biggest companies in the Net, such as Google or Facebook,work, but not only them. It became worldwide famous how even simple Smartphoneapplications (for instance, a �ashlight app) were asking for permissions to access data,even though it was not relevant for its correct operation [79].

Going back to IMSI protection, by concealing the identi�er we are making harderfor others to trace and follow users, to both malicious and curious-but-honest attackers.However, it is important to recall that, when the information is used for good, it canhelp to several purposes. Thus, the analysis of part of our personal data can improveown security, and then we must permit that part of it is used by authorities if neededon a legal framework.

Chapter 7

Conclusions

I think you'll have to �nd your way like the rest ofus, Sonny. That's what Dr. Lanning would've

wanted. That's what it means to be free.

Detective Spooner, I, Robot

Abstract: In this �nal chapter, conclusions from this work are stated, highlighting

the ful�llment of the initial objectives and the suitability of the proposed solution. Ad-

ditionally, some future lines of this Thesis are presented and analyzed.

7.1. Conclusion

The main goal of the Thesis work was to �nd and propose a solution for enhancingthe long-term subscriber identi�er (IMSI) privacy in 5G systems, with a particularfocus on the IMSI-based Attach procedure. After a preliminary analysis of the relatedworks, it was decided to suggest and implement a method in which the IMSI wasencrypted employing public-key cryptography.

Hence, research was conducted in this sense for determining which public-key ap-proach was the most suitable in our case. Several implementations were analyzed,including KP-ABE, RSA, and ECC. Finally, it was decided to base our solution inElliptic Curve Integrated Encryption Scheme.

The solution we have proposed, encrypted IMSI based on ECIES, consists of ge-nerating a shared, secret key at both sides from the result of applying public-keyprimitives. Such secret key is then used for the symmetric encryption of the MSINpart of the IMSI. The MCC and MNC are sent in clear text, such that the servingnetwork can identify the user's home network, which is the responsible for performingthe decryption.

To do so, as a previous step the home network must have provisioned its staticpublic key in the UE. Then, for allowing the decryption, the UE forwards in the newidenti�er its ephemeral public key. Note that, due to the short-term validity of theUE's public key, the proposal is randomized, i.e., every time the identi�er is refreshed,it will look di�erent.

61

62 Chapter 7. Conclusions

Therefore, the privacy enhancement goal is ful�lled. The proposed solution is re-sistant to active and passive IMSI-Catcher attacks, which will make them virtuallyuseless. For a passive attack, the attacker would eavesdrop a temporary identi�er,which is untraceable with its actual long-term identi�er. On the other case, if the at-tack is more elaborated and impersonate an eNB and fool the user, it would just replywith the encrypted IMSI, which is useless for the attacker to know.

There are some changes to be done in the NAS and DIAMETER protocols to allowthis identi�er go on the network, along with some minor modi�cations in the MME. Ofcourse, the HSS and the UE have to be able to perform ECIES operations. Nevertheless,these modi�cations are judged to be a�ordable and easy to implement. Further, thesolution is compatible with the actual implementations of network nodes such as eNB,most of the protocols analyzed in Section 2.3 (all but NAS and DIAMETER), andprocedures such as LI.

Changes in the USIM are not mandatory if the HSS's static public key is provisionedon the ME, and the EC operations are done in the general processor. Nevertheless,issuing new USIMs would result in new IMSI per subscriber, so that the map is reset.On the other hand, this process is costly.

Another property of the proposal to be highlighted is the lack of a recovery me-chanism, i.e., the system does not rely on varying �elds that require synchronization.Therefore, the UE will always be able to generate new identi�ers to be correctly deco-ded by its HSS, and thus there is no risk for the user to be locked out of the system.

In this sense, yet another characteristic is that it can be used as a part of a morecomplex system, such as acting as the recovery mechanism for a system that needs so,for instance, Pseudonyms approaches.

We have also shown that the scheme presents good performance �gures concerningboth total identi�er size and execution time in commodity devices. For the former, wehave shown that our scheme performs the best of the analyzed ones based on public-key cryptography. Secondly, the results on Android devices presented in Section 6.1prove that it is feasible for actual MEs to perform the required operations.

Last but not least, and even though we focused the work on the uplink channel, wehave also presented solutions based on encrypted IMSI that allows the enhancementof user privacy in the downlink one. The analysis is referred to the Paging channel,for which the user is noti�ed in case of missing network services, such as an incomingcall. This aspect is further discussed in the paper [78].

To sum up, the arguments given in the present dissertation point to the fact thatthere are not technical obstacles for the introduction of a mechanism for the conceal-ment of the IMSI, and therefore it should be taken into account when developing thetechnology and standards for the future 5G network.

7.2. Future lines

After this Thesis, there is still some work that can be done to continue the researchon IMSI protection, as well as some new features that can be exploitable:

Inclusion in 5G standards. Hopefully, a proposal for concealing the IMSIwill be accepted in 3GPP. In our case, some practicalities have to be taken intoaccount before moving to this step. Examples of such are (but not limited):

7.2. Future lines 63

• Elliptic Curves to be used. In the Thesis, we worked with NIST P-256 andCurve25519. It is for further study to decide if the curve has to be stan-dardized together with the scheme, no matter whether these speci�c curvesare decided to be used or not; or if this parameter is left dependent on eachimplementation.

• Modi�cations at the UE side. The only thing that our proposal needs towork is the static public key of the home network. Again, it is for furtherstudy how to securely provision such key, and where the encryption processis done, e.g., as a normal CPU task or using dedicated hardware.

• Modi�cations at the CN side. We have seen, in Fig. 5.4, that to let theencrypted IMSI �ow in the protocol stack some changes have to be done.Nevertheless, there are some other valid solutions, being what is proposedhere just a proof of concept of a feasible and requirement-compliant imple-mentation.

• Format-preserving encryption. The presented proposal is suitable to be usedwith a format-preserving cipher [80], which generates a cipher text consis-tent of digits of the same alphabet. For the MSIN case, it implies that theencrypted MSIN would consist of at most 10 BCD numbers, i.e., it wouldlook like a true MSIN. This idea was left unaddressed in this work becauseit implied extra (around eight) iterations in the symmetric cipher. However,after checking the results from Section 6.1, we see that this would almostnot impact on the performance.

Analysis on IoT devices. We focused our evaluation in commodity Androiddevices, but as we stated in Section 1.1, it is expected that IoT will play animportant role in the 5G society. Therefore, it would be interesting to see some�gures of how ECIES encryption performs in such devices.

We also saw in Section 6.1 that there is a relation between the execution timeand the CPU frequency: the faster the CPU, the faster the process is done,as expected. Hence, since IoT devices may be very constrained in this aspect,it would a�ect the performance. However, it is noteworthy to say that ECIESencryption is expected to be done not so frequently because, for normal operation,the short-term identi�er GUTI will still be used.

Impact of future Quantum computers. In [81], researchers claim that, inthe future, Quantum computers would be able to break public-key cryptographyapproaches in general, and subsequently ECC. Therefore, it would be a threatfor the upcoming years, and a challenge for researchers to re-think public keycryptography.

Digital signature: Since the UE has been provisioned with the public key of itshome network, some messages could now be signed. In this sense, there are alsoways of signing based on ECC, such as ECDSA (Elliptic Curve Digital SignatureAlgorithm). It is thus for further study to analyze the convenience of doing so.

Secure channel between the user and its home network. The derivedsecret key sκ described in Section 5.1 is a de-facto shared key which is onlyknown to the UE and its HSS. Hence, it can be interpreted as a secure channelbetween these two parties. As before, it is for further study to determine the

64 Chapter 7. Conclusions

worthiness of this aspect. Note that, in this case, the XOR cipher would not be afeasible option, because it is vulnerable to the plain-text attack as we presentedin Section 2.4.3. However, AES-CTR would be still suitable for this purpose.

Combination of KASME and sκ in the AKA procedure. By doing so, thesession key between the MME and the UE will take into account both keys,which would increase the security of the scheme. This proposal, which is nowbeing discussed in 3GPP, has another useful feature, which is that it would bepossible for the MME to decrypt the encrypted MSIN. Therefore, there is anincrease of the trust between the MME and the HSS, since the former can nowcheck the IMSI that came from the UE. On the other hand, sκ can no longer beused for a secure channel as explained in the previous item.

Appendices

65

Appendix A

ECIES implementations

A.1. NIST P-256

HSS static parameters:

h = 0xd17025d613995dfbf77f00ba2bd8b23fef9d97a535cb3ae60436fd5209170aa2

Hx = 0x319d7d5f85946760d393cc659813c65762ee53f5b336792702f8af6a36fed35e

Hy = 0x132d036348b10f189330875f72f15c28c538d8c8f030f9899637073eea1e0c5b

Encryption

<1> Generating ephemeral UE keypair... (KG)

u = 0x190837fbe66e165bee39084df30723729e4a497e8cb8c64c9b385ce64eb4c77a

Ux = 0x407a52b5bd88bda9d61505090f552e9497158e624c526bf153c3ee691f2bb301

Uy = 0x84bf7a08616ff8f0268925375d28621836813d875d8f15b130b7bb14c7c22d17

<2> Computing secret point and key using SHA2... (KA + KD)

Sx = 0x1eb3e6fa1e915bc9366077a4c5e11ac3072b714379fc6e88532df33eeb45a5e0

Sy = 0x635fd574f6923d876a0b400cf2bf6e7f81398f8474829761afda4ae1904db415

sκ = 0x57eb17deb02fbb4c06517f852130cd4a

<3> Encrypting MSIN using AES... (Enc)

MSIN = 0x9876543210

E-MSIN = 0x27097d2a03

<4> Sending data to HSS...

E-MSIN = 0x27097d2a03

U = 0x407a52b5bd88bda9d61505090f552e9497158e624c526bf153c3ee691f2bb301

PC = 0b1

67

68 Appendix A. ECIES implementations

Decryption

<1> Reading data from UE...

E-MSIN = 0x27097d2a03

U = 0x407a52b5bd88bda9d61505090f552e9497158e624c526bf153c3ee691f2bb301

PC = 0b1

<2> Recovering UE's public key...

Ux = 0x407a52b5bd88bda9d61505090f552e9497158e624c526bf153c3ee691f2bb301

Uy = 0x84bf7a08616ff8f0268925375d28621836813d875d8f15b130b7bb14c7c22d17


Sx = 0x1eb3e6fa1e915bc9366077a4c5e11ac3072b714379fc6e88532df33eeb45a5e0

Sy = 0x635fd574f6923d876a0b400cf2bf6e7f81398f8474829761afda4ae1904db415

sκ = 0x57eb17deb02fbb4c06517f852130cd4a

<4> Decrypting MSIN using AES... (Enc)

E-MSIN = 0x27097d2a03

MSIN = 0x9876543210

A.2. Curve25519 69

A.2. Curve25519

HSS static parameters:

h = 0x2ebd38879a2f0c1ae1298cba354bc351d19d66a42de8a1be769b339683b6fbca

H = 0x4954093380602738aac213fe67e44b800a4ba45e55994c1076c50e2f6e6b287a

Encryption

<1> Generating ephemeral UE keypair... (KG)

u = 0x54df6aa1286b260f96ce2d28dd133c4a4be4885ef2583179ee2677bc30d934e7

U = 0x7506affd4088ee5477e848174f9c657210dc906cf91830dfb0dce50b46dae2e2


S = 0x7a4068acbd67ec85218440e9371494a05ca0a0d55140ed7b732ebf542b933041

sκ = 0x9e23beecc839827ae8232602d91e44f5

Note that the bitsize of Curve25519 is 255, which implies that the most signi�cantbit, i.e. the leftmost bit, of the point is neglected. To prove so, we vary H in this lineand repeat the KA + KD stages:

H′ = 0xc954093380602738aac213fe67e44b800a4ba45e55994c1076c50e2f6e6b287a


sκ = 0x9e23beecc839827ae8232602d91e44f5

<3> Encrypting MSIN using XOR... (Enc)

MSIN = 0x9876543210

E-MSIN = 0x0655eaded8

<4> Sending data to HSS...



70 Appendix A. ECIES implementations

Decryption

<1> Reading data from UE...



<2> Recovering UE's public key...

There is no need of doing so, since Curve25519 works by construction only withthe x-coordinate.



sκ = 0x9e23beecc839827ae8232602d91e44f5

<4> Decrypting MSIN using XOR... (Enc)


MSIN = 0x9876543210

Appendix B

Test results

Nexus 1, Nettle

Starting Prime256 test, 10000 iterations...

KG: 3167.630

KA: 4386.966

End of Prime256 test...

Starting Curve25519 test, 10000 iterations...

KG: 2939.948

KA: 3514.920

End of Curve25519 test...

Starting Prime256 test...

7720.947: 3234.863, 4394.531, 61.035, 30.518, 0.000

7659.912: 3234.863, 4394.531, 30.518, 0.000, 0.000

7690.431: 3234.864, 4425.049, 30.518, 0.000, 0.000

7690.428: 3173.828, 4455.565, 30.518, 30.517, 0.000

7690.431: 3204.346, 4425.049, 30.518, 30.518, 0.000

7598.877: 3173.828, 4394.532, 0.000, 30.517, 0.000

7598.877: 3173.828, 4394.531, 0.000, 30.518, 0.000

7598.877: 3173.828, 4394.532, 0.000, 30.517, 0.000

7598.877: 3173.828, 4394.531, 0.000, 30.518, 0.000

7568.360: 3173.828, 4364.014, 30.518, 0.000, 0.000


Starting Curve25519 test...

6469.727: 2929.688, 3509.521, 30.518, 0.000, 0.000

6500.244: 2960.205, 3509.521, 0.000, 0.000, 30.518

6500.244: 2960.205, 3540.039, 0.000, 0.000, 0.000

6469.727: 2929.688, 3509.521, 30.518, 0.000, 0.000

6469.726: 2960.205, 3509.521, 0.000, 0.000, 0.000

6500.244: 2960.205, 3509.521, 30.518, 0.000, 0.000

6469.727: 2929.688, 3509.521, 0.000, 30.518, 0.000

6469.726: 2929.687, 3509.522, 30.517, 0.000, 0.000

6500.244: 2929.687, 3540.039, 0.000, 30.518, 0.000

6439.209: 2929.688, 3509.521, 0.000, 0.000, 0.000


That's all Folks! for Nettle library

Nexus 1, OpenSSL

Starting Prime256_EVP test, 10000 iterations...

KG: 10279.504

KA: 10477.985

End of Prime256_EVP test...

Starting X25519 test, 10000 iterations...

KG: 1269.861

KA: 3507.596

End of X25519 test...

Starting Prime256_EVP test, sequential mode...

20904.541: 10375.977, 10467.529, 30.517, 30.518, 0.000

20721.435: 10284.424, 10437.011, 0.000, 0.000, 0.000

20904.541: 10314.941, 10559.082, 0.000, 30.518, 0.000

20690.919: 10223.390, 10437.012, 0.000, 30.517, 0.000

20660.401: 10253.907, 10375.976, 0.000, 30.518, 0.000

20874.024: 10314.942, 10528.564, 0.000, 30.518, 0.000

20782.471: 10284.424, 10467.529, 30.518, 0.000, 0.000

20507.812: 10162.353, 10314.942, 30.517, 0.000, 0.000

20935.058: 10406.494, 10528.564, 0.000, 0.000, 0.000

20446.777: 10131.836, 10284.424, 30.517, 0.000, 0.000


Starting X25519 test, sequential mode...

4791.260: 1281.738, 3509.522, 0.000, 0.000, 0.000

4821.777: 1281.738, 3509.522, 0.000, 30.517, 0.000

4760.742: 1251.221, 3509.521, 0.000, 0.000, 0.000

4821.777: 1281.738, 3509.522, 0.000, 0.000, 30.517

4760.742: 1251.220, 3509.522, 0.000, 0.000, 0.000

4791.259: 1281.738, 3509.521, 0.000, 0.000, 0.000

4791.260: 1281.738, 3479.004, 30.518, 0.000, 0.000

4791.260: 1251.221, 3509.521, 30.518, 0.000, 0.000

4791.259: 1281.738, 3479.004, 0.000, 30.517, 0.000

4760.742: 1251.221, 3509.521, 0.000, 0.000, 0.000


That's all Folks! for OpenSSL library

71

72 Appendix B. Test results

Aquaris E5 HD, Nettle


KG: 3218.551

KA: 4031.714



KG: 2875.137

KA: 3058.649



7352.539: 3226.770, 4039.846, 65.692, 18.308, 1.923

7257.692: 3202.769, 4020.308, 23.769, 8.923, 1.923

7229.384: 3199.231, 3997.461, 23.000, 8.000, 1.692

7246.462: 3217.385, 3996.846, 22.846, 7.769, 1.616

7249.769: 3197.615, 4019.769, 23.154, 7.538, 1.693

7225.846: 3198.538, 3996.770, 21.769, 7.077, 1.692

7246.308: 3212.923, 3999.154, 24.462, 8.154, 1.615

7246.923: 3217.154, 3998.000, 22.693, 7.461, 1.615

7241.923: 3198.385, 4012.000, 22.538, 7.308, 1.692

7225.923: 3198.000, 3996.769, 22.308, 7.153, 1.693



5903.308: 2852.077, 3031.923, 10.077, 7.538, 1.693

5917.616: 2869.385, 3029.385, 10.230, 7.000, 1.616

5914.538: 2853.000, 3042.692, 10.231, 7.077, 1.538

5900.923: 2853.923, 3028.231, 10.385, 6.692, 1.692

5919.077: 2853.308, 3045.153, 11.693, 7.384, 1.539

5910.231: 2857.154, 3030.769, 12.538, 8.077, 1.693

5925.923: 2877.616, 3029.153, 10.462, 7.154, 1.538

5978.384: 2854.385, 3088.614, 19.846, 13.616, 1.923

5978.692: 2925.231, 3031.846, 11.539, 8.461, 1.615

5940.462: 2854.462, 3064.846, 11.692, 7.847, 1.615



Aquaris E5 HD, OpenSSL


KG: 8730.881

KA: 8901.724



KG: 1340.321

KA: 3786.213



19116.846: 9415.307, 9633.078, 40.000, 26.153, 2.308

19375.769: 9627.538, 9723.847, 12.461, 10.077, 1.846

18311.921: 9387.692, 8907.768, 8.154, 6.615, 1.692

17972.000: 8815.153, 9136.616, 10.077, 8.308, 1.846

17762.845: 8784.000, 8951.461, 14.230, 11.539, 1.615

17637.538: 8758.538, 8860.539, 9.077, 7.846, 1.538

17421.000: 8605.385, 8798.461, 8.616, 6.615, 1.923

17627.384: 8763.769, 8841.923, 10.615, 9.231, 1.846

17693.769: 8791.000, 8887.308, 8.154, 5.384, 1.923

17803.538: 8826.308, 8945.923, 17.923, 11.692, 1.692



5138.461: 1339.000, 3782.384, 8.923, 6.154, 2.000

5175.538: 1375.153, 3779.769, 11.693, 7.307, 1.616

5141.077: 1344.692, 3781.539, 7.769, 5.461, 1.616

5171.077: 1361.615, 3793.693, 8.692, 5.539, 1.538

5132.923: 1330.846, 3788.307, 7.693, 4.538, 1.539

5092.385: 1322.461, 3757.231, 7.154, 4.000, 1.539

5148.001: 1330.616, 3802.923, 8.000, 4.923, 1.539

5094.000: 1323.923, 3757.231, 7.230, 4.000, 1.616

5115.384: 1317.230, 3784.539, 7.385, 4.692, 1.538

5102.077: 1319.385, 3769.154, 7.538, 4.308, 1.692



73

Aquaris E10, Nettle


KG: 2363.658

KA: 2940.272



KG: 2100.102

KA: 2234.315



5416.461: 2399.307, 2949.231, 50.385, 15.923, 1.615

5326.461: 2357.153, 2943.308, 18.077, 6.615, 1.308

5337.769: 2372.000, 2940.308, 18.154, 5.923, 1.384

5346.922: 2351.769, 2968.076, 19.154, 6.538, 1.385

5315.230: 2351.846, 2939.308, 17.153, 5.616, 1.307

5328.077: 2350.769, 2953.077, 17.462, 5.461, 1.308

5313.076: 2350.923, 2939.000, 16.384, 5.385, 1.384

5335.539: 2357.077, 2953.616, 18.000, 5.538, 1.308

5313.615: 2351.538, 2938.846, 16.616, 5.307, 1.308

5331.769: 2350.308, 2954.230, 19.847, 6.076, 1.308



4343.769: 2097.692, 2229.000, 9.769, 6.000, 1.308

4365.692: 2117.538, 2228.770, 10.923, 7.231, 1.230

4342.231: 2100.846, 2227.000, 7.769, 5.308, 1.308

4361.384: 2119.384, 2227.539, 7.692, 5.461, 1.308

4363.538: 2106.000, 2233.308, 14.000, 8.769, 1.461

4379.385: 2108.000, 2253.616, 10.231, 6.077, 1.461

4341.615: 2100.462, 2226.384, 7.923, 5.539, 1.307

4361.692: 2097.769, 2247.846, 8.847, 5.923, 1.307

4348.153: 2105.230, 2227.461, 8.308, 5.846, 1.308

4338.692: 2098.692, 2226.077, 7.462, 5.230, 1.231



Aquaris E10, OpenSSL


KG: 6378.278

KA: 6504.275



KG: 974.304

KA: 2767.394



13057.154: 6435.462, 6569.923, 30.077, 19.846, 1.846

12926.693: 6401.539, 6507.692, 9.539, 6.461, 1.462

12808.693: 6351.000, 6444.539, 7.692, 4.000, 1.462

12893.077: 6381.077, 6501.230, 5.693, 3.692, 1.385

12880.384: 6384.923, 6483.076, 6.693, 4.307, 1.385

13023.385: 6460.308, 6551.308, 6.769, 3.769, 1.231

12788.769: 6308.308, 6467.923, 6.692, 4.231, 1.615

12687.231: 6276.539, 6398.615, 7.000, 3.693, 1.384

13093.616: 6497.846, 6584.923, 6.077, 3.385, 1.385

12713.923: 6273.077, 6424.154, 9.538, 5.924, 1.230



3752.846: 973.384, 2767.000, 6.923, 4.154, 1.385

3767.923: 973.154, 2782.308, 7.307, 3.923, 1.231

3762.693: 979.616, 2770.769, 6.077, 5.000, 1.231

3766.231: 990.000, 2764.770, 6.307, 3.769, 1.385

3770.077: 976.770, 2782.615, 5.846, 3.462, 1.384

3755.000: 971.846, 2773.308, 5.230, 3.385, 1.231

3739.923: 969.000, 2761.461, 5.154, 3.077, 1.231

3762.999: 985.231, 2767.537, 5.385, 3.539, 1.307

3741.692: 970.076, 2761.693, 5.154, 3.461, 1.308

3754.769: 968.616, 2776.307, 5.231, 3.231, 1.384



74 Appendix B. Test results

Sony Xperia Z1 Compact, Nettle


KG: 1389.729

KA: 1559.484



KG: 1321.557

KA: 1235.882



2991.979: 1384.427, 1570.104, 28.437, 7.448, 1.563

2962.187: 1377.343, 1567.865, 11.042, 4.375, 1.562

2961.250: 1376.875, 1567.708, 10.834, 4.270, 1.563

2983.125: 1398.802, 1567.813, 10.781, 4.219, 1.510

2959.479: 1375.000, 1567.865, 10.781, 4.271, 1.562

2959.584: 1375.104, 1567.969, 10.729, 4.271, 1.511

2976.615: 1374.896, 1584.948, 10.937, 4.323, 1.511

2959.740: 1374.948, 1568.334, 10.729, 4.219, 1.510

2959.843: 1374.843, 1568.438, 10.781, 4.271, 1.510

2975.625: 1374.844, 1584.010, 10.937, 4.323, 1.511



2551.615: 1307.135, 1233.750, 4.896, 4.271, 1.563

2551.563: 1307.240, 1233.593, 4.948, 4.219, 1.563

2551.302: 1307.135, 1233.594, 4.844, 4.166, 1.563

2567.239: 1322.291, 1234.323, 4.844, 4.271, 1.510

2551.146: 1306.927, 1233.542, 4.844, 4.271, 1.562

2551.146: 1306.927, 1233.594, 4.844, 4.219, 1.562

2551.302: 1307.083, 1233.594, 4.844, 4.219, 1.562

2566.458: 1321.927, 1233.958, 4.844, 4.219, 1.510

2550.989: 1306.822, 1233.542, 4.844, 4.219, 1.562

2551.146: 1306.875, 1233.594, 4.843, 4.271, 1.563



Sony Xperia Z1 Compact, OpenSSL


KG: 4620.584

KA: 4693.989



KG: 431.091

KA: 1180.892



9225.677: 4536.145, 4648.334, 22.864, 16.615, 1.719

9333.907: 4604.740, 4720.417, 3.906, 3.437, 1.407

9163.698: 4531.562, 4623.854, 3.854, 3.021, 1.407

9190.313: 4553.594, 4628.490, 3.854, 2.969, 1.406

9224.584: 4574.011, 4642.344, 3.854, 2.969, 1.406

9222.917: 4591.355, 4623.385, 3.802, 2.969, 1.406

9095.728: 4508.177, 4579.270, 3.854, 3.021, 1.406

9298.646: 4607.084, 4683.437, 3.802, 2.917, 1.406

9220.312: 4588.593, 4623.438, 3.802, 3.073, 1.406

9244.583: 4590.625, 4645.833, 3.802, 2.917, 1.406



1605.729: 430.729, 1166.823, 3.750, 2.916, 1.511

1625.677: 430.573, 1186.875, 3.958, 2.864, 1.407

1606.875: 431.458, 1167.500, 3.750, 2.761, 1.406

1614.271: 439.063, 1167.291, 3.750, 2.761, 1.406

1614.219: 430.365, 1175.729, 3.907, 2.812, 1.406

1604.948: 430.990, 1166.093, 3.750, 2.709, 1.406

1604.010: 430.208, 1165.938, 3.697, 2.761, 1.406

1620.417: 429.740, 1182.760, 3.750, 2.761, 1.406

1603.802: 430.157, 1165.833, 3.698, 2.708, 1.406

1603.490: 429.792, 1165.938, 3.698, 2.656, 1.406



References

[1] �Ericsson Mobility Report, november 2016.� https://www.ericsson.com/mobility-report. Last accessed on 13-3-2017.

[2] A. Shaik, R. Borgaonkar, N. Asokan, V. Niemi, and J.P. Seifert, �Practical at-tacks against privacy and availability in 4G/LTE mobile communication systems,�CoRR, vol. abs/1510.07563, 2015.

[3] R. Gallagher, �Meet the machines that steal your phone's data.�https://arstechnica.com/tech-policy/2013/09/meet-the-machines-that-steal-your-phones-data/. Last accessed on 13-3-2017.

[4] �Third Generation Partnership Project.� http://www.3gpp.org/. Last accessedon 14-2-2017.

[5] A. Herzberg, G. Tsudik, and H. Krawczyk, �On travelling incognito,� Mobile Com-puting Systems and Applications, IEEE Workshop on, vol. 00, pp. 205�211, 1899.

[6] 3GPP Discussion Document S3-99067, �Enhanced User identity Con�dentia-lity.� http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_02/docs/S3-99067.zip. Last accessed on 25-1-2017.

[7] 3GPP Discussion Document S3-99360, �Enhanced User Identity Con�dentia-lity.� http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_07/docs/s3-99360_enhanced%20UI%20conf.zip. Last accessed on 25-1-2017.

[8] 3GPP Discussion Document S3-00268, �Removal of enhanced user identitycon�dentiality.� http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_12_Stockholm/Docs/PDF/S3-000268.PDF. Last accessed on 25-1-2017.

[9] M. Arapinis, L. Mancini, E. Ritter, M. Ryan, N. Golde, K. Redon, and R. Borgaon-kar, �New privacy issues in mobile telephony: Fix and veri�cation,� in Proceedingsof the 2012 ACM Conference on Computer and Communications Security, CCS'12, (Raleigh, North Carolina, USA), pp. 205�216, ACM, 2012.

[10] 3GPP TR 33.821, �Rationale and track of security decisions in Long TermEvolution (LTE) RAN / 3GPP System Architecture Evolution (SAE).� http://www.3gpp.org/dynareport/33821.htm, Aug 2016. Last accessed on 14-2-2017.

[11] N. Golde, K. Redon, and R. Borgaonkar, �Weaponizing Femtocells: The E�ect ofRogue Devices on Mobile Telecommunications,� in Proceedings of the 19th AnnualNetwork & Distributed System Security Symposium, Feb. 2012.

75

https://www.ericsson.com/mobility-report

https://www.ericsson.com/mobility-report

https://arstechnica.com/tech-policy/2013/09/meet-the-machines-that-steal-your-phones-data/

https://arstechnica.com/tech-policy/2013/09/meet-the-machines-that-steal-your-phones-data/

http://www.3gpp.org/

http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_02/docs/S3-99067.zip

http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_02/docs/S3-99067.zip

http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_07/docs/s3-99360_enhanced%20UI%20conf.zip

http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_07/docs/s3-99360_enhanced%20UI%20conf.zip

http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_12_Stockholm/Docs/PDF/S3-000268.PDF

http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_12_Stockholm/Docs/PDF/S3-000268.PDF

http://www.3gpp.org/dynareport/33821.htm


76 References

[12] �Ericsson White Paper on 5G security: Scenarios and solutions.� https://www.ericsson.com/res/docs/whitepapers/wp-5g-security.pdf. Last accessed on13-3-2017.

[13] 3GPP TR 33.899, �Study on the security aspects of the next generation system.�http://www.3gpp.org/dynareport/33899.htm, Aug 2016. Last accessed on 16-2-2017.

[14] �5G Ensure: 5G enablers for network and system security and resilience.� https://5gensure.eu. Last accessed on 13-3-2017.

[15] �Latex.� http://en.wikibooks.org/wiki/LaTeX/. Last accessed on 13-3-2017.

[16] 3GPP TS 23.401, �General Packet Radio Service (GPRS) enhancements for Evol-ved Universal Terrestrial Radio Access Network (E-UTRAN) access. Rel. 14.�http://www.3gpp.org/dynareport/23401.htm, Sep 2016. Last accessed on 16-2-2017.

[17] 3GPP TS 31.102, �Characteristics of the Universal Subscriber Identity Modu-le (USIM) application. Rel. 14.� http://www.3gpp.org/dynareport/31102.htm,Oct 2016. Last accessed on 16-2-2017.

[18] 3GPP TS 23.003, �Numbering, addressing and identi�cation. Rel. 14.� http://www.3gpp.org/dynareport/23003.htm, Sep 2016. Last accessed on 16-2-2017.

[19] 3GPP TS 36.331, �Evolved Universal Terrestrial Radio Access (E-UTRA); RadioResource Control (RRC); Protocol speci�cation. Rel. 14.� http://www.3gpp.org/dynareport/36331.htm, Oct 2016. Last accessed on 16-2-2017.

[20] 3GPP TS 36.323, �Evolved Universal Terrestrial Radio Access (E-UTRA); PacketData Convergence Protocol (PDCP) speci�cation. Rel. 14.� http://www.3gpp.org/dynareport/36323.htm, Oct 2016. Last accessed on 16-2-2017.

[21] 3GPP TS 36.322, �Evolved Universal Terrestrial Radio Access (E-UTRA); Ra-dio Link Control (RLC) protocol speci�cation. Rel. 14.� http://www.3gpp.org/dynareport/36322.htm, Oct 2016. Last accessed on 16-2-2017.

[22] 3GPP TS 36.413, �Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP). Rel. 14.� http://www.3gpp.org/dynareport/36413.htm, Sep 2016. Last accessed on 16-2-2017.

[23] 3GPP TS 29.274, �3GPP Evolved Packet System (EPS); Evolved General PacketRadio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C). Rel.14.� http://www.3gpp.org/dynareport/29274.htm, Sep 2016. Last accessed on16-2-2017.

[24] 3GPP TS 29.281, �General Packet Radio System (GPRS) Tunnelling ProtocolUser Plane (GTPv1-U). Rel. 14.� http://www.3gpp.org/dynareport/29281.htm, Sep 2016. Last accessed on 16-2-2017.

[25] 3GPP TS 24.301, �Non-Access-Stratum (NAS) protocol for Evolved Packet Sys-tem (EPS). Rel. 14.� http://www.3gpp.org/dynareport/24301.htm, Sep 2016.Last accessed on 16-2-2017.

https://www.ericsson.com/res/docs/whitepapers/wp-5g-security.pdf

https://www.ericsson.com/res/docs/whitepapers/wp-5g-security.pdf


https://5gensure.eu

https://5gensure.eu

http://en.wikibooks.org/wiki/LaTeX/

















References 77

[26] V. Fajardo, J. Arkko, J. Loughney, and G. Zorn, �IETF RFC 6733: Diameter Ba-se Protocol.� https://www.ietf.org/rfc/rfc6733.txt, Oct 2012. Last accessedon 16-2-2017.

[27] C. Rigney, S. Willens, A. Rubens, and W. Simpson, �IETF RFC 2865: RemoteAuthentication Dial In User Service (RADIUS).� https://www.ietf.org/rfc/rfc2865.txt, Jun 2000. Last accessed on 16-2-2017.

[28] 3GPP TS 29.272, �Evolved Packet System (EPS); Mobility Management Entity(MME) and Serving GPRS Support Node (SGSN) related interfaces based onDiameter protocol. Rel. 14.� http://www.3gpp.org/dynareport/29272.htm, Sep2016. Last accessed on 16-2-2017.

[29] 3GPP TS 33.401, �3GPP System Architecture Evolution (SAE); Security archi-tecture. Rel. 14.� http://www.3gpp.org/dynareport/33401.htm, Sep 2016. Lastaccessed on 16-2-2017.

[30] 3GPP TS 33.106, �Lawful interception requirements. Rel. 13.� http://www.3gpp.org/dynareport/33106.htm, Jun 2016. Last accessed on 16-2-2017.

[31] 3GPP TS 33.107, �Lawful interception architecture and functions. Rel. 14.� http://www.3gpp.org/dynareport/33107.htm, Dic 2016. Last accessed on 16-2-2017.

[32] W. Stallnings, Cryptography and Network Security. Prentice Hall, �fth ed., May2010. ISBN: 978-0-13-705632-3.

[33] R. Rivest, A. Shamir, and L. Adleman, �A Method for Obtaining Digital Sig-natures and Public-key Cryptosystems,� Communications of the ACM, vol. 21,pp. 120�126, Feb. 1978.

[34] D. Giry (editor), �BlueKrypt: Cryptographic Key Length Recommendation.�https://www.keylength.com/. Last accessed on 16-2-2017.

[35] National Institute of Standards and Technology (NIST), �Recommendation forkey management - Part 1: General,� SP 800-57, 2007.

[36] W. Di�e and M. E. Hellman, �Multiuser Cryptographic Techniques,� in Pro-ceedings of the June 7-10, 1976, National Computer Conference and Exposition,AFIPS '76, pp. 109�112, 1976.

[37] �Block Cipher Mode of Operation.� https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation. Last accessed on 7-2-2017. Public domain (unlicen-sed) �gures.

[38] 3GPP Discussion Document S3-161379 and S3-161380, �Security enhancementsto the Attach procedure.� http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_84b_San_Diego/Docs/. Last accessed on 13-3-2017.

[39] 3GPP Discussion Document S3-161666, �Privacy Protection for EAP-AKA.�http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_85_Santa_Cruz/Docs/S3-161666.zip. Last accessed on 13-3-2017.

[40] �ID Based Encryption: O�ine and Online Steps.� https://en.wikipedia.org/wiki/ID-based_encryption. Last accessed on 16-2-2017. License CC-BY-SA 3.0.

https://www.ietf.org/rfc/rfc6733.txt









https://www.keylength.com/

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_84b_San_Diego/Docs/

http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_84b_San_Diego/Docs/

http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_85_Santa_Cruz/Docs/S3-161666.zip


https://en.wikipedia.org/wiki/ID-based_encryption

https://en.wikipedia.org/wiki/ID-based_encryption

78 References

[41] V. Goyal, O. Pandey, A. Sahai, and B. Waters, �Attribute-based Encryption forFine-grained Access Control of Encrypted Data,� in Proceedings of the 13th ACMConference on Computer and Communications Security, CCS '06, (Alexandria,Virginia, USA), pp. 89�98, ACM, 2006.

[42] 5G ENSURE, Deliverable D3.1, �5G-PPP security enablers technical roadmap(early vision).� http://5gensure.eu/sites/default/files/Deliverables/5G-ENSURE_D3.1-5G-PPPSecurityEnablersTechnicalRoadmap_early_vision.pdf. Last accessed on 25-1-2017.

[43] 3GPP Discussion Document S3-162108, �New privacy solution for concea-ling permanent subscriber identi�er.� http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_85_Santa_Cruz/Docs/S3-162108.zip. Last accessed on 25-1-2017.

[44] 3GPP Discussion Document S3-161782, �Protect the Permanent or Long TermUser Identity with Public Key Technologies.� http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_85_Santa_Cruz/Docs/S3-161782.zip. Last accessedon 25-1-2017.

[45] Groves, M., �IETF RFC 6508: Sakai-Kasahara Key Encryption (SAKKE).�https://www.ietf.org/rfc/rfc6508.txt, Oct 2012. Last accessed on 16-2-2017.

[46] 3GPP Discussion Document S3-170194, �Using pools of IMSIs.� http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_86_Sophia/docs/S3-170194.zip. Last accessed on 13-3-2017.

[47] 3GPP Discussion Document S3-170195, �Encrypted pseudonym in RAND.�http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_86_Sophia/docs/S3-170195.zip. Last accessed on 13-3-2017.

[48] F. van den Broek, R. Verdult, and J. de Ruiter, �Defeating IMSI Catchers,� inProceedings of the 22Nd ACM SIGSAC Conference on Computer and Communi-cations Security, CCS '15, (Denver, Colorado, USA), pp. 340�351, ACM, 2015.

[49] M. S. A. Khan and C. J. Mitchell, �Improving Air Interface User Privacy inMobile Telephony,� in Proceecdings of the Second International Conference onSecurity Standardisation Research, SSR 2015, Tokyo, Japan, December 15-16,2015, pp. 165�184, Springer International Publishing, 2015.

[50] K. Norrman, M. Näslund, and E. Dubrova, �Protecting IMSI and Subscriber Pri-vacy in 5G Networks,� in Proceedings of 9th EAI International Conference onMobile Multimedia Communications, MobiMedia 2016, (Xian, China), 2016.

[51] �KP-ABE, a set of shell commands for KP-ABE operations.� https://github.com/gustybear/kpabe. Last accessed on 16-1-2017.

[52] �PBC Library, the Pairing-Based Cryptography Library.� https://crypto.stanford.edu/pbc. Last accessed on 16-1-2017.

[53] �GMP Library, the GNU Multiple Precision Library.� https://gmplib.org/.Last accessed on 16-1-2017.

http://5gensure.eu/sites/default/files/Deliverables/5G-ENSURE_D3.1-5G-PPPSecurityEnablersTechnicalRoadmap_early_vision.pdf








http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_86_Sophia/docs/S3-170194.zip





https://github.com/gustybear/kpabe

https://github.com/gustybear/kpabe

https://crypto.stanford.edu/pbc

https://crypto.stanford.edu/pbc

https://gmplib.org/

References 79

[54] 3GPP Discussion Document S3-170343, �Privacy protection of permanent orlong-term subscription identi�er using ABE.� http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_86_Sophia/docs/S3-170343.zip. Last accessed on13-3-2017.

[55] K. Moriarty, B. Kaliski, J. Jonsson, and A. Rusch, �IETF RFC 8017: PKCS #1:RSA Cryptography Speci�cations Version 2.2.� https://www.ietf.org/rfc/rfc8017.txt, Nov 2016. Last accessed on 20-2-2017.

[56] �RSA Optimal Asymmetric Encription Padding.� https://commons.wikimedia.org/wiki/File:EME-OAEP.jpg. Last accessed on 20-1-2017. Released into thepublic domain.

[57] V. Gayoso Martínez, L. Hernández Encinas, and C. Sánchez Ávila, �A Survey ofthe Elliptic Curve Integrated Encryption Scheme,� Journal of Computer Scienceand Engineering, vol. 2, pp. 7�13, 2010.

[58] American National Standards Institute (ANSI), �Public Key Cryptography forthe Financial Services Industry: Key Agreement and Key Transport Using EllipticCurve Cryptography,� X9.63, 2001.

[59] Institute of Electrical and Electronics Engineers (IEEE), �Standard Speci�cationsfor Public Key Cryptography,� Std. 1363, 2000.

[60] National Institute of Standards and Technology (NIST), �Recommendation forPair-wise Key Establishment Schemes Using Discrete Logarithm Cryptography,�SP 800-56A, 2005.

[61] Standards for E�cient Cryptography Group (SECG), �Elliptic Curve Crypto-graphy,� SEC 1, version 2, 2009.

[62] D. Adrian, K. Bhargavan, Z. Durumeric, P. Gaudry, M. Green, J. A. Halder-man, N. Heninger, D. Springall, E. Thomé, L. Valenta, B. VanderSloot, E. Wus-trow, S. Zanella-Béguelin, and P. Zimmermann, �Imperfect Forward Secrecy: HowDi�e-Hellman Fails in Practice,� in ACM Conference on Computer and Commu-nications Security (CCS'15), 2015.

[63] 3GPP Discussion Document S3-161856, �Encrypting IMSI based on ECIES.�http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_85_Santa_Cruz/Docs/S3-161856.zip. Last accessed on 13-3-2017.

[64] National Institute of Standards and Technology (NIST), �Federal InformationProcessing Standards Publication - Digital Signature Standard (DSS),� FIPS PUB186-4, 2013.

[65] A. Langley, M. Hamburg, and S. Turner, �IETF RFC 7748: Elliptic Curves forSecurity.� https://www.ietf.org/rfc/rfc7748.txt, Jan 2016. Last accessedon 16-2-2017.

[66] D. J. Bernstein, �Curve25519: new Di�e-Hellman speed records,� in In PublicKey Cryptography (PKC), Springer-Verlag LNCS 3958, 2006.

[67] Niels Möller (editor), �Nettle, a low-level cryptographic library.� https://www.lysator.liu.se/~nisse/nettle. Last accessed on 12-12-2016.





https://commons.wikimedia.org/wiki/File:EME-OAEP.jpg

https://commons.wikimedia.org/wiki/File:EME-OAEP.jpg




https://www.lysator.liu.se/~nisse/nettle

https://www.lysator.liu.se/~nisse/nettle

80 References

[68] �Modular square root patch for GMP.� https://gmplib.org/list-archives/gmp-devel/2006-May/000633.html. Last accessed on 6-3-2017.

[69] �OpenSSL, cryptography and SSL open source Toolkit.� https://www.openssl.org. Last accessed on 12-12-2016.

[70] �OpenSSL 1.1.0 X25519 implementation (issue #2048).� https://github.com/openssl/openssl/issues/2048/. Last accessed on 8-2-2017.

[71] �Sony Xperia Z1 Compact: Technical speci�cations.� http://www.gsmarena.com/sony_xperia_z1_compact-5753.php. Last accessed on 7-2-2017.

[72] �Aquaris E10 Tablet: Technical speci�cations.� http://www.devicespecifications.com/en/model/f84b311a. Last accessed on 7-2-2017.

[73] �Aquaris E5 HD: Technical speci�cations.� http://www.devicespecifications.com/en/model/741b30e5. Last accessed on 7-2-2017.

[74] �HTC Google Nexus One: Technical speci�cations.� http://www.gsmarena.com/htc_google_nexus_one-3069.php. Last accessed on 7-2-2017.

[75] �Android Debug Bridge (ADB).� https://developer.android.com/studio/command-line/adb.html. Last accessed on 13-1-2017.

[76] �eBACS: ECRYPT Benchmarking of Cryptographic Systems.� https://bench.cr.yp.to. Last accessed on 19-12-2016.

[77] �ECRYPT: European Network of Excellence in Cryptology.� http://www.ecrypt.eu.org. Last accessed on 9-1-2017.

[78] E. Cobo Jiménez, P. K. Nakarmi, M. Näslund, and K. Norrman, �SubscriptionIdenti�er Privacy in 5G Systems,� in 2017 International Conference on SelectedTopics in Mobile and Wireless Networking (MoWNet'17), 2017.

[79] T. Fox-Brewster, �Check the permissions: Android �ashlight apps criticised overprivacy.� https://www.theguardian.com/technology/2014/oct/03/android-flashlight-apps-permissions-privacy, Oct 2014. Last accessed on 8-2-2017.

[80] National Institute of Standards and Technology (NIST), �Recommendation forBlock Cipher Modes of Operation: Methods for Format-Preserving Encryption,�SP 800-38G, 2016.

[81] 3GPP Discussion Document S3-162135, �Quantum safe cryptography.� http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_85_Santa_Cruz/Docs/S3-162135.zip. Last accessed on 25-1-2017.

https://gmplib.org/list-archives/gmp-devel/2006-May/000633.html

https://gmplib.org/list-archives/gmp-devel/2006-May/000633.html

https://www.openssl.org

https://www.openssl.org

https://github.com/openssl/openssl/issues/2048/

https://github.com/openssl/openssl/issues/2048/

http://www.gsmarena.com/sony_xperia_z1_compact-5753.php

http://www.gsmarena.com/sony_xperia_z1_compact-5753.php

http://www.devicespecifications.com/en/model/f84b311a

http://www.devicespecifications.com/en/model/f84b311a

http://www.devicespecifications.com/en/model/741b30e5

http://www.devicespecifications.com/en/model/741b30e5

http://www.gsmarena.com/htc_google_nexus_one-3069.php

http://www.gsmarena.com/htc_google_nexus_one-3069.php

https://developer.android.com/studio/command-line/adb.html

https://developer.android.com/studio/command-line/adb.html

https://bench.cr.yp.to

https://bench.cr.yp.to

http://www.ecrypt.eu.org

http://www.ecrypt.eu.org

https://www.theguardian.com/technology/2014/oct/03/android-flashlight-apps-permissions-privacy

https://www.theguardian.com/technology/2014/oct/03/android-flashlight-apps-permissions-privacy




List of Acronyms

3GPP . . . . . . . . . Third Generation Partnership Project

AES . . . . . . . . . . . Advanced Encryption Standard

AKA . . . . . . . . . . Authentication and Key Agreement

ANSI . . . . . . . . . American National Standards Institute

API . . . . . . . . . . . Application Programming Interface

AuS . . . . . . . . . . . Authentication Server

AUTN . . . . . . . . . . . Authentication Token

AV . . . . . . . . . . . . Authentication Vector

BCD . . . . . . . . . . Binary-Coded Decimal

CBC . . . . . . . . . . Cipher Block Chaining

CN . . . . . . . . . . . . Core Network

CTR . . . . . . . . . . Counter

DH . . . . . . . . . . . . Di�e-Hellman

DHC . . . . . . . . . . Di�e-Hellman Cofactor

DHIES . . . . . . . . Di�e-Hellman Integrated Encryption Scheme

DLP . . . . . . . . . . Discrete Logarithm Problem

EC . . . . . . . . . . . . Elliptic Curve

ECC . . . . . . . . . . Elliptic Curve Cryptography

ECDSA . . . . . . . Elliptic Curve Digital Signature Algorithm

ECIES . . . . . . . . Elliptic Curve Integrated Encryption Scheme

eNB . . . . . . . . . . . Evolved Node B

GPRS . . . . . . . . . General Packet Radio Services

GTP . . . . . . . . . . GPRS Tunnelling Protocol

GUTI . . . . . . . . . Global Unique Temporary Identity

81

82 List of Acronyms

HSS . . . . . . . . . . . Home Subscriber Server

IBE . . . . . . . . . . . Identity-Based Encryption

IEEE. . . . . . . . . . Institute of Electrical and Electronics Engineers

IMEI . . . . . . . . . . International Mobile Equipment Identity

IMSI . . . . . . . . . . International Mobile Subscriber Identity

IoT . . . . . . . . . . . Internet of Things

ITU . . . . . . . . . . . International Telecommunication Union

KA . . . . . . . . . . . . Key Agreement

KASME . . . . . . . . . Key Access Security Management Entity

KD . . . . . . . . . . . . Key Derivation

KG . . . . . . . . . . . . Key Generation

KP-ABE . . . . . . Key-Policy Attribute-Based Encryption

LI . . . . . . . . . . . . . Lawful Interception

MAC . . . . . . . . . . Message Authentication Code

MCC . . . . . . . . . . Mobile Country Code

ME . . . . . . . . . . . . Mobile Equipment

MGF . . . . . . . . . . Mask Generator Function

MitM . . . . . . . . . Man-in-the-Middle

MME . . . . . . . . . Mobility Management Entity

MNC . . . . . . . . . . Mobile Network Code

MSIN . . . . . . . . . Mobile Subscriber Identity Number

MSISDN . . . . . . Mobile Station Integrated Services Digital Network

NAS . . . . . . . . . . Non-Access Stratum

NIST . . . . . . . . . . National Institute of Standards and Technology

PC . . . . . . . . . . . . Point Compression

PDCP . . . . . . . . Packet Data Convergence Protocol

PKI . . . . . . . . . . . Public Key Infrastructure

PLMN . . . . . . . . Public Land Mobile Network

RAN . . . . . . . . . . Radio Access Network

RAND . . . . . . . . . . . Random Challenge

List of Acronyms 83

RES . . . . . . . . . . . . Response

RFC . . . . . . . . . . Request For Comments

RLC . . . . . . . . . . Radio Link Control

RRC . . . . . . . . . . Radio Resource Control

RSA . . . . . . . . . . Rivest, Shamir, and Adleman

S1AP . . . . . . . . . S1 Application Protocol

SAKKE . . . . . . . Sakai-Kasahara Key Encryption

SECG . . . . . . . . . Standards for E�cient Cryptography

SGW . . . . . . . . . . Serving Gateway

TMSI . . . . . . . . . Temporary Mobile Subscriber Identity

TR . . . . . . . . . . . . Technical Report

TS . . . . . . . . . . . . Technical Speci�cation

UE . . . . . . . . . . . . User Equipment

UICC . . . . . . . . . Universal Integrated Circuit Card

USIM . . . . . . . . . Universal Subscriber Identity Module

WLAN . . . . . . . . Wireless Local Area Network

XRES . . . . . . . . . . . Expected Response

TRITA ICT-EX-2017:19

www.kth.se

encrypting imsi to improve privacy in 5g networks1095875/fulltext01.pdf · 2017-05-16 · this...

Documents