The present document defines a generic Terminal/Integrated Circuit Card (ICC) interface.
The aim of the present document is to ensure interoperability between an ICC and a terminal independently of the respective manufacturer, card issuer or operator. The present document does not define any aspects related to the administrative management phase of the ICC. Any internal technical realization of either the ICC or the terminal is only specified where these are reflected over the interface.
Application specific details for applications residing on an ICC are specified in the respective application specific documents. The Universal Subscriber Identity Module (USIM)-application for 3G telecommunication networks is specified in TS 31.102.
The present document specifies the interface between the UICC and the terminal.
The present document specifies:
the requirements for the physical characteristics of the UICC;
the electrical interface for exchanging APDUs between the UICC and the terminal, based on ISO/IEC 7816-3 [11];
the initial communication establishment and the transport protocols for this interface;
a model which serves as a basis for the logical structure of the UICC APDU interface;
communication commands and procedures for the UICC APDU interface;
application independent files and protocols for the UICC APDU interface.
Starting from Release 17, the UICC may support Logical Secure Element interfaces, which allows it to host multiple logical secure elements. A special form of such a Logical Secure Element (LSE) is a logical UICC. Where required, the lower layers which represent the features common to all LSEs are denoted as LSE base. The applicability of the clauses in the present document to either the LSE base or to the logical UICC is given in the introduction of each affected clause.
The administrative procedures, initial card management and optional communication interfaces between the UICC and terminal are not within the scope of the present document.
References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
In the case of a reference to a TC SET document, a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
Referenced documents which are not found to be publicly available in the expected location might be found at https://docbox.etsi.org/Reference.
The following referenced documents are necessary for the application of the present document.
TS 23.038: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Alphabets and language-specific information".
TS 31.102: "Universal Mobile Telecommunications System (UMTS); LTE; 5G; Characteristics of the Universal Subscriber Identity Module (USIM) application".
References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
In the case of a reference to a TC SET document, a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.
link between the card and the external world, using APDUs, starting with the ATR and ending with a subsequent reset or a deactivation of the card
channel session:
link between the card and the external world during a card session on a given logical channel, starting with the opening of the logical channel and ending with the closure of the logical channel or the termination of the card session
class A operating conditions:
terminal or a smart card operating at 5 V ± 10 %
class B operating conditions:
terminal or a smart card operating at 3 V ± 10 %
class C operating conditions:
terminal or a smart card operating at 1,8 V ± 10 %
class D operating conditions:
terminal or a smart card operating at 1,2 V ± 0,1 V
current directory:
latest MF, DF or ADF selected
current EF:
latest EF selected
current file:
current EF, if an EF is selected, else the current directory
Data Object (DO):
information coded as TLV object(s), i.e. consisting of a Tag, a Length and a Value part
Dedicated File (DF):
file containing access conditions and, optionally, Elementary Files (EFs) or other Dedicated Files (DFs)
directory:
general term for MF, DF and ADF
Elementary File (EF):
file containing access conditions and data and no other files
file:
directory or an organized set of bytes or records in the UICC
file identifier:
2 bytes which address a file in the UICC
first level application:
selectable application that is indicated in EFDIR under the MF
EXAMPLE:
A USIM application.
function:
contains a command and a response pair
GSM session:
part of the card session dedicated to the GSM operation
ID-1 UICC:
UICC having the format of an ID-1 card
Lc:
length of command data sent by the application layer in a case 3 or 4 Command
Le:
maximum length of data expected by the application layer in response to a case 2 or 4 Command
Logical Secure Element (LSE):
secure element functionalities, applications and files grouped together to act like a secure element (e.g. UICC) when multiple logical secure element interfaces are supported
Logical Secure element Interface (LSI):
logical connection between an endpoint in the terminal and one logical secure element
logical UICC:
upper layers of the UICC which implement the logic for handling the commands, files and protocols
Lr:
length of data sent back to the terminal by the UICC in response to a case 2 or 4 Command
LSE base:
lower layers of the UICC which are common for all LSEs
Luicc:
exact length of data available in the UICC to be returned in response to the case 2 or 4 Command received by the UICC
terminal that can support more than one first level application with possibly separate user verification requirements for each application
multi-application card:
card that can have more than one selectable application
multi-session card:
card that supports more than one concurrent selectable application session during a card session
multi-verification capable UICC:
card that can have more than one first level application and may support separate user verification requirements for each application
normal USIM operation:
relating to general, PIN related, 3G and or GSM security and subscription related procedures
padding:
one or more bits appended to a message in order to cause the message to contain the required number of bits or bytes
plug-in UICC:
second form factor (format) of UICC
proactive UICC:
UICC which is capable of issuing commands to the terminal
proactive UICC session:
sequence of related CAT commands and responses which starts with the status response '91XX' (proactive command pending) and ends with a status response of '90 00' (normal ending of command) after Terminal Response
record:
string of bytes within an EF handled as a single entity
record number:
number which identifies a record within an EF
record pointer:
pointer which addresses one record in an EF
removable UICC:
UICC which is easily accessible or replaceable, is intended to be removed or replaced in the terminal
second level application:
application which can only be activated during the session of a first level application
selectable application:
application that is selectable by an AID according to the process described in ISO/IEC 7816-4 [12] over the terminal-UICC interface
selectable application session:
link between the application and the external world during a card session starting with the application selection and ending with de-selection or termination of the card session
single verification capable UICC:
card that only supports one user verification requirement for all first level applications
state H:
high state on the I/O line (Vcc)
state L:
low state on the I/O line (Gnd)
test capability:
capability of the UICC to support the test configuration state
test configuration:
UICC configuration fulfilling the test configuration criterion
test configuration criterion:
first level application (e.g. NAA) specific criterion defined in the first level application specific extension of the UICC platform, and includes one or more conditions necessary to activate a test configuration state
test configuration state:
state of test configuration on a UICC after evaluating the test configuration criterion (refer to Annex N)
test functionality:
capability of the UICC or the device to support a functionality (e.g. test toolkit events, device APDU monitoring, etc.) required for a test method
test toolkit events capability:
support of test capability and the test toolkit events within the UICC
transport layer:
layer responsible for transporting Secured Packets through the network
type 1 UICC:
UICC which always enters the negotiable mode after a warm reset
type 2 UICC:
UICC which always enters the specific mode after a warm reset
USIM session:
selectable application session for a USIM application
For the purposes of the present document, the following coding conventions apply:
All lengths are presented in bytes, unless otherwise stated. Each byte is represented by bits b8 to b1, where b8 is the Most Significant Bit (MSB) and b1 is the Least Significant Bit (LSB). In each representation, the leftmost bit is the MSB.
In the UICC, all bytes specified as RFU shall be set to '00' and all bits specified as RFU shall be set to 0. If the GSM and/or USIM application exists on a UICC or is built on a generic telecommunications card, then other values may apply for the non-GSM or non-USIM applications. The values will be defined in the appropriate specifications for such cards and applications. These bytes and bits shall not be interpreted by a terminal in a GSM or 3G session.
The coding of all data objects in the present document is according to ETSI TS 101 220 [3]. All data objects are BER-TLV except if otherwise defined.