Ady Wicaksono Daily Activities

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:

A0C200004ED14C820283818B46400881556677887FF600112912000004350270000030150E19252
5000000010E0A8A0E1BD80CABB2C3F3903D80EF579BAEECBE6941A6DC0D437D553FE120026765CF
497DEE5D

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

Details:

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

4ED14C82028381:
^^ -> 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

8B46400881556677887F
^^ -> 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

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

Now the TP-UD of SMS

0270000030150E192525000000010E0A8A0E1BD80CABB2C3F3903D80EF579BAEECBE6941A6DC0D437D553FE120026765CF497DEE5D

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

0030150E192525000000
^^^^ -> 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
                        Management 

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

And this is the secure data:
80EF579BAEECBE6941A6DC0D437D553FE120026765CF497DEE5D

Written by adywicaksono

May 21, 2008 at 2:00 pm

10 Responses

Subscribe to comments with RSS.

  1. boss u are great in terms of ur exceptional clarity on whatever subject u choose to write. i am working in a telecom company. although i can do without going in to much technical details , but i do not like this way . please tell me how to know every thing abt sms . which recomendations to read.i am working on nokia and comverse SMSC
    regrds
    anurag

    anurag

    July 27, 2008 at 6:48 am

  2. Hello, everybody. Somebody knows how to get CC? In the standard 23048 Note3 is below CPL and CHL, but in the S3-040242 CPI and CHI are noted to. What bytes are using for CC in the header. And generaly is CC the last bytes?

    antsu

    August 7, 2008 at 11:48 am

  3. Hello,
    Does anybody know how to find the 8 octets of RS/CC/DS (in this example CC)? The key and algorithm are specified in KIc. Is it correct that SPI-KIc-KID-TAR-CNTR-PCNTR-SecureData are all concatenated and then encrpted to find the RS/CC/DS (in this example CC)? How can only 8octets be the result of the encrytion?

    ann-sofie

    August 29, 2008 at 10:31 am

  4. I read some posts here every now and then but this is top one i’ve read so far

    Gary Arctic

    February 25, 2010 at 5:27 am

  5. Thanks, Ady you are great

    linpeh

    April 7, 2010 at 10:38 am

  6. I have a clear understanding of what can be implemented & deployed with GSM 03.48. Really great and detailed post, very good explanations and should lead to a top level understanding of the GSM network.

    Thank you.

    service gsm

    August 10, 2010 at 7:36 pm

  7. Very good article, but when reading spec GSM 03.48 I can’t find any information how to calculate RC/CC/DS.

    lOkAn

    March 2, 2011 at 4:28 pm

    • it’s standard crypto, please googling🙂

      adywicaksono

      May 28, 2011 at 6:12 am

  8. Hi, Andy I think there is a mistake because when we put your command to gemalto ınterpreter it calculates RC_CC_DS value CNTR adn Padding Counter Different and when we use this key to dechiper getting different values DES3 CBC nopadding

    Ugur Coruh

    March 21, 2011 at 3:51 pm

  9. Wow! Never thought I was about to find someone who takes the time to put this info in a blog and so well explained and detailed.
    Thank you for sharing

    R@U

    April 14, 2011 at 2:48 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: