Skip to content

SIM

Summary

  • A "SIM card" is really a small smart card computer (a UICC) — its own CPU, memory, and file system — not just a chip storing a phone number.
  • SIM, USIM, and ISIM aren't different physical cards; they're different applications that can all live on the same UICC, each holding the credentials and logic for a different generation/service (2G, 3G/4G/5G, IMS voice).
  • eSIM and iSIM don't change what's stored — they change how — replacing a removable card with a permanently soldered chip (eSIM) or logic embedded directly into the main SoC (iSIM), provisioned remotely instead of swapped by hand.

Physical Form Factors

Before anything about the card's structure, "SIM" has referred to a shrinking series of physical cutouts of the exact same chip:

SIM Formats

Figure 1. SIM Formats: From left, full-size SIM (1FF), mini-SIM (2FF), micro-SIM (3FF), and nano-SIM (4FF)1

Form Factor Introduced Dimensions (approx.)
Standard-SIM (1FF) 1990 85.60 × 53.98 mm — Full-size / Standard SIM
Mini-SIM (2FF) 1996 25 × 15 mm — the original "credit-card-cutout" size
Micro-SIM (3FF) 2003 15 × 12 mm
Nano-SIM (4FF) 2012 12.3 × 8.8 mm — current smallest removable size
eSIM / MFF2 2016 (consumer) ~6 × 5 mm or smaller, soldered directly to the board

Table 1. SIM Physical Form Factors

Same chip, smaller plastic

A Mini, Micro, and Nano SIM from the same carrier are frequently the exact same silicon, just punched out of progressively smaller plastic carriers — which is why "cutting" a SIM down a size (carefully) has historically worked.

UICC Hardware Structure

The UICC (Universal Integrated Circuit Card) is the actual smart card hardware; SIM/USIM/ISIM are applications that run on it.2 Physically, it's built like any ISO/IEC 7816 smart card:

UICC Hardware Structure

Figure 2. SIM chip structure and packaging1

The 8 physical contacts follow the ISO/IEC 7816-2/7816-3 layout:5

UICC contact layout (ISO/IEC 7816-2)
C1:  VCC                # (1)!
C2:  RST                # (2)!
C3:  CLK                # (3)!
C4:  (reserved / USB)   # (4)!
C5:  GND                # (5)!
C6:  VPP / SWP          # (6)!
C7:  I/O                # (7)!
C8:  (reserved / USB)   # (8)!
  1. C1 — VCC — Supply voltage from the phone to the card (historically 5V, now typically 1.8V or 3V on modern low-power cards).
  2. C2 — RST — Reset line; the phone pulses this to trigger the card's Answer To Reset (ATR) sequence.
  3. C3 — CLK — Clock signal supplied by the phone; the card has no internal oscillator and derives timing entirely from this line.
  4. C4 — Reserved/USB — Historically unused on GSM cards; some modern UICCs use it for a USB data interface.
  5. C5 — GND — Ground reference.
  6. C6 — VPP/SWP — Originally a programming voltage for early cards; on modern UICCs this is commonly repurposed as the SWP (Single Wire Protocol) line, used to connect the SIM to an NFC controller for contactless payments.
  7. C7 — I/O — The single bidirectional serial line carrying every APDU command and response between phone and card — the entire SIM "conversation" happens over this one wire.
  8. C8 — Reserved/USB — Paired with C4 for USB-capable cards.

Internally, the chip is a self-contained computer:

Component Role
CPU Executes the card OS and cryptographic operations (authentication, key derivation)
ROM Card operating system and fixed applications, written at manufacture
EEPROM / Flash The actual file system — IMSI, keys, contacts, network data — persists without power
RAM Working memory during a session; cleared when power is removed
Crypto Co-processor Accelerates algorithms like MILENAGE/COMP128 (2G/3G/4G auth) without exposing key material to the host

Table 2. UICC Internal Components

Keys never leave the card

The whole security model depends on one rule: the long-term secret key (Ki) never leaves the UICC, ever. The phone sends a random challenge in; the card runs the authentication algorithm internally and only returns the computed result. This is precisely why cloning a SIM by reading its memory over the I/O line doesn't actually work.

SIM vs. USIM vs. ISIM: Applications, Not Cards

A modern UICC typically holds multiple applications side by side, selected by their AID (Application Identifier):3

Application Generation Purpose
SIM 2G (GSM) Legacy authentication (COMP128), basic subscriber data
USIM 3G/4G/5G Stronger MILENAGE-based mutual authentication, larger file set, mandatory for LTE/5G registration
ISIM IMS (VoLTE/VoWiFi) Separate credentials specifically for IP Multimedia Subsystem (voice-over-LTE/Wi-Fi) registration

Table 3. SIM Application Types on One UICC

A phone requesting LTE service will SELECT the USIM application's AID; a VoLTE call setup separately selects the ISIM application — both coexisting on the same physical (or embedded) card.

The File System: MF, DF, EF

Everything the card stores is organized in a strict tree, defined by ISO/IEC 7816-4 and extended for telecom use by 3GPP TS 31.102:4

UICC File System Structure

Figure 3. The UICC/SIM file system hierarchy — MF at the root, with DF_TELECOM and DF_GSM as its 2G-era dedicated files4

USIM File System Structure

Figure 4. The USIM (ADF_USIM) file system, selected by AID rather than a fixed file ID3

Three file types, not just folders and files

ISO 7816 defines exactly three file categories: MF (the one root), DF (Dedicated Files — directories, including ADFs), and EF (Elementary Files — the actual leaf data, further subtyped as transparent (raw byte array), linear fixed (record-based, like a phonebook), or cyclic (a rolling log, like recent calls).

Level FID Name Contents
MF 3F00 Master File The root of the file system
EF 2FE2 EF_ICCID The card's unique serial number
EF 2F00 EF_DIR Directory of applications (AIDs) on the card
DF 7F10 DF_TELECOM Phonebook, SMS, and other telecom services
↳ EF 6F3A EF_ADN Abbreviated Dialing Numbers (phonebook)
↳ EF 6F42 EF_SMSP SMS parameters
DF 7F20 DF_GSM The 2G SIM application's files
↳ EF 6F07 EF_IMSI The subscriber's IMSI
↳ EF 6F20 EF_Kc Cached ciphering key from the last GSM session
ADF (by AID) ADF_USIM The 3G/4G/5G USIM application's files
↳ EF 6F07 EF_IMSI The subscriber's IMSI (USIM copy)
↳ EF 6F38 EF_UST USIM Service Table — which optional services are enabled
↳ EF 6FAD EF_AD Administrative Data
ADF (by AID) ADF_ISIM The IMS application's files
↳ EF 6F02 EF_IMPI IMS Private User Identity
↳ EF 6F04 EF_IMPU IMS Public User Identity

Table 4. Common SIM/USIM/ISIM File System Entries

ADFs don't have a fixed FID

Unlike DF_TELECOM or DF_GSM, ADF_USIM and ADF_ISIM aren't reached by a fixed file identifier — they're selected directly by their AID, since each is a full standalone application rather than a plain subdirectory.

APDUs: How the Phone Talks to the Card

Every single interaction — selecting a file, reading data, running authentication — is one APDU (Application Protocol Data Unit) command/response pair over that single I/O line.8

Command APDU

Field Length (bytes) Description
CLA 1 Instruction class — indicates the command type, e.g. interindustry or proprietary
INS 1 Instruction code — the specific command, e.g. "select," "write data"
P1–P2 2 Instruction parameters, e.g. an offset into a file to write data at
Lc 0, 1, or 3 Encodes the number (Nc) of command data bytes to follow
Command data Nc The actual Nc bytes of data
Le 0, 1, 2, or 3 Encodes the maximum number (Ne) of response bytes expected

Table 5. Command APDU Structure

How exactly do Lc and Le encode their length?
Lc length Meaning
0 bytes Nc = 0
1 byte (value 1–255) Nc equals that value
3 bytes (first byte must be 0) Nc in the range 1–65,535 (all three bytes can't be zero)
Le length Meaning
0 bytes Ne = 0
1 byte (1–255, or 0) Ne equals that value, or 256 if the byte is 0
2 bytes (only if extended Lc was used) Ne equals that value (1–65,535), or 65,536 if both bytes are zero
3 bytes (only if Lc was absent, first byte must be 0) Ne encoded the same way as the 2-byte case

Response APDU

Field Length (bytes) Description
Response data Nr (at most Ne) The actual response data
SW1–SW2 (status trailer) 2 Command processing status — e.g. 90 00 (hex) indicates success

Table 6. Response APDU Structure

Common Commands

Command INS Purpose
SELECT 0xA4 Navigate to a specific MF/DF/EF or application AID
READ BINARY 0xB0 Read raw bytes from a transparent EF
UPDATE BINARY 0xD6 Write raw bytes to a transparent EF
VERIFY 0x20 Submit a PIN for verification
AUTHENTICATE 0x88 Run the network authentication algorithm (MILENAGE) using a network-supplied challenge
STATUS 0xF2 Query the current selected file's metadata

Table 7. Frequently Used SIM/USIM APDU Commands

eSIM: Same Model, Remote Provisioning

An eSIM is not a new kind of authentication or file system — it's the same UICC model, just soldered to the board as an eUICC (embedded UICC) and loaded with a profile over the air instead of by inserting a pre-programmed card.6

Role Description
eUICC The embedded chip itself — ships blank (or with a bootstrap profile) and is never swapped
Profile A complete SIM/USIM/ISIM file set — MF/DF/EF structure, IMSI, keys, applications — downloaded and installed as one unit
SM-DP+ Subscription Manager – Data Preparation: the server (typically operated by or for the carrier) that prepares and securely delivers a specific profile to a specific eUICC
SM-DS Subscription Manager – Discovery Server: an optional server that helps a device find which SM-DP+ to talk to, used in some (mainly M2M) provisioning flows
LPA Local Profile Assistant: software (often on the device itself) that manages downloading, enabling, disabling, and deleting profiles — the "SIM toolkit" an end user or technician actually interacts with

Table 8. eSIM Ecosystem Roles (GSMA RSP)

Consumer eSIM vs. M2M eSIM

GSMA defines two separate remote-provisioning specifications: SGP.22 for consumer devices (phones, tablets — profile switching triggered by the user via QR code or LPA app) and SGP.02 for M2M (machine-to-machine — remote, often carrier-initiated switching for industrial/IoT deployments with no user interface).6

iSIM: One Step Further

An iSIM (integrated SIM) goes past eSIM by removing the separate chip entirely — the UICC's secure environment is implemented as an isolated, certified enclave directly inside the main cellular SoC, using the same processor die instead of a discrete piece of silicon.7 Functionally, it still runs the same USIM/ISIM applications over the same logical file structure — the difference is purely physical integration, aimed at further reducing board space, cost, and power for compact IoT devices.

SIM (removable) eSIM iSIM
Physical form Removable card Soldered chip Integrated into main SoC
Swappable by user Yes No — profile-switched instead No — profile-switched instead
Board space Largest Smaller Minimal (shares SoC die)
Typical use Consumer phones Consumer + industrial Highly space/power-constrained IoT

Table 9. SIM vs. eSIM vs. iSIM

Useful Resources


  1. Wikipedia contributors. (n.d.). SIM card. Wikipedia. https://en.wikipedia.org/wiki/SIM_card ↩↩

  2. ETSI. (n.d.). TS 102 221 — UICC-Terminal interface; Physical and logical characteristics. https://www.etsi.org/deliver/etsi_ts/102200_102299/102221/ ↩

  3. 3GPP. (n.d.). TS 31.102 — Characteristics of the Universal Subscriber Identity Module (USIM) application. https://www.3gpp.org/DynaReport/31102.htm ↩↩

  4. ISO/IEC. (n.d.). ISO/IEC 7816-4 — Organization, security and commands for interchange. https://www.iso.org/standard/54550.html ↩↩

  5. ISO/IEC. (n.d.). ISO/IEC 7816-3 — Cards with contacts; Electrical interface and transmission protocols. https://www.iso.org/standard/38770.html ↩

  6. GSMA. (n.d.). RSP Technical Specification (SGP.22 / SGP.02). https://www.gsma.com/esim/ ↩↩

  7. GSMA. (n.d.). iSIM — Integrated SIM. https://www.gsma.com/esim/isim/ ↩

  8. Wikipedia contributors. (n.d.). Smart card application protocol data unit. Wikipedia. https://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit ↩