What is a UICC ?
The USIM is telecom application inside a UICC.
UICC is a tiny computer, common to all smart cards: telecom, banking, …
The interface is a serial link, with only one pin for both Tx and Rx, so it is half duplex.
To interface UICC with a computer, a USB/serial converter is the current solution. It could be two flavors: direct dialog over the serial link or a protocol called PC/SC.
As 3GPP describes the actual dialog (no PC/SC encapsulation). We choose to use this direct interface between our SW ans the UICC (see our commercial page about SIM cards readers).
In our reader, the converter is a Prolific PL2303 chip. So, the car reader is seen as a serial/USB converter in Linux (or other OS). It doesn’t require any additional driver.
Opening the serial link connects us directly to the UICC Tx/Rx pin. By this connection, we can send/receive data to a UICC card.
UICC dialog
The dialog is master/slave: the card only answer to requests.
The requests are called “APDU”, see wikipedia doc
The APDU for telecom application are described in ETSI and 3GPP standards.
Most dialogs implements a “file system” concept: 3GPP defined UICC embedded files. The files are in directories as we do in computers.
The UICC file system specific concepts:
- file names, directory names are only 2 bytes (no explicit label)
- rich file types: regular binary type, record based type, circular type
- powerful access control features
Some orders doesn’t implement “file system” design pattern: specific APDU calls, for example, 3GPP authentication.
A more complex UICC facility is to download applications in the card. These applications are written in a java (“javacard” flavor). Java application are not useful for regular 4G subscription and authentication.
Typical 4G smartphone example
Power (or reset) the UICC. The card answer with a structured word called “ATR” (answer to reset). This ATR tells us the card features and supplier identification.
The commands subset used by regular mobile phones is implemented in a pure standard way by all card suppliers.
Nevertheless, 3GPP defines some parts as only examples, to free proprietary implementations, like a operator that would use his own algorithm instead of “Milenage”. Also, most suppliers have their own implementation for the operator provisioning parts (this is the case for our UICC).
The second order to the UICC will be to select a directory under the root directory.
GSM SIM, 3G/4G USIM, IMS IMSI, … have their own directories.
Example: APDU=a0a40000023f00
- a0 is GSM class
- a4 is select directory
- 0000 are always defined APDU syntax parameters, we don’t need values in this case
- 02 is the length of the following data
- 3f00 is the name of the GSM directory, defined by 3GPP
The we have to read the card answer, it should be: 9f17, that 3GPP defined as the success answer in GSM 11.11 standardization document
All of this is simple, but there is two painful issues:
proprietary commands per supplier for card configuration
each file content encoding is specific, described in big documents:
From physical interface to root files (above telecom application): ETSI standard
Our application: USIM files are defined in: 3GPP standard