ETSI TS 102 226 V9.0.0 (2009-06)

Smart Cards; Remote APDU structure for UICC based applications (Release 9)

RTS/SCP-T02850v900

General Information

• Status: Published
• Publication Date: 24-Jun-2009
• Technical Committee: SET TEC - SET-TEC
• Current Stage: 12 - Completion
• Due Date: 30-Jun-2009
• Completion Date: 25-Jun-2009

Standards Content (Sample)

Technical Specification
Smart Cards;
Remote APDU structure for UICC based applications
(Release 9)
2 ETSI TS 102 226 V9.0.0 (2009-06)

Reference
RTS/SCP-T02850v900
Keywords
protocol, smart card
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 226 V9.0.0 (2009-06)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Overview of remote management . . 9
5 Remote APDU format . 9
5.1 Compact Remote Application data format . 9
5.1.1 Compact Remote command structure . 9
5.1.2 Compact Remote response structure . 10
5.2 Expanded Remote Application data format . 10
5.2.1 Expanded Remote command structure . 10
5.2.1.1 C-APDU TLV . 11
5.2.1.2 Immediate Action TLV . 11
5.2.1.3 Error Action TLV . 12
5.2.1.4 Script Chaining TLV . 13
5.2.2 Expanded Remote response structure . 14
5.3 Automatic application data format detection . 16
6 Security parameters assigned to applications . 16
6.1 Minimum Security Level (MSL) . 16
6.2 Access domain . 16
7 Remote File Management (RFM) . 17
7.1 Commands . 17
7.2 UICC Shared File System Remote File Management . 18
7.3 ADF Remote File Management . 18
8 Remote Application Management (RAM) . 18
8.1 Remote application management application behaviour . 19
8.2 Commands coding and description. 19
8.2.1 Commands . 19
8.2.1.1 DELETE . 20
8.2.1.2 SET STATUS . 20
8.2.1.3 INSTALL . 20
8.2.1.3.1 INSTALL [for load] . 20
8.2.1.3.2 INSTALL [for install] . 20
8.2.1.4 LOAD . 27
8.2.1.5 PUT KEY . 27
8.2.1.5.1 PUT KEY for AES . 28
8.2.1.6 GET STATUS . 28
8.2.1.6.1 Menu parameters . 29
8.2.1.7 GET DATA . 29
8.2.1.7.1 Void . 30
8.2.1.7.2 Extended Card resources information . 30
8.2.1.8 STORE DATA . 30
9 Additional command for push . 30
9.1 Push command behaviour . 30
9.1.1 Request for open channel . 30
9.1.2 Request for CAT_TP link establishment . 30
ETSI
4 ETSI TS 102 226 V9.0.0 (2009-06)
9.1.3 Behaviour for responses . 30
9.2 Commands coding . 31
9.2.1 Data for BIP channel opening . 31
9.2.2 Data for CAT_TP link establishment. 31
9.3 Closing of the BIP channel . 32
10 Confidential application management . 32
10.1 Confidential loading . 33
10.2 SCP02 in secured packets . 33
10.3 Confidential setup of security domains . 33
10.4 Application personalisation in an APSD . 33
Annex A (normative): BER-TLV tags . 34
Annex B (informative): Change history . 35
History . 37

ETSI
5 ETSI TS 102 226 V9.0.0 (2009-06)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP).
It is based on work originally done in the 3GPP in TSG-terminals WG3 and ETSI SMG.
The contents of the present document are subject to continuing work within EP SCP and may change following formal
EP SCP approval. If EP SCP modifies the contents of the present document, it will then be republished by ETSI with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x: the first digit:
0 early working draft;
1 presented to EP SCP for information;
2 presented to EP SCP for approval;
3 or greater indicates EP SCP approved document under change control.
y: the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z: the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
6 ETSI TS 102 226 V9.0.0 (2009-06)
1 Scope
The present document defines the remote management of the UICC based on the secured packet structure specified in
TS 102 225 [1].
It specifies the APDU format for remote management.
• Furthermore the present document specifies: a set of commands coded according to this APDU structure and
used in the remote file management on the UICC. This is based on TS 102 221 [2].
• A set of commands coded according to this APDU structure and used in the remote application management
on the UICC. This is based on the GlobalPlatform Card Specifications.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• In the case of a reference to a TC SCP document, a non specific reference implicitly refers to the latest version
of that document in the same Release as the present document.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI TS 102 225: "Smart Cards; Secured packet structure for UICC based applications".
[2] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics".
[3] ETSI TS 102 223: "Smart Cards; Card Application Toolkit (CAT)".
[4] GlobalPlatform: "GlobalPlatform Card Specification, Version 2.2" including "Errata and precision
list" Version 0.2.
NOTE: See http://www.globalplatform.org/.
[5] ETSI TS 101 220: "Smart cards; ETSI numbering system for telecommunication application
providers".
[6] ETSI TS 102 241: "Smart Cards; UICC Application Programming Interface (UICC API) for Java
Card (TM)".
ETSI
7 ETSI TS 102 226 V9.0.0 (2009-06)
[7] GlobalPlatform: "GlobalPlatform Card Specification Version 2.0.1".
NOTE: See http://www.globalplatform.org/.
[8] Void.
[9] ETSI TS 102 222: "Integrated Circuit Cards (ICC); Administrative commands for
telecommunications applications".
[10] ETSI TS 123 048: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Security mechanisms for the (U)SIM application toolkit;
Stage 2 (3GPP TS 23.048, Release 5)".
[11] ETSI TS 102 127: "Smart Cards; Transport protocol for CAT applications; Stage 2".
[12] ETSI TS 143 019: "Digital cellular telecommunications system (Phase 2+); Subscriber Identity
Module Application Programming Interface (SIM API) for Java Card; Stage 2
(3GPP TS 43.019 Release 5)".
[13] FIPS-197 (2001): "Advanced Encryption Standard (AES)".
NOTE: See http://csrc.nist.gov/publications/fips/index.html.
[14] NIST Special Publication 800-38A (2001): "Recommendation for Block Cipher Modes of
Operation - Methods and Techniques".
NOTE: See http://csrc.nist.gov/publications/nistpubs/.
[15] NIST Special Publication 800-38B (2001): "Recommendation for Block Cipher Modes of
Operation: The CMAC Mode for Authentication".
NOTE: See http://csrc.nist.gov/publications/nistpubs/.
[16] "GlobalPlatform Card UICC Configuration", Version 1.0.
NOTE: See http://www.globalplatform.org/.
[17] ETSI TS 102 588: "Smart Cards; Application invocation Application Programming Interface
(API) by a UICC webserver for Java Card™ platform".
[18] GlobalPlatform: "GlobalPlatform Card Specification Version 2.2, Amendment A"
Version 1.0 including "Errata and Precisions" Version 1.0.
NOTE: See http://www.globalplatform.org/.
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
Not applicable.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TS 102 225 [1] and TS 101 220 [5] apply.
ETSI
8 ETSI TS 102 226 V9.0.0 (2009-06)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TS 102 225 [1] and the following apply:
ACK ACKnowledge
ADD Access Domain Data
ADF Application Data File
ADP Access Domain Parameter
AES Advanced Encryption Standard
AID Application IDentifier
APDU Application Protocol Data Unit
API Application Programming Interface
APSD Application Provider Security Domain
BER-TLV Basic Encoding Rules - Tag, Length, Value
BIP Bearer Independent Protocol
C-APDU Command Application Protocol Data Unit
CASD Controlling Authority Security Domain
CBC Cell Broadcast Centre
CLA Class
CMAC Cipher-based Message Authentication Code
DAP Data Authentication Pattern
DEK Data Encryption Key
DES Data Encryption Standard
DF Directory File
ECB Electronic Code Book
EF Elementary File
ICCID Integrated Circuit Card IDentification
INS INStruction
KIc Key and algorithm Identifier for ciphering
KID Key and algorithm IDentifier for RC/CC/DS
MAC Message Authentication Code
MF Management Field
MSL Minimum Security Level
MSLD Minimum Security Level Data
OTA Over The Air
PDU Packet Data Unit
RAM Remote Application Management
R-APDU Response Application Protocol Data Unit
RFM Remote File Management
RFU Reserved for Future Use
SCP02 Secure Channel Protocol 02
SDU Service Data Unit
TAR Toolkit Application Reference
TLV Tag Length Value
ETSI
9 ETSI TS 102 226 V9.0.0 (2009-06)
4 Overview of remote management
Sending Sending Receiving Receiving
Application Entity Entity Application
Secured
C-APDU
[Secured R-APDU]
Server UICC
Figure 4.1: Remote management
All data exchanged between the Sending Entity and Receiving Entity shall be formatted as "Secured data" according to
TS 102 225 [1]:
1) The parameter(s) in the "Secured data" is either a single command, or a list of commands, which shall be
processed sequentially.
2) The Remote Management application shall take parameters from the "Secured data" and shall act upon the
files or applications or perform other actions according to these parameters. A Remote Management
application is the on-card Receiving Application that performs either Remote File Management (RFM) or
Remote Application Management (RAM) as defined in the following clauses.
3) Remote Management commands shall be executed by the dedicated Remote Management Application (RAM).
A Command "session" is defined as starting upon receipt of the parameter/command list, and ends when the
parameter list in the "Secured data" is completed, or when an error (i.e. SW1 of the command indicates an
error condition) is detected which shall halt further processing of the command list. Warnings or procedure
bytes do not halt processing of the command list.
4) At the beginning and end of a Command "session" the logical state of the UICC as seen from the terminal shall
not be changed to an extent sufficient to disrupt the behaviour of the terminal. If changes in the logical state
have occurred that the terminal needs to be aware of, the application on the UICC may issue a REFRESH
command according to TS 102 223 [3].
5 Remote APDU format
5.1 Compact Remote Application data format
5.1.1 Compact Remote command structure
A command string may contain a single command or a sequence of commands. The structure of each command shall be
according to the generalized structure defined below; each element other than the Data field is a single octet
(see TS 102 221 [2]).
ETSI
10 ETSI TS 102 226 V9.0.0 (2009-06)
The format of the commands is the same as the one defined in TS 102 221 [2] for T = 0 TPDU commands.
Class byte Instruction P1 P2 P3 Data
(CLA) code (INS)
If the sending application needs to retrieve the Response parameters/data of a case 4 command, then a GET
RESPONSE command shall follow this command in the command string.
The GET RESPONSE and any case 2 command (i.e. READ BINARY, READ RECORD) shall only occur once in a
command string and, if present, shall be the last command in the string.
For all case 2 commands and for the GET RESPONSE command, if P3 = '00', then the UICC shall send back all
available response parameters/data e.g. if a READ RECORD command has P3='00' the whole record shall be returned.
The limitation of 256 bytes does not apply for the length of the response data. In case the data is truncated in the
response, the remaining bytes are lost and the status words shall be set to '62 F1'.
5.1.2 Compact Remote response structure
If a proof of Receipt is required by the sending entity, the Additional Response Data sent by the Remote Management
Application shall be formatted according to table 5.1.
Table 5.1: Format of additional response data
Length Name
1 Number of commands executed within the command script (see note)
2 Status bytes or '61 xx' procedure bytes of last executed command /
GET RESPONSE
X Response data of last executed command / GET RESPONSE if
available (i.e. if the last command was a case 2 command or a GET
RESPONSE)
NOTE: This field shall be set to '01' if one command was executed within the
command script, '02' if two commands were executed, etc.

5.2 Expanded Remote Application data format
5.2.1 Expanded Remote command structure
The "Secured data" sent to a Remote Management Application shall be a BER-TLV data object formatted according to
table 5.2.
Table 5.2: Expanded format of Remote Management application command "secured data"
Length in bytes Name
1 Command Scripting template tag
L Length of Command Scripting template= A+B+…C
A Command TLV
B Command TLV
…
C Command TLV
The Command Scripting template is a BER-TLV data object as defined in TS 101 220 [5] and the tag of this TLV is
defined in annex A.
A Remote Management application command string may contain a single or several Command TLVs.
ETSI
11 ETSI TS 102 226 V9.0.0 (2009-06)
A Command TLV can be one of the following:
• A C-APDU, containing a remote management command.
• An Immediate Action TLV, containing a proactive command or another action to be performed when it is
encountered while processing the sequence of Command TLVs.
• An Error Action TLV, containing a proactive command to be performed only if an error is encountered in a
C-APDU following this TLV.
• A script Chaining TLV as first Command TLV.
5.2.1.1 C-APDU TLV
The structure of each C-APDU shall be a TLV structure coded according to the C-APDU COMPREHENSION-TLV
data object coding defined in TS 102 223 [3]. The restriction on the length of the C-APDU mentioned in the note in
TS 102 223 [3] shall not apply.
For all case 2 and case 4 C-APDUs, if Le='00' in the C-APDU, then the UICC shall send back all available response
parameters/data in the R-APDU e.g. if a READ RECORD command has Le='00' the whole record shall be returned.
The limitation of 256 bytes does not apply for the length of the response data.
In case the data is truncated in the response of a C-APDU, the status words for this C-APDU shall be set to
'62 F1' in the corresponding R-APDU. This shall terminate the processing of the command list.
If a R-APDU fills the response buffer so that no further R-APDU can be included in the response scripting template,
this shall terminate the processing of the command list.
If Le field is empty in the C-APDU, then no response data is expected in the R-APDU. In that case, no R-APDU shall
be returned by the UICC in the application additional response data except if the corresponding C-APDU is the last
command executed in the script.
NOTE: In this expanded format the GET RESPONSE command is not used.
5.2.1.2 Immediate Action TLV
The Immediate Action TLV is a BER TLV data object that allows the Remote Management Application to issue a
proactive command during the execution or that allows to abort the execution if a proactive session is ongoing. It shall
be formatted as shown in table 5.3 or table 5.4.
Table 5.3: Immediate Action TLV - normal format
Length in bytes Name
1 Immediate Action tag (see annex A)
L Length of Immediate Action = A > 1
A Set of COMPREHENSION-TLV data objects

Table 5.4: Immediate Action TLV - referenced format
Length in bytes Name
1 Immediate Action tag (see annex A)
1 Length of Immediate Action = 1
1 '01' to '7F': Reference to a record in EF
RMA
'81': Proactive session indication
'82': Early response
other values: RFU
In case of reference to a record in EF , the referenced record shall contain the set of COMPREHENSION-TLV data
RMA
objects preceded by a length value as defined for a BER TLV, see [10].
ETSI
12 ETSI TS 102 226 V9.0.0 (2009-06)
If present, the Immediate Action TLV coding "proactive session indication" shall be:
• The first Command TLV in the script if there is no script chaining.
• The second Command TLV in the script if there is script chaining.
In case of "proactive session indication", execution of the remaining script shall be suspended if a proactive session is
ongoing. Script processing shall be resumed after the end of the proactive session. If the UICC cannot suspend the script
execution, e.g. because there is not enough internal resources available, the UICC shall terminate the processing of the
script and return a "suspension error" in the response data.
If no "proactive session indication" is present as first Command TLV and another proactive session is ongoing,
proactive commands in the script shall be silently ignored.
In case of "early response", the response to the sending entity shall be sent before processing the rest of the command
TLVs. The number of executed commands TLV objects shall include all objects up to the immediate action TLV
encoding the "early response". No other response data shall be sent after the response sent due to the early response
action TLV.
NOTE: This is useful in case of some refresh modes, where the UICC might not be able to send a response after
the refresh is performed by the terminal.
Proactive commands as defined in table 5.5 are allowed as Immediate Action. The behaviour of the card for other
commands is undefined.
Table 5.5: Allowed proactive commands for Immediate Action
DISPLAY TEXT
PLAY TONE
REFRESH
5.2.1.3 Error Action TLV
The Error Action TLV is a BER TLV data object that allows the Remote Management Application to issue a proactive
command in case of error in the execution. It shall be formatted as shown in tables 5.6, 5.7 or 5.8.
The Error Action tag is defined in annex A.
Table 5.6: Error Action TLV - normal format
Length in bytes Name
1 Error Action tag
L Length of Error Action = A > 1
A Set of COMPREHENSION-TLV data objects

Table 5.7: Error Action TLV - referenced format
Length in bytes Name
1 Error Action tag
1 Length of Error Action = 1
1 '01' to '7F': Reference to a record in EF
RMA
other values: RFU
Table 5.8: Error Action TLV - no action
Length in bytes Name
1 Error Action tag
1 Length of Error Action = 0
ETSI
13 ETSI TS 102 226 V9.0.0 (2009-06)
In case of referenced format, the referenced record in EF shall contain the set of COMPREHENSION-TLV data
RMA
objects preceded by a length value as defined for a BER TLV, see [10].
Proactive commands as defined in table 5.9 are allowed as Error Action. The behaviour of the card for other commands
is undefined.
Table 5.9: Allowed proactive commands for Error Action
DISPLAY TEXT
PLAY TONE
If an error is encountered when processing a C-APDU, error actions shall be performed as follows:
• If there is an Error Action TLV between the start of the script and the C-APDU resulting in an error, the action
defined in the last Error Action TLVs shall be performed. If this last Error Action TLV has zero length, no
action shall be performed.
• If there is no Error Action TLV between the start of the script and the C-APDU resulting in an error, no action
shall be performed.
5.2.1.4 Script Chaining TLV
The optional Script Chaining TLV is a BER-TLV data object and shall be coded as shown in table 5.9a.
Table 5.9a: Script Chaining TLV
Length in bytes Name
1 Script Chaining tag
1 Script Chaining Length= 1
1 Script Chaining Value
The Script Chaining tag is defined in annex A.
If present, the Script Chaining TLV shall be present only once and shall be the first Command TLV in the Command
Script. It may only be present for Remote File Management. If it is received by any other application standardized in the
present document, the error "Script Chaining not supported by this application" shall be sent back to the sending entity.
The Script Chaining Value is defined as follows:
'01' first script - delete chaining information upon card reset;
'11' first script - keep chaining information across card reset;
'02' subsequent script - subsequent script(s) will follow;
'03' subsequent script - last script.
Whether or not chaining information is kept across card reset(s) is defined in the first script for the whole chain.
ETSI
14 ETSI TS 102 226 V9.0.0 (2009-06)
5.2.2 Expanded Remote response structure
The additional response application data which may be sent by a Remote Management application is a BER-TLV data
object.
In case no Script Chaining is present in the command list or processing of the Script Chaining produces no error, it shall
be formatted according to table 5.10.
Table 5.10: Expanded Format of Remote Management application additional response data
Length in bytes Name
1 Response Scripting template tag
L Length of Response Scripting template= X+A+B…C
X Number of executed Command TLV objects
A R-APDU of first executed case 2/ case 4 C-APDU in the script
B R-APDU of second executed case 2/ case 4 C-APDU in the script
…
C R-APDU of last executed C-APDU (case 1, 2, 3 or 4) in the script
or Bad format TLV
NOTE: If the last executed C-APDU is a case 2 or case 4 command, its
corresponding R-APDU TLV shall only be present once in the Response
Scripting template.
The Response Scripting template is a BER-TLV data object as defined in TS 101 220 [5] and the tag of this TLV is
defined in annex A.
The Number of executed command TLV objects is a BER-TLV data object and shall be coded as shown in table 5.11.
Table 5.11: Number of executed command TLV objects
Length in bytes Description
1 Number of executed command TLV objects tag
1 Length=X
X Number of executed command TLV objects

The Number of executed command TLV objects tag is defined in annex A. The Number of executed command TLV
objects value corresponds to the number of command TLV objects executed within the command script.
The structure of each R-APDU shall be a TLV structure coded according to the R-APDU COMPREHENSION-TLV
data object coding defined in TS 102 223 [3]. The restriction on the length of the R-APDU mentioned in the note in
TS 102 223 [3] shall not apply. For Le='00', the length of the R-APDU may be coded on more than two bytes.
A Remote Management application response string may contain a single or several R-APDU TLVs.
In case of an unknown Tag, or TLV with a wrong format (e.g. length > length of BER-TLV or length < 4) is
encountered while processing the command script, a Bad format TLV shall be put into the response data and processing
of the command script shall be aborted at that point.
The Number of executed C-APDUs shall take into account the incorrectly formatted TLV.
The Bad format TLV is a BER-TLV data object and shall be coded as shown in table 5.5.
Table 5.12: Bad format TLV
Length in bytes Description
1 Bad format TLV tag
1 Length
1 Error type
ETSI
15 ETSI TS 102 226 V9.0.0 (2009-06)
Error type Coding:
• '01': Unknown Tag found
• '02': Wrong length found
• '03': Length not found
other values: RFU.
If "proactive session indication" is present in the script and a proactive session is ongoing and the UICC is unable to
suspend script processing, the additional response application data shall be formatted according to tables 5.12 and 5.13
and indicate "suspension error".
Table 5.13: Expanded Format of Remote Management application additional
response data in case of Immediate Action error
Length in bytes Name
1 Response Scripting template tag
L Length of Response Scripting template= X+A
X Number of executed command TLV objects (value is 1)
A Immediate Action Response
The Immediate Action Response is an Immediate Action Response TLV which is a BER-TLV data object coded as
shown in table 5.13.
Table 5.14: Immediate Action Response TLV
Length in bytes Description
1 Immediate Action Response tag
1 Length=X
X Immediate Action Response Value

The Immediate Action Response tag is defined in annex A.
The Immediate Action Response Value is defined as follows:
• '01' Suspension error
In case a Script Chaining TLV indicating "subsequent script - …" is present in the list, the following situations shall be
considered as chaining errors:
• The previous script did not contain a Script Chaining TLV indicating "first script - …" or "subsequent script -
subsequent script(s) will follow".
• The first script of the chain indicating "first script - delete chaining information upon card reset" was processed
in an earlier card session.
In case of chaining errors, the additional response application data shall be formatted according to table 5.15.
Table 5.15: Expanded Format of Remote Management application additional response data in case of
Script Chaining error
Length in bytes Name
1 Response Scripting template tag
L2 Length of Response Scripting template= X+A
X Number of executed Command TLV objects
A Script Chaining Response
The Script Chaining Response TLV is a BER-TLV data object and shall be coded as shown in table 5.16.
Table 5.16: Script Chaining Response TLV
ETSI
16 ETSI TS 102 226 V9.0.0 (2009-06)
Length in bytes Description
1 Script Chaining Response tag
1 Length=X
X Script Chaining Result Value

The Script Chaining Response tag is defined in annex A. The Script Chaining Result Value is defined as follows:
• '01' No previous script;
• '02' Script Chaining not supported by this application;
• '03' Unable to process script chaining (e.g. no resources to store chaining context).
5.3 Automatic application data format detection
If a TAR is configured for multiple data formats, the following automatic application data format detection shall apply:
• If b2b1 of the first data byte of the application data are 00, the format of the application data shall be the
compact remote application data format.
• Otherwise, the first data byte of the application data shall indicate the format of the data packet.
NOTE: b2b1 of the CLA byte, which is the first byte in compact format, indicate the logical channel. As logical
channels are not used in remote management, these can be used to indicate other data formats. With the
tag value chosen for the expanded format, this allows for co-existence of both formats even if the same
TAR is used.
6 Security parameters assigned to applications
6.1 Minimum Security Level (MSL)
The Minimum Security Level (MSL) is used to specify the minimum level of security to be applied to Secured Packets
sent to any Receiving Application. The Receiving Entity shall check the Minimum Security Level before processing the
security of the Command Packet. If the check fails, the Receiving Entity shall reject the messages and a Response
Packet with the "Insufficient Security Level" Response Status Code (see TS 102 225 [1]) shall be sent if required.
A Minimum Security Level as described in clause 8.2.1.3.2.4 shall be assigned to each Remote Management application
(RFM/RAM).
6.2 Access domain
The Access Domain is a parameter used to define the access rights granted to an Application allowing it to perform
operations on UICC files specified in TS 102 221 [2]. Access Conditions of UICC Files shall be coded as defined in
TS 102 221 [2].
The access rights granted to an application by its Access Domain shall be independent from the access rights granted at
the UICC/Terminal interface.
NOTE: This implies in particular that the status of a secret code (e.g. disabled PIN1, blocked PIN2, etc.) at the
UICC/Terminal interface does not affect the access rights granted to an application.
An Access Domain as described in clause 8.2.1.3.2.5 shall be assigned to each Remote File Management Application.
ETSI
17 ETSI TS 102 226 V9.0.0 (2009-06)
7 Remote File Management (RFM)
The concept of embedding APDUs in a command packet and the Additional Response data in a response packet shall be
as defined in the previous clauses describing the Compact and expanded Remote Application data format.
Unless a TAR is used that is configured for automatic application data format detection, the Compact and expanded
Remote Application data formats shall be distinguished by different TAR values.
For the Expanded Remote Application data format, it is possible to chain two or more scripts using Script Chaining
TLVs.
If a Script Chaining TLV indicating "first script - …" or "subsequent script - subsequent script(s) will follow" is
processed successfully, the file context (current directory, current file, current tag pointer, etc.) and the PIN verification
status at the end of the script shall be remembered until the next script is processed by the Remote File Management
application. If the next script received successfully contains a Script Chaining TLV indicating "subsequent script - …",
the remembered file context and PIN verification status shall be restored. Else the default context shall be used.
If a non-shareable file is selected by the remembered file context, the mechanisms defined in TS 102 221 [2] limiting
the access to non-shareable files shall apply.
NOTE: It is up to the sending entity to guarantee that a sequence of scripts, each relying on the context of the
previous one, is processed in the correct sequence by the UICC. This can be achieved by using a reliable
transport mechanism, by waiting for a positive response of one script before sending the next, or by using
appropriate settings in the security layer ("process only if counter value is one higher than previous
value").
7.1 Commands
The standardized commands are listed in table 7.1. The commands are as defined in TS 102 221 [2] and TS 102 222 [9].
Table 7.1: Remote File Management commands
Operational command
SELECT (see below)
UPDATE BINARY
UPDATE RECORD
SEARCH RECORD
INCREASE
VERIFY PIN
CHANGE PIN
DISABLE PIN
ENABLE PIN
UNBLOCK PIN
DEACTIVATE FILE
ACTIVATE FILE
READ BINARY
READ RECORD
CREATE FILE
DELETE FILE
RESIZE FILE
SET DATA
RETRIEVE DATA
ETSI
18 ETSI TS 102 226 V9.0.0 (2009-06)
The SELECT command shall not include the selection by DF name corresponding to P1='04' in the Command
Parameters of SELECT (see TS 102 221 [2]).
The Response Data shall be placed in the Additional Response Data element of the Response Packet.
• If P3/Le = '00' in the READ RECORD command, then the UICC shall send back the whole record data.
• If P3/Le = '00' in the READ BINARY command, then the UICC shall send back all data until the end of the
file, according to clause 5.1.
• If P3/Le = '00' in the RETRIEVE DATA command, then the UICC shall send back all data until the end of the
data object from the current BER-TLV structure EF.
7.2 UICC Shared File System Remote File Management
A UICC Shared File System Remote File Management application shall have access only to the MF and all DFs and
EFs that are located under the MF.
NOTE: ADFs are not considered to be files located under the MF.
Unless Script Chaining is used, the MF shall be implicitly selected and be the current directory at the beginning of a
Command "session".
No ADF shall be accessed by the UICC Shared File System Remote File Management application.
All commands defined in clause 7.1 shall apply.
The TAR value of the UICC Shared File System Remote File Management application is defined in TS 101 220 [5].
7.3 ADF Remote File Management
An ADF Remote File Management application shall have access to the DFs and EFs located under the ADF.
Unless Script Chaining is used, the ADF shall be implicitly selected and be the current directory at the beginning of a
Command "session".
The UICC Shared File System, i.e. the MF and all DFs and EFs that are located under the MF, may also be accessed,
depending on the access rights granted to the ADF Remote File Management application.
NOTE: ADFs are not considered to be files located under the MF.
All commands defined in clause 7.1 shall apply.
The TAR of an ADF RFM application shall be linked to the AID of the application to which the ADF belongs.
The TAR value of an ADF Remote File Management application is defined in TS 101 220 [5].
8 Remote Application Management (RAM)
Remote Application Management on a UICC card includes the ability to load, install, and remove applications. This
management is under the control of a security domain with card content management capabilities, such as the Issuer
Security Domain or any Security Domain with Delegated Management privileges or Authorized Management as
described in GlobalP
...