Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.048  Word version:  5.9.0

Top   Top   None   None   Next
1…   5…

 

1  Scopep. 6

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.
Up

2  Referencesp. 6

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.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 22.048: "Security mechanisms for the (Universal) Subscriber Interface Module (U)SIM Application Toolkit; Stage 1".
[3]
TS 23.040: "Technical realization of the Short Message Service (SMS)".
[4]
TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface".
[5]
TS 51.011: Release 4: "Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface".
[6]
TS 31.111: "USIM Application Toolkit (USAT)".
[7]
ISO/IEC 7816-4: "Information technology - Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange".
[8]  Void
[9]
ISO 8731-1 (1987): "Banking - Approved algorithms for message authentication - Part 1: DEA".
[10]
ISO/IEC 10116 (1997): "Information technology - Security techniques - Modes of operation for an n-bit block cipher".
[11]
TS 23.041: "Technical realization of Cell Broadcast Service (CBS)".
[12]
TS 24.012: "Short Message Service Cell Broadcast (SMSCB) support on the mobile radio interface".
→ to date, withdrawn by 3GPP
[13]
TS 23.038: "Alphabets and language-specific information".
[14]
Open Platform Card Specification version 2.0.1: (see http://www.globalplatform.org/)
[15]
TS 43.019: "Subscriber Identity Module Application Programming Interface (SIM API); SIM API for Java Card™; Stage 2".
[16]
TS 31.101: "UICC-Terminal Interface, Physical and Logical Characteristics".
[17]
Schneier, Bruce: "Applied Cryptography Second Edition: Protocols, Algorithms and Source code in C", John Wiley & Sons, 1996, ISBN 0-471-12845-7.
[18]
ETSI TS 101 220: "Smart Cards; ETSI numbering system for telecommunication application providers".
Up

3  Definitions and abbreviationsp. 7

3.1  Definitionsp. 7

For the purposes of the present document, the following terms and definitions apply:
Application Layer:
layer above the Transport Layer on which the Application Messages are exchanged between the Sending and Receiving Applications
Application Message:
package of commands or data sent from the Sending Application to the Receiving Application, or vice versa, independently of the transport mechanism
Card Manager:
An application in charge of application management as defined in the Open Platform Card Specification [14].
Command Header:
Security Header of a Command Packet. It includes all fields except the Secured Data
Command Packet:
Secured Packet transmitted by the Sending Entity to the Receiving Entity, containing a secured Application Message
Counter:
mechanism or data field used for keeping track of a message sequence
Cryptographic Checksum:
string of bits derived from some secret information, (e.g. a secret key), part or all of the Application Message, and possible further information (e.g. part of the Security Header)
DES:
standard cryptographic algorithm specified as DEA in ISO 8731-1 [9]
Digital Signature:
string of bits derived from some secret information, (e.g. a secret key), the complete Application Message, and possible further information (e.g. part of the Security Header)
Message Identifier:
two-octet field used to identify the source and type of the message
Page Parameter:
single octet field used to represent the CBS page number in the sequence and the total number of pages in the SMS-CB message
Receiving Application:
the entity to which the Application Message is destined
Receiving Entity:
the entity where the Secured Packet is received (e.g. SMS-SC, UICC, USSD entry point, or dedicated (U)SIM Toolkit Server) and where the security mechanisms are utilised
Redundancy Check:
string of bits derived from the Application Message and possible further information for the purpose of detecting accidental changes to the message, without the use of any secret information
Response Header:
security Header of a Response Packet
Response Packet:
secured Packet transmitted by the Receiving Entity to the Sending Entity, containing a secured response and possibly application data
Secured Data:
field contains the Secured Application Message and possibly padding octets
Security Domain:
An application in charge of security management as defined in the Open Platform Card Specification [14]
Secured Packet:
information flow on top of which the level of required security has been applied
Security Header:
that part of the Secured Packet which consists of all security information (e.g. counter, key identification, indication of security level, checksum or Digital Signature)
Sender Identification:
this is the simple verification of the identity of the Sending Entity by the Receiving Entity comparing the sender identity with an apriori stored identity of the sender at the Receiving Entity.
Sending Application:
entity generating an Application Message to be sent
Sending Entity:
this is the entity from which the Secured Packet originates (e.g. SMS-SC, UICC, USSD entry point, or dedicated (U)SIM Toolkit Server) and where the security mechanisms are invoked
Serial Number:
two octet field which identifies a particular message.
Short Message:
information that may be conveyed by means of the SMS Service as defined in 3G TS 23.040.
Status Code:
this is an indication that a message has been received (correctly or incorrectly, indicating reason for failure).
Transport Layer:
this is the layer responsible for transporting Secured Packets through the 3G and GSM network.
Unsecured Acknowledgement:
this is a Status Code included in a response message.
Up

3.2  Abbreviationsp. 8

For the purpose of the present document, the following abbreviations apply:
ADD
Access Domain Data
ADP
Access Domain Parameter
CBC
Cipher Block Chaining
CBS
Cell Broadcast Service
CC
Cryptographic Checksum
CNTR
Counter
CHI
Command Header Identifier
CHL
Command Header Length
CPI
Command Packet Identifier
CPL
Command Packet Length
DAP
Data Authentication Pattern
DES
Data Encryption Standard
DCS
Data Coding Scheme
DS
Digital Signature
ECB
Electronic codebook
IEI
Information Element Identifier
IEIDL
Information Element Identifier Data Length
IED
Information Element Data
KIc
Key and algorithm Identifier for ciphering
KID
Key and algorithm Identifier for RC/CC/DS
KIK
Key Identifier for protecting KIc and KID
MID
Message IDentifier
MO-SMS
Mobile Originated Short Message
MSL
Minimum Security Level
MSLD
Minimum Security Level Data
MT-SMS
Mobile Terminated Short Message
OP
Open Platform
PCNTR
Padding Counter
PLMN
Public Land Mobile Network
PoR
Proof of Receipt
PP
Page Parameter
RA
Receiving Application
RC
Redundancy Check
RE
Receiving Entity
RHI
Response Header Identifier
RHL
Response Header Length
RPI
Response Packet Identifier
RPL
Response Packet Length
SA
Sending Application
SE
Sending Entity
SIM
Subscriber Identity Module
SM
Short Message
SMS
Short Message Service
SMS-PP
Short Message Service - Point to Point
SMS-CB
Short Message Service - Cell Broadcast
SMS-SC
Short Message Service - Service Centre
SN
Serial Number
SPI
Security Parameters Indication
TAR
Toolkit Application Reference
TLV
Tag - Length - Value (data structure)
UDH
User Data Header
UDHI
User Data Header Indicator
UDHL
User Data Header Length
UDL
User Data Length
USIM
Universal Subscriber Identity Module
USSD
Unstructured Supplementary Services Data
Up

4  Overview of Security Systemp. 9

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).
Copy of original 3GPP image for 3GPP TS 23.048, Fig. 1: System Overview
Figure 1: System Overview
(⇒ copy of original 3GPP image)
Up
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.
Up

Up   Top   ToC