The present document specifies the structure of the Secured Packets in a general format and in implementations using Short Message Service Point to Point (SMS-PP) and Short Message Service Cell Broadcast (SMS-CB). Furthermore, the coding is specified for a set of common application commands within the secured packets. This set is a subset of commands specified in TS 51.011 and allows remote management of files on the UICC in conjunction with SMS and the Data Download to UICC feature of TS 31.111. For UICCs based on 3GPP TS 43.019 [15], the set of commands used in the remote applet management is defined in the present document. This is based on the Open Platform card management specification [14]. For UICCs based on other technologies, other loading mechanisms may be used. The present document is applicable to the exchange of secured packets between an entity in a 3G or GSM PLMN and an entity in the UICC. Secured Packets contain application messages to which certain mechanisms according to TS 22.048 have been applied. Application messages are commands or data exchanged between an application resident in or behind the 3G or GSM PLMN and on the UICC. The Sending/Receiving Entity in the 3G or GSM PLMN and the UICC are responsible for applying the security mechanisms to the application messages and thus turning them into Secured Packets.

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

• References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

An overview of the secure communication related to the (U)SIM Application Toolkit together with the required security mechanisms is given in TS 22.048, (see Figure 1).

The Sending Application prepares an Application Message and forwards it to the Sending Entity, with an indication of the security to be applied to the message. The Sending Entity prepends a Security Header (the Command Header) to the Application Message. It then applies the requested security to part of the Command Header and all of the Application Message, including any padding octets. The resulting structure is here referred to as the (Secured) Command Packet. Under normal circumstances the Receiving Entity receives the Command Packet and unpacks it according to the security parameters indicated in the Command Header. The Receiving Entity subsequently forwards the Application Message to the Receiving Application indicating to the Receiving Application the security that was applied. The interface between the Sending Application and Sending Entity and the interface between the Receiving Entity and Receiving Application are proprietary and therefore outside the scope of the present document. If so indicated in the Command Header, the Receiving Entity shall create a (Secured) Response Packet. The Response Packet consists of a Security Header (the Response Header) and optionally, application specific data supplied by the Receiving Application. Both the Response Header and the application specific data are secured using the security mechanisms indicated in the received Command Packet. The Response Packet will be returned to the Sending Entity, subject to constraints in the transport layer, (e.g. timing). Although there is no direct acknowledgement to an SMS-CB message in 3GPP TS 24.012 [12], the Sending Application may have requested a response. In this case a (Secured) Response Packet could be sent using a different bearer by the Receiving Application. In some circumstances a security related error may be detected at the Receiving Entity. In such circumstances the Receiving Entity shall react according to the following rules:

1. nothing shall be forwarded to the Receiving Application. i.e. no part of the Application Message, and no indication of the error.
2. if the Sending Entity does not request a response (in the Command Header) the Receiving Entity discards the Command Packet and no further action is taken.
3. if the Sending Entity does request a response and the Receiving Entity can unambiguously determine what has caused the error, the Receiving Entity shall create a Response Packet indicating the error cause. This Response Packet shall be secured according to the security indicated in the received Command Packet.
4. if the Sending Entity does request a response and the Receiving Entity cannot determine what has caused the error, the Receiving Entity shall send a Response Packet indicating that an unidentified error has been detected. This Response Packet is sent without any security being applied.
5. If the Receiving Entity receives an unrecognisable Command Header (e.g. an inconsistency in the Command Header), the Command Packet shall be discarded and no further action taken.