Mobile Security: October 2016

I will not explain in this article about how sending a SMS PDU or how the SMS arrives to its destination. However, I'll detail as much as I can about the PDU parts.

The SMS is a a messaging feature that been around since 1992, and now it's widely supported in every operator's network, as a mandatory.

It a very old service, however the newer services, such as MMS, EMS and sometimes WAP, are based on it.

One of the most important features of the SMS is the Store-Forward mechanism. This means when the SMS arrives to the SMSC (SMS center), it stored the message until it arrives the destination (or the validity period of the message reached out). This feature makes the SMS a very interesting surface.

The specification this article based on is the 3GPP TS 23.040.

Address Presentation

In the PDU there are some parameters whom presents an address.

This presentation contains 4 fields :

Length - this field determine the number of semi-octets the parameter has (without the Length field).
TON (Type Of Number) - this field placed at the 4 most significant bits of the second octet. It will define the type of the address. It can be coded as the following table :

Figure 1. TON coding (bit 7 is always 1)
NPI (Numbering Plan Identification) - this field placed at the 4 least significant bits of the send octet. It will define the numbering plan identification (usually NPI=1 will be used). It can be coded as the following table :

Figure 2. NPI coding
BCD Digits - this field's size is 0-8 octets. It will define the actual address, formatted in BCD format (switched digits). For example, the address 12 34 56 78 will be formated as 21 43 65 87. If the address contain odd number of digits, an F will be inserted to the end of it. So, the address 12 34 56 7 will be formatted as 21 43 65 F7.

Figure 3. Address presentation

Time Presentation

Some parameters of the PDU present time. The time presentation contains 7 octets, which are coded as the following :

Octet 1 - the last 2 digits of the year.
Octet 2 - the month (with leading 0, if needed).
Octet 3 - the day of the month (with leading 0, if needed).
Octet 4 - the hour (in 24 hours format).
Octet 5 - the minutes.
Octet 6 - the seconds.
Octet 7 - the timezone.

The timezone is given in 15 minutes. If the timezone offset is negative, the bit 3 of the last octet set to 1.

In all octets, the values stored at BCD format (switched digits).

For example, the time 23:01:56 Mar 5th 2016 PST (GMT-7) will be presented as :

61 30 50 32 10 65 8A

PDU Structure

The SMS PDU enables a regular subscriber to perform functions, that suppose to be the operator-only functions (I have no idea way there is no real filtering yet).

To use them, it is necessary to know the PDU structure and its component, of the SMS-SUBMIT (the message sent to the SMSC) as well as the SMS-DELIVER (the message sent from the SMSC to the handeset).

In this article, I'll describe the structure of the SMS-SUBMIT and SMS-DELIVER structures.

SMS-SUBMIT PDU Structure

The SMS-SUBMIT is the message sent from the handset to the SMSC (like a regular message sent from the phone). It also called MO SM (Mobile Originated Short Message).

The structure can be described as the following figure :

Figure 4. SMS-SUBMIT PDU structure

SCA (Service Center Address)

Presentation : Address presentation.

The SCA parameter defines the SMSC address to send the message to.

The SMSC address usually written in the UICC. So, in order to use the address in the UICC, the SCA should be 00 (which tells that the length of the address provided is 0).

PDU Type

Presentation : Octet presentation.

The PDU Type parameter defines the message type and some indicator of the existence of components in the message. Its size is 1 octet, which divided into 6 fields (message type + 5 indicators). The fields in the parameter can be coded as the following :

TP-MTI (TP-Message Type Indicator) - this field located at bit 0 & 1 (least significant bits). It defines the type of the message (SMS-DELIVER, SMS-DELIVER-REPORT, SMS-SUBMIT, SMS-SUBMIT-REPORT, SMS-STATUS-REPORT and SMS-COMMAND). For SMS-SUBMIT the coding should be 0b01.

TP-RD (TP-Reject Duplicated) - this field located at bit 2. It instruct the SMSC to reject/accept a message with the same TP-MR and TP-DA. If TP-RD set to 0, it will accept it. If it set to 1, it will reject it (will not send duplicated message).

TP-VPF (TP-Validity Period Format) - this field located at bit 3&4. It defines the presentation of the validity period (if presented in the message). If the TP-VPF=0b00, there is no validity period in the message. If the TP-VPF=0b10, the validity period is presented in the message, in a relative format. If the TP-VPF=0b11, the validity period is presented in time presentation.

TP-SRR (TP-Status Report Requested) - this field located at bit 5. It defines if a status report of the message requested by the sender. If it set to 0, no status report request. If it set to 1, the sender will get a status report about the arrival of the message to the destination.

TP-UDHI (TP-User Data Header Indicator) - this field located at bit 6. It defines if the message contains UDH (User Data Header). If it set to 0, the message don't have UDH. If it set to 1, the message will treated as it does have.

TP-RP (TP-Reply Path) - this field located at bit 7 (the most significant bit). It defines if a reply path presents in the message. If it set to 0, there is no reply path in the message. If set to 1, there is.

Figure 5. SMS-SUBMIT PDU Type

TP-MR (Transport Protocol-Message Reference)

Presentation : Integer presentation.

The TP-MR is a single octet, used to synchronize the message submission process. For every message sent, this parameter should be incremented for the next message.

If the message submission failed, the handset should retry with the same message, with the same TP-MR value, but with TP-RD on (for avoiding the same message delivery).

TP-DA (Transport Protocol-Destination Address)

Presentation : Address presentation.

The TP-DA defines the destination address of the message (the recipient's phone number).
The TON of the address usually be 8 or 9 (national or international number) with a NPI 1 (ISDN numbering plan identification) - the TON/NPI will be 0x81 or 0x91.

TP-PID (Transport Protocol-Protocol IDentifier)

Presentation : Integer presentation.

The TP-PID defines which higher layer protocol being used, such as indicating interworking with telematic device (fax, telex, fax, teletex, email), replace message, type 0 and download of configuration parameters.

The TP-PID can be coded as the following :

Figure 6. TP-PID coding

TP-DCS (Transport Protocol-Data Coding Scheme)

Presentation : Integer presentation.

The TP-DCS is an octet which defines basic information of how the recipient handset should process the received message. The information includes :

The character set used to encode the message content.
The message class, which determines the component to process the message (ME/UICC/TE).
Store/Discard the message after processing it.
The state of MWI indicators (voicemail, email, fax and etc).
The indication of compressed content in the message.

A description about the coding of this parameter can be found at 3GPP TS 23.038 (or here).

TP-VP (Transport Protocol-Validity Period)

Presentation : Time presentation or Relative presentation.

The TP-VP parameter defines the time period which the SMSC should attempt to deliver the message. This parameter is optional (its presence indicated by the TP-VPF field at the PDU Type parameter). Although, some of the SMSC set a default validity period (48 or 72 hours).

Its presentation can be a time presentation (7 octets) or a relative one (1 octet). If the relative presentation was chosen, the TP-VP can be coded as the following table :

Figure 7. TP-VP coding

TP-UDL (Transport Protocol-User Data Length)

Presentation : Integer presentation

The TP-UDL defines the size of the TP-UD (user data) by octets or septets.

If the TP-DCS indicates the the coding scheme is a GSM 7-bit default alphabet, the TP-UDL will indicate the number of septets the TP-UD has.

Otherwise (no matter if 8-bit data alphabet or 16-bit UCS-2 alphabet), the TP-UDL will indicate the number of octets the TP-UD has.

TP-UD (Transport Protocol-User Data)

Presentation : Octets presentation.

The TP-UD is the content of message.

The content of the message can be a simple text or a binary data, which can have extra features (such as concatenation). In order to add additional features, some headers should be added.

TP-UD with headers (or TP-UDH, TP-User Data Header) can be constructed as th following figure :

Figure 8. TP-UDH (the encoding of the SM can be different)

As the above figure describes, more than 1 header can be added to the user data.

The UDHL (User Data Header Length) defines the number of octets of the headers (all of them).

the IEI (Information Element Identifier) is the identifier of the header - determine what feature will the current header will apply to.

The IEIDL (Information Element Identifier Data Length) defines the number of octets the header's data will have.

The IED (Information Element Data) contains the actual data of the header.

The IEI can be coded as the following table :

Figure 9. IEI coding

SMS-DELIVER PDU Structure

The SMS-DELIVER is the message sent from the SMSC to the handset (like a regular message received at the phone). It also called MT SM (Mobile Terminated Short Message).

The structure can be described as the following figure :

Figure 10. SMS-DELIVER PDU structure