Short Message Service (sms) security solution for mobile devices

2. 
SMS Security Specifications 
The technical specifications for SMS and SIM are described in ETSI TS 
03.48. The intent was to spell out the specifications required to achieve end-to-
end security between Mobile Stations and SMS Centers. However, all the 
specifications did was to define additional fields that could be used in the user-
defined portion of the SMS Transfer Protocol Data Unit (TPDU) to describe the 
security properties that the SMS will have.
The SMS application server or the SIM can set the first byte of the User 
Data Header to a value of Ox70 to indicate that the User Data Header will be 
followed by a Command Header, which in turns describes the security 
parameters used to secure the data. The first two bytes of the Command Header 
denote the total length of the Command Header and the Secured User Data. The 
next byte is the length of the rest of the Command Header. Figure 6 shows the 
SMS_SUBMIT TPDU structure when the security headers are used. 

---

 18
Figure 6. SMS_SUBMIT TPDU with Security Headers (After Ref. [19]) 
The Command Header essentially describes how the user data is being 
encrypted. The Command Header consists of seven fields as follows: 
•
Security Parameter Index (SPI)
•
Ciphering Key Identifier (KIc)
•
Key Identifier (KID)
•
Toolkit Application Reference (TAR) 
•
Padding Counter (PCNTR) 
•
Integrity Value (RC/CC/DS) 
Figure 7 is a graphical representation of the Command Header. 
Figure 7. Structure of Command Header 

---

 19
The SPI is a collection of flags used to describe the security parameters. 
This provides the recipient with sufficient information to undo the sequence of 
operations to recover the data. The byte value coding for the SPI is shown in 
Figures 8 below, where PoR refers to Proof of Receipt and RE is the Receiving 
Entity, who will create the PoR. 
Figure 8. Security Parameter Index Coding [After Ref. [22]) 

---

 20
The KIc describes the key and the ciphering algorithm used. The 
specifications allow for the implementation of proprietary encryption algorithms.
Figure 9 shows the coding of the KIc values. It can be seen that no key exchange 
mechanism is built into the specifications. It is assumed that the agreement on 
the key to be used has already been established. 
Figure 9. KIc Coding (After Ref. [22]) 
The KID refers to the key and algorithm used to compute the redundancy 
check (RC), cryptographic checksum (CC) or digital signature (DS) of the 
secured data. The coding is very similar to the KIc and is shown in Figure 10. 
Figure 10. KID Coding (After Ref. [22]) 

---

 21
The Toolkit Application Reference (TAR) is used to indicate which 
application should handle the secured data, similar to the use of port numbers in 
Transmission Control Protocol (TCP). However the definition of its use is very 
fuzzy in the specifications. The official description is “coding is application 
dependent.”
The Counter (CNTR) indexes the messages between the application 
server and the SIM. The main purpose is to create a nonce to prevent replay 
attacks. However, the management of the counter value is challenging if the 
application or the SIM needs to keep track of the counter values in conversations 
with multiple parties. As such, a weaker method of counter was implemented in 
some applications using time stamp values in the CNTR field.
The Padding Counter (PCNTR) is the number of padding bytes at the end 
of the secured data. This is typically required in block ciphers, where the data is 
encrypted in fixed block sizes. If the data is not in multiples of the block size, the 
last block needs to be padded to the block size. 
A Redundancy Check (RC), Cryptographic Checksum (CC) or Digital 
Signature (DS) is used to verify the integrity of the secured data.
It is apparent that the SMS application layer only provides options for 
describing the security context between the SMS applications and SIM. Data 
confidentiality protection, integrity protection, and anti-replay mechanisms can be 
described. However, the specific implementations of all these mechanisms are 
left to the application developer. No specific requirements were placed at the 
application layer to secure SMS. Ultimately, SMS still rides on the security 
provided by the GSM network. The specifications merely provide application 
developers with options to describe the security measures that are implemented.