`
`
`
`
`
`
`
`
` GSM 03.48 V8.0.0 (1999-07)
`
`Technical Specification
`
`Digital cellular telecommunications system (Phase 2+);
`Security Mechanisms for the SIM application toolkit;
`Stage 2
`(GSM 03.48 version 8.0.0 Release 99)
`
`Available SMG only
`
`GLOBAL SYSTEM FOR
`MOBILE COMMUNICATIONS
`
`
`
`
`
`
`R
`
`
`
`
`
`1
`
`APPLE 1021
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`2
`
`GSM 03.48 V8.0.0 (1999-07)
`
`
`
`
`
`
`
`
`
`Reference
`RTS/SMG-090348Q6R1 (axo030c3.PDF)
`
`Keywords
`Digital cellular telecommunications system,
`Global System for Mobile communications (GSM)
`
`ETSI
`
`Postal address
`F-06921 Sophia Antipolis Cedex - FRANCE
`
`Office address
`650 Route des Lucioles - Sophia Antipolis
`Valbonne - FRANCE
`Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
`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
`
`Internet
`secretariat@etsi.fr
`http://www.etsi.org
`
`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 1999.
`All rights reserved.
`
`ETSI
`
`2
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`3
`
`GSM 03.48 V8.0.0 (1999-07)
`
`Contents
`
`Intellectual Property Rights ................................................................................................................................ 4
`Foreword ............................................................................................................................................................ 4
`1
`Scope ........................................................................................................................................................ 5
`2
`References ................................................................................................................................................ 5
`2.1
`Normative references ......................................................................................................................................... 5
`2.2
`Informative references ....................................................................................................................................... 6
`3
`Definitions and abbreviations .................................................................................................................. 6
`3.1
`Definitions ......................................................................................................................................................... 6
`3.2
`Abbreviations ..................................................................................................................................................... 7
`4
`Overview of Security System ................................................................................................................... 8
`5
`Generalised Secured Packet structure .................................................................................................... 10
`5.1
`Command Packet structure .............................................................................................................................. 10
`5.1.1
`Coding of the SPI ....................................................................................................................................... 11
`5.1.2
`Coding of the KIc ....................................................................................................................................... 11
`5.1.3
`Coding of the KID ...................................................................................................................................... 12
`5.1.4
`Counter Management ................................................................................................................................. 12
`5.2
`Response Packet structure ................................................................................................................................ 13
`6
`Implementation for SMS-PP .................................................................................................................. 14
`6.1
`Structure of the UDH of the Security Header in a Short Message Point to Point ............................................ 14
`6.2
`A Command Packet contained in a Single Short Message Point to Point ........................................................ 15
`6.3
`A Command Packet contained in Concatenated Short Messages Point to Point .............................................. 15
`6.4
`Structure of the Response Packet ..................................................................................................................... 17
`7
`Implementation for SMS-CB ................................................................................................................. 18
`7.1
`Structure of the CBS page in the SMS-CB Message ....................................................................................... 18
`7.2
`A Command Packet contained in a SMS-CB message .................................................................................... 18
`7.3
`Structure of the Response Packet for a SMS-CB Message .............................................................................. 19
`8
`Standardised SIM toolkit commands for Remote File Management ..................................................... 19
`8.1
`Behaviour of the Remote File Management Application ................................................................................. 19
`8.2
`Coding of the commands ................................................................................................................................. 20
`8.2.1
`Type 1 Commands ..................................................................................................................................... 20
`8.2.2
`Type 2 Commands ..................................................................................................................................... 20
`8.3
`SIM specific behaviour for Response Packets (Using SMS-PP) ..................................................................... 20
`Annex A (informative): Change History ...................................................................................................... 22
`History .............................................................................................................................................................. 23
`
`
`ETSI
`
`3
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`4
`
`GSM 03.48 V8.0.0 (1999-07)
`
`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 SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect
`of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the
`ETSI Web server (http://www.etsi.fr/ipr or http://www.etsi.org/ipr).
`
`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 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 ETSI Technical Specification (TS) has been produced by the Special Mobile Group (SMG) of the European
`Telecommunications Standards Institute (ETSI).
`
`This TS defines the stage 1 description for the standardised security mechanisms in conjunction with the SIM
`Application Toolkit for the interface between a GSM PLMN Entity and a SIM within the digital cellular
`telecommunications system.
`
`The contents of this TS are subject to continuing work within SMG and may change following formal SMG approval.
`Should SMG modify the contents of this TS it will then be republished by ETSI with an identifying change of release
`date and an increase in version number as follows:
`
`Version 8.x.y
`
`where:
`
`8
`
`x
`
`indicates GSM Release 1998 of Phase 2+;
`
`the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections,
`updates, etc.
`
`y
`
`the third digit is incremented when editorial only changes have been incorporated in the specification.
`
`ETSI
`
`4
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`5
`
`GSM 03.48 V8.0.0 (1999-07)
`
`Scope
`1
`This 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 GSM 11.11 [5] and allows remote management of files on the Subscriber Identity
`Module (SIM) in conjunction with SMS and the SIM Data Download feature of GSM 11.14 [6].
`
`This specification is applicable to the exchange of secured packets between an entity in a GSM PLMN and an entity in
`the SIM.
`
`Secured Packets contain application messages to which certain mechanisms according to GSM 02.48 [2] have been
`applied. Application messages are commands or data exchanged between an application resident in or behind the GSM
`PLMN and on the SIM. The Sending/Receiving Entity in the GSM PLMN and the SIM are responsible for applying the
`security mechanisms to the application messages and thus turning them into Secured Packets.
`
`References
`2
`References may be made to:
`
`a) specific versions of publications (identified by date of publication, edition number, version number, etc.), in
`which case, subsequent revisions to the referenced document do not apply; or
`
`b) all versions up to and including the identified version (identified by "up to and including" before the version
`identity); or
`
`c) all versions subsequent to and including the identified version (identified by "onwards" following the version
`identity); or
`
`d) publications without mention of a specific version, in which case the latest version applies.
`
`A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same
`number.
`
`2.1
`[1]
`
`Normative references
`GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and
`acronyms".
`
`[2]
`
`[3]
`
`[4]
`
`[5]
`
`[6]
`
`[7]
`
`GSM 02.48: "Digital cellular telecommunications system (Phase 2+); Security Mechanisms for the
`SIM Application Toolkit - Stage 1".
`
`GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical realization of the
`Short Message Service (SMS) Point-to-Point (PP)".
`
`GSM 04.11: "Digital cellular telecommunications system (Phase 2+); Point-to-Point (PP) Short
`Message Service (SMS) support on mobile radio interface".
`
`GSM 11.11: "Digital cellular telecommunications system (Phase 2+); Specification of the
`Subscriber Identity Module - Mobile Equipment (SIM - ME) interface".
`
`GSM 11.14: "Digital cellular telecommunications system (Phase 2+); Specification of the SIM
`Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM - ME)
`interface".
`
`ISO/IEC 7816-4: "1995 Information technology -- Identification cards -- Integrated circuit(s) cards
`with contacts -- Part 4: Interindustry commands for interchange".
`
`ETSI
`
`5
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`6
`
`GSM 03.48 V8.0.0 (1999-07)
`
`[8]
`
`[9]
`
`[10]
`
`[11]
`
`[12]
`
`[13]
`
`ISO/IEC 7816-6:1996 "Identification cards -- Integrated circuit(s) cards with contacts -- Part 6:
`Interindustry data elements".
`
`ISO 8731-1:1987 "Banking -- Approved algorithms for message authentication -- Part 1: DEA".
`
`ISO/IEC 10116:1997 "Information technology -- Security techniques -- Modes of operation for an
`n-bit block cipher".
`
`GSM 03.41: "Digital cellular telecommunications system (Phase 2+); Technical realisation of
`Short Message Service Cell Broadcast (SMSCB)".
`
`GSM 04.12: "Digital cellular telecommunications system (Phase 2+); Short Message Service Cell
`Broadcast (SMSCB) support on the mobile radio interface".
`
`GSM 03.38: "Digital cellular telecommunications system (Phase 2+); Alphabets and language-
`specific information".
`
`2.2
`[20]
`
`Informative references
`Schneier, Bruce: "Applied Cryptography Second Edition: Protocols, Algorithms and Source code
`in C", John Wiley & Sons, 1996, ISBN 0-471-12845-7.
`
`3
`
`Definitions and abbreviations
`
`Definitions
`3.1
`For the purposes of this specification, the following definitions apply:
`
`Application Layer: The layer above the Transport Layer on which the Application Messages are exchanged between
`the Sending and Receiving Applications.
`
`Application Message: The package of commands or data sent from the Sending Application to the Receiving
`Application, or vice versa, independently of the transport mechanism. An Application Message is transformed with
`respect to a chosen Transport Layer and chosen level of security into one or more secured packets.
`
`Command Header: The Security Header of a Command Packet. It includes all fields except the Secured Data.
`
`Command Packet: A Secured Packet transmitted by the Sending Entity to the Receiving Entity, containing a secured
`Application Message.
`
`Counter: A mechanism or data field used for keeping track of a message sequence. This could be realised as a sequence
`oriented or time stamp derived value, maintaining a level of synchronisation between the Sending Entity and the
`Receiving Entity.
`
`Cryptographic Checksum: A 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). The secret key is known to the
`Sending Entity and to the Receiving Entity. The Cryptographic Checksum is often referred to as Message Authentication
`Code.
`
`DES: a standard cryptographic algorithm specified as DEA in ISO 8731-1 [9].
`
`Digital Signature: A 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). The secret information is known only to the
`Sending Entity. Although the authenticity of the Digital Signature can be proved by the Receiving Entity, the Receiving
`Entity is not able to reproduce the Digital Signature without knowledge of the secret information owned by the Sending
`Entity.
`
`Message Identifier: A two-octet field used to identify the source and type of the message.
`
`ETSI
`
`6
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`7
`
`GSM 03.48 V8.0.0 (1999-07)
`
`Page Parameter: A 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: This is the entity to which the Application Message is destined.
`
`Receiving Entity: This is the entity where the Secured Packet is received (e.g. SMS-SC, SIM, USSD entry point, or
`dedicated SIM Toolkit Server) and where the security mechanisms are utilised. The Receiving Entity processes the
`Secured Packets.
`
`Redundancy Check: A 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: The Security Header of a Response Packet.
`
`Response Packet: A Secured Packet transmitted by the Receiving Entity to the Sending Entity, containing a secured
`response and possibly application data.
`
`Secured Data: This field contains the Secured Application Message and possibly padding octets.
`
`Secured Packet: The information flow on top of which the level of required security has been applied. An Application
`Message is transformed with respect to a chosen Transport Layer and chosen level of security into one or more Secured
`Packets.
`
`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: The entity generating an Application Message to be sent.
`
`Sending Entity: This is the entity from which the Secured Packet originates (e.g. SMS-SC, SIM, USSD entry point, or
`dedicated SIM Toolkit Server) and where the security mechanisms are invoked. The Sending Entity generates the
`Secured Packets to be sent.
`
`Serial Number: A two octet field which identifies a particular message. It is linked to the Message Identifier and is
`altered every time the message is changed.
`
`Short Message: Information that may be conveyed by means of the SMS Service as defined in GSM 03.40 [3].
`
`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 GSM network. The
`transport layer implements one or more transport mechanisms, (e.g. SMS or USSD).
`
`Unsecured Acknowledgement: This is a Status Code included in a response message.
`
`Abbreviations
`3.2
`In addition to those below, abbreviations used in this specification are listed in GSM 01.04.
`
`CBC
`CBS
`CC
`CNTR
`CHI
`CHL
`CPI
`CPL
`DES
`DCS
`DS
`
`Cipher Block Chaining
`Cell Broadcast Service
`Cryptographic Checksum
`Counter
`Command Header Identifier
`Command Header Length
`Command Packet Identifier
`Command Packet Length
`Data Encryption Standard
`Data Coding Scheme
`Digital Signature
`
`ETSI
`
`7
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`8
`
`GSM 03.48 V8.0.0 (1999-07)
`
`ECB
`IEI
`IEIDL
`IED
`KIc
`KID
`MID
`MO-SMS
`MT-SMS
`PCNTR
`PLMN
`PoR
`PP
`RA
`RC
`RE
`RHI
`RHL
`RPI
`RPL
`SA
`SE
`SIM
`SM
`SMS
`SMS-PP
`SMS-CB
`SMS-SC
`SN
`SPI
`TAR
`TLV
`UDH
`UDHI
`UDHL
`UDL
`USSD
`
`Electronic codebook
`Information Element Identifier
`Information Element Identifier Data Length
`Information Element Data
`Key and algorithm Identifier for ciphering
`Key and algorithm Identifier for RC/CC/DS
`Message IDentifier
`Mobile Originated Short Message
`Mobile Terminated Short Message
`Padding Counter
`Public Land Mobile Network
`Proof of Receipt
`Page Parameter
`Receiving Application
`Redundancy Check
`Receiving Entity
`Response Header Identifier
`Response Header Length
`Response Packet Identifier
`Response Packet Length
`Sending Application
`Sending Entity
`Subscribers Identity Module
`Short Message
`Short Message Service
`Short Message Service – Point to Point
`Short Message Service – Cell Broadcast
`Short Message Service - Service Centre
`Serial Number
`Security Parameters Indication
`Toolkit Application Reference
`Tag – Length – Value (data structure)
`User Data Header
`User Data Header Indicator
`User Data Header Length
`User Data Length
`Unstructured Supplementary Services Data
`
`Overview of Security System
`4
`An overview of the secure communication related to the SIM Application Toolkit together with the required security
`mechanisms is given in GSM 02.48 [2], (see figure 1).
`
`
`
`
`ETSI
`
`8
`
`

`

`
`GSM 03.48 version 8.0.0 Release 99
`
`9
`
`GSM 03.48 V8.0.0 (1999-07)
`
`Security
`
`Security
`
`Sending
`Application
`
`Sending
`Entity
`
`Transport
`Mech.
`
`Receiving
`Entity
`
`Receiving
`Application
`
`Information flow
`
`(e.g. a bank)
`
`(e.g. SMS-SC)
`
`(e.g. USSD, SMS)
`
`(e.g. SIM)
`
`(e.g. SIM
`resident
`application)
`
`(e.g. SIM)
`
`(e.g. SMS-SC)
`
`(e.g. SIM
`resident
`application)
`
`(e.g. a bank
`resident
`application)
`
`
`
`Figure 1: System Overview
`
`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 this specification.
`
`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 GSM 04.12 [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)
`
`3)
`
`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
`
`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.
`
`ETSI
`
`9
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`10
`
`GSM 03.48 V8.0.0 (1999-07)
`
`4)
`
`5)
`
`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.
`
`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.
`
`Generalised Secured Packet structure
`5
`Command and Response Packets have the same overall structure consisting of a variable length security header within a
`variable length shell. To model this, use is made of a double TLV -tag, length, value- structure.
`
`Command Packet structure
`5.1
`The Command Header precedes the Secured Data in the Command Packet, and is of variable length.
`
`The Command Packet shall be structured according to table 1.
`
`Table 1: Structure of the Command Packet
`
`Element
`Command Packet Identifier (CPI)
`Command Packet Length (CPL)
`
`Length
`1 octet
`variable
`
`Command Header Identifier (CHI)
`Command Header Length (CHL)
`
`1 octet
`variable
`
`Comment
`Identifies that this data block is the secured Command Packet.
`This shall indicate the number of octets from and including the
`Command Header Identifier to the end of the Secured Data,
`including any padding octets.
`Identifies the Command Header.
`This shall indicate the number of octets from and including the
`SPI to the end of the RC/CC/DS.
`see detailed coding in section 5.1.1.
`Key and algorithm Identifier for ciphering.
`Key and algorithm Identifier for RC/CC/DS.
`Coding is application dependent.
`
`Security Parameter Indicator (SPI)
`Ciphering Key Identifier (KIc)
`Key Identifier (KID)
`Toolkit Application Reference
`(TAR)
`Counter (CNTR)
`Padding counter (PCNTR)
`
`Redundancy Check (RC),
`Cryptographic Checksum (CC) or
`Digital Signature (DS)
`Secured Data
`
`2 octets
`1 octet
`1 octet
`3 octets
`
`5 octets
`1 octet
`
`variable
`
`variable
`
`Replay detection and Sequence Integrity counter.
`This indicates the number of padding octets at the end of the
`secured data.
`Length depends on the algorithm. A typical value is 8 octets if
`used, and for a DS could be 48 or more octets; the minimum
`should be 4 octets.
`Contains the Secured Application Message and possibly padding
`octets.
`Unless indicated otherwise, the CPL and the CHL shall be coded according to ISO/IEC 7816-6 [8].
`
`Table 2: Linear Representation of Command Packet
`
`CPI CPL
`
`CHI
`
`CHL
`
`SPI
`
`KIc
`
`KID
`
`TAR
`
`CNTR PCNTR RC/CC/DS Secured
`Data with
`Padding
`Note 1
`Note 1
`Note 1 Note 1
`
`
`
`
`
`
`
`
`Note 2
`
`Note 3 Note 2 Note 2 Note 2 Note 2 Note 2 Note 2
`
`Note 3
`
`NOTE 1: These fields are included in the data to be ciphered if ciphering is indicated in the Security Header.
`NOTE 2: These fields are included in the calculation of the RC/CC/DS.
`NOTE 3: Part or all of these fields may also be included in the calculation of the RC/CC/DS, depending on
`implementation (e.g. SMS).
`
`
`
`
`If ciphering is indicated, first the RC/CC/DS shall be calculated as indicated in Note 2, and then ciphering shall be
`applied, as indicated in Note 1.
`
`If the SPI indicates that a specific field is unused, the Sending Entity shall set the contents of this field to zero, and the
`Receiving Entity shall ignore the contents.
`
`ETSI
`
`10
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`11
`
`GSM 03.48 V8.0.0 (1999-07)
`
`If the SPI indicates that no RC, CC or DS is present in the Command Header, the RC/CC/DS field shall be of zero
`length.
`
`If the Padding Counter content is zero, this shall indicate no padding octets, or no padding is necessary.
`
`5.1.1 Coding of the SPI
`The SPI is coded as below.
`
`00: No RC, CC or DS
`01: Redundancy Check
`10: Cryptographic Checksum
`11: Digital Signature
` : No Ciphering
`1 : Ciphering
`
`00: No counter available
`01: Counter available; no replay or sequence
` checking (note 1)
`10: Process if and only if counter value is higher
` than the value in the RE (note 2)
`11: Process if and only if counter value is one
` higher than the value in the RE (note 3)
`
`Reserved (set to zero and ignored by RE)
`
` 0
`
`First Octet:
`
`b8 b7 b6 b5 b4 b3 b2 b1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`NOTE 1: In this case the counter value is used for information purposes only, (e.g. date or time stamp). If the
`Command Packet was successfully unpacked, the counter value can be forwarded from the Receiving
`Entity to the Receiving Application. This depends on proprietary implementations and happens in a
`application dependent way.
`
`NOTE 2: The counter value is compared with the counter value of the last received Command Packet. This is
`tolerant to failures on the transport level (i.e. losses of Command Packets). A possible scenario is a global
`update.
`
`NOTE 3: This provides strict control in addition to security indicated in Note 2.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`00: No PoR reply to the Sending Entity (SE)
`01: PoR required to be sent to the SE
`10: PoR required only when an error has occured
`11: Reserved
`
`00: No security applied to PoR response to SE
`01: PoR response with simple RC applied to it
`10: PoR response with CC applied to it
`11: PoR response with DS applied to it
` : PoR response shall not be ciphered
`1 : PoR response shall be ciphered
`
`For SMS only
`0 : PoR response shall be sent using
` SMS-DELIVER-REPORT
`1 : PoR response shall be sent using SMS-SUBMIT
`
`Reserved (set to zero and ignored by RE)
`
` 0
`
`ETSI
`
`Second Octet:
`
`b8 b7 b6 b5 b4 b3 b2 b1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`5.1.2 Coding of the KIc
`The KIc is coded as below.
`
`11
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`12
`
`GSM 03.48 V8.0.0 (1999-07)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`b8 b7 b6 b5 b4 b3 b2 b1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`00: Algorithm known implicitly by both entities
`01: DES
`10: Reserved
`11: proprietary Implementations
`
`00: DES in CBC mode
`01: Triple DES in outer-CBC mode using two
` different keys
`10: Triple DES in outer-CBC mode using three
` different keys
`11: DES in ECB mode
`
`indication of Keys to be used
`(keys implicitly agreed between both entities)
`
`
`DES is the algorithm specified as DEA in ISO 8731-1 [9]. DES in CBC mode is described in ISO/IEC 10116 [10].
`Triple DES in outer-CBC mode is described in section 15.2 of [20]. DES in ECB mode is described in ISO/IEC 10116
`[10].
`
`The initial chaining value for CBC modes shall be zero. For the CBC modes the counter (CNTR) shall be used.
`
`5.1.3 Coding of the KID
`The KID is coded as below.
`
`
`b8 b7 b6 b5 b4 b3 b2 b1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`00: Algorithm known implicitly by both entities
`01: DES
`10: Reserved
`11: proprietary Implementations
`
`00: DES in CBC mode
`01: Triple DES in outer-CBC mode using two
` different keys
`10: Triple DES in outer-CBC mode using three
` different keys
`11: Reserved
`
`indication of Keys to be used
`(keys implicitly agreed between both entities)
`
`
`DES is the algorithm specified as DEA in ISO 8731-1 [9]. DES in CBC mode is described in ISO/IEC 10116 [10].
`Triple DES in outer-CBC mode is described in section 15.2 of [20].
`
`The initial chaining value for CBC modes shall be zero. For the CBC modes the counter (CNTR) shall be used. If
`padding is required, the padding octets shall be coded hexadecimal '00'.
`
`Counter Management
`5.1.4
`The following rules shall apply to counter management:
`
`- The SE sets the counter value. It shall only be incremented.
`
`- When the counter value reaches its maximum value the counter is blocked .
`
`-
`
`In order to prevent replay attacks the RE shall increment the counter to its next value upon receipt of a Command
`Packet irrespective of whether or not the Command Packet could be successfully unpacked.
`
`If there is more than one SE, care has to be taken to ensure that the counter values remain synchronised between the SE's
`to what the RE is expecting, irrespective of the transport mechanism employed.
`
`The level of security is indicated via the proprietary interface between the Sending/Receiving Application and
`Sending/Receiving Entity. Application designers should be aware that if the Sending Application requests "No
`RC/CC/DS" or "Redundancy Check" and "No Counter Available" from the SE, no security is applied to the Application
`Message and therefore there is an increased threat of malicious attack.
`
`ETSI
`
`12
`
`

`

`GSM 03.48 version 8.0.0 Release 99
`
`
`13
`
`GSM 03.48 V8.0.0 (1999-07)
`
`5.2
`
`Response Packet structure
`Table 3: Structure of the Response Packet
`
`Element
`Response Packet Identifier (RPI)
`Response Packet Length (RPL)
`
`Length
`1 octet
`variable
`
`Response Header Identifier (RHI)
` Response Header Length (RHL)
`
`Toolkit Application Reference
`(TAR)
`Counter (CNTR)
`
`Padding counter (PCNTR)
`
`Response Status Code Octet
`Redundancy Check (RC),
`Cryptographic Checksum (CC) or
`Digital Signature (DS)
`Additional Response Data
`
`1 octet
`variable
`
`3 octets
`
`5 octets
`
`1 octet
`
`1 octet
`variable
`
`variable
`
`
`
`Comment
`Identifies a Response Packet.
`Indicates the number of octets from and including RHI to the end
`of Additional Response data, including any padding octets.
`Identifies the Response Header.
`Indicates the number of octets from and including RC/CC/DSto
`the end of the Response Status Code octet.
`This shall be a copy of the contents of the TAR in the Command
`Packet.
`This shall be a copy of the contents of the CNTR in the Command
`Packet.
`This indicates the number of padding octets at the end of the
`Additional Response Data.
`Codings defined in Table 5.
`Length depending on the algorithm indicated in the Command
`Header in the incoming message. A typical value is 4 to 8 octets,
`or zero if no RC/CC/DS is requested.
`Optional Application Specific Response Data, including possible
`padding octets.
`
`Unless indicated otherwise, t