As heralded by the title, this section presents aspects of Universal Mobile Telecommunications System (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 mobile telecommunication systems, most of the concepts described here apply to other generations as well. 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 devices through a set of spatially distributed, interconnected, stationary antennas. Figure 2.5 outlines the architecture of UMTS mobile networks. The system consists of two parts: the UMTS terrestrial radio 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). According to[42], each RNC is usually responsible for several hundred node Bs.
UTRAN Core network (CN)
Figure 2.5: Simplified UMTS network architecture (Release 99). Dashed lines represent signaling links. 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 closed again, the transmission resources claimed by the connection are unavailable to other parties. CS connections are used for voice calls and video telephony, i.e. applications with (mostly) constant bit rates. For applications with variable bit rate requirements, e.g. mobile Internet, PS connections are better suited. Instead of reserving transfer capacity exclusively for one connection, available bandwidth is shared by multiple connections. Since PS applications typically send data in short bursts separated by relatively long periods of inactivity, relying on circuit switching would lead to a 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 GMSC connects 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 Radio Service (GPRS): the serving GPRS support node (SGSN) is the counterpart of the MSC in the PS domain, 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 location register (HLR) and the visitor location register (VLR) – are also part of the core network. Each mobile network operator (MNO) maintains an HLR for storing information about the accounts of its subscribers. That information includes the international mobile subscriber identity (IMSI) – a permanent subscriber identifier – and the mobile subscriber ISDN number (MSISDN) – the telephone 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 particular subscriber. That MSC then copies some of the subscriber-related information to its VLR where it is 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 packet data protocol (PDP) context activation or as making a PS call. During this procedure, the UE is temporarily assigned an IP address. That address is usually from a private address space, which requires the GGSN to perform network address translation (NAT). But this also means that there is 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
procedure that requires access to the subscriber’s UICC – a special smart card that needs to be plugged 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 (see below). Most MNOs also perform the authentication procedure when a subscriber connects to their 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 identified by their cell ID. Normally, directional antennas are used, which allows each node B to service multiple surrounding cells. Whenever a UE attaches to the mobile network, it registers with a cell that covers the UE’s location to tell the network where the subscriber using the UE can be found. Having UEs repeat this location update procedure every time they enter a new cell would lead to a lot of signaling traffic. Therefore, adjoining cells are arranged in groups and an idle UE has to perform a location update only when is moves into the area of a different group of cells or when the amount of time since the last location update has exceeded a specific value. For the CS domain, the areas of grouped cells are called location areas (LAs). For the PS domain, cells are 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 to LAs, without further subdivision. If there is an incoming call to an idle UE (whose current cell is therefore unknown) the network has to first broadcast a paging request in all cells of the UE’s last reported LA. After the UE’s response, the call can be established in its present cell. While the call is ongoing or while the UE is in a state with similar requirements, the UE constantly monitors the signal strength of nearby network antennas and shares this information with the RNC responsible for the current node B. For better reception or load balancing, that RNC may instruct the UE to switch to a different cell. Since neighboring cells partially overlap, an almost seamless handover between them may be possible.
Within the core network, subscribers are identified by their IMSI. On the air interface, UEs and node Bs use temporary identities instead, to prevent third parties that may be listening to unencrypted control messages from identifying and tracking subscribers. The network assigns a random, frequently changing identifier called the temporary mobile subscriber identity (TMSI) to each subscriber. The TMSI changes with each LAU. For the PS domain, there exists an analogue transient 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 encryption keys are generated as part of the subscriber authentication procedure. When identifying with a TMSI or P-TMSI outside of the LA and RA respectively where it was assigned, the UE must also supply the original location or routing area identity (LAI, RAI). The MSC or SGSN of the new cell can then contact its respective counterpart responsible for that area and retrieve the IMSI to which the temporary identity is mapped. If the UE cannot provide a valid TMSI or P-TMSI or if the 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 verify its authenticity, but the IMEI is used for blocking stolen or disruptive devices. It also permits the MNO 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 be neither 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. This thesis focuses on UICCs with a USIM application, which enables the subscriber to make use of a 3G mobile network. The properties of UICCs are defined in[18]. Figure 2.6 shows the four
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 network in a predefined file structure. Figure 2.7 shows select elementary files under the USIM ADF. These EFs 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 instead of immediately writing changes to and always reading the current values from the card. If the UE does not adhere to initialization and termination procedures required by the application or in case of an error in the network, then the UICC, the UE, and the stationary network could end up in inconsistent states. For example, a sudden removal of the card from the terminal while the UE is attached to the mobile network’s CS domain would lead to a loss of the current TMSI on the subscriber side, because the UE would not have time to save the current value on the UICC for later 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 is based on both sides proving possession of a secret key K. Confidentiality is ensured by symmetric encryption of transmissions based on a cipher key CK. And data integrity is provided by digital signing of messages based on an integrity key IK. This allows the receiver to identify modified or altogether forged messages.
Mutual authentication and the establishment of CK and IK is achieved in a single procedure called 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 of cipher 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 contains a random challenge RAND and several derived values: the expected response XRES, keys CK and IK, and an authentication token AUTN. Besides RAND and a set of generating functions labeled f1 to f5, the subscriber’s secret key K is needed to compute the derived values. The subscriber’s HLR and USIM implement the same generating functions and they are they only entities with knowledge of K. AUTN encodes a sequence number that can be used to detect old authentication vectors.
After selecting the next authentication vector from its VLR, the MSC forwards RAND and AUTN to the UE, demanding the challenge response RES. Reading K off the UICC is supposed to be impossible2. The UICC shall allow only indirect access to K via theAUTHENTICATEcommand.
This instruction takes two input parameters: RAND and AUTN. The USIM first verifies AUTN to make sure that the challenge originated from a trusted network with access to recent, unused authentication 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 strategies have been reported, such as probing data bus wires[51], exploiting software vulnerabilities of the UICC[39], and differential power analysis[57].
ID-1 UICC
Figure 2.6: UICC form factors and pinout
Master file '3F00'MF
Contain files for GSM network access by UEs that only support SIM cards List of ADF names Language settings File access rules
DFTELECOM
Figure 2.7: UICC and USIM file structure. Only select files are shown, including their names and hexadecimal file identifiers. Graphic based on[2, Figures 4.1 and 4.2].
UICC/USIM UE MSC/VLR HLR
Distribution of authenticationvectors from HLR to VLR
Generate authentication
RES(i), CK(i), IK(i) User authentication response RES(i)
Authentication andkey agreement
Figure 2.8: Authentication and key agreement (AKA) in the CS domain with preceding retrieval of 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 actually start ciphering and integrity protection for the CS domain or to update the used keys, the MSC has 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 no security).
RAND, AUTN, and RES may be sent as cleartext over the air interface. But since user data is only 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, as pointed out by[35].
The UE shall send the user authentication response less than 1 s after receiving the user au-thentication request. Processing of theAUTHENTICATEcommand by the UICC shall take less than 500 ms.
Card Application Toolkit
Card application toolkit (CAT) is an optional but typically implemented set of mechanisms in the UICC and the UE that allow applications on the card to not only respond to incoming
instruc-UE RNC MSC/VLR
Figure 2.9: Start of integrity protection and ciphering in the CS domain following authentication and key agreement. Graphic based on[3, Figure 14].
tions, but to issue certain commands themselves. CAT is defined in[19]. UICCs that support it are referred to as proactive. A proactive UICC that is plugged into a compatible UE may trigger a wide range of activities, such as making phone calls, sending short messages, drawing responsive menus on the UE’s screen, and communicating with other UICCs connected to the same UE. The terminal 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 terminal profile.
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 by smart cards. They can only issue a command, after having finished processing a terminal command without 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, which signals both the successful termination of the terminal’s last instruction as well as the length of the information describing the pending proactive command. The terminal then fetches that data and ultimately returns the response using special terminal commands.
Terminal UICC
Figure 2.10: Position of the CAT layer in the UICC communication layer stack. The standard smart card communication layers shown previously in Figure 2.3 are colored gray.
OTA Programming of UICCs – an Excursion
From time to time, an MNO might want to reconfigure issued UICCs. To avoid costly recalls and replacements, a UICC may support over-the-air (OTA) updates, i.e. changes of the data stored on the card via commands sent by the MNO over the mobile network. For example, the network operator 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 a different provider without having to replace the UICC in the phone. Apple was the first company to introduce cards with this feature. According to [8], their proprietary Apple SIM solution is likely to be replaced by the embedded SIM (eSIM)[49]industry standard, which pursues the same goal.