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 10: Process if and only if counter value is higher 11: Process if and only if counter value is one | |||||||||||||||||||
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 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 10: Triple DES in outer-CBC mode using three 11: DES in ECB mode | |||||||||||||||||||
indication of Keys to be used | |||||||||||||||||||
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 10: Triple DES in outer-CBC mode using three 11: Reserved | |||||||||||||||||||
indication of Keys to be used | |||||||||||||||||||
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. |