Smart Cards

After a long (14 year) hiatus, I recently dug out an old Towitoko ChipDrive smartcard reader and resumed writing code for it.

Towitoko was acquired by SCM Microsystems in 2002. Later that year they changed their name to Tx Systems, Inc. You can see their website here.

Global System for Mobiles (GSM) uses a personalized smartcard, called a Subscriber Identity Module (SIM) to provide storage and authentication functions for the customer.

Interesting information can be extracted from the SIM.

The mobile equipment communicates with the SIM using standard ISO 7816-3 Operating Procedures (a copy of parts 1, 2, and 3 can be found here).

This transmission protocol uses Application Protocol Data Units (APDU), which can be either commands or responses. These are sent across the electrical interface between the SIM and the mobile equipment, or the SIM-ME interface for short.

There are five fields in an APDU command. The class of instruction (CLA) is always A0 for GSM. The instruction code (INS) indicates the particular command to be performed. P1, P2, and P3 are parameters for the command, with P3 containing the length of the Data segment, if any.

The response to a command is returned in three fields. The Data portion, if any, contains information requested in the command. SW1 and SW2 are status words indicating the success or failure of the command.

A number of commands are defined for GSM SIM cards, including functions to read and write data, confirm security features, and run the GSM authentication algorithm. Completing an entire GSM procedure may require a series of APDU command/response pairs.

The SIM maintains information in a series of "files" that are organized hierarchically, much like the operating system of a personal computer. These files may be for administrative purposes or be specific to the GSM user application. Data in these files are accessed through APDU commands sent to the operating system.

A file is composed of a header and a body. The header contains structure and attribute information and is managed by the operating system. The body, which is optional, contains the actual data. Files are uniquely identified by a two-byte hexadecimal number.

There are three different types of files on a SIM: a master file (MF), dedicated files (DF), and elementary files (EF). There is one master file on a SIM, which holds all the other files in a tree-like structure. Dedicated files are headers that hold hierarchical trees of elementary files, but don't have data of their own. GSM defines two dedicated files immediately under the MF, DF_GSM containing GSM application files and DF_TELECOM containing the application service features.

Elementary files (EF) have both a header and a body, and come in three flavors. The first, called transparent, is a binary file that can store information of varying length in any location. This is a raw, unstructured, random access file. The second is called linear fixed and stores data records that all have the same fixed length. The third is termed cyclic and is designed to store records in chronological order. It also uses fixed-length records, but when the last entry is full the next record overwrites the oldest entry.

In the following examples, the Towitoko-specific bytes sent from the computer are also included. These bytes are necessary in order to get the Towitoko reader to interact with the SIM card. Other types of readers will not need these bytes but may have different control sequences.

To access the Master File, we perform two steps. First, issue a "SELECT" instruction. If it is successful, we issue a "GET RESPONSE" instruction to retrieve the response data from the "SELECT" instruction.

1. Send the APDU to "SELECT" the Master File (which has the identifier 3F 00):

   To Towitoko (9 bytes): 6F 05 05 62 A0 A4 00 00 02
   From Towitoko (1 byte): A4
   To Towitoko (6 bytes): 6F 02 05 7E 3F 00
   From Towitoko (2 bytes): 9F 1A

2. Now send the APDU to GET RESPONSE from the previous SELECT instruction, using the length information (1A from the 9F status). Note that we actually get back three additional bytes on top of the indicated 26 bytes:

   To Towitoko (9 bytes): 6F 05 05 62 A0 C0 00 00 1A
   From Towitoko (29): C0 00 00 AC FF 3F 00 01 00 00 00 00 00 0D 13 02 04 04 00 83 8A 83 8A 00 01 AC FF 90 00

This 29-byte response has three parts:

• The first byte, C0, is an acknowledgment of the original APDU (The C0 is the instruction code for "GET RESPONSE").
• The last two bytes (90 00) are the two status words indicating a successful "GET RESPONSE" command.
• The 26 bytes in between are the actual response data, which is broken out and annotated below:

[MF/DF] RFU: 00 00
  Free Memory: AC FF
  File ID:     3F 00 (MF)
  File Type:   01 (Master File)
  RFU:         00 00 00 00 00
  Length Following: 0D
  File characteristics:    13
    Clock stop:     Allowed, no preferred level
    Required speed: 13/4
    CHV:            Enabled
  Child DFs:               02
  Child EFs:               04
  CHVs, Unblock CHVs, etc: 04
  RFU:                     00
  CHV1 Status:             83 (Initialized, 3 remaining)
  Unblock CHV1 Status:     8A (Initialized, 10 remaining)
  CHV2 Status:             83 (Initialized, 3 remaining)
  Unblock CHV2 Status:     8A (Initialized, 10 remaining)
  RFU:                     00

To read an Elementary File, perform the following steps:

1. Send the APDU to SELECT the desired Elementary File. The proper Master File or Directory File must have been selected previously. In this example we read the ICCID file (identifier 2F E2).

   To Towitoko (9 bytes): 6F 05 05 62 A0 A4 00 00 02
   From Towitoko (1 byte): A4
   To Towitoko (6 bytes): 6F 02 05 7E 2D E2
   From Towitoko (2 bytes): 9F 0F

2. Now send the APDU to GET RESPONSE from the previous SELECT instruction, using the length information (0F from the 9F status):

   To Towitoko (9 bytes): 6F 05 05 62 A0 C0 00 00 0F
   From Towitoko (18): C0 00 00 00 0A 2F E2 04 00 04 00 44 01 01 00 00 90 00

   [EF] RFU:    00 00
     File Size:   00 0A
     File ID:     2F E2 (EF-ICCID)
     File Type:   04 (Elementary File)
     RFU:         00
     Access:      04 00 44
       Read/Seek:    Always
       Update:       Admin 4
       Increase:     Always
       RFU:          Always
       Rehabilitate: Admin 4
       Invalidate:   Admin 4
     Status:      01 (Not Invalidated)
     Length:      01
     EF Structure:  00 (Transparent)
   

3. Now we read the contents of the file. This is a transparent type of data file, so we can perform a binary read. We request the 10 bytes (the 00 0A file size) as given in the file information:

   To Towitoko (9 bytes): 6F 05 05 62 A0 B0 00 00 0A
   From Towitoko (13 bytes): B0 98 88 61 39 52 00 10 81 51 F4 90 00

   Again we discard the first byte (B0, the original "READ BINARY" instruction) and the last two bytes (90 00, the two status words that indicate success). The remaining ten bytes are interpreted this way:

     Identification Number: 8 9 8 8 1 6 9 3 2 5 0 0 0 1 1 8 1 5 4
     Luhn is 4, computed is 4.
     MII: 89 (Telecommunications), Country ID: 881 (Global Mobile Satellite System), Issuer ID: 6 (Iridium)
   

Send mail to Dan Veeneman
Last revised February 5, 2013