Hardware

A Brief Introduction to SIM Cards

SIM cards are far more than simple flash drives — they are well-protected microcomputers with CPUs, RAM, and cryptographic hardware. This article explains their architecture, manufacturing, software, file systems, and the GSM authentication process.

When asked "What do you do?", answering "software developer for SIM cards" often surprises even technically-minded people. Many believe a SIM card is "something like a flash drive."

This article briefly explains what a SIM card is, why it's needed, and what's inside.

Core Definition

A SIM card is a specific type of contact smart card with a microprocessor. Essentially, it's a well-protected microcomputer featuring a CPU, optional crypto-coprocessor, ROM, RAM, and NVRAM (functioning as the PC equivalent of a hard drive), plus hardware random number generators and hardware implementations of cryptographic algorithms.

The microprocessor smart card architecture can be roughly represented as follows:

Manufacturing Overview

Understanding the subsequent material requires explaining the key manufacturing processes.

1. Chip Production

Performed by: Chip manufacturer (silicon vendor)

End product: Wafer with chips

Companies like Samsung, ST Microelectronics, Infineon, and SST produce the chips.

The module's reverse side shows the white rectangle in the center — that's the SIM chip itself:

2. Module Assembly

Performed by: Smart card manufacturer (card vendor) or a third-party assembly factory

End product: Tape with modules (chip + contact pad)

The wafer is cut into individual chips (often by the chip manufacturer), chips are attached to contact pads, contacts are soldered, and the chip is sealed with glue. This complete assembly is called a "module":

3. Card Production

Performed by: Card vendor

End product: SIM card

Modules are extracted from the tape, mounted on the plastic card base, and then the file system and applications are loaded. Card personalization follows — loading unique data per card (various IDs, keys, etc.) and printing onto the card itself (ICCID and PIN codes for SIM cards):

Card Types

Currently, SIM cards divide into two groups by memory type: those using ROM and EEPROM, and those using Flash memory.

In the first type, the operating system (OS) and constantly-used, minimally-changing applications are placed in ROM by the chip manufacturer (stage one). Production cycles are lengthy — two to three months between OS release and first chip shipment. The card manufacturer uses EEPROM for loading the file system (FS) and applications.

With Flash cards, the OS, FS, and applications all reside on Flash memory. Flash enables OS loading during module assembly or card production (stages two and three). Currently, Flash cards have virtually replaced ROM cards in the SIM market. Flash chips cost less and allow easier OS modifications. Card manufacturers benefit from simpler chip ordering — rather than ordering chips with specific OS versions, they order chips with various memory sizes and load the needed OS for specific operators. Since chip purchase forecasts typically occur once yearly, planning becomes substantially easier.

Software: Native vs. JavaCard

Yes, that's correct — Java runs on cards. By software composition, smart cards divide into two major groups: native and javacard.

Native Cards

Native card software is written in C. Required applications are typically tightly integrated with the OS and load simultaneously. Installing third-party applications on native cards is impossible. Additional operator-requested functionality often requires adding to the OS code. Due to C usage and OS simplicity, OS sizes remain quite small (approximately 10–20 KB for SIM cards). Consequently, native cards occupy the low-cost segment where operators want only simple menus.

JavaCard

During Java's expansion era, Sun Microsystems created the JavaCard specifications. The idea was to enable installing applications (applets) on cards from various manufacturers and chips. In 1996, Schlumberger's smart card division (later renamed Axalto, now Gemalto) introduced the first JavaCard. The concept is straightforward: besides the OS, the card contains a Java virtual machine. Developed applications compile to bytecode and load onto the card. Applications load after OS loading (during card production), and if the card contains a Remote Applet Manager, JavaCard applets can be installed post-release over the air (OTA).

The JavaCard development language is heavily reduced Java — much more restricted than J2ME. Primitives are limited to boolean, byte, and short, with optional int support (rarely used for compatibility, as not all manufacturers support it). Familiar classes like String don't exist (only Object, Throwable, and several Exception classes from java.lang). There's no multithreading and no garbage collector. JavaCard drawbacks include slower execution speed and high memory demands (both RAM and EEPROM/Flash). Java cards cost more due to more expensive chips and the complex software architecture.

Applications

Previous text frequently mentioned applications, but non-experts often wonder what applications actually exist on cards.

First, core card functionality can become a separate application. For example, a Java-written SIM applet implementing full SIM functionality. R-UIM applications exist (used in CDMA networks). Visa or Mastercard applications transform smart cards into bank cards. With Java, the OS can retain just memory management, I/O, and the Java machine. If manufacturers need SIM cards, they load the SIM applet; for Visa cards, they load the Visa application.

Second, there's a class of card applications: microbrowsers. These are bytecode interpreters for building SIM menus — not Java bytecode, but bytecode understood by installed browsers. Menus are typically developed in XML-like markup languages, converted to bytecode, and loaded into the browser. Currently, S@T browsers from SIMalliance and WIB from SmartTrust dominate. These organizations don't develop browsers themselves; they write specifications and certify browsers written to those specifications.

Third, there are Java-developed SIM menus (without browsers) or background applets. For instance, an applet that tracks your phone. Insert the card into a new phone, and the SIM sends the new phone's IMEI to the operator, which responds with WAP/GPRS settings for your specific model.

File System

SIM cards contain file systems like desktop computers. Files come in two types: DF (Dedicated File — the folder equivalent) and EF (Elementary File — a regular file equivalent). The root DF file is called MF (Master File).

The SIM file system stores secret keys, address books, recent SMS lists, operator names, preferred roaming networks, forbidden networks, and more. File access levels naturally exist. Keys often have NEVER access for reading, preventing them from ever being read externally.

Purpose: Authentication

SIM menus and other "non-system" applications are simply value-added services. The card's primary purpose is subscriber identification and network authentication.

For this, the card contains the IMSI (International Mobile Subscriber Identity) — the unique SIM identifier — and a 128-bit secret key Ki.

Below is the GSM network authentication procedure and session key Kc generation:

Authentication uses algorithm A3; Kc generation uses algorithm A8. When the Authentication Center (AuC) receives a card authentication request, it generates a 128-bit pseudo-random sequence RAND and sends it to the SIM card. Knowing the card's IMSI, the AuC uses the Ki key tied to that IMSI and the RAND data as inputs to algorithms A3 and A8. The card simultaneously performs identical calculations.

Algorithm A3's result — the Signed Response (SRES) — is sent from the card to the AuC, where the received SRES is compared with the calculated SRES. If they match, authentication succeeds. The Kc key from algorithm A8 is subsequently used to encrypt traffic between the phone and the network.

Card "cloning" programs exploit a vulnerability in the old A8 algorithm version (COMP128-1). Currently, GSM networks widely use COMP128-2 and COMP128-3. The vulnerability was discovered in 1999, yet some GSM operators still haven't migrated to versions two and three (which currently have no known vulnerabilities).

Conclusion

This article attempted to concisely explain SIM cards. Hopefully it succeeded. Nearly everything described applies equally to USIM cards used in 3G networks (UMTS) and R-UIM cards (CDMA networks), except the authentication procedure. Feel free to leave comments or questions.