Understanding GSM 03.48
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