Ady Wicaksono Daily Activities

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 0×00.

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 15^th 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

Kira-kira celetukan itu muncul dari pelanggan perusahaan tempat saya bekerja saat ini, sebut saja pelanggan ini X. Unik memang, dulu saya bekerja di sister company perusahaan ini, dan duduknya tidak jauh dari pekerja-pekerja asing yang mengerjakan aplikasi billing untuk X ini (oh ya X ini adalah sebuah operator seluler di Indonesia). Saya sempat bertanya ke HRD katanya tarif pekerja-pekerja asing itu mahal, saben hari nginepnya di hotel bintang 5, dan bayarannya mahal, mana jadwal implementasi billing itu lama, jadi bisa dikatakan biaya untuk pekerja asing itu mahal.

Nah sekarang giliran saya yang merasakan fasilitas expat itu, nginep di Marriot, dibayarnya pake dollar, opo ora enak?… Dateng-dateng ke kantor X ketemu banyak kawan lama, pada komentar… lho jare sing dikirim engineer seko Singapura, lah kok kowe sing teko … {lho katanya yang dikirim engineer dari Singapura, kok kamu yang dateng} … jadinya kita ya banyak haha-hihi, ngobrol ngablor ngidul selama implementasi project …..

Ya itulah potret Indonesia, pekerja asing mendapatkan benefit yang berlebihan, padahal secara skill orang Indonesia tidak kalah dengan skill orang asing.

I’m now building the MySQL Cluster with 7 Linux server, each using Intel EMT64 (not 32 bit but has PAE ext so support 4Gbytes RAM), RAM each 6Gbytes. Please wait for my next report

I believe many of you ever receive this kind of SMS, normally content provider send java games, midi ringtone, or any multimedia content usin this type of SMS.

Actually how they send it is normally like picture below:

At first stage Push Initiator will send Service Indication in XML format (process 1) into Push Proxy Gateway (PPG) and then PPG will build a WAP Push SMS and send it to user (2).

When User receive it (3), it will be simply like normal SMS but contains a URL that could be simply opened. If user try to open it, then the rest is normally WAP session or TCP/IP session (4) and it’s actually like normal mobile browsing (5)

The algorithm use by mobile phone when receiving WAP Push Service Indication is like this:

Now I don’t want to discuss about how SI XML is sent by push initiator, but how PPG build WAP Push Service Indication. Actually the SI XML sent by push initiator is like this:

<?xml version="1.0"?>
<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
"http://www.wapforum.org/DTD/si.dtd">
<si>
<indication href="http://www.xyz.com/email/123/abc.wml"
created="1999-06-25T15:23:15Z"
si-expires="2099-06-30T00:00:00Z">
You have 4 new emails
</indication>
</si>

PPG will then build WBXML or Wireless Binary format for that XML data, and it’s like this

02056A0045C60D0378797A008503656D61696C2F3132332F6162632E776D6C000AC307199906251
5231510C304209906030103596F7520686176652034206E657720652D6D61696C73000101

That code above is hexadecimal code where 2 digit represented 1 byte hexadecimal digit range from 0×00 to 0xFF.

The detail of this encoding is:

02056A0045C60D0378797A00
^^ -> 0x02: Version of WBXML is 1.2
  ^^ -> 0x05: SI 1.0 Public Identifier, this indicated that document is a SI version 1.0 document
    ^^ -> 0x6A: Character Set is UTF-8
      ^^ -> 0x00: Table string length is 0x00
        ^^ -> 0x45: This is a WBXML coding for tag <SI> with content only (No attribute)
	  ^^ -> 0xC6: This is a WBXML coding for tag <indication> with content & attribute
	    ^^ -> 0x0D: This is a WBXML coding for attribute href="http://www."
	      ^^ -> 0x03: This is an indicator that a string is following ended with 0x00 (NULL)
	        ^^^^^^^^ -> 0x78 0x79 0x7A 0x00: This is a hex value of string "xyz" ended with 0x00 (NULL)

8503656D61696C2F3132332F6162632E776D6C00
^^ -> 0x85: This is a WBXML coding for string ".com/"
  ^^ -> 0x03: This is an indicator that a string is following ended with 0x00 (NULL)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -> 0x656D61696C2F3132332F6162632E776D6C000
                                             Hex representation of string "email/123/abc.wml"
					     ended with 0x00 (NULL)

0AC30719990625152315
^^ -> 0x0A: This is a WBXML coding for attribute "created="
  ^^ -> 0xC3: This is an indicator that an OPAQUE data (data with Length Value format)
    ^^ -> 0x07: Length of OPAQUE data
      ^^^^^^^^^^^^^^ -> 0x19990625152315 (7 octet) this is represent date "1999-06-25 15:23:15"

10C3042099060301
^^ -> 0x10: This is a WBXML coding for attribute "expires="
  ^^ -> 0xC3: This is an indicator that an OPAQUE data (data with Length Value format)
    ^^ -> 0x04: Length of OPAQUE data
      ^^^^^^^^ -> 0x20990603 (4 octet) this is to represent date "2099-06-30 00:00:00"
              ^^ -> 0x01: This is to indicate end of attribute for current TAG
	                  so no more attribute inside tag <indication>

03596F7520686176652034206E657720652D6D61696C7300
^^ -> 0x03: This is an indicator that a string is following ended with 0x00 (NULL)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -> 0x596F7520686176652034206E657720652D6D61696C73000
                                       This is a hex representation of string:
				       "You have 4 emails" ended with 0x00 (NULL)
0101
^^ -> 0x01: this is to indicate end of attribute for current TAG (should refer to </indication> )
  ^^ -> 0x01: this is to indicate end of attribute for current TAG (should refer to </si> )

Now, PPG will generate WSP (Wireless Session Protocol) header as defined in WAP spec (www.openmobilealliance.org) like this:

01060403AE81EA

01060403AE81EA

This WSP header is actually encoded like this:

01060403AE81EA
^^ -> 0x01: This is Push Identifier
  ^^ -> 0x06: WSP PDU Type = Push
    ^^ -> 0x04: Length of octet followed 4 bytes
      ^^^^^^^^ -> 03AE81EA

03AE81EA itself is encoded like this:
^^ -> Length of content-type + header (3 octets)
  ^^ -> This is the content type of WAP Push (application/vnd.wap.sic)
        generated by doing OR operation with 0x80 like this
	1. Value of application/vnd.wap.sic is 0x2E
	   0x2E = 00101110
	   0x80 = 10000000
	   ------------------ OR
	   0xAE = 10101110

    ^^ -> 0x81: This is a header "Accept-Charset" (0x01) -> become 0x81
                since 0x81 = 0x01 | 0x80
      ^^ -> 0xEA: This is a value of header "Accept-Charset" which is UTF-8 (hexa code 0x6A)
                become 0xEA since 0xEA = 0x6A|0x80

The job is not done yet, PPG will now build WDP (Wireless Datagram Protocol) like this

05040B8423F0

Where actually this WDP is refer to this encoding:

05040B8423F0
^^ -> 0x05: IEI (Application Port Schema Addressing, 16 bit), see GSM 03.40
  ^^ -> 0x04: Length of octet following (4 bytes)
    ^^^^ -> 0x0B84: Destination Port of datagram = 2948 in decimal
                    Mobile phone which support WAP Push will normally listen
		    on WDP port 2948 to receive WAP Push 

		    This is the standard port for WAP Push connectionless
		    session service
        ^^^^ -> 0x23F0: Source port of datagram: the value here
	                is refer to Connectionless WAP Browser Proxy Server

So now we have combination WSP+WDP+SI layer to send as WAP Push:

05040B8423F0 (WDP Layer)
01060403AE81EA (WSP Layer)
02056A0045C60D0378797A008503656D61696C2F3132332F6162632E776D6C000AC307199906251
5231510C304209906030103596F7520686176652034206E657720652D6D61696C73000101 (SI layer)

If you try to calculate the number of octet there is 89 octets,means we can send it using 1 SMS only no need for sending long sms, since 1 SMS can contains 140 octets of data.

Now PPG will send it to end user by completing GSM 03.40 header for this data, like this

55010C9126582602680800F5A75A0605040B8423F001060403AE81EA02056A0045C60D0378797A0
08503656D61696C2F3132332F6162632E776D6C000AC3071999062515231510C304209906030103
596F7520686176652034206E657720652D6D61696C73000101

Where:

55010C9126582602680800F5A75A   --> GSM 03.40 Header
06                             --> UDHI Length
05040B8423F0                   --> WDP Layer
01060403AE81EA                 --> WSP Layer

-------------------------------------------------
02056A0045C60D0378797A0085036
56D61696C2F3132332F6162632E77
6D6C000AC3071999062515231510C    ==> SI Layer
304209906030103596F7520686176
652034206E657720652D6D61696C7
3000101
-------------------------------------------------

Now if send it using AT command like this:

AT+CMGF=0[ENTER]
OK

AT+CMGS=104[ENTER]
>0055010C9126582602680800F5A75A0605040B8423F001060403AE81EA02056A00
45C60D0378797A008503656D61696C2F3132332F6162632E776D6C000AC30719990
62515231510C304209906030103596F7520686176652034206E657720652D6D61696
C73000101[CTRL-Z]
OK

Our mobile phone will receive the WAP Push like this:

Please note, the WAP Push application behaviour for each mobile phone may different each others.