4G/LTE - Usim

 

 

 

UICC/USIM

 

USIM (Universal Subscriber Identity Module) and UICC (Universal Integrated Circuit Card) are components of modern mobile networks that store user identity, authentication, and network access information:

  • UICC: A smart card that serves as a platform for various applications like USIM, enabling secure storage and communication between the device and the network. It can support multiple applications, such as USIM for 3G/4G/5G, ISIM for IMS services, and more.
  • USIM: A specific application on the UICC card, designed for 3G and later networks. It manages user authentication, stores network configurations, and facilitates secure communication with the cellular network, offering enhanced security and features over older SIM cards.

Followings are the topics that I am interested and noted here

What is inside ?

A UICC (Universal Integrated Circuit Card) is a smart card that integrates various hardware and software components to manage secure communication between a mobile device and a cellular network. Here’s a breakdown of its key components:

Microcontroller - MCU:

The heart of the UICC, typically an embedded microcontroller with limited processing power. It handles data processing, secure key management, and execution of applications like USIM.

Memory:

A UICC keeps three kinds of memory, and each one has a different job. The card must keep the subscriber data when the phone is off, but it computes in a small working memory that is cleared at every power cycle.

  • ROM (Read-Only Memory): Stores firmware and operating system.
  • EEPROM (Electrically Erasable Programmable Read-Only Memory): Stores user data, network information, encryption keys, and other dynamic data.
  • RAM (Random Access Memory): Provides working memory for processing tasks during operation.

Cryptographic Co-processors:

Authentication runs inside the card, so the card needs its own cryptographic hardware. The long-term key K is not in any EF of 31.102, so the terminal cannot read it. For the AUTHENTICATE command, the USIM computes RES, CK and IK from K and RAND, and it returns only these results (31.102 clause 7.1).

  • Supports encryption algorithms like AES, DES, or RSA for secure communication and authentication.
  • Crucial for operations like generating session keys and validating network challenges.

Software Stack:

The hardware above is general-purpose, so the software decides what the card is. One card can carry several applications at the same time, and the file system keeps their data apart.

  • Operating System: A specialized OS that manages communication between the UICC and external entities, ensuring security and resource management.
  • File System: Organizes stored data into structured files (e.g., contacts, SMS, authentication data).
  • Applications: USIM, ISIM, CSIM, and others, depending on the network requirements.

Communication Interface:

Uses protocols like ISO/IEC 7816 (physical communication with the device) and APDU commands for data exchange. (Refer to this note for further details) The terminal is always the master on this interface. It sends a command APDU, and the UICC answers with a response and a status word.

31.101 adds 3GPP rules on top of ETSI TS 102 221 for this interface. For example, a UICC that holds a 3GPP application must support at least two consecutive voltage classes, such as AB or BC. The card reports its classes in the ATR, which the Boot Up Process below describes.

  • The USIM is an application, not the card : the UICC is the platform, and the USIM is one application on it.
  • The long-term key stays on the card : the USIM returns RES, CK and IK, and never K.
  • The terminal drives the interface : every exchange starts with a command APDU from the terminal.

Operating System in UICC ?

The operating system in a UICC is a specialized, embedded OS that manages secure access, file handling, and communication between the UICC and external devices like mobile phones. It handles data encryption, authentication processes, and execution of applications (e.g., USIM, ISIM).

File System

The file system of a UICC is organized in a hierarchical structure to manage various types of data and applications. It consists of the following:

  • Master File (MF): Acts as the root of the file structure. It contains all other files and directories, providing access to the entire UICC system.
  • Dedicated Files (DF): These function like subdirectories, each dedicated to a specific application or function. For instance:
    • DF_TELECOM: Manages user data like phonebook entries and SMS.
    • DF_GSM or ADF_USIM: Holds network-specific data for 2G/3G services.
  • Elementary Files (EF): These are the actual data containers and can store various types of information. Some of the examples are (For further details about EF files, refer to this note) :
    • IMSI (International Mobile Subscriber Identity): A unique identifier for the user.
    • Authentication Keys: For network authentication and encryption.
    • Contacts and SMS: Stores phonebook entries, messages, and user preferences.
    • Network Configuration Files: Includes information like PLMN lists (preferred and forbidden networks).

The hierarchical structure of these files helps in organizing data for secure storage and efficient access, ensuring that each function or service has its designated area in the UICC's memory. This structured approach also simplifies the retrieval of specific information by applications like USIM, ISIM, or CSIM.

Two details in this file structure need care on a UICC. First, the USIM is not a plain DF under the MF. It is an application DF, ADF_USIM, and the terminal selects it with the AID stored in EF_DIR (31.102 clause 4.7). DF_TELECOM stays under the MF, and the files for GSM access sit in DF_GSM-ACCESS ('5F3B') inside ADF_USIM. Second, the keys in an EF are session keys. EF_Keys holds the ciphering key CK and the integrity key IK of the last authentication, and EF_IMSI ('6F07') holds the IMSI. The long-term key K is not in any EF.

Boot Up Process

The UICC has a boot-up process for its operating system, which is initiated when the UICC is powered on by the mobile device. This boot-up process ensures that the UICC is ready to communicate with the mobile device, allowing secure interactions between the device and the network.

Here's an overview of the process:

  • Power-On: The mobile device supplies power to the UICC, enabling it to start its internal operations.
  • Reset: The UICC receives a reset signal (RST) from the device, prompting it to initialize its internal state.
  • ATR (Answer to Reset): The UICC sends an ATR message back to the device, containing information about its communication capabilities and protocols. The information contained in this message allows the mobile device to configure itself to communicate with the UICC effectively. Followings are what the information carries :
    • Protocol Type Indicator: Indicates the communication protocol supported, such as T=0 or T=1, which defines how data will be exchanged.
    • Timing Parameters: Specifies clock rates and bit rates, helping the mobile device sync with the UICC.
    • Supported Features: Lists features like supported voltage levels or additional capabilities.
    • Historical Bytes: Can contain manufacturer information or other specific data about the UICC’s functionalities.
  • Operating System Initialization: The embedded OS initializes, loading critical system files and preparing the file system (including MF, DF, and EF structures).
    • Self-Check and Diagnostics: The OS first performs self-diagnostics to verify the integrity of hardware components, ensuring that the microcontroller, memory, and cryptographic modules are functioning correctly.
    • Loading System Files: It loads critical system files from ROM (firmware) into RAM, which includes the basic OS instructions and routines needed for subsequent processes.
    • File System Setup:
      • Master File (MF) Initialization: Sets up the root directory of the file system, which acts as the entry point for accessing other files.
      • Dedicated Files (DF) Configuration: Loads and organizes DFs, which are used for specific services like DF_GSM, DF_TELECOM, or ADF_USIM.
      • Elementary Files (EF) Preparation: Ensures EFs (where critical user data like IMSI, authentication keys, and network configuration are stored) are accessible for future APDU command processing.
    • Security Context Setup: Initializes encryption modules and secure key management systems, ensuring that authentication keys and encryption algorithms are ready for secure communication.
    • Memory Management: Sets up memory regions, ensuring that EEPROM for persistent storage and RAM for temporary data are properly allocated and managed for the card’s operations.
    • Protocol Stack Activation: Prepares the communication protocols, such as T=0 or T=1, for interfacing with the mobile device. This ensures that the card can send and receive APDU commands correctly.
  • Application Activation: The USIM/ISIM applications are activated, allowing the UICC to process APDU commands for authentication, network configuration, and other operations. This activation process ensures that the UICC can securely communicate with the mobile network, handle various user services, and provide a secure environment for data storage and transmission. It allows the mobile device to utilize the capabilities of the UICC, such as network authentication, secure key exchanges, and data management. Overall process goes as follows.
    • Applets Initialization: Activates different applications like USIM for cellular services and ISIM for IP-based services, enabling the UICC to support various network features.
      • NOTE  : applets on a UICC are similar to Java applets but specifically designed for the secure environment of smart cards. These applets are usually developed using the Java Card platform, which is a subset of Java tailored for resource-constrained environments like smart cards, including UICCs. Key Characteristics of the applet are:
        • Java Card Platform: Allows developers to write applets in Java for secure elements like UICCs.
        • Security Focused: Java Card applets have built-in security features, enabling them to handle encryption, authentication, and secure data storage.
        • Multifunctional: These applets can perform tasks like managing USIM/ISIM functions, handling secure communications, or even supporting contactless payment applications.
    • Loading Network Profiles: Retrieves stored network-specific data, such as IMSI, authentication keys, and access control lists, which are required for network registration and secure communication.
    • Setting Security Context: Establishes encryption keys and algorithms for secure data exchange during network authentication.
    • Command Processing Enablement: Prepares the UICC to receive and process APDU commands from the mobile device, allowing it to handle requests like PIN verification, accessing network configurations, and storing or retrieving user data.
    • Application Registration: Registers the applications with the mobile device's baseband processor, ensuring compatibility and enabling the device to recognize and interact with the activated USIM/ISIM applets for network operations.

Proactive Command

A Proactive Command in a UICC refers to an instruction sent by the UICC to the mobile device, allowing the UICC to initiate specific actions independently. This is part of the SIM Toolkit (STK) functionality, enabling the UICC to request the device to perform tasks like displaying a message, setting up a call, sending an SMS, or establishing a data connection.

Examples of Proactive Commands:

  • DISPLAY TEXT: Instructs the device to display a message to the user.
  • SET UP CALL: Requests the device to initiate a call.
  • SEND SHORT MESSAGE: Asks the device to send an SMS to a specific number.
  • LAUNCH BROWSER: Directs the device to open the web browser to a specific URL.
  • PROVIDE LOCAL INFORMATION: Requests local information from the device, such as the location information (MCC, MNC, LAC/TAC and cell ID of the serving cell), the IMEI, or the date and time.

These commands allow the UICC to interact with the device and the user, enabling dynamic services like operator-specific menus, secure over-the-air updates, or roaming management without user intervention. This capability makes the UICC more than a passive data store, allowing it to actively manage its interaction with the network and the user interface.

How it is stored, loaded and executed ?

The steps below follow one command from the applet code to the result on the phone. The paragraph after them shows how the card gets its turn on the interface. The Proactive Command process in a UICC involves several steps from storage to execution:

  • Storage:
    • Proactive commands are typically stored as part of the applets (like USIM or custom Java Card applets) within the UICC.
    • The logic for these commands is embedded in the applet's code, written in Java Card language, which defines conditions under which the command should be triggered.
  • Loading:
    • During the UICC's boot-up and initialization, the applet containing the proactive command logic is loaded into memory.
    • The mobile device and UICC establish a communication session using the ISO/IEC 7816 protocol, preparing both to exchange commands like APDUs.
  • Triggering and Execution:
    • The applet within the UICC monitors conditions and events (e.g., network changes or user actions).
    • When a trigger condition is met (like network registration), the applet sends a Proactive Command to the mobile device using APDU commands.
    • The Proactive Command is then processed by the mobile device's SIM Toolkit (STK) engine, which interprets the command and performs the requested action, like displaying a message or sending data.
  • Response Handling:
    • The device sends a response back to the UICC, indicating the result of the executed action.
    • The UICC can then store the result or continue with further commands if needed.

One detail in the steps above needs care. The UICC cannot start an exchange on the ISO/IEC 7816 interface, because the terminal always sends the command APDU. So the UICC signals in its status word that a proactive command is pending, and the terminal then fetches the command. The terminal also gives the card regular chances to do this. In idle mode it sends STATUS commands at an interval negotiated with the UICC (31.101 clause 14.2), and the card can change that interval with the POLL INTERVAL command. After the action, the terminal reports the result in a TERMINAL RESPONSE (31.111 clause 6.8).

  • The UICC asks, and the terminal acts : a proactive command is a request, and the terminal performs the action.
  • The command names come from 31.111 and ETSI TS 102 223 : for example DISPLAY TEXT, SET UP CALL and PROVIDE LOCAL INFORMATION.
  • The terminal polls the card : STATUS commands in idle mode give the UICC a chance to raise a pending command.
  • Every command ends with a TERMINAL RESPONSE : it tells the UICC whether the action succeeded.

Reference