03.483GPPRelease 1999Security mechanisms for SIM application toolkitStage 2TS
There are two elements to Remote File Management on the SIM; the first is the behaviour of the SIM resident Toolkit Application which performs the Remote File Management, and the second is the command structure in the SIM Data Download message, see TS 11.14 . Access conditions for the GSM files as seen by the SIM resident application, are not standardised. These are under the control of the application designer, in co-operation with the Network Operator or Service Provider owning the SIM. These access conditions may be dependent on the level of security applied to the SIM Data Download message (e.g. SMS-PP).
8.1 Behaviour of the Remote File Management Application
1. The parameter(s) in the SIM Data Download Message is either a single command, or a list of commands, which shall be processed sequentially.
2. The application shall take parameters from the SIM Data Download message and shall act upon the GSM files according to these parameters.
3. A Command "session" is defined as starting upon receipt of the parameter/command list, and ends when the parameter list in the SIM Data Download Message is completed, or when an error is detected which shall halt further processing of the command list.
4. At the beginning and end of a Command "session" the logical state, (e.g. file pointers) of the SIM as seen from the ME shall not be changed to an extent sufficient to disrupt the behaviour of the ME. If changes in the logical state have occurred that the ME needs to be aware of, the application on the SIM may issue a REFRESH command according to TS 11.14 . However, this is application dependent and therefore out of scope of the present document.
8.2 Coding of the commands
A command string may contain a single command or a sequence of commands. Each command is coded according to the generalised structure defined below; each element other than the Data field is a single octet; see TS 11.11 .
Class byte (CLA)
Instruction code (INS)
If a command has P3=’00’, then the SIM shall send back all available response parameters/data.
Administrative commands have not yet been defined, and thus, remain proprietary to SIM manufacturers for the present.
8.2.1 Input Commands
The standardised commands are listed in table 10. The commands are as defined in TS 11.11 , except that the SELECT command is extended from the one in TS 11.11  to include "SELECT by path" as defined in ISO/IEC 7816-4 .
Table 10: Input Commands
8.2.2 Output Commands
The commands listed in table 11 are defined in TS 11.11 . These commands shall only occur once in a command string and, if present, shall be the last command in the string. The Response Data shall be placed in the Additional Response Data element of the Response Packet. If SMS is being used, these should result in the generation of a single SM by the SIM application.
Table 11: Output commands
8.3 SIM specific behaviour for Response Packets (Using SMS‑PP)
Table 12 summarises the behaviour of the SIM’s RE/RA with regard to PoR.
Table 12: SIM specific behaviour
Unsuccessful cases (see table 5)
’90 00′ or ’91 XX’, null RP-ACK
’90 00′ or ’91 XX’, null RP-ACK
‘9F XX’ (PoR OK, status code ’00’).
‘9E XX’ (security error of some kind).
NOTE: in the case where no proof of Receipt is required by the sending entity, it is however permissible for the SIM to send back data using ‘9F XX’ in the successful case or ‘9E XX’ in the unsuccessful case.
If the SIM responds with the ’90 00′ or ’91 XX’ code, then there is no User Data to be included in an SMS-DELIVER-REPORT; the ME sends a "null" RP-ACK, with no User Data attached.
In the case of a ‘9F XX’ or ‘9E XX’ response from the SIM, ‘XX’ indicates the length of the response data to be obtained from the SIM using a later GET RESPONSE command. The response obtained from the SIM is the complete Response Packet to be included in the User Data part of the SMS-DELIVER-REPORT which will be returned to the Sending Entity as the TP part of the RP-ACK in the ‘9F XX’ case, or as the TP part of the RP-ERROR in the ‘9E XX’ case. In the case of a ‘9E XX’ response from the SIM, the value of the TP-FCS element of the RP-ERROR shall be ‘SIM data download error’. Because the SIM is unable to indicate to the ME that the TP-UDHI bit is to be set, the Sending Entity receiving the Response Packet shall expect the UDH structure in any event. See TS 04.11  for more detail of the structure of the RP-ACK and RP-ERROR protocol element, and TS 23.040  for more detail of the SMS-DELIVER-REPORT structure.
If a proof of Receipt is required by the sending entity, the Additional Response Data sent by the Remote File Management Application shall be formatted according to table 13:
Table 13: Format of additional response data
Number of commands executed within the command script (see note)
Last executed command status word
Last executed command response data if available (i.e., if the last command was an outgoing command)
NOTE: This field shall be set to ’01’ if one command was executed within the command script, ’02’ if two commands were executed, etc…