location privacy in mobile networks - uni-konstanz.de
TRANSCRIPT
Location Privacy in Mobile Networks
Master Thesis
presented by
Andreas Ergenzinger
at the
Universität Konstanz
Faculty of Sciences
Department of Computer and Information Science
1st Examiner: Prof. Dr. Marcel Waldvogel
2nd Examiner: Prof. Dr.-Ing. Oliver Haase
Constance, 2015
Konstanzer Online-Publikations-System (KOPS) URL: http://nbn-resolving.de/urn:nbn:de:bsz:352-0-327409
Abstract
This master thesis presents a client-server system for protecting the anonymity and location pri-vacy of mobile network users against a passive network-side adversary. The server provides a poolof UICCs – technological successors to SIM cards. Users’ cellphones rely on those UICCs for ac-cessing a mobile network. Through simultaneous, coordinated switching to new UICCs, groupsof users in the same mobile radio cell become indistinguishable to the adversary. The system’sperformance was evaluated based on simulated vehicle traffic. An increase of the number of usersled to a rise in coordinated UICC switching, higher distance errors, and a decrease of user identifi-cation ratios. The system is capable of enhancing the anonymity and location privacy of its usersagainst a passive adversary, provided that the opponent does not track mobile phones based ontheir device identities.
iii
Dedicated to my parents.
v
Table of Contents
List of Figures ix
List of Tables xi
Symbols and Abbreviations xiii
1 Introduction 11.1 Statement of the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Technical Background 32.1 Integrated Circuit Cards with Electrical Contacts . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Files, Functions, and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Application Protocol Data Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Card Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.4 Transmission of Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.5 Card Operating Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.6 Transport Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 3G Mobile Networks and UICCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 UMTS Mobile Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 UICCs and Security-Related Procedures . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Related Work 173.1 Location Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Characteristics, Re-Identification, and Prediction of Human Trajectories . . . . . . . . 21
4 A System for Protecting Location Privacy in Mobile Networks 234.1 The Adversary and a Strategy for Defense . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.2 Increased Location Privacy through Switching and Sharing of UICCs . . . . 24
4.2 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.1 System Architecture and Basic Functioning . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Virtualization for Improved Performance and Reliability . . . . . . . . . . . . . 29
4.3 Switching Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.1 Naive, Pairwise Swapping of Subscriber Identities . . . . . . . . . . . . . . . . . 304.3.2 Improved SI Switching Based on Direct Encounters . . . . . . . . . . . . . . . . 324.3.3 SI Switching Based on Cell-Level Encounters . . . . . . . . . . . . . . . . . . . . 324.3.4 Autonomous SI Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3.5 Comparison and Summary of Switching Strategies . . . . . . . . . . . . . . . . . 34
4.4 Compatibility with Existing Cellular Technologies . . . . . . . . . . . . . . . . . . . . . . 35
vii
5 Implementation 395.1 Card Server Side and Card Service Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Card Client Side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 Initialization Procedure and Normal Operation . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Experiments and Analysis of Results 456.1 Measurements of Response Time Requirements . . . . . . . . . . . . . . . . . . . . . . . . 456.2 Simulation of Cell-Based SI Switching for Users of Private Transport . . . . . . . . . . 46
6.2.1 Preprocessing and Characterization of the Input Datasets . . . . . . . . . . . . 466.2.2 Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.2.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3 Simulation of SI Switching Based on Direct Encounters By Users of Public Transport 566.3.1 Preprocessing and Characterization of the Input Dataset . . . . . . . . . . . . . 566.3.2 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.3.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7 Conclusion 657.1 Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.3 Opportunities for Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
APPENDICES 69
A Circuits and Connections of the MIM Module Prototype 71
References 73
viii
List of Figures
2.1 Command and response APDU fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Transmission of characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Smart card communication layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Block fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 UMTS network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 UICC form factors and pinout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 UICC and USIM file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.8 Authentication and key agreement (AKA) . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.9 Start of integrity protection and ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.10 Position of the CAT layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 An example for simultaneous subscriber identity switching . . . . . . . . . . . . . . . . 254.2 Generic card service client-server architecture . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Protocol stacks of the basic card service implementation . . . . . . . . . . . . . . . . . . 274.4 3G GPRS Security procedures with a remote UICC . . . . . . . . . . . . . . . . . . . . . 364.5 Authentication procedure in 2G GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 Major components of the client-side implementation . . . . . . . . . . . . . . . . . . . . 415.2 Picture of the MIM module prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3 Simplified state diagram of the MIM module firmware . . . . . . . . . . . . . . . . . . . . 425.4 Protocol and technology stacks of the client-side implementation . . . . . . . . . . . . 425.5 Components of the card client app and flow of messages . . . . . . . . . . . . . . . . . . 43
6.1 Feasibility of attaching to the mobile network depending on card client responsetimes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 Overlaid traces and cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.3 Number of active nodes by time of day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.4 2D histogram of distances traveled and trip durations of the node population . . . . . 486.5 Box plot legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.6 Sample size and end distance error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.7 Sample size and number of encounters per node . . . . . . . . . . . . . . . . . . . . . . . . 506.8 Sample size and node identification ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.9 Probability density function of the end distance error distribution . . . . . . . . . . . . 516.10 Distribution of the number of encounters per node . . . . . . . . . . . . . . . . . . . . . 526.11 Relationship between trip distance and end distance error . . . . . . . . . . . . . . . . . 546.12 Relationship between trip duration and end distance error . . . . . . . . . . . . . . . . . 556.13 Metro rail map showing stations and lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.14 Number of riders by time of day and ride type . . . . . . . . . . . . . . . . . . . . . . . . . 596.15 Distribution of rider-specific mean distance errors . . . . . . . . . . . . . . . . . . . . . . 596.16 Cumulative histogram of distance error in hops . . . . . . . . . . . . . . . . . . . . . . . . 596.17 Relationship between mean distance error, ride duration, and ride type . . . . . . . . . 60
ix
A.1 Circuit for level shifting and I/O splitting/joining . . . . . . . . . . . . . . . . . . . . . . 72
x
List of Tables
2.1 Roles of universal smart card contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Classes of operating conditions and high voltage levels . . . . . . . . . . . . . . . . . . . . 6
4.1 Sequence of events for naive, pairwise subscriber identity swapping . . . . . . . . . . . 314.2 Comparison of reliable SI switching strategies . . . . . . . . . . . . . . . . . . . . . . . . . 35
A.1 U(S)ART instances and associated pins used by the MIM module prototype . . . . . . 72A.2 Gate-source threshold voltages of used transistors types . . . . . . . . . . . . . . . . . . . 72A.3 Pin connections of the HC-06 Bluetooth module and the Arduino Due . . . . . . . . 72
xi
Symbols and Abbreviations
2G 2nd Generation3G 3rd Generation3GPP 3rd Generation Partnership ProjectA,B,C Classes of operating conditionsADF Application DFAKA Authentication and Key AgreementAPDU Application Protocol Data UnitAPI Application Programming InterfaceATR Answer To ResetAUTN Authentication tokenBd BaudBWT Block Waiting TimeCGT Character Guard TimeCAT Card Application ToolkitCK Cipher KeyCLK Clock pinCN Core NetworkCS Circuit-switchedCSP Card Service ProtocolCWT Character Waiting TimeDF Dedicated FileDSDA Dual SIM Dual ActiveEF Elementary Fileetu Elementary Time Unitf Frequency value of the clock signalf2 Key generating function used for computing RES and XRESf3 Key generating function used for computing CKf4 Key generating function used for computing IKGGSN Gateway GPRS Support NodeGMSC Gateway MSCGND Ground pinGPRS General Packet Radio ServiceGSM Global System for Mobile communicationsH High stateHLR Home Location RegisterIC Integrated CircuitICC Integrated Circuit CardIDF Interface DeviceIEC International Electrotechnical CommissionIK Integrity Key
xiii
IMEI International Mobile Station Equipment IdentityIMSI International Mobile Subscriber IdentityI/O Input/Output pinIP Internet ProtocolISDN Integrated Services Digital NetworkISO International Organization for StandardizationK Long-term secret key shared between a subscriber’s USIM and HLRL Low stateLA Location AreaLAI Location Area IdentityLAU Location Area UpdateLBS Location-Based ServiceLCS Location ServiceMF Master FileMIM Neither an abbreviation nor an acronym.MITM Man-in-the-middleMNO Mobile Network OperatorMSC Mobile Switching CenterMSISDN Mobile Subscriber ISDN NumberO/D Origin-DestinationOS Operating SystemOSI Open Systems InterconnectionOTA Over-the-airPC/SC Personal Computer/Smart CardPDP Packet Data ProtocolPPS Protocol and Parameter SelectionP-TMSI Packet TMSIPS Packet-switchedPSTN Public Switched Telephone NetworkRA Routing AreaRAI Routing Area IdentityRAND Random challengeRAU Routing Area UpdateRES Response to random challengeRFCOMM Radio Frequency CommunicationRNC Radio Network ControllerRRLP Radio Resource LCS ProtocolRST Reset pinRTD Round-Trip DelaySGSN Serving GPRS Support NodeSI Subscriber IdentitySIM Subscriber Identity ModuleTCP Transmission Control ProtocolTMSI Temporary Mobile Subscriber IdentityTPDU Transport Protocol Data UnitUART Universal Asynchronous Receiver/TransmitterUE User EquipmentUICC Universal Integrated Circuit Card — inofficial
3GPP standards specify that it is neither an abbreviation nor an acronym.UMTS Universal Mobile Telecommunications System
xiv
USART Universal Synchronous/Asynchronous Receiver/TransmitterUSB Universal Serial BusUSIM Universal Subscriber Identity ModuleUTM Universal Transverse MercatorUTRAN UMTS Terrestrial Radio Access NetworkVCC Power pinVLR Visitor Location RegisterWLAN Wireless Local Area NetworkWTX Waiting Time ExtensionXRES Expected response
xv
Chapter 1
Introduction
This thesis investigates ways to protect the location privacy of mobile network users against theprovider of that network. Location privacy can be defined as “the ability of an individual to movein public space with the expectation that under normal circumstances their location will not besystematically and secretly recorded for later use” [13]. This chapter justifies why that problem isworthy of study and outlines the content of the remaining chapters.
1.1 Statement of the Problem
In January 2014, 90 % of adults living in the United States owned some kind of cell phone [36].Due to their greater versatility, smartphones are more and more replacing simple feature phones.Between spring of 2013 and October 2014, the ratio of U.S. adults owning a smartphone rosefrom 35 % to 64 %, with a more widespread adoption by the younger age groups [45]. Moreover,smartphone owners were found to be very attached to their devices; 79 % reported to spend atmost 2 hours per day without their mobile phone [29]. Thus, the location history of a cellphonemay quite accurately reflect the movement and activities of its owner.
When using a mobile network, subscribers cannot avoid revealing personal location informa-tion to their mobile network operator (MNO). In order to be reachable for incoming calls, mes-sages, and data, the phone must always keep the network informed about the area it can be foundin. Activities that require interacting with the network, such as making a call or fetching a web-site, allow placing the phone within an even smaller region, the radio cell covered by the servingcell tower antenna. The MNO may store obtained location information about its customers forbilling, analyses, or legal reasons, even though this is not necessary for providing the communi-cation services. Since market forces usually allow only a small number of competing MNOs percountry, each network operator may be able to collect location data for a large number of people.
Such comprehensive population movement data can have many beneficial and legitimate usesin disciplines like city and transportation planning, targeting of disease control measures [50], andmapping of population densities [16]. However, there is also considerable potential for misuseof this private information. It is commonly assumed, that privacy risks can only result from thetheft of the data and that the MNOs themselves are trustworthy. Some, e.g. [31], believe thatthe potential damage to the companies’ reputation and profits that could result from violatingthe privacy expectations of their subscribers are sufficient to prevent any deliberate infraction ontheir part. Yet, there are numerous examples of MNOs from around the world monetizing thelocation information of their customers. These cases range from location-based advertising toselling aggregated, anonymized user demographic and movement data [28]. So MNOs do notalways deserve unqualified confidence, especially not if their core business is built on the extensiveanalysis and exploitation of information about their users [46].
In the wrong hands, subscriber location data might be used to monitor people’s movement,
1
to identify their routines, to find out if they are employed, who they work for, who they arespending time with, how fast they drive, what demonstrations they participate in, and which placesof worship and hospitals they visit. And even though some might feel that they have nothing tohide [47], others, through no fault of their own, might not be so fortunate. For them, locationprivacy might be indispensable for ensuring their livelihood, freedom, or physical safety.
1.2 Thesis Outline
The remainder of this thesis is structured as follows:
• Chapter 2 provides pertinent technical background information.• Chapter 3 reviews scientific literature on location privacy and human mobility behavior.• Chapter 4 proposes a system for the anonymous usage of mobile networks and describes
various strategies that allow system users to change their mobile network user identity inways that hinder re-identification.
• Chapter 5 presents an implemented prototype of the system.• Chapter 6 describes a partial, experimental evaluation of the system’s performance, and• Chapter 7 lists conclusions, contributions, and opportunities for future work.
2
Chapter 2
Technical Background
This chapter provides technical background information relevant to the rest of the thesis. Sec-tion 2.1 gives and overview over contact-based smart cards. Section 2.2 describes UMTS mobilenetworks and the role of a special smart card type in subscriber authentication.
2.1 Integrated Circuit Cards with Electrical Contacts
An integrated circuit card (ICC), better known as smart card, is a plastic card with an embeddedmicrochip. Common examples for ICCs are debit cards and SIM cards. Depending on its integratedcircuit (IC) component, a smart card may be either capable of data storage, data processing, or both.
An ICC is accessed via an interface device (IDF), commonly referred to as card reader or termi-nal. Based on the way the card and the terminal connect, two types of ICCs can be distinguished:contactless smart cards communicate over a low-range radio interface, whereas contact cards haveelectrical contacts on the surface that must be electrically connected to corresponding contacts onthe terminal side. All future mentions of smart cards in this thesis shall refer to the contact-basedvariety. Figure 2.6 on page 12 shows several smart card form factors used in mobile telephony.
The following parts of this section recap material from the ISO/IEC 7816 technical standard,more precisely from [23] and [24], in order to give the reader a basic understanding of smart cardoperations.
2.1.1 Files, Functions, and Applications
A smart card stores user-accessible data in a file system that is a forest data structure composed ofrooted trees with two kinds of nodes: elementary files (EFs) and dedicated files (DFs). Each EFstores a set of data units, records or objects. EFs are always leaf nodes. DFs are used for groupingother files, which means that a DF is only a leaf node if it is empty. The master file (MF) is amandatory DF found on all ICCs that can serve as the root of a file system tree. There existvarious ways to address files depending on file type, for example by variable-length names or bytwo-byte identifiers, which may be concatenated to absolute and relative paths.
In addition to offering access to the file system, a smart card may also provide functions thatoperate on parameters provided by the interface device, data stored on the card, or both. Functionsmay return a result, update an internal state, write data to files, or perform a combination of theseactions.
The hierarchical structure, the names, identifiers and purposes of files as well as the availablefunctions are usually standardized and reflect a card’s intended purpose. Depending on the specificrequirements, an ICC may implement several applications. An application consists of a set offunctions and a single subtree in the file system. The subtree’s root DF is called an application DF(ADF). It can either be a descendant of the master file, or it can be a proper root node. The latter
3
CLA INS P1 P2 Lc field Command data field Le field
Class byte Instructionbyte
Parameter bytesP2-P2
Only presentif Nc > 0
0, 1 or 3 bytes
String of Nc data bytes,only present if Nc > 0
Only presentif Ne > 00-3 bytes
Command header Command trailer
(a) Command APDU fields
Response data field
String of Nr < Nc data bytesonly present if Nr> 0
Status bytesSW1-SW2
SW1 SW2Response header Response trailer
(b) Response APDU fields
Figure 2.1: Command and response APDU fields
arrangement is more common for modern applications. Such ADFs are addressed by their uniqueDF name, which must be listed in a standardized EF under the MF. Figure 2.7 on page 12 showsan example for an ICC file system with an ADF root node.
2.1.2 Application Protocol Data Units
The IDF and the ICC interact by exchanging messages called application protocol data units (AP-DUs). An APDU sent by the terminal is called a command APDU, which answered by exactlyone response APDU from the card. Both messages taken together are referred to as an command-response pair and only one exchange of such a pair may be ongoing at the same time.
Figure 2.1a shows the fields that may be present in a command APDU. The first four bytes,called the command header, are mandatory. The class byte specifies a class of commands. The codetransmitted in the instruction byte denotes a specific command, telling the card which operationsto perform. Command arguments may be encoded in the parameter bytes P1 and P2. Nc denotesthe number of input bytes contained in the command data field. If Nc > 0 then this value isencoded in the Lc field. Otherwise both fields are absent. The Le field encodes an upper bound forthe size of the result data field of the expected response APDU.
Figure 2.1b shows the fields of the response APDU. If the instruction specified in the commandAPDU does not generate response data, then the respective data field of the response APDU is ab-sent. The response trailer containing the status bytes SW1 and SW2 is always present. These bytescategorize the outcome of the finished operation and may inform the terminal about necessaryfollow-up commands.
2.1.3 Card Contacts
The contact-based interface of a standard-compliant smart card may have up to eight electricalcontacts. Five of these are needed for basic functionality, i.e. their purpose and behavior is fullyspecified in ISO/IEC 7816. These contacts are listed in Table 2.1. The remaining three can serveapplication-specific functions, but they are not relevant to this thesis.
2.1.4 Transmission of Characters
The card and the terminal communicate by altering the voltage level on the shared I/O line. TheIDF side is responsible for pulling the voltage on I/O up to the high state (H) by connecting
4
Contact Purpose
VCC Used for supplying the card with power.RST Used for sending the reset signal to the ICC.CLK Used for providing the card with a clock signal for synchronous communication.GND Used for grounding and for providing a low reference voltage to the ICC.I/O Used for half-duplex transmission of data to and from the card.
Table 2.1: Roles of universal smart card contacts
it to VCC using a (pull-up) resistor. Then either side can impose the low state (L) of 0 V onthe line by connecting it directly to ground. This resulting state can easily be picked up by areceiver on the opposite side. Since the communication line is used bidirectionally, simultaneoustransmissions would lead to mutual interference. The available transport protocols address thisissue by specifying strict rules for turn-taking (see Section 2.1.6).
A special time unit called elementary time unit (etu) is introduced. Its duration is defined bythe following formula:
1 etu=F
D·
1
f
Both F and D are integer values that can be chosen by the card. The symbol f denotes the fre-quency of the clock signal provided by the terminal over the CLK input. The ICC selects theupper limit for f , but the terminal may provide any clock frequency within the applicable boundsand may even change it between commands.
Bytes are embedded into so-called characters for transmission over the I/O line, as shown inFigure 2.2. Each character is divided into ten equally long time increments called moments. Thelength of a moment is 1 etu. A characters starts with an initial moment of low state, followedby one moment for each transmitted data bit. Moment number 10 is used to encode parity in-formation, computed over the nine preceding moments. The endianness of the embedded byte,the mapping of bit values to voltage states, and the parity type (odd or even) are determined bythe card. How the receiver reacts to a transmission error, identified by an incorrect parity value,depends on the used transport protocol.
The delay between consecutive characters sent in the same direction is bounded by two param-eters. The character guard time (CGT) is the minimum delay from the beginning of one characterto the beginning of the next one. CGT is at least 12 etu. The maximum delay between the begin-ning of two consecutive characters is called character waiting time (CWT). The receiving side canuse this parameter as a timeout value to detect incomplete or incorrect transmissions.
2.1.5 Card Operating Procedures
An ICC shall support one or several consecutive classes of operating conditions. Three classesexist, labeled A, B, and C. Each one is characterized by a different high voltage level that maybe applied to the card’s contacts. Voltages exceeding this maximum might damage the card’s ICcomponent. Therefore, it is common practice for an IDF to apply the classes in reverse order,
Start ParityByte
Pause1 2 3 4 5 6 7 8 9
Start
10H
LCharacter
Figure 2.2: Transmission of characters. Graphic taken from [23, Fig. 7]
5
Class State H Voltage Level
A 5.0 VB 3.0 VC 1.8 V
Table 2.2: Classes of operating conditions and high voltage levels
from lowest to highest voltage, when dealing with an ICC whose supported classes are not known.Table 2.2 lists the class-specific voltages.
After selecting a class of operating conditions, the terminal activates the card by executing thefollowing steps in the given order:
1. Put RST to state L.2. Provide power to VCC.3. Enable the pull-up resistor on I/O (ignoring any activity on the line for a specified period).4. Provide a stable clock signal on CLK.
Following activation, the interface device is ready to receive the first message sent by the card.The IDF triggers this transmission called answer to reset (ATR) by sending the reset signal i.e. byputting RST to state H. The ATR must begin between 400 and 40,000 clock cycles thereafter.
The answer to reset informs the terminal about the connection parameters and card capabil-ities. It may range in size from 2 to 32 characters, depending on how many default values aredeclared implicitly by omission.
Unless the ATR forbids it, the IDF may send one protocol and parameter selection (PPS)request, to suggest a different transport protocol as well as other values for F, D, and the maximumclock frequency. The card returns its binding decision in the PPS response. Then, at the latest,may both sides start exchanging APDUs using the selected protocol and parameters.
The card is deactivated by putting all interface lines back to state L. The specification dictatesthat these steps are to be carried out in a particular order, but deviating from that sequence shouldnot lead to negative consequences.
2.1.6 Transport Protocols
Transmission of APDUs requires the use of a transport protocol. The technical standard definestwo options: protocols T=0 and T=11. Figure 2.3 shows their role in the layered communicationarchitecture.
1The protocols are named after the ATR field and the respective value used for declaring their usage.
Interface Device Smart CardAPDU
T=0: TPDU, T=1: block
character
moment
Application Layer
Transport Layer
Data Link Layer
Physical Layer
Application Layer
Transport Layer
Data Link Layer
Physical Layer
Figure 2.3: Smart card communication layers and the smallest units of information exchanged oneach layer
6
Prologue field (mandatory) Information field (optional) Epilogue field (mandatory)NAD (1 byte) INF (0 to 254 bytes) LRC (1 byte) or CRC (2 bytes)PCB (1 byte) LEN (1 byte)
Figure 2.4: Block fields. Graphic taken from [23, Fig. 17].
Both protocols use a request-response pattern for message exchange, i.e. the terminal and thecard take turns sending transport layer messages, starting with a message from the interface device.
Protocol T=0
Protocol T=0 is described as a half-duplex protocol for the transmission of characters. APDUsfrom the application layer are mapped to messages referred to as transport protocol data units (TP-DUs) for transmission over the transport layer. The mapping algorithm has to consider multiplefactors, such as the presence of command data, the possibility of response data, maximum fieldlengths, and context information.
Usually, a command TPDU is mostly identical to the corresponding command APDU. If ei-ther command data is present or response data is expected, then an additional length field is in-cluded in the TPDU header. Response APDUs generally are mapped to response TPDUs withoutany change. The transmission of data field bytes must be delayed until the receiving side has indi-cated its readiness to receive them by sending a so-called procedure byte. This applies to transmis-sions in either directions.
If an instruction is accompanied by both command and response data, then the APDUs aremapped to at least two command-response TPDU pairs, one for transmitting the command datato the card, the other one for fetching the response data. Similarly, large APDUs may have to besplit up and transmitted in a sequence of chained TPDU pairs.
Protocol T=0 uses a low-level approach to error detection and correction. Transmission errorsare detected by comparing the received and computed parity bit values of an incoming charac-ter. If the values differ, then the received byte is assumed to have been corrupted, necessitating aretransmission.
If the terminal detects an error this way, it finishes receiving the current response TPDU basedon the number of expected bytes and a CWT timeout. Afterwards it retransmits the failed com-mand.
The card uses a different error correction method. When detecting a parity error for a receivedcharacter, it signals the terminal by putting I/O to state L for 1 to 2 etu, starting at moment10.5± 0.2 of the character frame. The transmitter checks the line state at moment 11± 0.2 and, ifit is low, retransmits the last character following a delay of at least 2 etu.
Protocol T=1
The standard describes protocol T=1 as a half-duplex protocol for the transmission of TPDUscalled blocks. Blocks are transmitted as continuous streams of characters. Three types of blocksare distinguished: information blocks (I-blocks), receive ready blocks (R-blocks), and supervisoryblocks (S-blocks). All of them adhere to the common structure shown in Figure 2.4.
The node address byte (NAD) is used in I-blocks to specify a logical channel for which the datain the information field (INF) is intended. (Each logical channel specifies a particular ongoing ses-sion involving the terminal and the card.) The size of the information field is encoded in the lengthbyte (LEN). The protocol control byte (PCB) identifies the block type and contains type-specificfields. The epilogue field holds a checksum value computed over the prologue and informationfields; the card determines whether a longitudinal redundancy check (LRC) or a cyclic redundancycheck (CRC) algorithm is used. The receiver of a block can check its integrity by comparing theincluded checksum with the expected value. The character parity bits are ignored.
7
The maximum information field size in bytes that a receiver can handle is called IFS. Differentvalues may apply for each direction. IFSC and IFSD are the IFS parameters of the card and the IDFrespectively. Their maximum value is 254 bytes, due to the range of the LEN field. Only blockswith a sufficiently small information field may be transmitted.
The terminal can identify an unresponsive card based on the block waiting time (BWT), themaximum permissible delay between a block sent by the IDF and the block sent in response bythe ICC (plus 10 etu).
I-blocks are used for transmitting command and response APDUs. To guarantee the reliabletransmission of application layer data, I-blocks have a one-bit send-sequence number field denotedN(S). Each side has its own N(S) counter, which is flipped each time the successful reception ofa transmitted I-block is acknowledged by the receiver. The most common way to send such apositive acknowledgment is by directly sending an I-block oneself.
If the APDU’s length is less than or equal to the respective IFS, then the whole applicationlayer message can be transmitted as INF of a single I-block. Otherwise the APDU is split intomultiple chunks and sent in a sequence of chained I-blocks. All but the last I-block of a chain mustbe positively acknowledged by an R-block.
R-blocks may also signal negative acknowledgment, indicating the reception of a corrupted orincomplete block, which usually leads to a retransmission. In some cases, they might be used onlyfor returning the right to transmit to the receiver.
S-blocks are control messages. They can be used to reset the N(S) counters in order to recoverfrom loss of synchronization, to update IFS values, to abort an incoming chain of I-blocks, and fornegotiating a waiting time extension (WTX).
The card can send a WTX request to avoid a BWT timeout, for example when a receivedcommand is going to take a long time to process. The terminal shall acknowledge the request witha WTX response, which restarts the timeout countdown. The ICC may demand longer waitingtime intervals and may issue an unlimited number of repeated WTX requests. Although thereexists no option for rejecting those requests, the terminal cannot be kept waiting indefinitely. Ifa response APDU is delayed for too long, then the IDF may respond with a card reset due tonon-compliance with response time requirements of the application layer.
2.2 3G Mobile Networks and UICCs
As heralded by the title, this section presents aspects of Universal Mobile TelecommunicationsSystem (UMTS) cellular networks and the role of UICCs, colloquially referred to as SIM cards.Although the focus is on 3rd generation (3G) technologies, due to the gradual evolution of mobiletelecommunication systems, most of the concepts described here apply to other generations aswell. For a more thorough introduction on mobile networks, see [42].
2.2.1 UMTS Mobile Networks
A mobile (or cellular) network provides wireless communication services to untethered devicesthrough a set of spatially distributed, interconnected, stationary antennas. Figure 2.5 outlines thearchitecture of UMTS mobile networks. The system consists of two parts: the UMTS terrestrialradio access network (UTRAN) and the core network (CN).
The stationary antennas belong to the UTRAN. Antenna stations are referred to as node Bs.They can establish a radio connection to the user equipment (UE), which may be a mobile phone,a broadband adapter, or any other device that relies on the cellular network for communication.The radio resources of node Bs are managed by radio network controllers (RNCs). Accordingto [42], each RNC is usually responsible for several hundred node Bs.
8
UTRAN Core network (CN)
Node BUEIP network
PSTN
HLR
GMSC
GGSN
HLR
RNC
RNC
VLRMSC/
VLRSGSN/
Figure 2.5: Simplified UMTS network architecture (Release 99). Dashed lines represent signalinglinks. Solid lines represent links for both data and signaling. Graphic based on [42, Figure 3.1].
The services provided by the core network can be divided into two domains: circuit-switched(CS) and packet-switched (PS) services. CS means that the network allocates an exclusive, dedi-cated communication channel with a guaranteed bandwidth. Until that channel is explicitly closedagain, the transmission resources claimed by the connection are unavailable to other parties. CSconnections are used for voice calls and video telephony, i.e. applications with (mostly) constant bitrates. For applications with variable bit rate requirements, e.g. mobile Internet, PS connectionsare better suited. Instead of reserving transfer capacity exclusively for one connection, availablebandwidth is shared by multiple connections. Since PS applications typically send data in shortbursts separated by relatively long periods of inactivity, relying on circuit switching would lead toa lot of unused, wasted transmission capacity.
CN nodes involved in relaying CS data are the mobile switching center (MSC) and the gate-way MSC (GMSC). The MSC is responsible for setting up calls to and from UEs. The GMSCconnects the mobile network to the public switched telephone network (PSTN) – the global tele-phony network. PS connections are managed by nodes belonging to the General Packet RadioService (GPRS): the serving GPRS support node (SGSN) is the counterpart of the MSC in the PSdomain, the functions of the gateway GPRS support node (GGSN) mirrors that of the GMSC,with the difference that the GGSN serves as an interface to the Internet or another Internet Proto-col (IP) network. Two types of databases with subscriber account information – the home locationregister (HLR) and the visitor location register (VLR) – are also part of the core network. Eachmobile network operator (MNO) maintains an HLR for storing information about the accountsof its subscribers. That information includes the international mobile subscriber identity (IMSI)– a permanent subscriber identifier – and the mobile subscriber ISDN number (MSISDN) – thetelephone number under which the subscriber may be reached. The HLR also stores more tran-sient data, such as which MSC is currently responsible for forwarding incoming calls to a particularsubscriber. That MSC then copies some of the subscriber-related information to its VLR where itis kept until the subscriber is handed over to a different MSC.
Establishing a mobile data connection from the UE to the IP network is referred to as a packetdata protocol (PDP) context activation or as making a PS call. During this procedure, the UE istemporarily assigned an IP address. That address is usually from a private address space, whichrequires the GGSN to perform network address translation (NAT). But this also means that thereis no competition for IP addresses among UEs, allowing the PDP contexts to be relatively long-lived.
In order to join a mobile network, the UE has to prove that it is acting on behalf of a partic-ular subscriber. Therefore, the network may demand from the UE to perform an authentication
9
procedure that requires access to the subscriber’s UICC – a special smart card that needs to beplugged into the UE. Authentication may happen whenever the network desires, however, it usu-ally coincides with billable events, such as outgoing or incoming calls, and location updates (seebelow). Most MNOs also perform the authentication procedure when a subscriber connects totheir network. The procedure is described in the next subsection.
Each antenna of a node B covers a specific region called a cell. Cells are uniquely identifiedby their cell ID. Normally, directional antennas are used, which allows each node B to servicemultiple surrounding cells. Whenever a UE attaches to the mobile network, it registers with acell that covers the UE’s location to tell the network where the subscriber using the UE can befound. Having UEs repeat this location update procedure every time they enter a new cell wouldlead to a lot of signaling traffic. Therefore, adjoining cells are arranged in groups and an idle UEhas to perform a location update only when is moves into the area of a different group of cellsor when the amount of time since the last location update has exceeded a specific value. For theCS domain, the areas of grouped cells are called location areas (LAs). For the PS domain, cellsare grouped into routing areas (RAs). The two types of update procedures are called LA update(LAU) and RA update (RAU) respectively. The cells of a particular RA all belong to the same LA.According to [42], LAs typically contain several dozens of cells and RAs are usually identical toLAs, without further subdivision. If there is an incoming call to an idle UE (whose current cell istherefore unknown) the network has to first broadcast a paging request in all cells of the UE’s lastreported LA. After the UE’s response, the call can be established in its present cell. While the callis ongoing or while the UE is in a state with similar requirements, the UE constantly monitors thesignal strength of nearby network antennas and shares this information with the RNC responsiblefor the current node B. For better reception or load balancing, that RNC may instruct the UE toswitch to a different cell. Since neighboring cells partially overlap, an almost seamless handoverbetween them may be possible.
Within the core network, subscribers are identified by their IMSI. On the air interface, UEsand node Bs use temporary identities instead, to prevent third parties that may be listening tounencrypted control messages from identifying and tracking subscribers. The network assigns arandom, frequently changing identifier called the temporary mobile subscriber identity (TMSI) toeach subscriber. The TMSI changes with each LAU. For the PS domain, there exists an analoguetransient identifier called packet TMSI (P-TMSI), which is renewed during each RAU. Confidential-ity of the new identities is always ensured by encrypted transmission. The necessary encryptionkeys are generated as part of the subscriber authentication procedure. When identifying with aTMSI or P-TMSI outside of the LA and RA respectively where it was assigned, the UE must alsosupply the original location or routing area identity (LAI, RAI). The MSC or SGSN of the newcell can then contact its respective counterpart responsible for that area and retrieve the IMSI towhich the temporary identity is mapped. If the UE cannot provide a valid TMSI or P-TMSI or ifthe subsequent lookup fails, then an LAU or RAU with the subscriber’s IMSI has to be performed,during which a new temporary identity is assigned.
Each UE has a unique permanent identifier, the international mobile station equipment iden-tity (IMEI). It plays no role in the provided communication services and the network cannot verifyits authenticity, but the IMEI is used for blocking stolen or disruptive devices. It also permits theMNO to monitor UEs for law enforcement purposes.
2.2.2 UICCs and Security-Related Procedures
A UICC is an integrated circuit card with one or more applications. The term is supposed to beneither an abbreviation nor an acronym. The UICC is the technological successor to the SIM card,i.e. it is supposed to store subscriber data necessary for participating in a mobile network. Thisthesis focuses on UICCs with a USIM application, which enables the subscriber to make use ofa 3G mobile network. The properties of UICCs are defined in [18]. Figure 2.6 shows the four
10
standardized UICC form factors and their pinout.
The USIM Application
The universal subscriber identity module (USIM) is a smart card application for UICCs that per-mits a UE to access a UMTS mobile network. The properties of the USIM are specified in [2].The application stores both fixed and dynamic information about the subscriber and the networkin a predefined file structure. Figure 2.7 shows select elementary files under the USIM ADF. TheseEFs represent less than two percent of the USIM application’s file tree.
For performance reasons, the UE may cache mutable parameters in its own memory insteadof immediately writing changes to and always reading the current values from the card. If the UEdoes not adhere to initialization and termination procedures required by the application or in caseof an error in the network, then the UICC, the UE, and the stationary network could end up ininconsistent states. For example, a sudden removal of the card from the terminal while the UEis attached to the mobile network’s CS domain would lead to a loss of the current TMSI on thesubscriber side, because the UE would not have time to save the current value on the UICC forlater use. The cryptographic keys mentioned in the next paragraph may be lost in the same way.UMTS provides re-synchronization procedures for recovering from these situations.
Security Procedures
The security features of UMTS include the mutual authentication of subscribers and of the net-work as well as ensuring the confidentiality and integrity of the transmitted data. Authentication isbased on both sides proving possession of a secret key K. Confidentiality is ensured by symmetricencryption of transmissions based on a cipher key CK. And data integrity is provided by digitalsigning of messages based on an integrity key IK. This allows the receiver to identify modified oraltogether forged messages.
Mutual authentication and the establishment of CK and IK is achieved in a single procedurecalled authentication and key agreement (AKA). Figure 2.8 shows the sequence of events of a suc-cessful authentication in the CS domain. Except for the replacement of the MSC by the SGSN,the procedure would be identical in the PS domain. Note that each domain uses a different set ofcipher and integrity keys. The authentication procedure begins with the serving MSC (or SGSN)selecting the first unused element from a subscriber-specific list of so-called authentication vectors,which are stored in the node’s VLR. If the list is empty, then new authentication vectors are re-trieved from the subscriber’s HLR, as shown in the upper part of Figure 2.8. Each vector containsa random challenge RAND and several derived values: the expected response XRES, keys CK andIK, and an authentication token AUTN. Besides RAND and a set of generating functions labeledf1 to f5, the subscriber’s secret key K is needed to compute the derived values. The subscriber’sHLR and USIM implement the same generating functions and they are they only entities withknowledge of K. AUTN encodes a sequence number that can be used to detect old authenticationvectors.
After selecting the next authentication vector from its VLR, the MSC forwards RAND andAUTN to the UE, demanding the challenge response RES. Reading K off the UICC is supposed tobe impossible2. The UICC shall allow only indirect access to K via the AUTHENTICATE command.This instruction takes two input parameters: RAND and AUTN. The USIM first verifies AUTNto make sure that the challenge originated from a trusted network with access to recent, unusedauthentication vectors. It then computes and returns RES, CK, and IK.
2The general goal is to make extracting the secret key at least very difficult. Yet, several successful attack strategieshave been reported, such as probing data bus wires [51], exploiting software vulnerabilities of the UICC [39], anddifferential power analysis [57].
11
ID-1 UICC
Plug-in UICC
Mini-UICC
4FF
C1C2C3C4
C5C6C7C8
C5C6C7
C8
C1C2C3
C4
C1C2C3C4
C5C6C7C8
C5C6C7C8
C1C2C3C4
C5C6C7C8
(a) UICC form factors
Contact Pinlabel name
C1 VCCC2 RSTC3 CLKC4 not usedC5 GNDC6 not usedC7 I/OC8 not used
(b) UICC pinout
Figure 2.6: UICC form factors and pinout
Master fileMF
'3F00'
Contain files for GSM networkaccess by UEs that only supportSIM cards
EFPL'2F05'
EFARR'2F06'
EFICCID'2FE2'
UICC serial numberList of ADF names Language settings File access rules
DFTELECOM'7F10'
DFGSM'7F20'
USIM applicationdedicated file
TMSI and LAIP-TMSI and RAIIMSI MSISDNCiphering andintegrity keys forthe CS domain
Ciphering andintegrity keys forthe PS domain
EFMSISDN'6F40'
EFLOCI'6F7E'
EFPSLOCI'6F73'
EFKeys'6F08'
EFKeysPS'6F09'
EFDIR'2F00'
EFIMSI'6F07'
ADFUSIM
Refer
ence
by n
ame
Figure 2.7: UICC and USIM file structure. Only select files are shown, including their names andhexadecimal file identifiers. Graphic based on [2, Figures 4.1 and 4.2].
12
UICC/USIM UE MSC/VLR HLR
Select CK(i) and IK(i)
Verify AUTN(i)RES(i)CK(i)IK(i)
← f3(K, RAND(i))← f4(K, RAND(i))
← f2(K, RAND(i))
Distribution of authenticationvectors from
HLR to VLR
Generate authenticationvectors AV(1...n)
Store authentication vectors
Compare RES(i) and XRES(i)
Select authentication vector AV(i) =(RAND(i), XRES(i), CK(i), IK(i), AUTN(i))
Select CK(i) and IK(i)
AUTHENTICATE responseRES(i), CK(i), IK(i) User authentication response
RES(i)
Authentication data request
Authentication data responseAV(1...n)
User authentication requestRAND(i), AUTN(i)AUTHENTICATE command
RAND(i), AUTN(i)
Authentication andkey agreem
ent
Figure 2.8: Authentication and key agreement (AKA) in the CS domain with preceding retrievalof fresh authentication vectors from the HLR. Graphic based on [3, Figure 5].
The UE passes RES on to the MSC for comparison. If RES and XRES match, then the sub-scriber is successfully authenticated and both sides prepare switching to CK and IK. To actuallystart ciphering and integrity protection for the CS domain or to update the used keys, the MSChas to perform another exchange with the UE as shown in Figure 2.9. Afterwards, the path be-tween the UE and its serving RNC is protected (assuming that neither side insists on weak or nosecurity).
RAND, AUTN, and RES may be sent as cleartext over the air interface. But since user data isonly ever sent after ciphering and integrity protection have begun, the user data is considered safe,even against an interposed attacker, provided that the UE does not fall back to 2G networks, aspointed out by [35].
The UE shall send the user authentication response less than 1 s after receiving the user au-thentication request. Processing of the AUTHENTICATE command by the UICC shall take less than500 ms.
Card Application Toolkit
Card application toolkit (CAT) is an optional but typically implemented set of mechanisms in theUICC and the UE that allow applications on the card to not only respond to incoming instruc-
13
UE RNC MSC/VLR
Security mode commandCK, IK
Start integrity protection
Start ciphering and deciphering
Verify received message andstart integrity protection
Verify received messageSecurity mode complete
Security mode command
Security mode complete
Start ciphering and deciphering
Figure 2.9: Start of integrity protection and ciphering in the CS domain following authenticationand key agreement. Graphic based on [3, Figure 14].
tions, but to issue certain commands themselves. CAT is defined in [19]. UICCs that support itare referred to as proactive. A proactive UICC that is plugged into a compatible UE may triggera wide range of activities, such as making phone calls, sending short messages, drawing responsivemenus on the UE’s screen, and communicating with other UICCs connected to the same UE. Theterminal side may support only some of the associated commands; the UE sends a list of avail-able instructions to the UICC during the USIM initialization procedure in the so-called terminalprofile.
Figure 2.10 shows the position of the CAT layer within the UICC communication layer stack.Proactive UICCs are constrained by the half-duplex, turn-taking transmission protocols used bysmart cards. They can only issue a command, after having finished processing a terminal commandwithout errors. Instead of returning the status value that indicates normal completion of the ter-minal’s command, a UICC with a queued proactive command sends a special status value, whichsignals both the successful termination of the terminal’s last instruction as well as the length of theinformation describing the pending proactive command. The terminal then fetches that data andultimately returns the response using special terminal commands.
Terminal UICCAPDU
T=0: TPDU, T=1: block
character
moment
Transport Layer
Data Link Layer
Physical Layer
APDUApplication Layer
CAT Layer
Transport Layer
Data Link Layer
Physical Layer
Application Layer
CAT Layer
Figure 2.10: Position of the CAT layer in the UICC communication layer stack. The standardsmart card communication layers shown previously in Figure 2.3 are colored gray.
14
OTA Programming of UICCs – an Excursion
From time to time, an MNO might want to reconfigure issued UICCs. To avoid costly recalls andreplacements, a UICC may support over-the-air (OTA) updates, i.e. changes of the data stored onthe card via commands sent by the MNO over the mobile network. For example, the networkoperator might use OTA programming to distribute a new UICC application.
A fairly recent area of application for OTA updates is reprogramming UICCs to switch to adifferent provider without having to replace the UICC in the phone. Apple was the first companyto introduce cards with this feature. According to [8], their proprietary Apple SIM solution islikely to be replaced by the embedded SIM (eSIM) [49] industry standard, which pursues the samegoal.
15
Chapter 3
Related Work
This chapter reviews existing scientific literature relevant to this thesis. Section 3.1 introducesfundamental concepts and presents various approaches for protecting the location privacy of indi-viduals. Section 3.2 presents findings from research aimed at characterizing human mobility.
3.1 Location Privacy
The existing literature offers two noteworthy definitions of location privacy, which are both morepractical than the rather subjective definition given in Chapter 1. According to Beresford andStajano, location privacy is
“. . . the ability to prevent other parties from learning one’s current or past location.” [12]
These authors consider location privacy a special type of information privacy, which, according toBanisar and Davies [6], is one of the four facets of privacy, the other three being bodily privacy,privacy of communications, and territorial privacy.
The second definition of location privacy comes from Duckham and Kulik, who narrow downthe definition of privacy by Westin – a pioneering author on the subject – to apply exclusively tothe location privacy domain. Thereby, Duckham et al. effectively define location privacy as
“. . . the claim of individuals, groups, or institutions to determine for themselves when,how, and to what extent [location] information about them is communicated to oth-ers.” [17], adapted from [56].
Compared to the first explanation of the term, this one accounts for more fine-grained control ofindividuals over the nature of shared location information and over the circumstances under whichthat sharing takes place.
Duckham et al. use their definition in [17] to put forward a comprehensive classification of ap-proaches for location privacy management. They distinguish four classes of protection strategies:regulatory approaches, privacy policies, anonymity, and obfuscation. These classes are not mutu-ally exclusive, i.e. a system may feature strategies from any combination of classes. Regulatorystrategies are legal rules for collecting and handling location information. Privacy policies refer toautomatic ways for users to interdict certain uses of their personal data. For example, when usinga location-based service (LBS) to find nearby abortion clinics, a user might specify that informa-tion about the query shall not be shared with third parties. Anonymity strategies attempt to hideindividuals’ identities, either by using pseudonyms in favor of true identities, or by withholdingidentity information altogether. Lastly, obfuscation strategies are aimed at implementing the need-to-know principle with regard to users’ location information, i.e. degrading the quality of releasedspatial and temporal information to what is absolutely necessary for a requested service.
17
Assessing the effectiveness of anonymity strategies requires an objective definition of the termanonymity. Pfitzmann and Hansen define it as follows:
Anonymity of a subject means that the subject is not identifiable within a set of sub-jects, the anonymity set. [41]
The minimum anonymity set size k is a common metric for evaluating anonymity strategies. Theterm k-anonymity is often used interchangeably. Gruteser and Grunwald define this concept withregard to location privacy as follows:
“ . . . a subject [is] k-anonymous with respect to location information, if and only if thelocation information presented is indistinguishable from the location information ofat least k − 1 other subjects.” [22]
User-specific location information is usually modeled as a set of discrete events. The genericproperties of each event can be represented as an event tuple (u, x, y, t ), which specifies the 2Dcoordinates x and y of a user u at time t .
In [22], Gruteser and Grunwald propose a system for protecting anonymous users of an LBSagainst identification and location tracking by guaranteeing k-anonymity for an arbitrary k. Theirsystem relies on the obfuscation strategies of spatial and temporal cloaking. Cloaking algorithmsreduce the accuracy of a numerical parameter by replacing its actual value with an enclosing inter-val. Thus, spatial cloaking replaces 2D coordinates with a surrounding area and temporal cloakingdegrades moments to time periods. The obfuscation is performed by a middleware system, which,after cloaking, forwards location-based requests from each mobile nodes to the desired LBS server.The default obfuscation algorithm uses known locations of the requester and other nodes in a tech-nique based on quadtrees, see [20], to compute an area that contains at least k nodes at the timeof the request. If higher spatial accuracy is required, i.e. there exists an upper bound for the area’ssize, and delays are acceptable, temporal cloaking can be added to the process. This means that arequest at time t will be delayed until time t2, when additional requests by k−1 other nodes froma suitable area have occurred. The forwarded request contains the surrounding area and the timeinterval [t1, t2], with t1 < t . As pointed out by the authors, requests with overlapping areas mayleak information about the locations of some active nodes, so the effective sizes of their respectiveanonymity set might be lower than the chosen parameter k. The authors also acknowledge that anattacker may use fake requests to counteract the cloaking algorithm and suggest authentication ofnodes by the middleware with difficult-to-obtain authentication keys as a solution. However, thiswould not only force nodes to disclose more information about themselves, but I believe that thisalso could not reliably stop a dedicated attacker with sufficient resources.
Since guaranteeing a specific minimum level of location privacy is often incompatible withpractical requirements, most privacy-enhancing systems only pursue a best-effort approach. Thefollowing systems presented in this section all belong to that category.
The just mentioned system of Gruteser and Grunwald is obviously only compatible withlocation-based services that do not have to distinguish between different users. Beresford and Sta-jano present a framework in [12], which supports services that require users to provide identityinformation. In the investigated scenario, each LBS defines an application zone in which it offersits service. These areas are assumed to be of limited size, for example the inside and surroundingsof a brick-and-mortar business, that operates the location-based application to reach potential cus-tomers. Users have to register for each application at a common middleware system and then keepthat system apprised of their current location. At regular intervals, the middleware evaluates users’positions, notifies concerned applications about changed user locations and forwards buffered mes-sages. A user’s location information is only shared with registered applications and only while theuser is within the respective application zone. Despite of the limited size of these areas, colluding
18
LBS operators could combine their knowledge to determine a user’s past and current locations,even if a different, but static, pseudonym is used for each application. Thus, the middleware sys-tem assigns a new, unused pseudonym to a user (discarding the old one) whenever (and only when)that user enters a so-called mix zone. The authors define this type of area as follows:
Given a group of users, a mix zone is “a connected spatial region of maximum size inwhich none of these users has registered any application callback.” [12]
This means that applications cannot directly observe users’ pseudonym switches. However, the au-thors show that the number of users present in a mix zone, while a particular user passes through it,i.e. the size of the anonymity set, is not an accurate indicator for that user’s gain in location privacy.That is because not all matchings of old to new pseudonyms are equally likely, or even possible.Therefore the authors suggest using Shannon’s entropy3 [44] instead of the average anonymity setsize for measuring a mix zone’s effectiveness.
In [30], Li et al. describe two pseudonym switching schemes – Swing and Swap – for a mobilenetwork consisting of mobile nodes that connect to stationary access points for some kind ofservice. Adversaries are assumed to know the exact locations of transmitting nodes. Pseudonymsand associated authentication keys for the nodes have a limited lifetime and are obtained in bulkfrom a trusted third party reachable via the network. In Swing, nodes that want to increase theirdegree of anonymity wait until they are about to change their current direction of movementor speed. Then they inform their nearby peers about their intention with a broadcast message,enter a random silent period, i.e. they make no transmissions for a space of time with randomlength, and then switch to the new identity. The broadcast may cause nearby, receiving nodes toalso perform the update procedure. Since silent periods lead to a transient disruption of service,frequent pseudonym updates are avoided. Swap is similar to Swing, but pseudonyms are exchangedand then used by the new holder, instead of being discarded, so the adversary might be unable tonotice the updates. Additionally, nodes that are close-by, but not participating in the exchange, alsoenter a random silent period, to further increase the size of the anonymity set. Using an entropy-based anonymity metric in simulations with a random way-point mobility model [38], Swingperformed better than randomly-triggered update procedures, but worse than Swap. The schemesof Li et al. permits nodes to change pseudonyms anywhere, not just in designated mix zones, butthe requirement of nodes having to predict their own movement greatly limits the applicability insituations with human-generated node movement. Even if nodes could successfully anticipate theirchanges in direction and speed, then one should assume that the adversary has similar capabilitiesand can use them to discover updates and match pseudonyms to users. Since the authors chose avery unrealistic model of node mobility for their evaluations, the obtained results might also be oflow significance.
Anonymization of location traces is not always performed in real-time, i.e. while the move-ment data is being generated, but there is also research into providing location privacy for com-pleted datasets. Due to legal and ethical requirements, user identities and information that mightallow the reidentification of individuals often must be removed before passing a dataset on to thirdparties. Compared to real-time methods, deferred algorithms should be able to produce betterresults, because they can take all subsequent events into account, when processing a particularevent, not just those that happened before. In [32], Mano et al. develop such an algorithm forretroactive anonymization of movement data. First, the algorithm computes a simplified graphrepresentation of users’ movement paths. The graph contains one vertex for each user’s start andend location, which are supposed to be identical to represent the user’s exclusively used home.
3Given a single mix zone z0 and multiple adjacent application zones z1, . . . , zn , let pi j denote the probability that anyparticular user moved from zi to z j from one update period to the next. Then the entropy h of the mix zone is defined
as h(z0) =−n∑
i=0
n∑
j=0pi j · log2 pi j .
19
Additional vertices are inserted for each place where two users meet. Path segments between theseplaces are represented by directed edges in the resulting graph. Using one pseudonym per user, thealgorithm then finds feasible pseudonym paths in the graph, that connects the start and end vertexpairs. Muno et al. also introduce a special location privacy metric called (K,t )-pseudonym locationprivacy, which is defined as the number of viable pseudonym assignments for a particular user attime t , taking all other users and feasible pseudonym assignments into account. This measure re-flects that path segments close to the home location vertices (i.e. with few intermediate encountervertices) can be attributed to a specific user with high probability by an adversary who knowsthat user’s home location. The authors consider (K ,t )-pseudonymity superior to privacy metricssimply based on counting encounters, because it is unaffected by repeated consecutive meetings ofthe same nodes. However, both the algorithm and the metric are based on the assumption, thatusers are equally likely to take any path segment leading away from the place of an encounter. Thisassumption is contradicted by existing literature [12, 21].
We now return to literature on real-time pseudonym switching systems, more specifically,those aimed at protecting the location privacy of cellular network users against network-side ad-versaries.
In [11, 10], Belle et al. present PathForge, a system for providing location privacy to cellularnetwork subscribers, which changes the way subscribers are authenticated and how incoming callsare established. Users register to the network with two identities I and T . Both may changefrequently, but for different reasons. Let u be an arbitrary user, then the mobile network operator(MNO) assigns a permanent personal identity Iu and an associated secret key Ku to u. Initially, uuses Iu as I , but every time u meets with another user (which might mean that they can exchangeinformation via Bluetooth), the two swap I . When Iu is exchanged this way, the new holder isalso informed about a seed value su , chosen by u, which can be used to compute the currentidentity T of u. Each value of T is valid for a specific time period. The seed s is never sharedwith the MNO, so it cannot use T for tracking users. Now, if there is an incoming call for u, thecarrier has to contact and authenticate the callee before setting up the call. Since Iu is exchangedwith every encounter, in order to protect u’s location privacy, the current holder of that identitymight be u or somebody else. In the former case u is immediately authenticated based on Ku .In the latter case, the MNO retrieves the current temporary identity Tu from the holder of Iuand contacts u by calling Tu , before proceeding with the subscriber authentication procedure.Authentication is also required, when a user makes an outgoing phone call. Each time u mustauthenticate him- or herself, u can no longer hide behind a current fake proxy identity I . Theauthors take this as cause for u to switch back to Iu . To make it clear that u is the new, rightfulholder of Iu , the proxy identities are accompanied by a sequence number, which is incrementedwhenever the original owner is forced to authenticate. Say u makes a call and switches to (Iu , 2),invalidating all older Iu tuples. The MNO informs the holder v of (Iu , 1) about this, the nexttime v tries to register the location of Iu . Then v must also discard I , switch back to Iv andincrement the associated counter. This cascade may eventually reach all member of the clique ofmeeting users that includes u. As observed by the authors, a single phone call may thus exposethe current proxy identities and locations of a large number of users. I see the following additionalproblems. In regions with a low user density, there will be few encounters and, as a consequence,few users with a proxy identity other than their own. The authors mention the possibility of usersregistering not with just one but with a list of proxy identities, to decrease the probability that auser’s assigned proxy identity and therefore the user is not reachable. However, such a list wouldallow inferences about the encounters that have taken place, facilitating the identification of users.But these lists could mitigate the problem that all but the first user in a proxy identity reset cascadeare unreachable for a certain amount of time, if each proxy identity has just one holder. Since useru is not notified when the current holder of Iu discards it, Iu will be absent from the network untilthe reset cascade reaches u. According to the authors’ description, the cascade proceeds one step
20
when a user tries to register with a proxy identity that has been invalidated in the previous step.This only happens when that user switches to a different access point or when that user’s identityT changes. Therefore, the frequency of these events would have a big effect on the amount of timeuntil a user can receive calls again. Immediately notifying the user u when Iu is discarded wouldavoid any unnecessary delays. Another weakness of PathForge results from each user having twoidentites, I and T , that are updated independently. So, in some cases, an observer may be able tolink the old and new value of one identity, because the value of the other one has stayed the sameand was used for registering with a new access point.
In order to get rid of some of the shortcomings of PathForge, Belle et al. present an enhance-ment called CallForge in [9]. Unlike its predecessor, this system does not expose the true identityof users making a phone call, thus avoiding proxy identity reset cascades along with the vulnera-bility to active probing by the carrier, i.e. frequently obtaining the current temporary identity Tuof a user u by contacting the current holder of Iu . The authors propose to separate the identitiesI and T by storing them on separate SIM cards. A two-step call setup procedure named Y-Routingprevents the MNO from finding out temporary identities. In this procedure, the caller (not theMNO) retrieves Tu from the current holder, before establishing a second call to the intended calleeu. In order to make correlating these calls harder, the caller uses different SIM cards for each ofthem. But, in my opinion, either an unrealistically high frequency of outgoing calls in the caller’scell or unacceptably long delays between the two Y-Routing steps would be required to achievethat goal. If these conditions are not met, then correlating the two calls would only be impossible,if I and T were registered in different networks whose MNOs were not cooperating to identifyusers. The authors claim that CallForge can be implemented completely on the mobile devices,without changes to the fixed network infrastructure. Yet, the network would clearly need cus-tomized authentication and billing procedures, because the established account-based techniquesare incompatible with the anonymity requirements of CallForge. So modifications on the networkside would be necessary. In Chapter 4, I present a system that can truly be embedded into unmod-ified, existing mobile network infrastructure.
3.2 Characteristics, Re-Identification, and Prediction of Human Trajec-tories
Bayir et al. report in [7], that individuals “spend approximately 85 % of their time in 3 to 5favorite locations” and that they spend less than 1 % of their time in each of the other locationsthey visit. These findings are based on the cell connectivity data of 100 phones carried by universitystudents and faculty members over a nine-month period. Readings were obtained every 6 minutes.Although both the observation period and the sampling frequency are sufficient to draw the aboveconclusions, the relatively small and homogeneous subject pool brings the generalizability of theseresults into question.
Yet, Gonzales et al. have found a similarly long-tailed distribution of the time that mobilephone users spend in visited cells. In [21], they investigated the trajectories of 100000 users, findingthat, on average, 40 % of calling and texting events take place in a user’s two most favored locations.This percentage is naturally lower than that reported by Bayir et al., because time spent at homeor at work coincides with periods of reduced phone usage; users’ rate of calling and texting shouldbe lower while they are asleep at home or busy at work.
Mobility trajectories (also known as traces) based on phones’ interactions with cell towers arefrequently used in location privacy research. Carriers often log this information by default, whena subscriber’s phone is sending or receiving user data.
Song et al. used trajectories based on calling and texting events in [48], to study the theoreticallimits of predicting human mobility. They discovered high spatial and temporal regularity inthe movement of individuals and an average potential predictability of 93 %, i.e. only 7 % of
21
mobility can be attributed to unpredictable, random factors. Their results also show little inter-person variability; the minimum potential predictability among all 50000 subjects was over 80 %.Interestingly, a user’s typical traversed distance had little impact on predictability.
De Monjoye et al. investigated the difficulty of uniquely identifying individual trajectoriesfrom a large set of such traces in [37]. Their dataset contained information of 1.5 million sub-scribers, from a region with almost 6500 cells (a small European country), spanning a time periodof 15 months, with a temporal resolution of one hour and, on average, 114 monthly events peruser. The authors found, that 2 randomly selected points of a trajectory were sufficient to uniquelyidentify over 50 % of all trajectories. With 4 random points, that ratio rose to 95 %. Spatial andtemporal degradation of the data, by joining neighboring cells and lowering the temporal resolu-tion respectively, led to a moderate, gradual reduction of the re-identification ratio. Increasing thenumber of randomly selected points had an opposite, positive effect.
The work of de Montjoye et al. was focused on re-identifying location traces, but their re-sults can easily be transferred to the problem of matching anonymous or pseudonymous mobilesubscriber accounts to individuals. Apart from the subscribers’ location traces, little informationabout the a person’s whereabouts may be enough, to identify the subscriber account used by thatindividual.
Krumm and Horvitz describe a method called Predestination in [27], which is intended forpredicting the destination of a user’s ongoing trip, after having observed only a continuous partof it, starting at the trip’s beginning. The prediction is based on the user’s own known previousdestinations and, to a lesser extent, on recent destinations of other users. With complete knowledgeof a user’s other trips and after observing his or her current trip for the first half of its total length,the average distance between the predicted and the actual destination is, on average, less than 2 km.
22
Chapter 4
A System for Protecting Location Privacyin Mobile Networks
“On another occasion I wished to jump across a [swamp]. When I was in the middle of it,I found it was much larger than I had imagined at first. So I at once turned back in themiddle of my leap, and returned to the bank I had just left, to take a stronger spring. Thesecond time, however, I again took off badly, and fell in up to my neck. I should, beyondany doubt, have come to an untimely end, had I not, by the force of my own unaided arm,lifted myself up by my pig-tail, together with my horse, whom I gripped tightly with myknees.”
— The Adventures of Baron Munchausen [15]
Since the fictitious exploits of the dauntless Baron Münchhausen were first published over twocenturies ago, they have lost little of their original appeal. In the well-known episode printedabove, the baron hoists himself from a mire without any outside support, in complete defiance ofthe laws of nature. Separating user equipment (UE) and UICC by moving the card to a remoteserver, then letting the UE use that card to establish a mobile Internet connection over which theywill channel their APDU traffic may, at first, sound equally impossible. Yet this approach servesas the basis for the novel, location-privacy-enhancing system described in this chapter.
To avoid unnecessarily long and complicated sentences, the following default assumptions aremade: There exists a single mobile network operator (MNO) that provides a UMTS mobile net-work. The MNO’s subscribers represent the user base, with exactly one account per user. Eachuser has precisely one mobile phone, which they carry on them at all times and which is alwaysattached to the network using the USIM application on their personal UICC.
Also for brevity, I introduce the term subscriber identity (SI), which shall refer to either theIMSI or the account it identifies. It shall not refer to a person, the terms user identity or simply userwill be used in that case. The terms card switching and SI switching will be used interchangeably.
The system description is split into several sections as follows. Section 4.1 defines the adversarythreatening users’ location privacy and introduces the system’s defense mechanism. Section 4.2incrementally develops a system that allows users of a mobile network to seamlessly switch sub-scriber identities. Section 4.3 presents different SI switching strategies for increasing anonymityand location privacy. Section 4.4 explores the network properties that determine whether thesystem is compatible with a particular mobile network or not.
23
4.1 The Adversary and a Strategy for Defense
This section has two parts. The first one defines the goals and capabilities of the adversary, i.e.the entity who wants to prevent the users of the mobile network from achieving location privacy.The second part explains how frequent switching of shared UICCs can be used as a mechanism fordefending users’ location privacy.
4.1.1 Threat Model
The previous chapters described some of the interactions that take place between a subscriber’scellphone and the mobile network and how they allow placing the user within a particular area.The MNO may log any of these events, thereby recording the subscriber’s location history. Apartfrom curtailing their usage of mobile communication altogether, there is little that ordinary userscan do to prevent this collecting of their personal location information.
The adversary in this thesis shall be either a single MNO that is keeping comprehensive, times-tamped logs of subscribers’ interaction with the operator’s network infrastructure or an entitywith access to those logs. So the adversary can tell an IMSI’s location area or routing area forany arbitrary moment. While the phone is actively communicating over the mobile network, theIMSI’s current cell is revealed. Handovers between cells allow even more precise positioning basedon the cell borders. Further accuracy improvements can be achieved by considering users’ possibleroutes and velocities.
The adversary is assumed not to have access to signal strength data that might allow trian-gulation of phones. Targeted tracking measures like position fixing with radio resource locationservices (LCS) protocol (RRLP, [1, 55]) are ruled out, too. In addition, the adversary is assumednot to collect or to ignore available IMEI location data. This means that phones cannot be traceddirectly via their device identifier, but only indirectly based on the subscriber identities of usedUICCs. But, the adversary does know that some users may be trying to protect their locationprivacy by using the previously mentioned system. The functioning of that system is consideredpublic knowledge.
The adversary’s goal is to compile detailed and accurate mobility traces of all users. In caseswhere the user is anonymous, these traces might serve a dual purpose: as a location history and asan aid in exposing the user’s identity by cross-referencing the location data with other sources ofinformation.
Having defined the capabilities and motivation of the adversary, we can now move on to thequestion of how to protect the location privacy of mobile phone users against the specified threat.
4.1.2 Increased Location Privacy through Switching and Sharing of UICCs
If, besides having access to IMSI mobility traces, the adversary also knows the user identity of theperson using a particular SI, then the adversary is able to place the individual within a specific areaat any arbitrary moment. Thus, the location privacy offered by UMTS to identified users (againstthe described adversary) is mostly limited to blurring their location coordinates.
A general way to boost users’ location privacy is by increasing anonymity. One method re-ported on by [25] is swapping prepaid UICCs with other users. Participants who had sent in acard, received a randomly selected UICC provided by another user in return. While this scheme of-fers protection against linking subscriber identities to user identities and vice versa by mere lookupsin the MNO’s account database, it has the drawback of returning false hits to such queries. So auser might be wrongly blamed for the actions of somebody else.
This can be avoided by registering a prepaid account using a sufficiently credible made-up iden-tity, e.g. as described in [33]. Or users can forgo the need to provide identity information alto-gether by using so-called anonymous SIM cards issued by a mobile telephony provider whose local
24
t1 t2 t3
s1
s2
s3
s4
Time period
Subs
crib
er id
entit
y
Figure 4.1: An example for simultaneous subscriber identity switching of two users as seen by theadversary. Each map shows the surrounding cell of a subscriber identity during a specific timeperiod.
laws allow subscribers to register anonymously. International roaming agreements may permit theuse of such UICCs in more strongly regulated countries.
In these approaches, the subscriber identity functions as a pseudonym. Although this is a steptowards greater anonymity and thereby increased location privacy, both methods suffer from thesame problem: Each SI is used exclusively by a single user over a prolonged period of time.
Hence, pieces of spatio-temporal information about a user are likely to fall into the time pe-riod during which he or she was using a particular UICC. It follows from [37], that only few suchdata points are necessary to match a user to an SI location trace with a high probability of cor-rectness. So, identifying anonymous users might require only little additional information. Oncede-anonymized, the adversary could keep tracking the users until the next time they switched to adifferent subscriber identity, which, in the above approaches, would be never.
Frequently switching subscriber identities with other users, while keeping the current user ofan SI a secret, might fix these shortcomings. Firstly, this should make it harder for the adversaryto reconstruct complete location traces because each user’s location history would be partitionedand spread across multiple subscriber identities.
Secondly, correctly matching user identities and SIs for a given moment should be more diffi-cult as well. Figure 4.1 provides a simplified example of two users A and B entering the same cell atthe beginning of time period t2 and then simultaneously switching to a different SI at the start oft3. Note that knowledge of either A’s or B’s location during t1 is sufficient for matching SIs s1 ands2 to the users with absolute certainty. However, the probability of correctly matching s3 and s4,the SIs active during time period t3, is only 50 %. So, linking users and subscriber identities duringt3 is made harder by the preceding SI transitions.
This example also shows that the usefulness of finding a correct matching would be limitedto the time interval during which the matching existed, provided that the user’s preceding andsubsequent SIs cannot be deduced.
So, in summary, frequently switching subscriber identities and sharing them with other usershas the potential to increase the location privacy of mobile network users. The next section de-scribes an automatic, location-privacy-enhancing system based on this approach.
4.2 System Design
This section incrementally develops a system for increased location privacy in mobile networksthat enables users to connect to the network with a subscriber identity from a shared set of SIs andthat allows automatic switching to a different identity at any moment. The design is based on thefollowing technical goals:
• Full compatibility with existing network infrastructure and protocols
25
MIMmodule
Cardserver
Smart cardreader
UICC
Internet
UE
UICC terminal
Card client app Forwardingnetwork
MIM-Ainterface
MIM-Binterface
Card client side Card server side
Figure 4.2: Generic card service client-server architecture
• Compatibility with a wide range of smartphones and mobile operating systems• No modifications of existing UE hardware and firmware• Avoidance of low-level software changes whenever possible• No manual intervention is required during operation
4.2.1 System Architecture and Basic Functioning
Building a system for SI switching on top of existing UMTS infrastructure without assistancefrom the MNO entails specials challenges due to the way subscriber identities are authenticatedin the network (see Section 2.2.2). Since the secret key K cannot be read from the UICC and isindispensable for computing the UE’s authentication response, all prospective users of a particularSI, or rather their mobile phones, must be able to communicate with the associated card. Thismotivates the client-server architecture shown in Figure 4.2, which moves the UICC away from theuser equipment and places it on the server side. I propose a single server or cluster of coordinatedservers which use off-she-shelf peripherals for managing and accessing a shared pool of UICCs.On the client side, there are two hardware components: a smartphone – the UE – and the MIMmodule4. The primary responsibility of the MIM module is relaying APDUs between the phone’sUICC terminal and card client app that runs on the UE. The client app requests a UICC from theserver and, in the most basic implementation, simply forwards all command APDUs sent by theterminal to the server for processing by the assigned card. The UICC’s response APDUs take thesame path in the reverse direction. Figure 4.3 shows the transparent transmission of APDUs fromthe application and CAT layers by the intermediate components.
The client side requires a more detailed presentation. The two interfaces between the MIMmodule and the UE are labeled MIM-A and MIM-B respectively. MIM-A is a physical interface,comprising the RST, CLK, GND, and I/O lines of the UICC terminal. VCC is not included,as the MIM module is assumed to have a separate, continuous power supply. The synchronousconnection used by the UE’s terminal for transmitting characters is terminated at the MIM module.This way, communication over the remaining hops are not bound by the terminal’s clock signal,which allows both faster and more simple, asynchronous transmissions. Since the beginning of theanswer to reset (ATR) must reach the terminal shortly after the reset signal, the timely transmissionof the ATR is also handled by the MIM module. The MIM module should choose protocol T=1 forexchanging APDUs with the terminal, because the alternative transmission protocol T=0 is morecomplicated to implement, offers less powerful error detection, and because its error signalingmethod might require special transceiver hardware. To avoid unnecessary forwarding of wholeblocks, the MIM module should also act as the protocol T=1 card-side endpoint, unwrappingcommand APDUs from incoming I-blocks and doing the opposite with response APDUs returnedby the UICC.
4The neologism “MIM” is a blend of the more or less germane abbreviations SIM and MITM, short for man-in-the-middle.
26
UE UICCterminal
MIMmodule
UE cardclient app
Cardserver
Smart cardreader
UICC
PC/SCstack
ProtocolT=0
orT=1
ApplicationCAT
ProtocolT=1
MIM-Btransportprotocol
stack
Cardservice
protocolTCP
ProtocolT=0
orT=1
ApplicationCAT
MIM-Ainterface
MIM-Binterface
Forwarding networkand Internet
Figure 4.3: Protocol stacks of basic card service implementation. Only layers corresponding toOSI model layer 4 and above are shown. (PC/SC does not represent protocols, but standardizedsoftware and hardware interfaces.)
The MIM-B interface connects the MIM module and the card client app. Since the protocolstack used by these two components is very implementation-specific, its description here shallremain abstract. Chapter 5 presents a fully specified implementation. The used stack must fulfilltwo requirements. One, it must guarantee the reliable bidirectional transmission of APDUs. Andtwo, the MIM module must be able to reliably inform the client app about reset signals from theterminal. When the reset signal reaches the card client app, the app may request a switch to adifferent, freshly-reset UICC from the server.
The communication protocol used by the client app and the server shall be called card serviceprotocol (CSP). Since the hosts communicate over IP-based networks, variants of TransmissionControl Protocol (TCP) can be used to ensure reliable transmission of CSP messages. Figure 4.2shows that the UE is not directly connected to the Internet, but to a forwarding network, whichmay be either a WLAN or a GPRS-based IP network. While relying on WLAN, the users’ free-dom of movement is obviously very restricted. Enabling cellphone users to move around freely,without severing the link between the UE’s terminal and the card, can only be achieved with mo-bile data services. But establishing a PDP context with GPRS requires access to a UICC for themutual authentication procedure, which the network will most likely demand. Using a mobileInternet connection established with a local UICC to speak with another UICC located at theserver would defeat the purpose of the system. Therefore, the following initialization procedure,proposed by M. Waldvogel (2013, pers. comm.), is used. First, the client obtains access to a UICCfrom the server, with a WLAN as the forwarding network. Then the UE establishes a parallelInternet connection over GPRS, using the assigned card for authentication. The client finishesthe initialization procedure by opening a second CSP connection, this one routed over the GPRSnetwork, which also grants access to the allocated UICC. The client may now disconnect from theWLAN and close the first CSP connection. After these steps, all future APDU traffic is sent overthe mobile data network. It should be noted that for this procedure to work as described, both themobile device and its operating system (OS) must support parallel data connections over differentnetworks. This is not always the case for standard smartphone OS versions, so customization maybe necessary.
If the UE has just one UICC terminal, then card switching is only possible with a WLANacting as a forwarding network. Assuming that the UE is configured to automatically initializethe USIM application and establish a PDP context when a UICC is plugged into the terminal,then the card client app might be able to trigger a card switch by issuing a card application toolkit(CAT) REFRESH command in UICC Reset mode by altering the flow of APDUs. When used inconjunction with a change of the assigned UICC, this would lead to a controlled deactivation ofthe old card followed by an ordered activation of the new one.
27
The system described so far only allows card switching when a WLAN is available, becausedeactivation of the old UICC terminates the associated PDP context. So, without the WLAN toserve as a forwarding network, the client cannot connect to the new card. Mobile card switching,i.e. switching without a WLAN, requires a UE that can maintain a GPRS-based Internet con-nection established with the old card until the new forwarding network has been set up. Thisprocedure comprises the following steps, all of which relate to the new UICC:
1. Open a CSP connection to a new UICC and associate it with an available terminal.2. Perform the UICC activation procedure.3. Perform the USIM session initialization procedure.4. Attach to the PS domain of the mobile network.5. Establish a PDP context. (It will serve as the new forwarding network.)6. Open a parallel CSP connection to the new UICC and close the connection opened in step 1.
At this point, the old UICC and the associated GPRS connection are no longer needed, so the oldcard that is linked to the other terminal can be released as follows:
7. Open a parallel CSP connection to the old UICC over the new forwarding network.8. Close the original CSP connection to the old UICC.9. Perform the USIM session termination procedure. (This includes the termination of the old
PDP context and the detachment from the old mobile network.)10. Perform the UICC deactivation procedure.11. Close the CSP connection established in step 7.
Thus, the periods during which the UE is attached to a mobile network with the old and thenew SI respectively overlap. Another difference to WLAN-based switching is that the terminalsalternate between being connected and not being connected to a UICC. This rules out triggeringcard resets with CAT commands, because proactive commands can only be issued by an activatedUICC application. Therefore, the client app requires access to API methods that control the abovesteps.
Not all UEs with more than one UICC slot are suitable for mobile card switching; a so-calleddual SIM dual active (DSDA) device is required. DSDA designates a UE with two UICC terminalsand two independent radio transceivers, which allow simultaneous CS and/or PS calls over twomobile networks.
Since each switch to a different UICC goes along with a change of the mobile phone number,keeping callers up to date about the cellphone numbers at which particular users can be contactedwould be difficult. But that problem could be circumvented easily by using a call forwardingservice linked to the card server. The service could provide a fixed phone number for each user andforward incoming calls to the user’s current mobile phone number. Outgoing calls would need nospecial handling.
Due to the deactivation of the old UICC, a card switch would deactivate ongoing CS calls. Sodisabling card switching while making phone calls would lessen the negative impact of the switch-ing system on normal phone use at the expense of potential gains in location privacy. SwitchingUICCs would also affect PS connections, but the used, PS-based services could be designed to ac-commodate clients with alternating IP addresses. Voice chat services with this feature may be asuperior alternative to circuit-switched voice communication, because phones could switch to anew card without terminating ongoing calls. Using a third-party system for communication in-stead of relying on the CS infrastructure of the MNO, would have the additional benefit of hidingthe contact details of a user’s conversational partners, thereby preventing the use of that informa-tion for user identification.
28
4.2.2 Virtualization for Improved Performance and Reliability
Although the system as described so far already offers the desired SI switching functionality, thereis still room for improvement. The physical separation of the terminal and the UICCs increaseslatencies and the necessity of routing APDUs over the mobile network and the Internet means thattheir timely delivery cannot be guaranteed. The latency issue is especially pronounced during thecard activation and USIM initialization procedures, which require the exchange of about 50 and 300command-response pairs, respectively5. So the initialization procedure for a remote UICC wouldtake at least those approximately 350 client-server round trip delays (RTDs). Since the respectiveaverage size of command and response APDUs sent during initialization is less than 9 and 32 bytes,transmission over TCP/IP also results in relatively large protocol overhead.
Latencies may easily become a critical problem. If the UE does not receive a response APDUwithin the allotted time frame, it will judge the UICC as unresponsive and trigger a card reset.Similarly, the mobile network may detach an SI and the associated UE, if the UE fails to respond intime to certain commands. This means that every command-response pair that has to be exchangedbetween client and server represents a potential point of failure. Hence, even short-term losses ofconnectivity, e.g. due to spotty radio coverage, may lead to an unordered deactivation of a UICC.
In addition to their primary purpose, the UE also uses command APDUs for checking thecontinued presence and responsiveness of the UICC. When the USIM application is active and theterminal has the right to transmit, at most 30 seconds of silence are permitted on the I/O line. TheUSIM may specify even shorter periods with CAT commands. If the UE has no other instructionsto send to the card, then the terminal is supposed to periodically issue a STATUS command, whichmust be answered within 5 seconds.
By maximal virtualization of UICCs in the card client app, both the total number as well asthe number of time-critical transmission between the client and the server can be minimized. Thiseliminates unnecessary delays and increases the reliability of the system. Instead of forwardingcommand APDUs to a physical UICC located at the server, a virtual image of the assigned cardmay processes the commands and return appropriate response APDUs. Only functionality basedon the user-readable file system can be virtualized reliably (assuming no cooperation from the cardissuer). This excludes card behavior based on CAT and the handling of AUTHENTICATE commands.The former is not essential and can therefore be omitted without affecting system functionality.But the commands for subscriber authentication have to and can only be answered correctly bythe USIM application of the physical card.
This leaves just three kinds of card-related exchanges between the client app and the card server,one for each of the following tasks: transfer of a UICC image to the client, subscriber authenti-cation, and transfer of a UICC image back to the server. The first transmission of a card imageoccurs when the server assigns a particular UICC to the client app; with the received data, theclient can create a local virtual instance of the UICC. Since the image can be sent as a single chunkof data, the lower time limit for the whole exchange is one client-server RTD plus the incurredpacket transfer delay. The same applies to the transmission of the UICC image in the reverse direc-tion, following the client’s deactivation of the virtual card. In either case, the transmission of thecard image is not time-critical; connectivity problems can only lead to an undesired deactivationof the PDP context and the card, when they interfere with the mutual authentication procedure.Therefore, maximal virtualization of the UICC in the client app leads to a considerable increasein the system’s reliability. And because almost all command APDUs are answered directly by thevirtual card, the response times for those commands are reduced by at least one client-server RTDcompared to the basic design.
5These numbers were obtained with the UE specified in Chapter 6 connecting to a 3G network. The figure forUSIM activation includes APDUs for PDP context activation.
29
4.3 Switching Strategies
The previous section described a system that supports switching of subscriber identities even whilebeing on the move and without access to a WLAN connected to the Internet. What is still missing,is a characterization of when and how to use this capability for mobile card switching in order toincrease location privacy. This section describes several strategies for SI switching, starting with arealization of a pairwise swapping approach and pointing out its fundamental problems. Based onthe insights gained from this analysis, I then propose three viable approaches for SI switching thatare possible with the described system. A summary and comparison of these techniques concludesthe section.
4.3.1 Naive, Pairwise Swapping of Subscriber Identities
One obvious strategy for switching pseudonyms in a setting with multiple mobile nodes is tohave any two meeting nodes swap their current pseudonyms. This idea forms the basis for Path-Forge [11], which requires a cooperating MNO and changes to the existing, stationary infrastruc-ture. The system presented in this chapter does not have either of these prerequisites. Pairwisepseudonym swapping is characterized by a short distance between the nodes during the encounterand the involvement of just one pseudonym per node. The approach is aimed at avoiding suddenappearances, disappearances, and jumps (i.e. unnaturally fast movement) of identities, to preventthe adversary from detecting pseudonym switches and from determining the set of pseudonymsavailable to users of the system.
With minor modifications, pairwise identity swapping can be realized with the described sys-tem. Table 4.1 lists the steps of an SI swapping procedure for pairs of meeting card clients. Thesequence uses a slightly improved method for exchanging UICC images – clients pass them ondirectly to their respective peer without involving the card server. However, server access is stillnecessary during the card initialization procedures, since the network might require authenticationof subscriber identities. With just two SIs, one of the clients – client B – has to depend on the otherone to communicate with the physical UICC. This puts client B at risk of ending up without aPDP context and without an SI, should the procedure fail between steps number 5 and 11. A likelycause for such a failure would be a loss of the wireless connection.
Pairwise SI swapping for card clients is not only unreliable, it also fails to meet the desiredobjectives. Although the strategy guarantees that all SIs move on continuous paths, it cannotprevent the telltale PDP context activation that occurs during each card initialization procedure.Since normally PDP contexts are relatively long-lived – the network usually deactivates a contextonly after a prolonged period of inactivity – and assuming that frequent SI switching is necessary toachieve a desired degree of location privacy, the activation of a PDP context with a UICC from thecard server generally indicates an SI switch. And the adversary can easily distinguishing betweenSIs used by regular subscribers and those managed by the card service based on the number of PDPcontext activations – it should much higher for the latter group. Moreover, SIs shared by multipleusers should also display conspicuous mobility patterns. Compared to a card with a single user,they should on average move more frequently, travel back and forth instead of following the fastestroutes towards destinations, visit a greater number of places, and stay put for shorter periods.
It should be noted that the inability to conceal switching events and the failure to keep theSIs used by the card service a secret are a result of the system and SI switching in general. Noswitching strategy can overcome those limitations. Yet, this does not excuse the reliability issues ofpairwise SI swapping. The other strategies for SI switching presented in this section stipulate thateach mobile phone always has to maintain at least one PDP context for critical communicationwith the card server.
30
StepNo.
UE / Card client
A B
Has PDP context with SI α. Has PDP context with SI β.
1 Mutual presence detection and establishmentof a short-range wireless connection for com-munication (e.g. via Bluetooth).
2 Sends IMSI of α to B.
3 Sends IMSI of β to A, thereby con-senting to swap.
4 Deemsβ acceptable and sends swapcommand to B.
5 Detaches β from mobile networkand deactivates the associated card.Network deletes PDP context.
6 Sends image of virtual UICC βto A. (Clients avoid unnecessary ex-changes with the card server.)
7 Performs initialization procedurefor UICCβ using the existing PDPcontext as forwarding network.
8 Detaches α from mobile networkand deactivates the associated card.Network deletes PDP context.
9 Sends image of deactivated virtualUICC α to B.
10 Performs initialization procedurefor UICC α. The wireless connec-tion to A and A’s PDP context serveas forwarding network.
11 A and B close their wireless connection.(Optional step.)
Has PDP context with SI β. Has PDP context with SI α.
Table 4.1: Sequence of events for naive, pairwise subscriber identity (SI) swapping
31
4.3.2 Improved SI Switching Based on Direct Encounters
During the presentation of the swapping-based SI switching strategy it has become clear, that at-tempts to make the SIs used by the card service act normally, i.e. like an SI used exclusively by oneperson, are ultimately futile. So there is little reason to reject switching strategies on the groundsthat they lead to card transitions accompanied by appearances, disappearances, and jumps of SIs.Therefore, with regards to the selection of a client’s next SI, all available UICCs from the server’spool of cards are considered as equivalent. Restricting the selection based on the time and place anSI was last active would not benefit location privacy. Therefore, the remaining SI switching strate-gies presented here all have the following two things in common: One, the card server assigns arandomly selected, free UICC to any client who wants to switch to a different SI. And two, eachclient uses its own, existing PDP context as forwarding network during the initialization proce-dure for the new card, as described in Subsection 4.2.1. With these commonalities in mind, we canmove on to the specifics of the next SI switching strategy.
Having meeting card clients swap their SIs turned out to be a flawed idea, but that does notnecessarily hold for proximity-based SI switching in general. If two clients switched to a new SIwhile being connected to the same cell and if the old PDP contexts were deactivated only afterthe card initialization procedures for both new SIs were finished, then the adversary could not tellwith certainty which old and new SIs were used by the same client. (Actually, due to the partialoverlap of neighboring cells, the adversary might be equally confounded by parallel SI switchesinvolving adjacent cells.) Since clients that are close together can usually meet these requirementsby changing UICCs in a coordinated manner, SI switching triggered by direct encounters mightbe an effective strategy for increasing location privacy. As in the previous swapping approach,clients could detect each others presence and coordinate their actions through short-range radio.This would limit the encounter radius – the maximum distance between two nodes that wouldstill allow them to reliably perform coordinated, simultaneous switching operations – to a fewmeters. Then again, putting the clients in charge of detecting their encounters sidesteps the needfor a central instance handling that task.
The meeting clients would not have to stay in contact until the switching operations havefinished. Their coordination efforts could be limited to agreeing on performing a synchronized SIswitch and choosing a time until the old GPRS connections must be maintained. This time mightbe easily determined based on the expected execution time of the necessary procedures.
4.3.3 SI Switching Based on Cell-Level Encounters
The short encounter radii of the two previous switching strategies might lead to an insufficientnumber or encounters in some scenarios. Especially if clients tend to be sparsely distributed, strate-gies based on direct encounters might trigger too few simultaneous card switches to adequatelyprotect the location privacy of all users. Besides, there might be a lot of missed opportunities forprivacy-enhancing switching, when two clients are connected to the same cell, but never get closeenough to notice each other’s presence.
SI switching based on cell-level encounters addresses these issues by introducing the switchingmanager, a component on the server side in charge of coordinating all card switches. The switchingmanager needs to know the whereabouts of all clients. At the least, they have to disclose their cur-rent cell. This allows the use of cells as mix zones; either some or all of the clients simultaneouslyconnected to the same cell could switch to new SIs in a way that would make user tracking moredifficult for the adversary. This thesis focuses on pairwise cell-level switching, i.e. encounters arelimited to two clients.
Cell-based switching can lead to obvious SI transitions, i.e. the correct matching of old tonew SIs might be readily apparent, because only one of the combinations is possible assumingrealistic travel velocities. If provided with more precise location information, i.e. more specific
32
than a client’s current cell, the switching manager might be able to predict and skip unpromisingswitches.
The need of clients to keep the switching manager apprised of their current location has anundesired side effect. Assuming that the update messages are sent over a mobile data connection,the MNO can log the cells from which those messages are sent. So, the adversary is provided withlocation data that shows all cell transitions of the used SIs, which might facilitate SI matching.
4.3.4 Autonomous SI Switching
All of the switching strategies presented so far require at least two cooperating clients that arerelatively close to one another. A card client switching on its own was pointless, since the adversarycould have easily attributed the disappearing, old SI and the appearing, new SI to the same (justindirectly visible) client. However, that is only because both SIs were assumed to have been issuedby the same MNO and used for connecting to the same mobile network. If the new SI came from adifferent MNO and was used to connect to a different network, then the client would pass from theview of any adversary who only has location data of the old network at his or her disposal. (Notethat each adversary is assumed to only have access to location information collected by a singleMNO.) Due to the limited number of carriers in any particular region of the world, the client canbe expected to eventually switch back to the original network. The adversary would then be facedwith the problem of having to match disconnected paths to reconstruct at least a partial locationhistory of the user. Computing the likely locations of clients while they are disconnected from themonitored network would probably be helpful in matching the visible path segments, but that isout of the scope of this thesis.
Autonomous SI switches could be triggered by various kinds of events; triggers based on users’movements or on time would be obvious choices. Movement-based events that might be used ascause for an SI switch are: exceeding a fixed or random movement distance threshold, or enteringone of many strategically positioned and shaped switching areas.
This thesis focuses on autonomous SI switching triggers that are based on time. Two variantsare presented. In the first one, clients switch SIs according to a shared schedule. The second variantis based on individual, random delays with a geometric distribution.
Schedule-Based Switching
In schedule-based SI switching, network switches take place during non-overlapping, non-adjacent,predetermined time slots. The slots are defined by a time window and a target network. Whenthe next time slot is reached, each client randomly picks a moment from the specified intervalaccording to a uniform probability distribution. At that moment, the client start switching to thedesignated mobile network.
The purpose of the time windows is to avoid overwhelming the card server and the mobile net-works with too many simultaneous requests. And since the moment when a client starts switchingis random, is cannot be used for identification.
In case of more than two available mobile networks, the clients should alternate between themin cyclical order, to maximize the length ot the time periods spent disconnected from each networkand thereby impede SI matching by the adversary.
Schedule-based switching can guarantee that SIs are only used for a limited time and it preventsinferences about correct matchings based only on time. However, it also permits narrowing downthe area in which the user of an old SI will reappear when returning to a particular network. Thismay greatly facilitate matching SI paths, because the problem might be decomposed into multiple,much simpler subproblems that only require matching small subsets of the vanishing and appearingSIs. The second autonomous SI switching variant addresses this issue.
33
Switching Based on Geometrically Distributed Delays
In autonomous SI switching based on geometrically distributed delays, the length of the time peri-ods spent connected to a particular mobile network is not determined by a shared schedule, but bya client-specific random process. This means that clients switch networks independently, thoughin to the same cyclic order. Switches may only happen at specific, equally spaced moments. Letp < 1 denote the constant probability that a particular client switches to a different SI and net-work at any specific moment. Then the probability P(X = k) that the next switch occurs at thek-th moment after the client started using a particular SI is given by the following formula:
P(X = k) = (1− p)k−1 p for k = 1,2,3, . . . (4.1)
The expected value of the number of moments until a client’s next switch can be expressed as:
E(X ) =1
p(4.2)
Thus, for N ≥ 2 available mobile networks, the expected value of the number of moments untila client returns to a particular network that is has just left is (N − 1)/p. But the actual momentof return cannot be predicted. Moreover, for N = 2, the universality of p makes all clients thathave left a particular network in the past and that have not returned in the meantime equally likelycandidates for switching to an appearing SI, irrespective of how long ago they have left. For N > 2,some differences do arise, with higher return probabilities for clients that have left the revisitednetwork longer ago. But the knowledge the adversary might gain from these differences may beoffset by the clients’ longer absence from the monitored network.
Finding an acceptable value for the parameter p may be difficult. It should be small enoughto lead to long absences, to make SI matching harder, yet large enough to avoid overly long staysin any single network, lest continuous SI traces contain sufficient specific location information foruser identification.
4.3.5 Comparison and Summary of Switching Strategies
This section described four types of strategies that card clients can use for subscriber identityswitching. Pairwise SI swapping by meeting clients, aimed at avoiding sudden appearances, disap-pearances, and jumps of SIs, was shown to be unreliable; a breakdown of the short-range wirelessconnection between the two clients involved in a swapping operation might leave one of themwithout access to a UICC. Therefore this approach does not seem viable and will not be taken intofurther consideration.
The remaining strategies have in common, that clients release their previous UICC only afterthey have activated a PDP context with the new card, which is randomly selected by the server.Table 4.2 compares these three strategies. SI switching based on direct encounters is likely to missmany opportunities for anonymity-enhancing switching. A cell-based approach was presented thataddresses this issue, but it requires clients to share current location information with a server-sidecomponent responsible for triggering switches. Both strategies rely on simultaneous, coordinatedswitching to make matching old and new SIs of clients more difficult for the adversary. The au-tonomous SI switching strategy uses a different approach: making clients seem to intermittentlydisappear by having them switch between multiple mobile networks.
Assuming that all server-side components of the system are controlled by a single entity that isalso aware of users’ true identities, then the cell-based strategy would put both a user’s identity andlocation data into the same hands. The operator of a service for protecting the location privacy ofmobile phone users may very well be more trustworthy than any particular MNO, nonetheless,any confluence of users’ identity and mobility data is a potential threat to their location privacy.
34
Name Switching trigger Client’s locationinfo. shared with
Based onnetworkswitchingother clients server
SI switching based ondirect encounters
Detection of nearby peervia short-range wirelesstechnology
Yes(implicitly)
No No
SI switching based oncell-level encounters
Signal from server when(two) clients report beingconnected to the same cell
No Yes No
Autonomous SI switching Scheduled events ortimeouts with geometricdistribution
No No Yes
Table 4.2: Comparison of reliable SI switching strategies
With the other switching strategies, these two types of user data can be kept entirely separate –the card service operator knows only about user identities and allocated SIs, whereas the mobilenetwork operator knows only SI location histories.
If not sharing personal location information with the server side is indeed an objective, thensome EFs of the virtual UICC must be cleared, before its image is returned to the card server afterthe deactivation of the card. This pertains to both EFLOCI and EFPSLOCI. When deactivatingthe USIM, the UE is supposed to store the subscriber’s current temporary identifiers (TMSI andP-TMSI) along with the identities of the associated location area and routing area (LAI and RAI) inthese files, as shown in Figure 2.7 on page 12. Thus, card switching without clearing EFLOCI andEFPSLOCI would disclose coarse user location information to the card server.
If the contents of these files is deleted, then the next client using that UICC will be forced toattach to the network by sending the card’s IMSI over an unencrypted channel, which might beintercepted by a local adversary who monitors the network’s radio frequencies. But since UICCsare assigned randomly, the IMSIs cannot be used for re-identification and tracking of specific users,i.e. the random assignment of cards serves the same purpose as temporary subscriber identities.
4.4 Compatibility with Existing Cellular Technologies
Section 2.2.2 described how the MSC and the SGSN may trigger an authentication of the USIMand a switch of the cryptographic keys used for confidentiality and integrity protection of messagesin the CS and PS domain respectively. The procedure is split into two parts: authentication andkey agreement (AKA), followed by an exchange of messages during which both the UE and theRNC start using the new keys. AKA involves an AUTHENTICATE command from the UE, which canonly be answered correctly by a physical UICC. The presented card switching system must be ableto reliably transfer that command and the USIM’s response over GPRS, even when the networkdemands an authentication and a change of keys for the packet-switched domain. Figure 4.4 showshow this requirement is met, due to the separation of key establishment and key activation.
Since the old ciphering and integrity keys CK and IK remain in effect during AKA, the AU-THENTICATE command-response pair can be transmitted over GPRS without difficulty, assumingthat the old key set is available to the serving RNC. During the key activation procedure, no morecommunication with the remote UICC is necessary, so the switch to the new keys is unaffected bythe use of the card switching system.
Non-3G mobile networks may not support the execution of the authentication procedure with
35
Aut
hent
icatio
n an
dke
y ag
reem
ent
Card server/UICC/USIM
UE SGSNRNC
User authentication request
AUTHENTICATE response
AUTHENTICATE command
User authentication response
Select new CK and IK
Security mode commandCK, IK
Verifiy commandwith new IK andswitch to new IK
Security mode command
Switch to new CK
Switch to new IK
Security mode complete
Switch to new CK
Act
ivat
ion
of n
ew ci
pher
ing
and
inte
grity
key
s
Select new CK and IK
Figure 4.4: 3G GPRS Security procedures with a remote UICC
a remote UICC. For example, GSM may be operated in either of two modes, classical A/Gb modeor Iu mode. Iu mode is modeled after UMTS, i.e. in the PS domain a variant of AKA is usedfor subscriber authentication as well as ciphering key agreement6, and a subsequent security modecommand triggers the switch to the new key. In GSM in A/Gb mode, however, both sides startciphering with the new key in a staggered fashion, as shown in Figure 4.5. The SGSN startsencrypting and decrypting messages with the new ciphering key immediately after sending theauthentication and ciphering request. So the UE and the SGSN are using different keys until theUE has sent the authentication and ciphering response. Both sides use retransmission to avoid theloss of user data, assuming that the USIM will eventually compute the new ciphering key for theUE. But if the UICC were located at the card server and could only be accessed via GPRS, thenthe UE would have to wait indefinitely for a response, resulting in an unsuccessful authenticationprocedure.
6GSM does not support authentication of the network and digital signing of the messages sent over the air.
36
UICC/USIM SGSNUE
AUTHENTICATE command
Authentication and ciphering request
Authentication and ciphering response
AUTHENTICATE response
Start ciphering anddeciphering withnew ciphering key
Start ciphering anddeciphering withnew ciphering key
Figure 4.5: Authentication procedure in 2G GPRS
37
Chapter 5
Implementation
This chapter describes a proof-of-concept prototype of the system architecture depicted in Fig-ure 4.2 on page 26. Thus, the reader is expected to be familiar with the pertinent aspects of theprevious chapter. The goal behind the prototype’s development was to explore the feasibility ofconnecting a cellphone’s card terminal to a remote UICC via mobile Internet access gained withthe card’s USIM. Therefore, just one phone and one UICC were used. The virtualization of cardsin the client app and the automatic switching of UICCs were not implemented.
This chapter is organized as follows: Section 5.1 offers a brief description of the server-side im-plementation and of the communication protocol used by the card client app and the card server.Section 5.2 describes the prototype’s client side and Section 5.3 presents a semi-manual card initial-ization procedure, after which WLAN access is no longer required.
5.1 Card Server Side and Card Service Protocol
The server prototype is composed of one of each of the server-side elements depicted in Figure 4.2,i.e. one server (hard- and software) connected to a smart card reader with a single UICC. Theserver software is written in Java, which allows the sharing of code with the client app. Moreover,the language provides the Java Smart Card I/O API for exchanging APDUs with ICCs, when usedin conjunction with a PC/SC7-compliant smart card reader. The reader used by the prototype isan SCM SCT3511, which is intended for plug-in-UICC-sized integrated circuit cards.
Since the UICC is used exclusively by a single client, there is no need for elaborate sessionmanagement. The server accepts one card service protocol (CSP) connection at a time, which maybe used for sending command APDUs to and receiving response APDU from the card. The clientautomatically reestablishes contact with the server, whenever the current CSP connection is nolonger working.
5.2 Card Client Side
Chapter 4 introduced the MIM module, which relays APDUs between the phone’s UICC terminaland the card client app, sends ATR messages, and informs the client app about card reset signalsfrom the terminal. But the description of the MIM module and of its interactions with the otherclient-side component skipped over some significant details by focusing on the bigger picture. Thedescription of the prototype in this section fills these gaps. However, it should be noted in advance,that not all aspects of this implementation would be suitable for an actual card service system aspresented in the previous chapter.
7Personal Computer/Smart Card (PC/SC) is an open standard for using ICCs in a PC environment, which is sup-ported by many smart card readers.
39
Client Side Overview
Figure 5.1 shows a schematic representation of the major hard- and software components of theclient side prototype. The design is a refinement of the basic system architecture depicted in Fig-ure 4.2. Figure 5.2 shows a picture of the MIM module prototype.
At the heart of MIM module is an Atmel SAM3X8E microcontroller, which executes theMIM module firmware – custom software that handles all incoming messages and signals. Thefirmware relies on two built-in hardware components of the microcontroller for transmittingand receiving messages. A universal synchronous/asynchronous receiver/transmitter (USART)is used for communicating with the phone’s UICC terminal, whereas a universal asynchronous re-ceiver/transmitter (UART) is employed for communication with the card client app. The SAM3X8Eis part of an Arduino Due. This platform offers convenient access to the chip’s contacts, permitseasy flashing of the firmware, and can be powered over USB.
The other two main components of the MIM module – the (slave mode) HC-06 Bluetoothmodule, and the circuit for level shifting and I/O splitting/joining – draw their power from theArduino. The HC-06 acts as a bridge between the Bluetooth radio of the UE and the UART ofthe SAM3X8E. The aforementioned electrical circuit connects the phone’s UICC terminal to theArduino’s microcontroller, performing bidirectional voltage level translation and other functions.Detailed information about the level shifting circuit and about how it and the Bluetooth moduleare connected to the Arduino is provided in Appendix A.
The UE is a Motorola Moto G (2nd Generation) running Android 5.0.2. It operates up to twomini-UICCs in class C, i.e. at 1.8 V. Since there is just one UICC on the server side, the MIMmodule is only connected to one of the phone’s two terminals. A reworked adapter cable of anOsmocomb SIMtrace [40] links the two sides.
MIM-A Interface and MIM Module Firmware
As described in the previous chapter, the MIM-A interface comprises the following lines: I/O,CLK, GND, and RST. The first three play a role in the synchronous transmission of characters,the last two are needed for sending the card reset signal. Since the terminal’s nominal voltage of1.8 V is below the 2 V threshold voltage of the SAM3X8E’s contacts, the microcontroller cannotdistinguish between the high and low states the terminal imposes on the interface circuits. If wiredincorrectly, the 3.3 V used by the microcontroller might even damage the UE. Figure A.1 onpage 72 describes the electrical circuit that safely connects the terminal and the Arduino, translatingvoltage levels as needed. For CLK, RST, and GND, this is relatively trivial. The I/O line requires amore elaborate solution, because it is used for transmissions in both directions. Unlike the UICCterminal, the USART uses separate pins for sending and receiving characters. But since signals fromthe USART’s transmitter are echoed to the receiver, the receiver is deactivated during outgoingtransmissions.
The level-shifted signal from RST is fed to the Arduino’s reset pin. While the voltage stateis low, the microcontroller keeps constantly resetting itself. So, execution of the MIM modulefirmware starts only after the reset signal, continuing as long as RST stays in state H, i.e. as longas the terminal does not perform the card deactivation or reset procedure. Due to the turn-takingin protocol T=1, the firmware can handle all commands and responses in a continuous thread,without having to respond to any externally triggered interrupts besides the one causing the mi-crocontroller reset. The state diagram shown in Figure 5.3 describes the behavior of the MIMmodule firmware. If the MIM module served both card slots, then resetting the microcontrollerin response to a reset signal from one terminal might interfere with the processing of messagesassociated with the other one. Therefore, using the signal on RST for triggering resets of the MIMmodule’s microcontroller is unsuitable for the production environment.
Figure 5.4 shows the protocols and modes of transmission used on the client side for transport-
40
UEwith Android OS
Bluetooth-based MIM module
Atmel SAM3X8E
Arduino Due
HC-06 Bluetooth module
MIM-AInterface
MIM-BInterface
UICC terminal Circuit for level shiftingand I/O splitting/joining
UART
USART
MIM modulefirmware
Bluetooth radio UART
Card client app
Bluetooth radio
Figure 5.1: Major components of the client-side implementation. Rectangles with rounded cornersrepresent custom hard- and software components.
Figure 5.2: Picture of the MIM module prototype
41
Reset Embed the block ina MIM-B protocolmessage and transmitit with the UART
Receive a MIM-Bprotocol messagecarrying a responseblock with the UART
Send ATR viathe USART andnotify the card clientvia the UART
Receive a blockcarrying a com-mand APDU withthe USART
Forward the response block with the USART
Figure 5.3: Simplified state diagram of the MIM module firmware
ing messages. Contrary to the design proposed in the previous chapter, the protocol T=1 cardside endpoint is located in the client app, not in the Arduino’s microcontroller. This simplifieddevelopment, but the transmission of blocks instead of only APDUs means that more bytes aresent over the MIM-B interface.
The MIM module firmware was programmed in C. Atmel Software Framework libraries pro-vided direct access to the hardware registers of the SAM3X8E. This was necessary for many taskssuch as configuration of the USART, sending, receiving, and timing of delays.
To avoid changes of the transmission parameters on the MIM-A interface, the MIM moduledictates continued usage of the default values in the ATR. Hence, 1 etu = 372/ f and f ≤ 4 MHz,resulting in a maximum net bit rate of approximately 7168 bits/s to and from the terminal. Theseparameter values were also chosen in the hopes of maximizing the block waiting time (BWT)and thereby giving the upstream components as much time as possible to process the terminal’scommands without being deemed unresponsive. However, even though the resulting BWT of theprotocol T=1 connection is over 45 seconds, this has no suspensive effect on the partially moresevere response time requirements of the application layer.
MIM-B Interface
After having found a way for the terminal and the Arduino’s microcontroller to exchange protocolT=1 blocks, the next challenge is extending that transmission path to the card client app. Sincethe UE comes with an integrated Bluetooth radio, which can be easily accessed through the An-droid Bluetooth API, using a serial-to-Bluetooth adapter like the HC-06 proved to be a simple andinexpensive way for connecting the MIM module firmware to the client app.
Once the UE and the Bluetooth module have been paired, the client app can open a radiofrequency communication (RFCOMM) connection to the HC-06 for forwarding bytes from theadapter’s Bluetooth side to its serial communication side and vice versa. Resets of the SAM3X8Eby the UICC terminal do not affect the HC-06 and the established RFCOMM connection. The
UE UICCterminal
UE cardclient app
MIM-Ainterface
MIM-Binterface
Level shifting andI/O splitting/joining
SAM3X8E HC-06 Bluetoothmodule
ApplicationCAT
Protocol T=1
Synchronous serial Asynchronous serialMIM-B protocol
RFCOMM stack
Card service protocolTCP
IP stack
Figure 5.4: Protocol and technology stacks of the client-side implementation
42
CardClient
CSPmessages
MIM-Bprotocolmessages
SocketCspConnection
BluetoothSocketMimModuleConnector
ProtocolT1EndpointBlocks APDUs
to HC-06 to card server
Figure 5.5: Components of the card client app and flow of messages. Rectangles with roundedcorners represent instances of custom classes.
asynchronous serial connection uses a constant baud rate of 9600 Bd, the default value of the HC-06, thereby avoiding signaling speed discrepancies after resets of the Arduino.
RFCOMM protocol guarantees reliable transmission of bytes between the Bluetooth moduleand the card service client, but due to the asynchronous communication leg from the SAM3X8E tothe HC-06, bytes exchanged by the MIM module firmware and the client app might get lost. There-fore, MIM-B protocol – the communication protocol used by these two components – was designedto provide reliable data transmission, too. Figure 5.4 shows the protocol’s role in transporting pro-tocol T=1 blocks. MIM-B protocol is an enhanced alternating bit protocol with turn-taking, i.e.after an endpoint has successfully acknowledged the reception of an incoming data packet, it getsthe right to transmit. The card client also sends acknowledgments in response to card reset notifi-cations from the MIM module, which are accompanied by a reset of all message sequence numbers,both for protocol T=1 and for MIM-B protocol.
Card Client App
The responsibilities and the behavior of the card client app have already been explained. Figure 5.5shows its major software components and what kind of messages they exchange with each otherand with other neighboring components. All processing is performed by an Android service, i.e.the app may keep running even while in the background.
5.3 Initialization Procedure and Normal Operation
As previously mentioned, the prototype system does not support automatic UICC switching.That is because the used Android version does not provide an API that allows apps to trigger cardresets or to activate and deactivate the USIM application of a plugged-in UICC. So the initializa-tion procedure for a remote card, after which the phone’s terminal and the associated UICC atthe server exchange APDU over GPRS, requires some manual intervention. Assuming that thecard server is running and that the phone is connected to a WLAN providing Internet access, theprocedure comprises the following steps:
1. Start the card client app. This opens a Bluetooth connection to the HC-06.2. Plug the MIM module’s adapter cable into the UICC slot, triggering a card reset and an
initialization of the UICC. The first APDU from the terminal causes the card client app toopen a CSP connection to the card server.
3. Enable the UICC in Android’s SIM card settings menu to activate the USIM application, ifnecessary. The phone attaches to the CS domain of the mobile network.
4. Enable mobile Internet access in the settings menu for the UICC. The phone attaches to thePS domain, but due to the existing WLAN connection, the phone does not yet establish aPDP context.
5. Wait until the communication between the terminal and the card has slowed down to peri-odic STATUS command-response pairs spaced approximately 30 s apart. Immediately follow-ing the delivery of a STATUS response block, disable the phone’s WLAN. As a result, the UE
43
activates a PDP context to regain Internet access. To reestablish contact to the server, thecard client app opens a new CSP connection over GPRS.
After this sequence, all future APDUs will be forwarded over the mobile Internet connectionestablished with the remote UICC. The wait in step 5 is advisable, because switching forwardingnetworks might take longer than the time that is afforded for answering the terminal’s commands.So, performing the switch when communication is unlikely to be affected makes a failure of theprocedure less probable.
44
Chapter 6
Experiments and Analysis of Results
This chapter describes various experiments aimed at studying the performance as well as the con-straints of the card service system and discusses the results. Section 6.1 describes the measurementof mobile network tolerance to delays in the authentication procedure. Section 6.2 studies sim-ulated SI switching based on cell-level encounters by users of private transport, and Section 6.3investigates the potential of public transport to conceal the destinations of travelers. The results ofthese experiments are discussed in Section 6.4.
6.1 Measurements of Response Time Requirements
As mentioned in Chapter 4, most UICC functionality can be virtualized in the card client app,so only AUTHENTICATE commands require the exchange of a command-response APDU pair withthe assigned, physical UICC located at the card server. The relevant technical standards [4, 5]specify that this exchange shall take less than 500 ms, so that the UE can answer user authenticationrequests from the network in less than 1 s.
To find out the response time requirements for user authentication requests from an actual mo-bile network, the effect of artificially delaying AUTHENTICATE response APDUs in the card clientwas measured with the prototype system described in Chapter 5. The remote UICC granted accessto the German D1 UMTS network. Figure 6.1 shows the UE’s ability to attach to the network andauthenticate with the card’s USIM (for both the CS and the PS domain), depending on the amountof time between having received a block carrying a command APDU and forwarding the associ-ated response block. The figure distinguishes between three kinds of outcomes. Failure means thatthe procedure was unsuccessful. Success with repetitions stands for an attach procedure that was ul-timately successful, but in which the network retransmitted user authentication requests, whereasin case of a complete success, retransmissions did not occur.
1 2 3 4 5 6 7 8Delay [s]
Outcome
complete successsuccess with repetitionsfailure
Figure 6.1: Feasibility of attaching to the mobile network depending on the time needed by theclient for responding to AUTHENTICATE commands. Each circle represents one attempt to initializethe USIM (always successful) and connect to the network.
45
6.2 Simulation of Cell-Based SI Switching for Users of Private Transport
SI switching based on cell-level encounters was studied by simulating the movement of nodeswithin an area partitioned into non-overlapping cells. The simulations were performed by a cus-tom software application, which combined two separate, publicly available datasets, both relatedto the same geographical region – the German city of Cologne. Vehicular mobility traces from theTAPASCologne dataset [52, 53] provided the trajectories of the simulated nodes. Cell boundarieswere generated based on the cell tower location data from [43].
6.2.1 Preprocessing and Characterization of the Input Datasets
The TAPASCologne dataset describes one day of simulated road vehicle traffic within Colognecity limits. According to [53], node movement is guided by both microscopic (e.g. speed limits,traffic lights, collision avoidance, acceleration, and deceleration) and macroscopic (evolution oftraffic flows over time due to learning) aspects. Node locations are specified in a two-dimensionalCartesian coordinate system, based on Universal Transverse Mercator (UTM) coordinates, witha temporal resolution of one second. Locations are only provided for active nodes, i.e. for thosecurrently traveling from their respective origin to their destination. An excerpt of the 24 hourdataset available at [52] covering approximately 100 minutes of early morning traffic was used forthe simulations described in this section. After removing nodes that were moving at the beginningor at the end of the observation period, a total of 88735 nodes remained. They served as thenode population from which random subsets of various sizes were sampled for the simulations.Figure 6.3 shows the number of active nodes from the population by time of day.
The second dataset provided street addresses of UMTS cell tower locations belonging to the D1mobile network in addition to the number of cells per tower. These addresses were transformedto geographic coordinates by forward geocoding via the Google Maps Geocoding API. A subse-quent transformation from latitude and longitude to UTM coordinates and a shift by −342506and −5630716 meters in the x- and y-direction respectively, aligned the cell tower locations withthe coordinate system of the vehicle dataset.
For each of the k ∈ 1,2,3 antennas of a cell tower, a so-called site (i.e. a 2D point), wasgenerated. For k = 1, the corresponding site was positioned at the tower’s location. For k >1, the sites were located on a small circle around the tower separated by an angular distance ofeither 180° (k = 2) or 120° (k = 3). Based on the sites, a Voronoi diagram was computed. Theresulting polygons served as cells. To equalize the areas Ai of multiple cells belonging to the sametower, all corresponding sites were systematically rotated around the circle center (preserving theangular distances) to maximize
∏ki=1 Ai . Figure 6.2 shows the final shapes and locations of the 713
generated cells superimposed on the plotted traces of the node population.The relationship between the duration and spatial length of trips is visualized in Figure 6.4. The
figure shows a largely linear relationship between the distance traveled by a node and trip duration.The distribution fans out from the chart’s origin, due to variations in node velocity. Local peaksaround 16 km and 22 km can be explained by nodes traveling through the simulation area alonghighly frequented routes in the freeway network. Outliers that represent small numbers of nodesmay be due to the synthetic nature of the movement data. The algorithm used for finding a setof trips that satisfy real-world traffic count constraints might have produced some unrealistic nodepaths. However, the overall ratio of outliers appears sufficiently small to be of no consequence tothe subsequent analyses.
6.2.2 Simulations
The simulations measured the effectiveness of pairwise, cell-based SI switching against a knowl-edgeable adversary as described in Section 4.1. This means that the adversary knows that and
46
Figure 6.2: Overlaid traces and cells
47
0
5000
10000
6:00 6:15 6:30 6:45 7:00 7:15 7:30Time of day [h:min]
Num
ber o
f act
ive n
odes
Figure 6.3: Number of active nodes by time of day
0
20
40
60
0 10 20 30 40Distance traveled [km]
Dur
atio
n [m
in]
1
7
54
403Count
Figure 6.4: 2D histogram of distances traveled and trip durations of the node population. Eachchromatic rectangle represents one or more nodes according to the logarithmic color scale.
48
when SI switching is taking place and which pseudonyms (i.e. subscriber identities) are involved inan encounter. Based on the assumption that the adversary uses a guessing strategy to match old tonew pseudonyms, the probability that the matching is correct is 50 %. Each encounter between apair of nodes and their accompanying synchronized switching operations were modeled as a singleinstantaneous event.
Each node was only simulated as present during the time of its trip, i.e. it appeared at its originand disappeared at its destination. Since almost all trace starting points and end points respectivelyform connected clusters (e.g. near motorway junctions), simply extending the time the nodes spendat those locations to cover the whole simulation period was not considered an option. The initialappearance of each node was treated like a normal transition into that cell.
The simulations investigated the influence of two independent variables on the overall effec-tiveness of cell-based SI switching: the sample size n and the switching partner selection strategy.The parameter n designates the number of randomly selected nodes from the population whosemovements and interactions were simulated in a single pass. Each sampled set of nodes was testedunder two switching partner selection strategies: random and fair. The random strategy means thatwhenever a node q enters a new cell with one or more other nodes already in it, then both q and arandomly selected peer from the new cell perform a synchronized SI switch. Under the fair strat-egy, the already present node that has been using its current SI for the longest time is chosen as q’sswitching partner. Any ties are resolved randomly. So, when multiple nodes share the same cell,the fair strategy ensures that nodes are not passed over indefinitely due to chance. The simulationsof the random and fair strategy was repeated 50 times for each n. A different set of sampled nodeswas used for each repetition. The results were aggregated by sample size and switching partnerselection strategy to cancel out random measurement errors.
6.2.3 Results
Figures 6.6 to 6.8 show the mean and certain quantiles of select variables depending on samplesize. Circles and triangles represent statistical means, box-plot-type elements visualize quantiles asexplained in Figure 6.5.
Figure 6.6 displays the relationship between sample size and the end distance error, i.e. thedistance between the last position of a particular node q and the last position of the node that theadversary assumes to be q . As the sample size increases, the mean distance error converges towardsthe population mean. Above n = 2000, the interquantile ranges appear stable. The figure alsoshows no effect of the switching partner selection strategy on end distance errors.
Figure 6.7 shows the relationship between sample size and the number of encounters per node.As n increases, the mean number of encounters converges towards the mean value of the node pop-ulation. Since both switching partner selection strategies lead to identical numbers of encountersfor the same node samples, the mean values are unaffected by the selection strategy. Minor, yet vis-ible differences in quantile values for n ≥ 4000 between the strategies can be attributed to randomprocesses and the volatility of quantiles in distributions that contain only natural numbers.
Figure 6.8 shows the effect of sample size and switching partner selection strategy on the ratioof correctly identified nodes at the end of their respective trip. The node identification ratio wasobtained once for each simulation run and then aggregated for visualization. Again, the switchingpartner selection strategy exerts no systematic influence. Increases in sample size are accompaniedby a decline of the mean identification ratio and a decrease of variability.
The influence of the switching partner selection strategy on the distributions of both the enddistance error and the number of encounters per node is investigated further in Figure 6.9 and 6.10respectively. In line with the quantile similarities depicted in Figures 6.6 and 6.7, the distributionsshow no discernible differences based on the way how switching partners are selected. Therefore,the switching partner selection strategy is disregarded in the remaining figures of this section.
49
0 10 20 30 40 50 60 70 80 90 100Distribution percentile
Figure 6.5: Box plot legend
0
2500
5000
7500
10000
100
200
300
400
500
600
700
800
900
1000
2000
3000
4000
5000
6000
7000
8000
9000
1000
0Sample size (binned)
End
dista
nce e
rror
[m]
Switchingpartnerselection
randomfair
Figure 6.6: Sample size and end distance error. The dashed line shows the mean distance error forn = 88735 (for both selection strategies with one repetition). See Figure 6.5.
0
10
20
30
40
50
100
200
300
400
500
600
700
800
900
1000
2000
3000
4000
5000
6000
7000
8000
9000
1000
0
Sample size (binned)
Enco
unte
rs p
er n
ode
Switchingpartnerselection
randomfair
Figure 6.7: Sample size and number of encounters per node. The dashed line shows the meannumber of encounters per node for n = 88735. See Figure 6.5.
50
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
100
200
300
400
500
600
700
800
900
1000
2000
3000
4000
5000
6000
7000
8000
9000
1000
0
Sample size (binned)
Nod
e ide
ntifi
catio
n ra
tio
Switchingpartnerselection
randomfair
Figure 6.8: Sample size and node identification ratio per repetition. See Figure 6.5.
n=100 n=1000 n=10000
0.0
0.2
0.4
0.6
0 10 20 30 0 10 20 30 0 10 20 30End distance error [km]
Den
sity
Switchingpartnerselection
randomfair
Figure 6.9: Probability density function of the end distance error distribution
51
n=100 n=200 n=300
0
25
50
75
0 5 10 15 20 0 10 20 30 0 10 20 30Number of encounters
Cou
nt
Switchingpartnerselection
randomfair
(a) Histogram of the number of encounters per node for small sample sizes
n=1000 n=10000
0.000
0.025
0.050
0.075
0 20 40 60 0 100 200 300 400 500Number of encounters
Den
sity
Switchingpartnerselection
randomfair
(b) Probability density function showing the distribution of the number of encounters per node for largesample sizes
Figure 6.10: Distribution of the number of encounters per node
52
Figures 6.11 and shows the effects of spatial trip length on the size of the distance error, givenvarious sample sizes. It supports the previously made observation that increases of n lead to largerdistance errors. Subfigure (a) shows unprocessed binned frequencies in a two-dimensional his-togram. Due to the skewed distribution of trip lengths, that chart is hard to interpret. Subfigure (b)gives a clearer visualization, that normalizes each column from (a), showing no influence of triplength on the underlying distribution of the end distance error. Visible disparities between the enddistance error distributions for short and long trips can be explained by differences in sparseness;there are comparatively few sampled nodes with long trips.
Figure 6.12 investigates the relationship between trip duration and end distance error, relyingthe same column-wise normalization technique used in Figures 6.11. The underlying distributionof the end distance error is also unaffected by the duration of the simulated trips.
53
n=100 n=1000 n=10000
0
10
20
30
0 10 20 30 40 0 10 20 30 40 0 10 20 30 40Distance traveled [km]
Dist
ance
erro
r [km
]
1
7
54
403
Count
n=100 n=1000 n=10000
0
10
20
30
0 10 20 30 40 0 10 20 30 40 0 10 20 30 40Distance traveled [km]
Dist
ance
erro
r [km
]
0.03
0.67
13.53
Column−wiseratio [%]
(a) 2D histogram of trip distances and end distance errors
n=100 n=1000 n=10000
0
10
20
30
0 10 20 30 40 0 10 20 30 40 0 10 20 30 40Distance traveled [km]
Dist
ance
erro
r [km
]
1
7
54
403
Count
n=100 n=1000 n=10000
0
10
20
30
0 10 20 30 40 0 10 20 30 40 0 10 20 30 40Distance traveled [km]
Dist
ance
erro
r [km
]
0.03
0.67
13.53
Column−wiseratio [%]
(b) 2D histogram of trip distances and end distance errors normalized by trip distance
Figure 6.11: Relationship between trip distance and end distance error
54
n=100 n=1000 n=10000
0
10
20
30
0 20 40 60 0 20 40 60 0 20 40 60Trip duration [min]
Dist
ance
erro
r [km
]
1
7
54
403
Count
100 1000 10000
0
10
20
30
0 20 40 60 0 20 40 60 0 20 40 60Trip Duration [min]
Dist
ance
erro
r [km
]
0.03
0.67
13.53
Column−wiseratio [%]
(a) 2D histogram of trip durations and end distance errors
n=100 n=1000 n=10000
0
10
20
30
0 20 40 60 0 20 40 60 0 20 40 60Trip duration [min]
Dist
ance
erro
r [km
]
1
7
54
403
Count
100 1000 10000
0
10
20
30
0 20 40 60 0 20 40 60 0 20 40 60Trip Duration [min]
Dist
ance
erro
r [km
]
0.03
0.67
13.53
Column−wiseratio [%]
(b) 2D histogram of trip durations and end distance errors normalized by distance traveled
Figure 6.12: Relationship between trip duration and end distance error
55
6.3 Simulation of SI Switching Based on Direct Encounters By Users ofPublic Transport
This section investigates the potential location privacy benefit of SI switching based on direct en-counters to users traveling by public transport, more specifically, by subway. Results were obtainedwith a custom simulation software that incorporated origin-destination (O/D) ridership data ofthe Washington D.C. metro system [34].
6.3.1 Preprocessing and Characterization of the Input Dataset
The O/D dataset specifies the number of subway riders in the month of October 2014, aggregatedby departure period (quarter hour time slots), entry and exit station, and type of day (weekday,Saturday, or Sunday). All passengers were required to swipe in and out respectively at the stationsthey entered and exited the metro system. The system had six lines serving a total of 91 stations, asdepicted in Figure 6.13. From Monday to Thursday, stations were open between 5 a.m. and mid-night. On Fridays, that period lasted until 3 a.m. of the following day. For the simulation, onlyweekday rides between 5 a.m. and midnight were considered. Travel times between stations be-longing to the same line were determined based on timetables and information from the metro tripplanning website. Linear distances between stations were computed with Vincenty’s formulae [54]based on geographic coordinates obtained from Google Maps.
6.3.2 Simulation
Since the ridership dataset only provides aggregated flow information, it lacks microscopic move-ment data that would be necessary for determining short-range encounters between users. There-fore, SI switching by the travelers was evaluated in a partially abstract way. Instead of simulatingencounters between pairs of individual mobile nodes, contacts between nodes and rider flows aswell as distances between the respective destinations were studied.
The subway system was modeled as a directed multigraph, with stations as vertices and oneedge for each metro line connecting two adjacent stations. Time was discretized into minutes.Paths in the network were chosen based on a shortest travel time. In case of multiple shortest routesbetween an origin and destination, all alternatives were equally likely. Since no comprehensivetimetables were available, trip durations were calculated as follows. Riders were assumed to spend5 minutes in their station of entry and in each station where they switched to a different line. Twominutes were allotted for leaving the exit station. The time spent in transit was the sum of thetravel times associated with each visited edge. All trips that would have ended after the end of thesimulation period were discarded.
The simulation comprised two phases. In the first phase, flows were generated. Given an entryin the preprocessed O/D dataset with x riders departing from station o with destination d duringdeparture period t , then for each minute of t , x distinct fastest paths from o to d were computed.For all vertices and edges of the network, the number of riders passing through at any particularminute and their respective destinations were saved as flow information.
In the second phase of the simulation, one trip for each passenger mentioned in the prepro-cessed O/D dataset was simulated, with a random starting time in the specified departure period.The distance in meters and in network hops between each rider’s exit station and the destinationsof encountered flow units were computed as the main outcome of the simulation.
Each simulated ride was classified as one of the following three types: towards center, throughcenter, or away from center, depending on the change of the closeness centrality values of the verticesalong the path. Based on the duration d of the fastest route between any two elements from the set
56
10 km
Figure 6.13: Metro rail map showing stations and lines
57
of stations V , the closeness C of a station v was defined as:
C(v) =1∑
w∈Vd(v, w)
Rides for which the closeness was monotonically increasing from origin o to destination d andwhich satisfied C(d ) > C(o) were classified as going towards the network center. Those with amonotonic decrease and with C(d )< C(o)were classified as going away from the center. All otherrides were classified as the through center type.
6.3.3 Results
Figure 6.13 shows the number of riders by time of day and ride type. All ride types show a peakin ridership during the morning and evening rush hour periods. During the morning peak, thereare more passengers traveling towards the network center than away from it. In the evening, thatpattern is reversed.
Figure 6.15 displays the distributions of riders’ mean end distance error for each ride type.(The means were computed individually for each passenger.) The figure shows that rider whotravel towards the network center are less likely to have a high mean distance error than thosetraveling away from the center.
Figure 6.16 shows the distribution of the distance error in hops. The hop distance of v, w ∈Vis the minimum of graph edges that need to be traversed to get from v to w. The figure shows that,the destinations of fellow passengers encountered by someone traveling towards the center tend tobe closer to the person’s own exit station than for the other ride types.
Figure 6.17 shows the relationship between the mean metric distance error, the duration of arider’s trip, and the ride type. Overall, riders with longer trips have larger mean distance errors.However, this does not hold for those traveling towards the center. For them, the range and meanof the duration-specific distribution both decrease as trips get longer. The positive linear correla-tion is greatest for the group traveling through the network center.
58
0
250000
500000
750000
6:00 9:00 12:00 15:00 18:00 21:00 0:00Time of day [h:min]
Num
ber o
f rid
ers Ride type
anytowards centerthrough centeraway from center
Figure 6.14: Number of riders by time of day and ride type
0.00000
0.00005
0.00010
0.00015
0.00020
0.00025
0 10000 20000Mean distance error [m]
Den
sity
Ride typetowards centerthrough centeraway from center
Figure 6.15: Distribution of rider-specific mean distance errors
0.0
0.2
0.4
0.6
0.8
1.0
0 5 10 15 20 25Distance error in hops
Nor
mali
zed
cum
ulat
ive f
requ
ency
Ride typeanytowards centerthrough centeraway from center
Figure 6.16: Cumulative histogram of distance error in hops
59
25
50
75
100
25
50
75
100
25
50
75
100
25
50
75
100
anytow
ards centerthrough center
away from
center
0 10000 20000Mean distance error [m]
Ride
dur
atio
n [m
in]
1
20
403
8103Count
Figure 6.17: Relationship between mean distance error, ride duration, and ride type
60
6.4 Discussion
The simulation of pairwise SI switching based on cell-level encounters by users of private trans-port identified sample size as the only relevant independent variable. Neither trip duration, nordistance traveled, nor the switching partner selection strategy had any systematic effect on thestudied performance parameters. So, the rate of adoption – the number of users relative to thetotal population – would have a strong influence on the degree location privacy offered by of thesystem.
For sample size n = 3000, approximately 3.4 % of the node population, the end distance errorof 9 out of 10 sampled nodes exceeds 550 m. This limit converges towards roughly 950 m for largern. At least for inner city regions, this amount of distance error should usually translate to incorrectdestination cell guesses by the adversary. Since the location traces represent early morning traffic,the studied nodes probably tend to go towards the city center, i.e. the distance errors are smallerthan they would have been with traces covering the whole day.
For n = 2000, about 2.3 % of the node population, half of the sampled nodes were involvedin 10 or more encounters and the adversary was able correctly identify approximately 9.9 % of thenodes at the end of their trip. For larger sample sizes, the identification ratio converges towardszero.
With some additional effort, the adversary might be able to correctly match old to new SIswith a probability above chance level. Some matchings may be ruled out completely because theresulting cell transitions would require unrealistic node velocities. The adversary could also userelative probabilities for more accurate matchings. For example, given the directions and velocitiesof nodes before an encounter, the matching with the smallest changes to those parameters mightbe considered the most likely. This would require a model of node mobility from which theprobabilities of particular outcomes can be derived. Alternatively, the adversary could computeconditional probabilities of a subscriber’s cell transitions, given one or more previously visitedcells, similar to [12]. But since users might have more than one encounter in each visited cell,finding maximum likelihood matchings would be non-trivial. Even if the adversary was betterthan chance (but not perfect) at correctly matching old to new SIs, due to the high number ofencounters per node, the mean identification ratio would probably still be relatively low.
However, these results might not be fully applicable to the real world. Some cells in the periph-ery of the simulation area appear unusually large, even when assuming that the outer cells do notextend to the map border. Since cell towers are usually positioned to achieve a uniform numberof subscribers per cell and because the population densities do not vary that much between thedowntown area and the suburbs8, these differences in size suggest that the used cell tower locationdataset is incomplete. Therefore, the number of cells is underestimated by the simulation, whichhas different implications depending on sample size. For small n, the larger cells lead to a tendencyto overestimate the number of encounters, because the probability that a newly-entered cell con-tains a switching partner increases noticeably. For very large n, cells are more likely to be occupiedeither way, irrespective of cell size. But if the cells are bigger, the number of crossed cell boundariesis reduced. This contributes to a tendency to underestimate the number of encounters if the nodedensity is very high. Concerning this matter, the simulated sample sizes probably do not qualifyas very large.
With the cell-based SI switching trigger, encounters can only occur when a node enters a newcell. Thus, the number of cell transitions would be an upper bound for the total number of en-counters in the real world. Since the simulation also treats each node’s initial appearance in its firstcell as a transition, the maximum number of encounters in the simulation is equal to the sum of thenumber of cell transitions and the sample size. This also contributes to a higher node identification
8According to [26], population densities of the downtown district and Cologne’s other districts differ by a factor ofless than 6.5.
61
ratio in the simulation.Due to filtering of partial trips at the beginning and the end of the simulation period, the
simulated number of encounters per node is reduced compared to the full 24 hour dataset.Since the simulation treated inactive nodes as absent, encounters with other nodes only happen
while a particular node is traveling. The average trip duration is about 10 minutes, one tenth ofthe simulation period. This concentration of encounters means that the adversary’s probabilityof correctly re-identifying simulated users at the end of their trip is significantly decreased, but atthe expense of the currently inactive nodes, which could be re-identified easily during their periodsof inactivity due to their fixed subscriber identities. In reality, nearby, immobile users would bepotential switching partners, too. Under the fair switching partner selection strategy, inactiveusers would be more likely to be chosen as partners, because their moving peers have at least oneencounter for each of their personal cell transitions, which means that the time since a particularuser’s last encounter would tend to be shorter for traveling individuals.
Not simulating inactive nodes is also the likely reason why there were no apparent differencesbetween the outcomes for the random and fair switching partner selection strategies.
When considering a greater population, including users who do not travel during the simu-lation period, then the encounters triggered by the sampled users would be distributed across aneven larger group of people. Hence, the average number of encounters per user in the simulationperiod would be lower still, resulting in a lower node identification ratio.
The described SI switching strategy, which, in the real world, triggers at most one pairwiseencounter for each cell transition, might not generate a sufficient number of encounters to suc-cessfully hide the identities of all users and thereby protect their location privacy. Hence, a dif-ferent switching strategy would probably be needed, which allows for more than two clients perencounter, uses a different SI switching trigger (possibly not depending on movement), or both.
Although pairwise SI switching based on direct encounters was not simulated as part of theprivate transport scenario, the number of SI switches one could expect in that case would be muchlower than for the cell-level strategy due to the considerably smaller encounter radius. Conse-quently, performance measured with the other two error metrics – end distance error and nodeidentification ratio – would be significantly worse, too. Switching based on direct encounterswould be much better suited for settings featuring shared spaces with high user densities, as in thesimulated subway system.
That simulation did not actually study any of the SI switching strategies proposed in Sec-tion 4.3. Instead, it ascertained the distribution of the distances between the destinations of partic-ular riders and those of all fellow passengers they could have met during their trip. Although thedurations of the simulated trips for a given entry and exit station pair was shorter than the meanvalues from the O/D ridership dataset due to usually shorter, constant-length waiting times in thesimulation, these differences probably were of little consequence.
Not surprisingly, the results suggest that riders who mingle with travelers going in many dif-ferent directions, e.g. at stations in the network center, can expect larger distance errors thanriders who follow the same route as the majority of people they come into contact with. Overall,only about 10.3 % of the fellow travelers met by any particular rider had the same exit station. So,when used by travelers in a subway system that is comparable to the simulated one, an SI switchingstrategy based on direct encounters would probably lead to high distance errors for most users.
The rush hour peaks in ridership had to be expected. But due to the probably higher trainfrequencies and more carriages per train during peak periods, a rise in the total number of travelersmight not be accompanied by an identical increase in train occupancy rates. Nonetheless, theperson density would be increased during rush hour, so the number of direct encounters betweenusers of the SI switching system should be higher as well.
Since the mobile network studied in Section 6.1 tolerates delays of user authentication re-sponses of up to five seconds without any negative consequences, the functioning of the card service
62
system would not be thwarted by normal network delays between the cellphone’s UICC terminaland the remote card. Since this delay tolerance is probably the result of practical considerationsthat apply to all carriers, other cellular networks are likely to be equally forgiving.
63
Chapter 7
Conclusion
This chapter concludes the thesis by summarizing the key findings, drawing conclusions abouttheir impact, pointing out the major contributions and identifying opportunities for future work.
7.1 Summary and Conclusions
This thesis described a distributed system for the anonymous usage of mobile networks. Userscan switch automatically between subscriber identities (SIs) from a pool of UICCs managed bya central server. Through coordinated, simultaneous SI switching, the members of a group ofusers located in the same mobile radio cell can become indistinguishable to a passive, network-sideadversary who tracks subscribers only based on IMSIs. However, analyzing the available cell-levellocation history of the involved SIs may help in correctly re-identifying users after a coordinatedswitch. The adversary might be able to distinguish between ordinary subscribers and users of thesystem based on the assigned subscriber identities. The system also cannot reliably conceal theoccurrence of SI switches.
Three kinds of SI switching triggers were presented: direct encounters that require short-rangeradio contact between users’ devices, cell-level encounters detected by a central, server-side instanceentrusted with the users’ location information, and time-based triggers used in alternating betweenmultiple cellular networks.
The proposed system is compatible with UMTS and GSM in Iu mode. Other mobile commu-nication technology generations may also be supported, if the establishment and the activation ofthe cryptographic keys that protect wireless transmissions are performed in separate exchanges.
The possibility to enhance the location privacy of a group of users who travel independentlyby car with SI switching based on cell-level encounters was clearly demonstrated. The difficulty ofcorrectly re-identifying users increases with group size. However, pairwise SI switching triggeredby users’ cell transitions might be insufficient for universally providing high levels of anonymityand location privacy, i.e. correct re-identification of users across short periods of time would belikely. But the switching strategy could easily be modified to allows for more SI switching, eitherby allowing cell-level encounters with more than two participating users, by triggering joint SIswitches based on necessity and opportunity, or by combining those two approaches.
I assume that unless the ratio of participating users among the population were extremelyhigh, direct encounters would be significantly less frequent than cell-level encounters for userstraveling with their own vehicle. Due to higher user densities, switching strategies based on directencounters should be much better suited for passengers of public transport. In the studied subwaynetwork, only about one in ten fellow travelers, that any particular rider might meet during hisor her trip, had the same exit station. So, in comparable subway systems, successful SI switchingbased on direct encounters is likely to hide the true destinations of users. However, this strategy
65
can only protect the location privacy of those who frequently come into close contact with otherusers, so it might not be suitable for everyone.
If forced to choose between the two evaluated switching strategies, the cell-level version wouldcome out on top, because, with minor modifications, it is capable of using all opportunities forlocation-privacy-enhancing SI switching and of assigning encounters fairly among the occupantsof a cell, even to immobile users. The privacy risks resulting from users having to share theircurrent location with the server side could be mitigated to some extent by moving all servers to acountry with strong privacy laws.
It must be emphasized, that the SI switching system offers only partial protection againstidentity-based tracking; users may still be re-identified based on IMEIs – the device identifiersof their phones. SI switching based on cell-level encounters may be less effective against an ac-tive network-side adversary, who continuously ascertains cellphone locations by requesting thephones to report their geographic coordinates or the signal strengths of nearby cell towers. Radiofingerprinting [14] – the identification of device-specific radio characteristics – might also be usedto re-identify cellphones and users.
7.2 Contributions
This thesis presented the first known identity switching system for mobile network users that istruly compatible with existing cellular network infrastructure and protocols. The mechanismsthat allow this interoperability were fully explained. Several ways of using the system for increas-ing anonymity and location privacy were identified. One of them was experimentally evaluatedagainst a realistic adversary model. The feasibility of using the USIM of a remote UICC for es-tablishing mobile Internet access and maintaining that connection to transmit the APDU trafficbetween the terminal and the card was proven with a prototype implementation. A descriptionof the prototype’s hard and software was provided. In addition, the potential of concealing one’sdestination through SI switching with fellow subway riders was investigated.
7.3 Opportunities for Future Work
This thesis leaves numerous opportunities for follow-up research. An obvious first step would be toinvestigate, if the SI switching system is compatible with 4th and 5th generation mobile networks.
Without the capability to stop mobile phones from revealing their IMEI, the system is inca-pable of actually offering protection from user re-identification. Hence, finding ways to alter thedevice identity that mobile phones report to the network would be indispensable for the successfulpractical application of the system. However, modifying IMEIs is illegal in many countries.
The described system cannot hide SI switching events from the adversary. By enabling thecovert exchange of subscriber identities and mobile Internet sessions between meeting phones,without the deactivation of PDP contexts and the detachment of SIs from the network, detectingencounters and re-identifying users would be made much more difficult.
For more reliable conclusions about the performance of various switching strategies, theyshould be re-evaluated with more comprehensive user mobility data that provides realistic loca-tions of representative individuals for at least a whole day. Such a dataset may prove useful fornumerous applications beyond identity switching. This data may be either collected by recordingthe movement of real persons (raising issues of cost, accuracy, and location privacy), or generatedartificially, which would require realistic models of human mobility. But once created, those mod-els might also serve adversaries in re-identifying and tracking users of the system, as well as allow amore accurate assessment of system performance.
With the described cell-based SI switching strategy, the server side must be kept apprised ofusers’ cell changes. To send the associated messages, the client has to break radio silence, revealing
66
the current cell of the assigned SI to the adversary. A card client might be able to just disclose itsSI’s routing area by predicting its own movement, sharing the resulting itinerary with the server,and only messaging it when deviating significantly from the computed schedule. Finding ways tocompute and preserve the secrecy of the itineraries and evaluating the gains in location privacymight also be worthwhile tasks.
67
APPENDICES
69
Appendix A
Circuits and Connections of the MIMModule Prototype
This appendix describes the custom electrical circuits of the MIM module prototype presentedin Chapter 5. The description here is based on the specific U(S)ART instances of the SAM3X8Emicrocontroller used by the prototype. They are listed in Table A.1. USART0 is used for syn-chronous communication with the UE’s UICC terminal. UART communicates asynchronously(i.e. with a predetermined baud rate, without a clock signal) with the HC-06 Bluetooth module.
Figure A.1 shows the circuit for level shifting and I/O splitting/joining. It uses two kinds ofN-channel enhancement mode field effect transistors: 2N7000 and BF245C. Table A.2 lists thesensitivity properties of these transistor models.
Table A.3 specifies the electrical connections between the Bluetooth module and the Arduino.
71
U(S)ART instance name Pin name Mapped pin name Purpose
UART PA8 RX0 ReceiverUART PA9 TX0 Transmitter
USART0 PA10 RX1 ReceiverUSART0 PA11 TX1 TransmitterUSART0 PA17 SDA1 Clock signal input
Table A.1: U(S)ART instances and associated pins used by the MIM module prototype. Mappedpin names refer to Arduino Due pin designations.
BF245C
4.7kΩ
10kΩ
4.7kΩ 3.3V
Arduino
Reset
Arduino
RST
IDF
BF245C10kΩ
SDA1
Arduino
CLK
IDF
1.65V
BF245C10kΩ
RX1
Arduino
I/O
IDF
10kΩ
2N7000
2N7000
TX1
Arduino
GND
IDF
GND
Arduino
Figure A.1: Circuit for level shifting and I/O splitting/joining. The electrical circuit connects theclass C UICC terminal (IDF) of the UE with the Arduino Due’s microcontroller.
Model name Threshold voltage [V]
min. typical max.
2N7000 0.8 2.1 3.0BF245C 0.5 unspecified 0.8
Table A.2: Gate-source threshold voltages of usedtransistors types
HC-06 pin Arduino pin
VCC 5VGND GNDRX TX0TX RX0
Table A.3: Pin connections of theHC-06 Bluetooth module and theArduino Due
72
References
[1] 3GPP TS 04.31 / ETSI TS 101 527. Location Services (LCS); Mobile Station (MS) – ServingMobile Location Centre (SMLC) – Radio Resource LCS Protocol (RRLP). Version 8.18.0. 3rdGeneration Partnership Project / European Telecommunications Standards Institute. 2014.
[2] 3GPP TS 31.102 / ETSI TS 131 102. Universal Mobile Telecommunications System (UMTS);LTE; Characteristics of the Universal Subscriber Identity Module (USIM) application. Ver-sion 12.5.0. 3rd Generation Partnership Project / European Telecommunications StandardsInstitute. 2014.
[3] 3GPP TS 33.102 / ETSI TS 133 102. Digital cellular telecommunications system (Phase 2+);Universal Mobile Telecommunications System (UMTS); 3G Security; Security Architecture. Ver-sion 12.2.0. 3rd Generation Partnership Project / European Telecommunications StandardsInstitute. Jan. 2015.
[4] 3GPP TS 35.205 / ETSI TS 135 205. Universal Mobile Telecommunications System (UMTS);LTE; 3G Security; Specification of the MILENAGE algorithm set: An example algorithm set forthe 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*; Document1: General. Version 12.0.0. 3rd Generation Partnership Project / European Telecommunica-tions Standards Institute. 2014.
[5] 3GPP TS 44.013 / ETSI TS 144 013. Digital cellular telecommunications system (Phase 2+);Performance requirements on the mobile radio interface. Version 12.0.0. 3rd Generation Part-nership Project / European Telecommunications Standards Institute. 2014.
[6] David Banisar and Simon Davies. Privacy and Human Rights. An International Survey ofPrivacy Laws and Practice. Global Internet Liberty Campaign. URL: http://gilc.org/privacy/survey (visited on 06/06/2015).
[7] Murat Ali Bayir, Nathan Eagle, and Murat Demirbas. “Discovering SpatioTemporal Mobil-ity Profiles of Cellphone Users”. In: in Proceedings of the 10th IEEE International Symposiumon a World of Wireless, Mobile and Multimedia Networks (WoWMoM 2009. 2009, pp. 1–9.
[8] Leo Becker. Umprogrammierbare SIM: Apple und Samsung angeblich an eSIM-Standard inter-essiert. July 16, 2015. URL: http://heise.de/-2751994 (visited on 07/21/2015).
[9] Sebastian Kay Belle, Oliver Haase, and Marcel Waldvogel. “CallForge: Call Anonymity inCellular Networks”. In: PERVASIVE 2008 Workshop on Security and Privacy in SpontaneousInteraction and Mobile Phone Use (SPMU 2008). May 19, 2010. URL: https://netfuture.ch/wp-content/uploads/2010/belle10callforge.pdf.
[10] Sebastian Kay Belle and Marcel Waldvogel. PathForge:: Faithful Anonymization of MovementData. Tech. rep. Apr. 2009. URL: http://kops.ub.uni-konstanz.de/volltexte/2009/7524 (visited on 06/16/2015).
[11] Sebastian Kay Belle, Marcel Waldvogel, and Oliver Haase. “PathForge: Faithful Anonymiza-tion of Movement Data”. In: Proceedings of the 1st ACM workshop on Networking, systems,and applications for mobile handhelds (MobiHeld ’09). Aug. 17, 2009, pp. 63–64. URL: https://netfuture.ch/wp-content/uploads/2009/belle09pathforge.pdf. published.
73
[12] Alastair R. Beresford and Frank Stajano. “Location Privacy in Pervasive Computing”. In:IEEE Pervasive Computing 2.1 (2003), pp. 46–55. ISSN: 1536-1268. DOI: http://doi.ieeecomputersociety.org/10.1109/MPRV.2003.1186725.
[13] Andrew J. Blumberg and Peter Eckersley. On Locational Privacy, and How to Avoid Losingit Forever. Electronic Frontier Foundation. Aug. 3, 2009. URL: https://www.eff.org/wp/locational-privacy (visited on 07/20/2015).
[14] Vladimir Brik et al. “Wireless Device Identification with Radiometric Signatures”. In: Pro-ceedings of the 14th ACM International Conference on Mobile Computing and Networking.MobiCom ’08. San Francisco, California, USA: ACM, 2008, pp. 116–127. DOI: 10.1145/1409944.1409959.
[15] Gottfried August Bürger. The Adventures of Baron Munchausen. Third. London, Paris andNew York: Cassel, Petter and Galpin, 1867.
[16] Pierre Deville et al. “Dynamic population mapping using mobile phone data”. In: Proceed-ings of the National Academy of Sciences 111.45 (2014), pp. 15888–15893. DOI: 10.1073/pnas.1408439111.
[17] Matt Duckham and Lars Kulik. “Location privacy and location-aware computing”. In: Dy-namic & Mobile GIS: Investigating Change in Space and Time. 2006. Chap. 3, pp. 34–51.
[18] ETSI TS 102 221. Smart Cards; UICC-Terminal interface; Physical and logical characteristics.Version 12.0.0. European Telecommunications Standards Institute. Dec. 2014.
[19] ETSI TS 102 223. Smart Cards; Card Application Toolkit (CAT). Version 12.1.0. EuropeanTelecommunications Standards Institute. Sept. 2014.
[20] R.A. Finkel and J.L. Bentley. “Quad trees a data structure for retrieval on composite keys”.English. In: Acta Informatica 4.1 (1974), pp. 1–9. DOI: 10.1007/BF00288933.
[21] Marta C. Gonzalez, Cesar A. Hidalgo, and Albert-Laszlo Barabasi. “Understanding indi-vidual human mobility patterns”. In: Nature 453.7196 (June 2008), pp. 779–782. DOI: 10.1038/nature06958.
[22] Marco Gruteser and Dirk Grunwald. “Anonymous Usage of Location-Based ServicesThrough Spatial and Temporal Cloaking”. In: Proceedings of the 1st International Confer-ence on Mobile Systems, Applications and Services. MobiSys ’03. San Francisco, California:ACM, 2003, pp. 31–42.
[23] ISO/IEC 7816-3:2006(E). Identification cards — Integrated circuit cards. Part 3: Cards with con-tacts — Electrical interface and transmission protocols. International Organization for Stan-dardization. 2006.
[24] ISO/IEC 7816-4:2005(E). Identification cards — Integrated circuit cards. Part 4: Organiza-tion, security and commands for interchange. International Organization for Standardization.2005.
[25] Torsten Kleinz. Handy-wechsel-dich. Zeit Online. Apr. 25, 2008. URL: http://www.zeit.de/online/2008/03/handykartenboerse (visited on 03/14/2015).
[26] Kölner Stadtteilinformationen. Zahlen 2014. Stadt Köln, 2015. URL: http://www.stadt-koeln.de/mediaasset/content/pdf15/stadtteilinformationen_2014.pdf (visited on09/07/2015).
[27] John Krumm and Eric Horvitz. “Predestination: Inferring Destinations from Partial Tra-jectories”. In: In Ubicomp. 2006, pp. 243–260.
[28] Jessica Leber. How Wireless Carriers Are Monetizing Your Movements. MIT Technology Re-view. Apr. 12, 2013. URL: http://www.technologyreview.com/news/513016/how-wireless-carriers-are-monetizing-your-movements (visited on 07/19/2015).
74
[29] Danielle Levitas. Always Connected. How Smartphones and Social Keep Us Engaged. Interna-tional Data Corporation, Mar. 27, 2013.
[30] Mingyan Li et al. “Swing & Swap: User-centric Approaches Towards Maximizing LocationPrivacy”. In: Proceedings of the 5th ACM Workshop on Privacy in Electronic Society. WPES’06. Alexandria, Virginia, USA: ACM, 2006, pp. 19–28. ISBN: 1-59593-556-8. DOI: 10.1145/1179601.1179605.
[31] Xinxin Liu and Xiaolin Li. Location Privacy Protection in Mobile Networks. Springer Pub-lishing Company, Incorporated, 2013. ISBN: 1461490731, 9781461490739.
[32] K. Mano, K. Minami, and H. Maruyama. “Protecting Location Privacy with K-ConfusingPaths Based on Dynamic Pseudonyms”. In: Pervasive Computing and CommunicationsWorkshops (PERCOM Workshops), 2013 IEEE International Conference on. IEEE, Mar. 2013,pp. 285–290. ISBN: 978-1-4673-5075-4. DOI: 10.1109/percomw.2013.6529496.
[33] Urs Mansmann. “Namenlos. Keine Ausweisprüfung bei Prepaid-SIM-Karten vom Discoun-ter”. In: c’t 24/14 (Oct. 31, 2014), pp. 108–109.
[34] Metrorail Data Download, October 2014. Washington Metropolitan Area Transit Author-ity. Jan. 26, 2015. URL: http://planitmetro.com/2015/01/26/metrorail- data-download-october-2014 (visited on 09/02/2015).
[35] Ulrike Meyer and Susanne Wetzel. “A Man-in-the-Middle Attack on UMTS”. In: in Proceed-ings of the 2004 ACM Workshop on Wireless Security. ACM Press, 2004, pp. 90–97.
[36] Mobile Technology Fact Sheet. Highlights of the Pew Internet Project’s research related to mobiletechnology. Pew Research Center. URL: http://www.pewinternet.org/fact-sheets/mobile-technology-fact-sheet (visited on 07/18/2015).
[37] Yves-Alexandre de Montjoye et al. “Unique in the Crowd: The privacy bounds of humanmobility”. In: Sci. Rep. 3 (1376 Mar. 25, 2013), pp. 1–5. DOI: 10.1038/srep01376.
[38] Mirco Musolesi and Cecilia Mascolo. “Mobility Models for Systems Evaluation. A Survey”.In: Middleware for Network Eccentric and Mobile Applications. Ed. by Benoit Garbinato,Hugo Miranda, and Luis Rodrigues. Springer, Feb. 2009, pp. 43–62.
[39] Karsten Nohl. Rooting SIM Cards. Black Hat USA 2013. 2013. URL: https : / / www .blackhat.com/us-13/briefings.html#Nohl (visited on 08/11/2015).
[40] Osmocomb SIMtrace. URL: http://bb.osmocom.org/trac/wiki/SIMtrace (visited on08/07/2015).
[41] Andreas Pfitzmann and Marit Hansen. A terminology for talking about privacy by dataminimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity,and Identity Management. v0.34. Aug. 2010. URL: http://dud.inf.tu-dresden.de/literatur/Anon%5C_Terminology%5C_v0.34.pdf (visited on 06/09/2015).
[42] Martin Sauter. From GSM to LTE-Advanced. John Wiley & Sons, Ltd, 2014. DOI: 10.1002/9781118861943.
[43] Frank Scholle. Telekom(D1)-Senderliste für Köln. Jan. 9, 2015. URL: http://www.fst-gsm.de/d1-k.html (visited on 04/13/2015).
[44] Claude Shannon. “A Mathematical Theory of Communication”. In: Bell System TechnicalJournal 27 (1948), pp. 379–423, 623–656.
[45] Aaron Smith et al. U.S. Smartphone Use in 2015. Pew Research Center, Apr. 1, 2015. URL:http://www.pewinternet.org/2015/04/01/us-smartphone-use-in-2015 (visited on07/19/2015).
75
[46] Daniel Sokolov. Project Fi: Google lanciert Mobilfunk-Dienst. Apr. 23, 2015. URL: http://heise.de/-2617408 (visited on 07/20/2015).
[47] Daniel J. Solove. “I’ve Got Nothing to Hide’ and Other Misunderstandings of Privacy”.In: San Diego Law Review 44 (July 12, 2007), pp. 745–772. GWU Law School Public LawResearch Paper No. 289.
[48] Chaoming Song et al. “Limits of Predictability in Human Mobility”. In: Science 327.5968(2010), pp. 1018–1021. DOI: 10.1126/science.1177170.
[49] Kazunani Suzuki and Teppei Azuma. “Standardization of Embedded UICC Remote Provi-sioning”. In: NTT DOCOMO Technical Journal 16.2 (2014), pp. 36–41.
[50] David Talbot. Big Data from Cheap Phones. MIT Technology Review. Apr. 23, 2013. URL:http://www.technologyreview.com/featuredstory/513721/big-data-from-cheap-phones (visited on 07/19/2015).
[51] Christopher Tarnovsky. Hacking the Smartcard Chip. Black Hat DC 2010. 2010. URL:https://www.blackhat.com/html/bh-dc-10/bh-dc-10-archives.html (visited on08/11/2015).
[52] Sandeesh Uppoor, Diala Naboulsi, and Marco Fiore. Vehicular mobility trace of the Cityof Cologne, Germany. URL: http://kolntrace.project.citi- lab.fr (visited on08/25/2015).
[53] Sandesh Uppoor and Marco Fiore. “MobiCom 2011 Poster: Vehicular Mobility in Large-scale Urban Environments”. In: SIGMOBILE Mob. Comput. Commun. Rev. 15.4 (Mar. 2012),pp. 55–57. DOI: 10.1145/2169077.2169089.
[54] Thaddeus. Vincenty. “Direct and inverse solutions of geodesics on the ellipsoid with appli-cation of nested equations”. In: Survey Review 23.176 (1975), pp. 88–93.
[55] Report of OpenBSC GSM field test. Hacking at Random (HAR2009). Vierhouten, TheNetherlands, Aug. 2009. URL: http://openbsc.osmocom.org/trac/raw-attachment/wiki/FieldTests/HAR2009/har2009-gsm-report.pdf (visited on 04/23/2015).
[56] Alan F. Westin. Privacy and Freedom. New York: Atheneum, 1967.
[57] Yu Yu. Cloning 3G/4G with a PC and an Oscilloscope: Lessons Learned in Physical Security.Black Hat USA 2015. 2015. URL: https://www.blackhat.com/us-15/briefings.html#cloning-3g-4g-sim-cards-with-a-pc-and-an-oscilloscope-lessons-learned-in-physical-security (visited on 08/11/2015).
76