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:

he 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
 About these ads

You May Like

1.

You May Like

1.

You May Like

1.

You May Like

1.

You May Like

1.

Written by adywicaksono
May 21, 2008 at 2:00 pm

Posted in Mobile, SmartCard, Telco - GSM

10 Responses

Subscribe to comments with RSS.

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

Reply
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

Reply
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

Reply
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

Reply
Thanks, Ady you are great

linpeh

April 7, 2010 at 10:38 am

Reply
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

Reply
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

 Reply
it’s standard crypto, please googling

adywicaksono

May 28, 2011 at 6:12 am

Reply
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

Reply
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

Reply

Create a free website or blog at WordPress.com. The Journalist v1.9 Theme.

 Follow

Follow “Ady Wicaksono Daily Activities”

Build a website with WordPress.com