Ady Wicaksono Daily Activities

Archive for May 21st, 2008

Understanding GSM 03.48

with 10 comments

The structure of SMS-PP APDU including GSM 03.40 & GSM 03.48 header is defined in this structure:

The 3GPP TS 23.048 standard specifies the structure of Secure Packets in a general format and implementation using in particular Short Message Service Point to Point (SMS-PP).

The 3GPP TS 23.048 format is contained in the TP-UD (TP-User-Data) field in the 3GPP TS 03.40 format.

In the 3GPP TS 03.40 header, the TP-UDHI (User Data Header Indicator) bit value must be set to 1 to indicate that the initial bytes in the TP-User-Data field contain a header, and in particular, a 3GPP TS 23.048 header.

Please note that TS-SCA (Service Center Address) is optional

The TP-UD of SMS contains GSM 03.48 header and secure data, there’s 2 type of secure data:

  • Command Packet

Is a secured packet transmitted by sending entity to the receiving entity, containing secured application message.

  • Response Packet

Is a secured packet transmitted by receiving entity to the sending entity, containing secured response and possibly application data.

For Command Packet, the structure is like picture below:

As seen GSM 03.48 data include:

  • CPL (Command Packet Length): 2 octet

Indicate the number of bytes from and including the command header identifier to the end of the secured data, including any padding bytes

  • CHL (Command Header Length): 1 octet

Indicate the length of command header of packet data, means the number of bytes from and including the SPI to the end of RC/CC/DS.

  • SPI (Security Parameter Indicator): 2 octet

These 2 bytes define the security level applied to the input and output message, this include if counter verification and PoR (proof of receipt) are required along with the associated security level. If the SPI indicates that a specific field is unused, the sending entity sets the contens of this field to zero and the receiving entity ignores the contents. For example, if there is no counter check, the counter value is set to 0x00.

If the SPI indicates that no RC, CC, or DS is present in the command header then the RC/CC/DS field is not present (length of zero)

First byte of SPI is described in picture below:

Second byte of SPI is:

  • Ciphering Key Identifer (KiC): 1 octet

Keyset Identifier and algorithm for encryption for data.

  • Key Identifer (KiD): 1 octet

Keyset Identifier and algorithm for encryption for RS/CC/DS.

The coding for KiC and KiD is shown below:

  • Toolkit Application Reference (TAR): 3 octets

The TAR is part of the 23.048 header that identifies and triggers the Over The Air (OTA) feature, which is an application on the Java Card™. Each application

has its own TAR, which cannot be duplicated on the same card.

The TAR of a SIM toolkit applet is coded on three bytes and is defined in ETSI

TS 101 220 as the 13th, 14th and 15th byte of the applet’s AID.

If these bytes are not present in the AID, the TAR is not defined for the SIM toolkit applet and cannot be triggered on a formatted SMS PP Envelope.

The remote applet management TAR is standardised in 3GPP TS 23.048 and

ETSI TS 101 220 as 00h 00h 00h. All card manufacturers must support this value. Since the TAR value for RFM is not yet standardised, operators should

Inform the card manufacturers as to which TAR value is required for RFM.

To offer interoperability, all card manufacturers must obviously provide the

same value for referencing applets. The SIM Alliance suggests that operators

define their own TAR values.

  • CNTR (Counter): 5 octets

This counter is used for replay detection and sequence integrity. The presence and verification of this information are defined in the SPI bytes. Even if the SPI bytes require no counter available, the five counter bytes must be present in the TS 23.048 header

The following rules apply to counter management, with the aim of preventing replay and synchronization attack:

The SE sets the counter value; it is only to be incremented

When the counter value reaches its maximum value, the counter is blocked

If the security checks on an incoming command packet are successful and the counter mode used is mode 3 or 4 (b5b4 = 10 or b5b4 = 11), the card counter is updated using the counter of the incoming command packet.

If the security checks on an incoming command packet are successful and the counter mode used is mode 0 (No counter available mode: b5b4 = 00h), the five-byte counter must be present in the message, but is not checked and the card

• For mode 1 (Counter available: no replay or sequence checking: b5b4 = 01h), behavior depends on the application.

Example SMS-PP APDU:


Please note that this secure data & RS/CC/DS is encrypted with KiC & KiD:

KiC: 30 42 30 42 30 44 30 44 30 45 30 45 30 46 30 46
KiD: 01 23 45 67 89 AB CD EF 10 02 76 FE DC BA 01 23


A0C20000: This is the APDU command for SMS-PP (Point to Point) Download
^^ ->  0xA0: CLA of APDU
  ^^ -> 0xC2: INS of APDU
    ^^ -> 0x00: P1 of APDU
      ^^ -> 0x00: P2 of APDU

^^ -> 0x4E is length of data followed
  ^^ -> 0xD1 is a TAG of APDU data
    ^^ -> 0x4C is length of data followed
      ^^ -> 0x82 is a TAG that indicate Device Identities
        ^^ -> 0x02 is a TAG that indicate length of data
          ^^ -> 0x83 is a source device (Network)
            ^^ -> 0x81 is a destination device (UICC/SIMCard)

This now is is GSM 03.40 header

^^ -> 0x8B is TAG that indicate starting of SMS-TPDU data
  ^^ -> 0x46 is length of data followed
    ^^ -> 0x40 or in binary 01000000
          The bit structure numbering is like this
          TP-MTI  is bit no. 1 & bit no. 0 = 00 = type MS-Delivery
          TP-MMS  is bit no. 2 = 0 = no more message to send
          TP-UDHI is bit no. 6 = 1 = there’s header in TP-UD
          TP-RP   is bit no. 7 = 0 = no reply path 

      ^^ -> 0x08: Length of TP-OA is 8 digit
        ^^ -> 0x81: TON/NPI
          ^^^^^^^^ -> 55667788: TP-OA in BCD swapped format (8 digit)
                  ^^ -> 0x7F: TP-PID SIM data download

^^ -> 0xF6: TP-DCS
  ^^^^^^^^^^^^^^ -> TP-SCTS:
                ^^ -> 0x35: TP-UDL: User Data Length 53 octet

Now the TP-UD of SMS


^^ -> 0x02: UDHL
  ^^ -> 0x70: IEI (Information Element Identifier)
    ^^ -> 0x00: IEDL (Information Element Identifier Data Length)

^^^^ -> 0x00 0x30: CPL (Command Packet Length) -> 48 octet
    ^^ -> 0x15: CHL (Command Header Length) -> 21 octet
      ^^^^ -> 0x0E 0x19: SPI (Security Parameter Indicator)
              0x0E = 01110 (in binary form) means:
		-	Cryptographic Checksum
		-	Encryption applied
		-	Counter Available, replay or sequence not checked

              0x19 = 11001 (in binary form) means:
		-	PoR required to be sent to sending entity
		-	PoR response with CC Applied
		-	PoR to be encrypted

          ^^ -> 0x25: KiC Identifier
                0x25 = 100101 (in binary form) means:
		-	DES
		-	Triple DES in outer CBC-Mode using 2 different keys
		-	Keyset to be used is 0x02

            ^^ -> 0x25: KiD Identifier
                  0x25 = 100101 (in binary form) means:
		-	DES
		-	Triple DES in outer CBC-Mode using 2 different keys
		-	Keyset to be used is 0x02

              ^^^^^^ -> 0x000000: TAR (Toolkit Application Reference)
                        This is the default TAR for Remote Applet

^^^^^^^^^^ -> 5 octets of CNTR
          ^^ -> 0x1B: 1 octet of PCNTR
            ^^^^^^^^^^^^^^^^ -> D80CABB2C3F3903D: 8 octets of RS/CC/DS

And this is the secure data:

Written by adywicaksono

May 21, 2008 at 2:00 pm