5 Generalised Secured Packet structure

03.483GPPRelease 1999Security mechanisms for SIM application toolkitStage 2TS

Command and Response Packets have the same overall structure consisting of a variable length security header within a variable length shell. To model this, use is made of a double TLV -tag, length, value- structure.

5.1 Command Packet structure

The Command Header precedes the Secured Data in the Command Packet, and is of variable length.

The Command Packet shall be structured according to table 1.

Table 1: Structure of the Command Packet

Element

Length

Comment

Command Packet Identifier (CPI)

1 octet

Identifies that this data block is the secured Command Packet.

Command Packet Length (CPL)

variable

This shall indicate the number of octets from and including the Command Header Identifier to the end of the Secured Data, including any padding octets required for ciphering.

Command Header Identifier (CHI)

1 octet

Identifies the Command Header.

Command Header Length (CHL)

variable

This shall indicate the number of octets from and including the SPI to the end of the RC/CC/DS.

Security Parameter Indicator (SPI)

2 octets

see detailed coding in section 5.1.1.

Ciphering Key Identifier (KIc)

1 octet

Key and algorithm Identifier for ciphering.

Key Identifier (KID)

1 octet

Key and algorithm Identifier for RC/CC/DS.

Toolkit Application Reference (TAR)

3 octets

Coding is application dependent.

Counter (CNTR)

5 octets

Replay detection and Sequence Integrity counter.

Padding counter (PCNTR)

1 octet

This indicates the number of padding octets used for ciphering at the end of the secured data.

Redundancy Check (RC), Cryptographic Checksum (CC) or Digital Signature (DS)

variable

Length depends on the algorithm. A typical value is 8 octets if used, and for a DS could be 48 or more octets; the minimum should be 4 octets.

Secured Data

variable

Contains the Secured Application Message and possibly padding octets used for ciphering.

Unless indicated otherwise, the CPL and the CHL shall be coded according to ISO/IEC 7816-6 [8].

Table 2: Linear Representation of Command Packet

CPI

CPL

CHI

CHL

SPI

KIc

KID

TAR

CNTR

PCNTR

RC/CC/DS

Secured Data with Padding

Note 1

Note 1

Note 1

Note 1

Note 3

Note 3

Note 2

Note 2

Note 2

Note 2

Note 2

Note 2

Note 2

NOTE 1: These fields are included in the data to be ciphered if ciphering is indicated in the Security Header.

NOTE 2: These fields are included in the calculation of the RC/CC/DS.

NOTE 3: Part or all of these fields may also be included in the calculation of the RC/CC/DS, depending on implementation (e.g. SMS).

If ciphering is indicated, first the RC/CC/DS shall be calculated as indicated in Note 2, and then ciphering shall be applied, as indicated in Note 1.

If the SPI indicates that a specific field is unused, the Sending Entity shall set the contents of this field to zero, and the Receiving Entity shall ignore the contents.

If the SPI indicates that no RC, CC or DS is present in the Command Header, the RC/CC/DS field shall be of zero length.

If the Padding Counter content is zero, this shall indicate no padding octets, or no padding is necessary.

5.1.1 Coding of the SPI

The SPI is coded as below.

First Octet:

b8

b7

b6

b5

b4

b3

b2

b1

00: No RC, CC or DS

01: Redundancy Check

10: Cryptographic Checksum

11: Digital Signature

0 : No Ciphering

1 : Ciphering

00: No counter available (note 1)

01: Counter available; no replay or sequence
checking (note 2)

10: Process if and only if counter value is higher
than the value in the RE (note 3)

11: Process if and only if counter value is one
higher than the value in the RE (note 4)

Reserved (set to zero and ignored by RE)

NOTE 1: In this case the counter field is present in the message.

NOTE 2: In this case the counter value is used for information purposes only, (e.g. date or time stamp). If the Command Packet was successfully unpacked, the counter value can be forwarded from the Receiving Entity to the Receiving Application. This depends on proprietary implementations and happens in an application dependent way.

NOTE 3: The counter value is compared with the counter value of the last received Command Packet. This is tolerant to failures on the transport level (i.e. losses of Command Packets). A possible scenario is a global update.

NOTE 4: This provides strict control in addition to security indicated in Note 3.

Second Octet:

b8

b7

b6

b5

b4

b3

b2

b1

00: No PoR reply to the Sending Entity (SE)

01: PoR required to be sent to the SE

10: PoR required only when an error has occured

11: Reserved

00: No security applied to PoR response to SE

01: PoR response with simple RC applied to it

10: PoR response with CC applied to it

11: PoR response with DS applied to it

0 : PoR response shall not be ciphered

1 : PoR response shall be ciphered

For SMS only

0 : PoR response shall be sent using
SMS-DELIVER-REPORT

1 : PoR response shall be sent using SMS-SUBMIT

Reserved (set to zero and ignored by RE)

5.1.2 Coding of the KIc

The KIc is coded as below.

b8

b7

b6

b5

b4

b3

b2

b1

00: Algorithm known implicitly by both entities

01: DES

10: Reserved

11: proprietary Implementations

00: DES in CBC mode

01: Triple DES in outer-CBC mode using two
different keys

10: Triple DES in outer-CBC mode using three
different keys

11: DES in ECB mode

indication of Keys to be used
(keys implicitly agreed between both entities)

DES is the algorithm specified as DEA in ISO 8731-1 [9]. DES in CBC mode is described in ISO/IEC 10116 [10]. Triple DES in outer-CBC mode is described in section 15.2 of [17]. DES in ECB mode is described in ISO/IEC 10116 [10].

The initial chaining value for CBC modes shall be zero. For the CBC modes the counter (CNTR) shall be used.

If the indication of the key to be used refers to an Open Platform key set version number, the algorithm to be used with the key shall be the algorithm associated with the key (as described in the Open Platform specification [14]).

5.1.3 Coding of the KID

The KID is coded as below.

b8

b7

b6

b5

b4

b3

b2

b1

00: Algorithm known implicitly by both entities

01: DES

10: Reserved

11: proprietary Implementations

00: DES in CBC mode

01: Triple DES in outer-CBC mode using two
different keys

10: Triple DES in outer-CBC mode using three
different keys

11: Reserved

indication of Keys to be used
(keys implicitly agreed between both entities)

DES is the algorithm specified as DEA in ISO 8731-1 [9]. DES in CBC mode is described in ISO/IEC 10116 [10]. Triple DES in outer-CBC mode is described in section 15.2 of [17].

The initial chaining value for CBC modes shall be zero. For the CBC modes the counter (CNTR) shall be used. If padding is required, the padding octets shall be coded hexadecimal ’00’. These octets shall not be included in the secured data.

If the indication of the key to be used refers to an Open Platform key set version number, the algorithm to be used with the key shall be the algorithm associated with the key (as described in the Open Platform specification [14]).

5.1.4 Counter Management

If in the first SPI byte b4b5=00 (No counter available) the counter field shall be ignored by the RE and the RE shall not update the counter.

If b5 of the first SPI byte is equal to 1 then the following rules shall apply to counter management, with the goal of preventing replay and synchronisation attacks:

– The SE sets the counter value. It shall only be incremented.

– The RE shall update the counter to its next value upon receipt of a Command Packet after the corresponding security checks (i.e. RC/CC/DS and CNTR verification) have been passed successfully.

The next counter value is the one received in the incoming message.

– When the counter value reaches its maximum value the counter is blocked.

If there is more than one SE, care has to be taken to ensure that the counter values remain synchronised between the SE’s to what the RE is expecting, irrespective of the transport mechanism employed.

The level of security is indicated via the proprietary interface between the Sending/Receiving Application and Sending/Receiving Entity. Application designers should be aware that if the Sending Application requests "No RC/CC/DS" or "Redundancy Check" and "No Counter Available" from the SE, no security is applied to the Application Message and therefore there is an increased threat of malicious attack.

5.2 Response Packet structure

Table 3: Structure of the Response Packet

Element

Length

Comment

Response Packet Identifier (RPI)

1 octet

Identifies a Response Packet.

Response Packet Length (RPL)

variable

Indicates the number of octets from and including RHI to the end of Additional Response data, including any padding octets required for ciphering.

Response Header Identifier (RHI)

1 octet

Identifies the Response Header.

Response Header Length (RHL)

variable

Indicates the number of octets from and including TAR to the end of the RC/CC/DS.

Toolkit Application Reference (TAR)

3 octets

This shall be a copy of the contents of the TAR in the Command Packet.

Counter (CNTR)

5 octets

This shall be a copy of the contents of the CNTR in the Command Packet.

Padding counter (PCNTR)

1 octet

This indicates the number of padding octets used for ciphering at the end of the Additional Response Data.

Response Status Code Octet

1 octet

Codings defined in Table 5.

Redundancy Check (RC), Cryptographic Checksum (CC) or Digital Signature (DS)

variable

Length depending on the algorithm indicated in the Command Header in the incoming message. A typical value is 4 to 8 octets, or zero if no RC/CC/DS is requested.

Additional Response Data

variable

Optional Application Specific Response Data, including possible padding octets used for ciphering.

Unless indicated otherwise, the RPL and RHL shall be coded according to ISO/IEC 7816-6 [8].

Table 4: Linear Representation of Response Packet

RPI

RPL

RHI

RHL

TAR

CNTR

PCNTR

Status Code

RC/CC/DS

Additional Response Data with padding

Note 1

Note 1

Note 1

Note 1

Note 1

Note 3

Note 3

Note 2

Note 2

Note 2

Note 2

Note 2

NOTE 1: If ciphering is indicated in the Command Packet SPI then these fields shall be ciphered.

NOTE 2: These fields shall be included in the calculation of the RC/CC/DS.

NOTE 3: Part or all of these fields may also be included in the calculation of the RC/CC/DS, depending on implementation (e.g. SMS).

If ciphering is indicated, first the RC/CC/DS shall be calculated as indicated in Note 2, and then ciphering shall be applied, as indicated in note 1.

If the SPI indicates that a specific field is unused, than its contents shall be set to zero, and ignored by the recipient of the Response Packet.

If the SPI in the Command Packet indicates that no RC, CC or DS is present in the Command Header, this field shall be of zero length.

If the Padding Counter content is zero, this shall indicate no padding octets are present, or no padding is necessary.

Table 5: Response Status Codes

Status Code (hexadecimal)

Meaning

’00’

PoR OK.

’01’

RC/CC/DS failed.

’02’

CNTR low.

’03’

CNTR high.

’04’

CNTR Blocked

’05’

Ciphering error.

’06’

Unidentified security error. This code is for the case where the Receiving Entity cannot correctly interpret the Command Header and the Response Packet is sent unciphered with no RC/CC/DS.

’07’

Insufficient memory to process incoming message.

’08’

This status code "more time" should be used if the Receiving Entity/Application needs more time to process the Command Packet due to timing constraints. In this case a later Response Packet should be returned to the Sending Entity once processing has been completed.

’09’

TAR Unknown

‘0A’ – ‘FF’

Reserved for future use.