A.1 Commands Description

03.483GPPRelease 1999Security mechanisms for SIM application toolkitStage 2TS

The minimum security applied to a Secured Packet containing Applet Management Commands shall be integrity using CC or DS, and in all cases, this security shall replace Data Authentication Patterns used in Open Platform commands for secure messaging.

A.1.1 DELETE

The Delete command shall be coded according to the Open Platform specification [14]. The references to DAP (Data Authentication Pattern) fields are not applicable for Over The Air Application Management.

NOTE: This command may be extended in the future to allow for other type of deletion since the command data uses TLV structure.

A.1.2 GET DATA

The Get Data command shall be coded according to the Open Platform specification [14]. The references to DAP (Data Authentication Pattern) fields are not applicable for Over The Air Application Management.

The command Get Data is extended to retrieve specific card information with tag values in P1 and P2. The following values have been defined :

‘FF 1F’: Menu Parameters Tag, this retrieves the menu parameters of an applet;

‘FF 20’: Card Resources Tag, this retrieves information on the card resources used and available;

‘FF 21’ to ‘FF 7F’: reserved for allocation in the present document.

A.1.2.1 Menu Parameters

The following format is used to code the command data :

Bytes

Description

Length

1

Application AID tag = ‘4F’

1

2

Application AID length

1

3 – (X+2)

Application AID

X = 5 – 16

After the successful execution of the command, the following data is returned by a GET RESPONSE command:

Bytes

Description

Length

1

First item position

1

2

First item identifier

1

X – 1

Last item position

1

X

Last item identifier

1

A.1.2.2 Card Resources Information

After the successful execution of the command, the following data is returned:

Bytes

Description

Length

1-2

Free E²PROM

2

3

Number of installed applets

1

A.1.3 GET STATUS

The Get Status command shall be coded according to the Open Platform specification [14]. The references to DAP (Data Authentication Pattern) fields are not applicable for Over The Air Application Management.

A.1.4 INSTALL

The Install command shall be coded according to the Open Platform specification [14]. The references to DAP (Data Authentication Pattern) fields are not applicable for Over The Air Application Management.

A.1.4.1 Install (Load)

The Load File DAP field is a Cryptographic Checksum, a Digital Signature or a Redundancy Check calculated over the CAP file as transmitted in the subsequent Load commands. The exact generation of this field is outside the scope of the present document. If a DES algorithm in CBC mode is used the initial chaining value shall be zero. If padding is required, the padding octets shall be coded hexadecimal ’00’.

NOTE: The Load File DAP CC, DS or RC is verified by the Card Manager.

The Load Parameter Field of the Install (Load) command shall be coded as follows:

Presence

Length

Name

Mandatory

1

Tag of System Parameters constructed field ‘EF’

1

Length of System Parameters constructed field

4-n

System Parameters constructed value field.

The System Parameters value field of the Install (Load) command shall be coded as follows:

Presence

Length

Name

Mandatory

1

Tag of non volatile memory space required for package loading field: ‘C6’

1

Length of non volatile memory space required for package loading field

2

Non Volatile memory space (in bytes) required for package loading (see note)

Optional

1

Tag of non volatile memory requirements for installation field: ‘C8’

1

Length of non volatile memory requirements for installation

2

Non volatile memory required for installation in byte

Optional

1

Tag of volatile memory requirements for installation field: ‘C7’

1

Length of memory requirements for installation

2

Volatile memory required for installation in byte

NOTE: The memory space required indicates the minimum size that shall be available onto the card to download the application. The SIM must reject the applet downloading if the required size is not available on the card.

A.1.4.2 Install (Install)

Toolkit registration is only active if the toolkit applet is at the state selectable, for example if the applet is registered for the event Menu Selection it shall only appear in the menu if the applet is in the selectable state.

The Install Parameter Field of the Install (Install) command shall be coded as follows:

Presence

Length

Name

Mandatory

1

Tag of System Parameters constructed field ‘EF’

1

Length of System Parameters constructed field

15-n

System Parameters constructed value field.

Mandatory

1

Tag of Applet specific parameters field: ‘C9’

1

Length of Applet specific Parameters field

0-n

Applet specific Parameters

The System Parameters value field of the Install (Install) command shall be coded as follows:

Presence

Length

Name

Mandatory

1

Tag of non volatile memory requirements for installation field: ‘C8’

1

Length of non volatile memory requirement for installation (see A.1.4.2.2)

2

Non volatile memory required for installation in byte (see A.1.4.2.2)

Mandatory

1

Tag of volatile memory requirements for installation field: ‘C7’

1

Length of volatile memory requirement for installation (see A.1.4.2.2)

2

Volatile memory required for installation in byte (see A.1.4.2.2)

Mandatory

1

Tag of GSM applet specific parameters field: ‘CA’

1

Length of GSM applet specific parameters field

6-n

GSM Applet specific Parameters (see A.1.4.2.1)

Even if the length of the non volatile or volatile memory is present in the Install(Load) command, the card shall use the values indicated in the Install(Install) command at instantiation, should these values differ.

The format of the install method buffer provided by the Install (Install) command shall be the one specified in the Open Platform Card specification [14].

The applet may invoke the register(bArray, bOffset, bLength) or the register() method: the applet instance shall be registered with the instance AID present in the Install (Install) command.

If the register (bArray, bOffset, bLength) is invoked, the AID passed in the parameters shall be the instance AID provided in the install method buffer.

If the register() method is invoked the instance AID present in the Install(Install) command and the AID within the Load File, as specified in Open Platform Card specification [14], should be the same.

A.1.4.2.1 GSM Applet Specific Parameters

The applet parameters field is used to specify the resources the applet instance can use. These resources include the timers, and menu items for the Set Up Menu. The Network Operator or Service Provider can also defines the menu position and the menu identifier of the menus activating the applet. The following format is used to code the applet parameters:

Length

Name

Value

1

Length of Access Domain field

1-n

Access Domain (see A.1.4.2.3)

1

Priority level of the Toolkit applet instance (see A.1.4.2.4)

1

Maximum number of timers allowed for this applet instance

1

Maximum text length for a menu entry

1

Maximum number of menu entries allowed for this applet instance

= m

1

Position of the first menu entry (’00’ means last position)

\

1

Identifier of the first menu entry (’00’ means don’t care)

|

….

| = 2*m bytes

1

Position of the last menu entry (’00’ means last position)

|

1

Identifier of the last menu entry (’00’ means don’t care)

/

The position of the new menu entries is an absolute position among the existing ones.

A part of the item identifier shall be under the control of the card system and the other part under the control of the card issuer. Item identifiers are split in two ranges:

– [1,127] under control of the card issuer;

– [128,255] under the control of the SIM toolkit framework.

If the requested item identifier is already allocated, or in the range [128,255], then the card shall reject the install command. If the requested item identifier is ’00’, the card shall take the first free value in the range [128,255].

A.1.4.2.2 Memory space

The memory space required indicates the minimum size that shall be available on the card to download the application. The SIM shall reject the applet downloading if the required size is not available on the card.

A.1.4.2.3 Access domain

The access domain is used to specify the SIM files that may be accessed by the applet and the operations allowed on these files. The Access Domain field is formatted as follows:

Length

Name

1

Access Domain Parameter (ADP) (see A.1.4.2.3.1)

n-1

Access Domain Data (ADD)

The Access Domain Data coding and length is defined for each Access Domain Parameter.

A.1.4.2.3.1 Access Domain Parameter

This parameter indicates the mechanism used to control the applet instance access to the GSM file System.

Value

Name

Support

ADD length

’00’

Full access to the GSM File System

Mandatory

0

’01’

APDU access mechanism (see A.1.4.2.3.2)

Optional

2

’02’

3GPP access mechanism (see A.1.4.2.3.3)

Optional

[To be defined]

’03’ to ‘7F’

RFU

RFU

RFU

’80’ to ‘FE’

Proprietary mechanism

‘FF’

No access to the GSM File System

Mandatory

0

If an applet with Access Domain Parameter ‘FF’ (i.e. No Access to the GSM File System) tries to access a GSM file (e.g. invoke the updateBinary(..) method) the framework shall throw the SIMViewException (AC_NOT_FULFILLED).

NOTE: The file access conditions specified in TS 11.11 [5] are relevant for the SIM/ME interface only. The file access conditions specified in the access domain parameter are used internally by the card operating system.

If the Access Domain Parameter requested is not supported, the card shall return the Status Word ‘6A80’, incorrect parameters in data field, to the Install(Install) command.

A.1.4.2.3.2 APDU access mechanism

This mechanism shall be used, if supported, by the framework if the Access Domain Parameter value is ’01’. It shall use the Access Domain Data passed at applet instantiation to define the access conditions fulfilled while the toolkit applet is running.

The APDU Access Domain Data is a bit map combination of the file access condition levels described in TS 11.11. When the bit is set the associated Access Condition is granted.

The APDU Access Domain Data is coded as follows:

Byte 1:

b8

b7

b6

b5

b4

b3

b2

b1

ADM4

ADM5

ADM6

ADM7

ADM8

ADM9

ADM10

RFU

Byte 2:

b8

b7

b6

b5

b4

b3

b2

b1

ALWays

CHV1

CHV2

RFU

ADM0

ADM1

ADM2

ADM3

EXAMPLE: Possible combinations of fulfilled Access Conditions are shown below:

ADD value

Applet access condition fulfilled

’00 00′

No access

’00 01′

ALWays

’00 02′

CHV1

’00 03′

ALWays and CHV1

’00 04′

CHV2

’00 05′

ALWays and CHV2

’00 06′

CHV1 and CHV2

:

:

’00 10′

ADM0

:

:

’00 20′

ADM1

:

:

’00 22′

ADM1 and CHV1

:

:

’01 00′

ADM4

:

:

’40 00′

ADM10

:

:

’41 37′

ADM10 and ADM4 and ADM1 and ADM0 and CHV2 and CHV1 and ALWays

:

:

A.1.4.2.3.3 3GPP access mechanism

[To be defined]

A.1.4.2.4 Priority level of the Toolkit applet

The priority specifies the order of activation of an applet compared to the other applet registered to, the same event. If two or more applets are registered to the same event and have the same priority level, the applets are activated according to their installation date (i.e. the most recent applet is activated first). The following values are defined for priority:

’00’ : RFU

’01’ : Highest priority level

‘FF’ : Lowest priority level

A.1.5 LOAD

The Load command shall be coded according to the Open Platform specification [14]. The references to APDU’s DAP (Data Authentication Pattern) fields are not applicable for Over The Air Application Management.

The load block data is created by taking successive blocks of the data from the Java Card CAP file components in the order described in the Java Card specification.

Figure 6: Relationship between CAP File components and Load File Blocks

A.1.6 SET STATUS

The Set Status command shall be coded according to the Open Platform specification [14]. The references to DAP (Data Authentication Pattern) fields are not applicable for Over The Air Application Management.

A.1.7 PUT KEY

The Put Key command shall be coded according to the Open Platform specification [14]. The references to DAP (Data Authentication Pattern) fields are not applicable for Over The Air Application Management.

The keys which may updated by the PUT KEY command refer to the transport security keys, i.e. KID and KIc in a Secured Packet. In addition, a third key type is defined : KIK. This key is used to protect the PUT KEY command itself. Keys are structured in the following way:

Key Set Version 0

Key Set Version 1

….

Key Set Version n (maximum ‘F’)

Key Index 1

Reserved

KIc 1

KIc n

Key Index 2

Reserved

KID 1

KID n

Key Index 3

Reserved

KIK 1

KIK n

A card may have up to 15 key set versions each containing 3 key indexes. These versions numbers represent the indication of keys to be used in bits 8 to 5 in the coding of KIc and KID (see section 5.1.2 and 5.1.3). Each key index represents:

Key Index 1: KIc

Key Index 2: KID

Key Index 3: KIK

Key Sets can only be changed with the PUT KEY command once the card has been issued. New Key Sets cannot be created using PUT KEY command at post issuance. Key used for securing the PUT KEY command is the key index 3 of the same key set version as the changed key. Key Set version 0 defined in OP for the creation of keys is not relevant for the present document.

A key set version number shall never be updated using the PUT KEY command.

This command shall be executed by the Card Manager or a Security Domain depending on the TAR in the case of Over The Air Application Management.