SIM Forensics: Part 1
A smart card, also known as an Integrated Circuit Card (ICC), is a micro-controller based access module. It is a physical/logical entity and can be either a Subscriber Identity Module (SIM) or a Universal Integrated Circuit Card (UICC). Originally, the ICC defined for 2G networks was the SIM. In 3G networks, the SIM may also be a logical entity (application) on a 3G UICC thereby making it functionally the same as a 2G SIM. The Universal Subscriber Identity Module (USIM) is a logical application running on a UICC smart card, which normally only accepts 3G Universal Mobile Telecommunications Service (UMTS) commands. A USIM can have multiple phone numbers assigned to it, thus allowing one phone to have multiple numbers. If the USIM and SIM applications reside on the same UICC, they cannot be active at the same time.
SIM Technology and Functionality
SIMs are found in GSM, iDEN, and Blackberry handsets and are also used by satellite phone networks such as Iridium, Thuraya, and Inmarsat. Under the GSM framework, a cell phone is termed a Mobile Station, consisting of a SIM card and a handset (Mobile Equipment–ME). One very important and functional feature of a SIM card is that it can be moved from one GSM compatible phone to another, thereby transferring all of the subscriber’s information.
The first SIM cards were about the size of a credit card. As cell phones began to shrink in size, the mini-SIM (about one-third the size of a credit card) was developed. Today an even smaller version, the micro-SIM, is available. Each of these three iterations varies in physical size and the functionality supported. Normally, a SIM card provides functionality for both the identification and authentication of the subscriber’s phone to its network; contains storage for phone numbers, SMS, and other information; and allows for the creation of applications on the card itself. The basic functions are illustrated in Figure 1.
SIMs contain both a processor (CPU) and an operating system which is either native (proprietary, vendor specific) or Java Card (a subset of the Java programming language). SIMs also have Electrically Erasable Programmable Read Only Memory (EEPROM), Random Access Memory (RAM) for controlling program execution, and persistent Read Only Memory (ROM) which stores user authentication, data encryption algorithms, the operating system, and other applications. Communication between the SIM card and the handset is via a serial interface.
A SIM card also contains a hierarchical file system which resides in EEPROM. The file structure consists of a Master File (MF), which is the root of the file system, Dedicated Files (DFs), and Elementary Files (EFs). Dedicated Files are subordinate directories under the MF, their contents and functions being defined by the GSM11.11 standards. Three are usually present: DF (DCS1800), DF (GSM), and DF (Telecom). Also present under the MF is EF (ICCID). Subordinate to each of the DFs are supporting EFs which contain the actual data. The EFs under DF (DCS1800) and DF (GSM) contain network related information and the EFs under DF (Telecom) contain the service related information. A typical SIM card file system is shown in Figure 2.
While all the files have headers, only the EFs contain data. The first byte of the header identifies the file type. Headers contain the security and meta-information related to the structure and attributes of the file, such as length of record. The body of the EFs contains information related to the application(s). Files can be either administrative or application specific and access to stored data is controlled by the operating system.
SIM cards have built in security features that are designed to make them tamper resistant, thereby ensuring data security. A SIM card’s MF, DFs, and EFs all contain security attributes. One security attribute, the access conditions, are constraints upon the execution of commands. They filter every execution attempt, thus ensuring that only those with the proper authorization can access the requested functionality controlled by the DFs or EFs. Access conditions can be thought of as somewhat analogous to the user rights associated with the file/directory attributes found in computer operating systems. There are different levels of access conditions associated with DF and EF files:
- Always (ALW): file access is allowed without restrictions and the command is executable upon the file.
- Card Holder Verification 1 (CHV1): file access is allowed with the valid verification of the users PIN1 (or PIN1 verification is disabled) and the command is executable upon the file.
- Card Holder Verification 2 (CHV2): file access is allowed with a valid verification of the user’s PIN2 (or PIN2 verification is disabled) and the command is executable upon the file.
- Administrative (ADM): the administrative authority (i.e. the card issuer who provides the SIM card to subscribers), is responsible for the allocation of these levels.
- Never (NEV): file access is prohibited and the command is never executable upon the file.
Data of Forensic Value
Depending upon the phone’s technology and access scheme, the same data, such as a contact list, may be stored on the SIM, in the handset, or on the phone’s memory card. SIM cards themselves contain a repository of data and information, some of which is listed below:
- Integrated Circuit Card Identifier (ICCID)
- International Mobile Subscriber Identity (IMSI)
- Service Provider Name (SPN)
- Mobile Country Code (MCC)
- Mobile Network Code (MNC)
- Mobile Subscriber Identification Number (MSIN)
- Mobile Station International Subscriber Directory Number (MSISDN)
- Abbreviated Dialing Numbers (ADN)
- Last Dialed Numbers (LDN)
- Short Message Service (SMS)
- Language Preference (LP)
- Card Holder Verification (CHV1) and (CHV2)
- Ciphering Key (Kc)
- Ciphering Key Sequence Number
- Emergency Call Code
- Fixed Dialing Numbers (FDN)
- Local Area Identity (LAI)
- Own Dialing Number
- Temporary Mobile Subscriber Identity (TMSI)
- Routing Area Identifier (RIA) network code
- Service Dialing Numbers (SDNs)
A discussion of some of this data and what it means will continue in the next column.
(Disclaimer: products mentioned in this column should not to be considered as an endorsement of that product by Forensic Magazine or by the author.)
John J. Barbara owns Digital Forensics Consulting, LLC, providing consulting services for companies and laboratories seeking digital forensics accreditation. An ASCLD/LAB inspector since 1993, John has conducted inspections in several forensic disciplines including Digital Evidence. John is the General Editor for the “Handbook of Digital & Multimedia Forensic Evidence” published by Humana Press. He can be reached at email@example.com.