Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  ETSI TS 102 221   PDF version:  18.2.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   7…   7.2.3…   7.3…   7.3.2…   7.4…   8…   9…   10…   10.2…   11…   11.1.2…   11.1.9…   11.1.14…   11.1.19…   11.1.20…   11.1.21…   11.2…   11.3…   12…   13…   14…   15   A   B   C…   D   E…   F…   G…   H…   I   J…   K…   L…   M…   N…   O… 
9 Security features  9.0 Introduction  9.1 Supported security features  9.2 Security architecture  9.2.0 Overview and basic rules  9.2.1 Security attributes  9.2.2 Access mode  9.2.3 Security condition  9.2.4 Access rules  9.2.5 Compact format  9.2.6 Expanded format  9.2.7 Access rule referencing  9.3 Security environment  9.3.0 Description  9.3.1 Definition of the security environment  9.3.2 Logical Channels and Security Environment  9.4 PIN definitions  9.4.0 Introduction  9.4.1 Universal PIN  9.4.2 Application PIN  9.4.3 Local PIN  9.4.4 PINs and logical channels  9.5 PIN and key reference relationship  9.5.0 Introduction  9.5.1 Access condition mapping  9.5.2 PIN status indication  9.6 LSE isolation 
...

 

9  Security features  p. 69

9.0  Introduction  p. 69

The provisions of clause 9 apply to the logical UICC with the following exceptions:
  • The provisions of clause 9.6 describe the specific security features of LSEs.
Every application that conforms to the present document may define security features in addition to the mandatory features defined in this clause.

9.1  Supported security features  p. 70

A terminal that conforms to the present document and is designed for a multi-application UICC shall recognize the security attribute tags specified in the present document.
A single application terminal conforming to the present document shall support one of the access rules format specified in the present document. The application specifies which format is used.
A multi-application capable terminal that is designed to support a multi-verification capable UICC shall, from the security context point of view, support the usage of the level 1 verification requirements (PIN) and the level 2 verification requirements (PIN2). The coding is defined in Table 9.3. The terminal shall, in addition, support the usage of a universal PIN as defined in the present document.
A multi-verification capable UICC conforming to the present document shall, from the security context point of view, support more than one level 1 user verification requirement (PIN). The specific key reference for the level 1 PIN is specified by each application in accordance with Table 9.3. In addition, the application may specify a level 2 user verification requirement (PIN2). A multi-verification capable UICC should support the use of a universal PIN. A multi-verification capable UICC shall support access rules defined in security attributes indicated in tag '8B' (i.e. referenced to expanded format).
A single verification capable UICC shall, from the security context point of view, support one level 1 user verification requirement (PIN) as defined in Table 9.3. In addition the application may specify a level 2 user verification requirement as a second application verification requirement (PIN2). A single verification capable UICC may contain one or more selectable applications if there are no security aspects to be considered between the different selectable applications. From the security point of view only one level 1 verification requirement (PIN) is assigned to all ADFs/DFs and files on the UICC. In addition, a level 2 user verification requirement (PIN2) may be assigned for each application. From the security and access rules point of view the UICC is seen as a single application card. The coding of the level 1 and level 2 user verification requirement shall be according to Table 9.3.
Up

9.2  Security architecture  p. 70

9.2.0  Overview and basic rules  p. 70

An application on a UICC conforming to the present document shall specify a level 1 key reference as the user verification (PIN). In addition the application may specify a level 2 key reference as a second user verification requirement (PIN2). The coding of the level 1 and level 2 user verification requirement shall be according to Table 9.3. In addition, an application may specify the usage of a universal PIN as a replacement for the application PIN.
In order to perform commands other than SELECT and STATUS/GET RESPONSE, the security condition for the file shall be met. A security condition data object contains the conditions to be met in order to perform certain commands on a selected ADF/DF/EF.
If the UICC cannot determine the access condition for the requested access to a file, then the requested access to this file shall not be granted and the card shall return an error status word '6982' (security status not satisfied).
The security architecture consists of the following parts:
  • Security attributes: a set of access rules.
  • Access rules: consist of an access mode and one or more security conditions.
  • Access Mode (AM): indicates to which operations (commands) the security condition applies.
  • Security Condition (SC): contains references to the applicable key references (PINs).
Clauses 9.2.1 to 9.2.7 define the parts constituting the security architecture.
Up

9.2.1  Security attributes  p. 70

The security attributes are attached to an ADF/DF/EF and they are part of the FCP. The security attributes are indicated in the FCP using tag '8B', tag '8C' or tag 'AB' depending upon the format used, see ISO/IEC 7816-4 [12].

9.2.2  Access mode  p. 71

The access mode byte/data object (AM byte/AM_DO) defines for which group/type of command(s) the security condition apply. The interpretation of the AM byte/AM_DO is file dependent (i.e. different for a DF/ADF and an EF), see ISO/IEC 7816-4 [12]. The command type/group is defined and coded according to ISO/IEC 7816-4 [12].
For instructions not belonging to a group as defined in ISO/IEC 7816-4 [12] the access rights can be indicated using AM_DO tags '81' to '8F'. The value of the tag defining the AM_DO indicates what description of the command exists in the definition list to follow in the value part of the data object. The coding of bit b4 to b1 in the AM_DO tag is defined in ISO/IEC 7816-4 [12].
The security conditions for bits not set to '1' in the AM byte are set to NEVer by default.
Up

9.2.3  Security condition  p. 71

The Security Condition (SC) indicates which security related procedures (user PIN verification) shall be satisfied before a command may be performed on a file. The SC is coded according to ISO/IEC 7816-4 [12].

9.2.4  Access rules  p. 71

The access rule defines the security conditions for access to a file for each command/command group indicated in the AM-byte/AM_DO. The security condition is indicated in the SC-byte(s)/SC_DO(s) following the AM-byte/AM_DO. The access rule is coded by using one or more AM-bytes/AM_DOs each followed by one or more security conditions that are to be satisfied for the appropriate access.
The access rules may be coded in a compact or an expanded format. Furthermore, it is possible to combine one or more SCs to one AM such that at least one SC (the OR relation) shall be fulfilled before the command can be executed. It is possible to combine the SC such that more than one SC has to be fulfilled (the AND relation).
An access rule is a set of requirement(s) that shall be met in order to perform operations on a file. An access rule contains one or more security attributes, the AM byte/AM_DO in the attribute indicates what commands can be performed and the SC byte/SC_DO indicates what SC shall be met to be able to perform the commands indicated in the AM byte/AM_DO. The content of each AM byte (in compact format) or AM_DO (in expanded format) shall be unique within the same access rule. SC_DOs OR and AND relations shall contain at least two access conditions. The terminal shall ignore an AM/SC combination which is syntactically incorrect or with unknown instructions.
The CRT tags for SC_DOs are defined in ISO/IEC 7816-4 [12]. The SC required to perform commands indicated in the AM byte/AM_DO may be a simple condition or a logical OR or AND condition of several SC_DOs. The constructed TLV object containing AM bytes/AM_DOs and SC bytes/SC_DOs is an access rule. An access rule can be indicated in the FCP in one of the following ways:
  • Tag '8C' Security attributes: Compact format.
  • Tag 'AB' Security attributes: Expanded format.
  • Tag '8B' Security attributes: Referenced to expanded format.
Up

9.2.5  Compact format  p. 71

The compact format is indicated by tag '8C' in the FCP. In the compact format an access rule consists of an AM byte and one or more SC bytes as defined in ISO/IEC 7816-4 [12].
The AM byte conveys two types of information. The interpretation of the AM byte itself (coded on b8), and the number of SC bytes following, this is equal to the number of bits set to '1' in bits b7 to b1 in the AM byte. If b8 in the AM byte is set to '0' the interpretation of bits b7 to b1 is as defined in ISO/IEC 7816-4 [12]. If b8 in the AM byte is set to '1' the usage of bits b7 to b4 is proprietary.
When multiple sets of an AM byte and one or more corresponding SC bytes are present in the value field they present an OR condition.
EXAMPLE 1:
The access rule for READ always for an EF is coded using the compact format as follows.
Tag L AM SC
'8C''02''01''00'
EXAMPLE 2:
The access rule for UPDATE user PIN verification and READ always for an EF is coded using the compact format as follows.
Tag L AM SC SC
'8C''03''03''10''00'
Up

9.2.6  Expanded format  p. 72

The expanded format is indicated by tag 'AB' in the FCP. This tag indicates a constructed data object. In the expanded format an access rule consists of one AM_DO followed by a sequence of SC_DOs. The contents of the AM_DO is defined by the tag that it is indicated with, see ISO/IEC 7816-4 [12]. Tag '80' indicates that the AM_DO contains an AM byte. The sequence of SC_DOs following the AM_DO is relevant for all commands specified in the AM_DO. The different SC_DOs can form an OR or an AND condition as defined in ISO/IEC 7816-4 [12]. The information following tag 'AB' in the FCP can contain a lot of data if the rule is complex. This information is part of the FCP that is transmitted over the interface in the response to a SELECT or a STATUS command. The structure of the security attribute in expanded format is as follows.
Tag length AM_DO tag AM_DO SC_DO tag SC_DO AM_DO tag AM_DO SC_DO tag SC_DO
'AB' See ISO/IEC 7816-4 [12] See ISO/IEC 7816-4 [12] See ISO/IEC 7816-4 [12] See ISO/IEC 7816-4 [12]
An example using the expanded format coding is given in Annex E.
Up

9.2.7  Access rule referencing  p. 72

Access rules may be shared between files in the UICC by referencing. This is accomplished by storing the security attributes in the expanded format in a linear fixed file, the Access Rule Reference(EFARR) in the UICC. The structure of the EFARR file is as follows.
Record Number (ARR) Record Content (Access Rule)
'01'AM_DO||SC_DO1||SC_DO2||AM_DO||SC_DO3||SC_DO4 …
'02'AM_DO||SC_DO1||AM_DO||SC_DO5||SC_DO6 …
The referenced format is indicated in the FCP following tag '8B'. The access rule is stored in a file, EFARR. This file is a linear fixed file. Referencing is based on the following two methods:
  • File ID and record number (File ID, record number).
  • File ID, SE ID and record number (File ID, SE ID, record number).
The second possibility allows the usage of different access rules in different security environments. When referencing EFARR is based on the file ID, the rules for the location of the access rules are as follows:
  • For an EF, if the EF(ARR) file with the file ID indicated in tag '8B' cannot be found in the current DF, the parent DF shall be searched for EF(ARR). This process shall continue until the EF(ARR) is found or until an ADF or the MF is reached.
  • For a DF, if the EF(ARR) file with the file ID indicated in tag '8B' cannot be found in the parent DF, the grandparent DF shall be searched for EF(ARR). This process shall continue until the EF(ARR) is found or until an ADF or the MF is reached.
  • For the MF or an ADF, the EF(ARR) file with the file ID indicated in tag '8B' shall be searched under the MF.
The structure of the access rule referencing DO is as follows.
Tag Length Value
'8B''03'File ID, record number
'8B''02' + n x '02'File ID, SE Idn1, Record number X, SE Idn2, Record number Y, etc.
Each record in EfARR contains a sequence of AM_DOs followed by SC_DOs. The content of the record is the rule that applies for access to the selected file. The content of a sample EFARR file is given in Annex F. The option with the SE ID referencing shall be used in an application where several security environments exist.
Up

9.3  Security environment  p. 73

9.3.0  Description  p. 73

The security environment is a mechanism to specify for the card system the security functions that are available to provide protection to commands for a specific application of the card according to ISO/IEC 7816-4 [12]. The security environment for a multi-application UICC is defined as a container for each activated application on the UICC. In case of a single application card the security environment is valid for the whole UICC. In the referenced format it is possible to indicate different access rules as a function of the SE that is in use.
Up

9.3.1  Definition of the security environment  p. 73

In case the referenced format contains SEID as the referencing method the terminal shall evaluate the SEID and perform the appropriate user verification accordingly.
The following properties are mapped to SE01 and SE00.
SE ID Properties
'00'(The global Application PIN is disabled AND the Universal PIN is disabled) OR (The global Application PIN is disabled AND the Universal PIN is enabled and used)
'01'(The global Application PIN is enabled) OR (The global Application PIN is disabled AND the Universal PIN is enabled but not used)
The above requirements are derived from Table 9.1. A multi-application capability UICC that supports the universal PIN shall also support the use of SE00 and SE01 in order to allow application verification requirement to be replaced by the Universal PIN. A multi-application capability terminal shall support SEID referencing in EFARR.
PIN to verify Universal PIN status
E NE
APPL_PIN statusEAPPL_PIN
SE01		APPL_PIN
SE01
NEUUPUniversal_PIN
SE00		NO PIN
SE00
DUUPNO PIN
SE01		NO PIN
SE00
Key:
UUP:
Use Universal PIN (usage qualifier set to '08').
DUUP:
Do not Use Universal PIN (usage qualifier set to '00').
E:
Enabled
NE:
Not Enabled
The Security Environment when no application is active on a given logical channel (SE_No_Active_Application) is set as follows: all application PINs assigned on the UICC are considered as APPL_PIN; if at least one of the application PINs is disabled, the SE is SE#00 except for the case where the Universal PIN is enabled but the default usage qualifier (see clause 9.5.2) is set to "do not use" as defined in Table 9.1 (DUUP). This Security Environment is valid under the MF and under its child DFs/EFs as long as no application is active.
The Security Environment when an application is active on a given logical channel (SE_Active_Application) is determined as in Table 9.1 with the APPL_PIN being the Application PIN of the active application. This Security Environment is valid under the ADF/MF and their child DFs/EFs.
Up

9.3.2  Logical Channels and Security Environment  p. 74

A UICC supporting logical channels has the security environment set during the application activation and is valid for the logical channel on which the application is activated. The security environment remains the same on this logical channel until a new application is selected or the status of the PIN status DO has changed, i.e. the application or universal PIN status has been changed from disabled to enabled or vice versa.
The security environment of an application running on a logical channel is inherited when a new channel is opened from the non-basic channel. It is evaluated as after the ATR and set as the SE_No_Active_Application when the new channel is opened from the basic channel.
Any command issued on a logical channel affecting the SE setting only affects the SE on the channel where the command was issued and other channels with inherited security from this channel. The SE change on a channel with inherited security also changes the SE on the channel from which the security status was inherited.
Up

9.4  PIN definitions  p. 74

9.4.0  Introduction  p. 74

Clause 9.4 defines the types of PIN that shall exist on a UICC, namely the Universal PIN and the application PIN, as well as other types of access conditions needed by the UICC/an application.

9.4.1  Universal PIN  p. 74

A Universal PIN is a PIN that is used in a multi-application environment to allow several applications to share one common PIN. The Universal PIN is a global access condition that has been assigned a key reference value '11'. This key reference value shall not be used for anything else but to indicate the Universal PIN.
In order to give access to several applications on a multi-application UICC, a terminal conforming to the present document shall support the usage of the Universal PIN. A multi-application UICC according to the present document should support the usage of a Universal PIN.
If an application allows the use of the Universal PIN as replacement PIN, the Universal PIN shall be part of the access condition for this application on a multi-application UICC that complies to the present document. In case of a single verification capable UICC the Universal PIN shall not be used.
The Universal PIN does not belong to any application, e.g. its verification status cannot be reset by the application activation or termination procedures.
Up

9.4.2  Application PIN  p. 75

An application PIN is a PIN that uses a global key reference (defined as level 1 in Table 9.2) as defined in Table 9.3. The application PIN allows access to any file on the UICC where it is referenced in the access rules. i.e. this PIN has global access rights with respect to files. It becomes an application PIN based on where it is assigned, and it belongs to the corresponding application Security Environment. An application, from the security context point of view, may consist of one or more ADFs/DFs. In this case the ADFs/DFs are seen as one application from the security and access rules point of view. All operations performed on a PIN (enable/disable/replace) covering several ADFs/DFs affects the applications where the PIN is used and the access rules where the corresponding key reference is used.
Up

9.4.3  Local PIN  p. 75

A local PIN is a PIN that uses a local key reference which is only valid within the ADF/DF where it is indicated in the FCP. It means that 2 ADFs can use the same local key reference number with two different values and two different status (enabled, disabled, verified, blocked), one for each ADF. The verification status of a local PIN is maintained when performing file selection. A local PIN shall be indicated in the FCP of child DFs. A local PIN is defined as level 2 in Table 9.2 and coded as defined in Table 9.3. A local PIN referenced in an ADF or a DF, which is not DFTELECOM, does not give access to DFTELECOM.
An ADF shall use one application PIN and zero, one or more local PIN(s). An ADF using at least one local PIN shall have one local PIN paired with application PIN. Table 9.3 indicates how application PINs and local PINs shall be paired (the global key reference '01' is paired with the local key reference '81', the global key reference '02' is paired with the local key reference '82', etc.). If replacement of the application PIN by the Universal PIN is authorized, the ADF shall also use the Universal PIN.
A local PIN can be assigned to any DF. In this case, a key reference indicating a second application PIN as defined in Table 9.3 shall be used.
Up

9.4.4  PINs and logical channels  p. 75

The PIN status of the Universal PIN and of application PINs is global in the UICC. The PIN status of local PINs exists within the ADF/DF where it is specified.
The PIN status of the Universal PIN, application PINs, and local PIN is independent from the logical channels. This means that when a PIN is verified in one logical channel, it is also verified in all other channels. Also when a PIN is enabled in one logical channel it is enabled in all other channels.

9.5  PIN and key reference relationship  p. 75

9.5.0  Introduction  p. 75

Clause 9.5 describes the relationship between the user verification requirement (PIN) and referencing to a PIN in the VERIFY, CHANGE, DISABLE/ENABLE VERIFICATION and UNBLOCK commands.

9.5.1  Access condition mapping  p. 75

Access condition mapping, using SC_DOs, is done using the expanded format with the entries coded as CRT values, i.e. tag 'A4' is used. The CRT is a constructed TLV DO containing a usage qualifier TLV DO (tag '95') and a Key reference TLV DO (tag '83').
The access condition groups are defined according to Table 9.2. Each group is divided into several key references. The usage of a key reference shall be in accordance with the group definition in Table 9.2.
Level Access condition
0ALWays
1User Verification (PIN)
2(see note 1)
3 to 4Reserved for Future Use
5 to 6(see note 2)
7NEVer
NOTE 1:
This level is reserved for a second level of user verification (PIN2) that may be defined by an application.
NOTE 2:
Allocation of these levels and the respective requirements for their fulfilment are the responsibility of the appropriate administrative authority.
The levels indicated in Table 9.2 are used in the present document to refer to a specific group of access conditions.
A key reference shall only be assigned for the purpose as it is defined in Table 9.3, e.g. a level 1 key reference is always to be used for an application or a set of applications that share the same access conditions. A level 2 key reference is only valid within the ADF/DF where it is indicated.
CRT Tag Len Value Access condition Level
Key Ref Tag Len Value Usage Qualifier Tag Len Val
'90''00'------ALW0
'A4'
'A4'
'A4'
'A4'		 '06'
'06'
'06'
'06'		 '83'
'83'
'83'
'83'		 '01'
'01'
'01'
'01'		 '01'
'02'
'03'
'04'		 '95'
'95'
'95'
'95'		 '01'
'01'
'01'
'01'		 '08'
'08'
'08'
'08'		 PIN Appl 1
PIN Appl 2
PIN Appl 3
PIN Appl 4		 1
'A4'
'A4'
'A4'
'A4'
'XX'		 '06'
'06'
'06'
'06'
'06'		 '83'
'83'
'83'
'83'
'83'		 '01'
'01'
'01'
'01'
'01'		 '05'
'06'
'07'
'08'
'09'		 '95'
'95'
'95'
'95'
'95'		 '01'
'01'
'01'
'01'
'01'		 '08'
'08'
'08'
'08'
'08'		 PIN Appl 5
PIN Appl 6
PIN Appl 7
PIN Appl 8
RFU		 1
'A4'
'A4'
'A4'
'A4'
'A4'		 '06'
'06'
'06'
'06'
'06'		 '83'
'83'
'83'
'83'
'83'		 '01'
'01'
'01'
'01'
'01'		 '0A'
'0B'
'0C'
'0D'
'0E'		 '95'
'95'
'95'
'95'
'95'		 '01'
'01'
'01'
'01'
'01'		 '08'
'08'
'08'
'08'
'08'		 ADM1
ADM2
ADM3
ADM4
ADM5		 5
'A4''06''83''01''11''95''01''08'PIN Universal PIN1
'XX''06''83''01''12-1E''95''01''08'RFU (Global)3
'A4'
'A4'
'A4'
'A4'		 '06'
'06'
'06'
'06'		 '83'
'83'
'83'
'83'		 '01'
'01'
'01'
'01'		 '81'
'82'
'83'
'84'		 '95'
'95'
'95'
'95'		 '01'
'01'
'01'
'01'		 '08'
'08'
'08'
'08'		 Second PIN Appl 1
Second PIN Appl 2
Second PIN Appl 3
Second PIN Appl 4		 2
'A4'
'A4'
'A4'
'A4'
'A4'		 '06'
'06'
'06'
'06'
'06'		 '83'
'83'
'83'
'83'
'83'		 '01'
'01'
'01'
'01'
'01'		 '85'
'86'
'87'
'88'
'89'		 '95'
'95'
'95'
'95'
'95'		 '01'
'01'
'01'
'01'
'01'		 '08'
'08'
'08'
'08'
'08'		 Second PIN Appl 5
Second PIN Appl 6
Second PIN Appl 7
Second PIN Appl 8
RFU		 2
'A4'
'A4'
'A4'
'A4'
'A4'		 '06'
'06'
'06'
'06'
'06'		 '83'
'83'
'83'
'83'
'83'		 '01'
'01'
'01'
'01'
'01'		 '8A'
'8B'
'8C'
'8D'
'8E'		 '95'
'95'
'95'
'95'
'95'		 '01'
'01'
'01'
'01'
'01'		 '08'
'08'
'08'
'08'
'08'		 ADM6
ADM7
ADM8
ADM9
ADM10		 6
'XX''06''83''01''90-9E''95''01''08'RFU (Local)4
'97''00'------NEV7
NOTE:
The CRT value 'XX' for RFU key references is specified at the time when the value is taken into use.
A single verification capable UICC (from the security context point of view) shall use key reference '01' as PIN and key reference '81' as PIN2. A multi-verification capable UICC shall use key references in the range of '01' to '08' as PIN and may use key references in the range from '81' to '88' as PIN2. In addition a multi-verification capable UICC should support the use of key reference '11' as a universal PIN, see clause 9.3.1 for the definition of a universal PIN. Multiple applications (from the security context point of view) on a UICC shall not share any key references except for key reference '11', which is used as the universal PIN.
Up

9.5.2  PIN status indication  p. 77

The status of a PIN that is used by an application for user verification is stored in the PS Template DO and shall be indicated in the FCP in a response to the SELECT or STATUS command issued at the application/DF level. The PIN status information is indicated in the FCP in the PS template DO using tag 'C6'. The PS template DO conveys two types of data, first the PS_DO indicated by tag '90' that indicates the status of the PIN(s) enabled/disabled. The PS_DO is followed by one or more key reference data objects indicated by tag '83'. The PIN status may be encoded over several bytes. For each bit set to '1' the corresponding key reference (PIN) is enabled. The PS_DO is coded using a bitmap list. Bit b8 in the most significant byte corresponds to the first key reference indicated by tag '83' following the PS_DO. Bits b7 to b1 are mapped to consecutive key references indicated by tag '83'. A key reference data object may be preceded by a usage qualifier data object. The usage qualifier data object indicated by tag '95' is mandatory for the universal PIN (see clause 9.4.1) and optional for other PINs. This usage qualifier indicates whether an enabled PIN needs to be verified for access. If there is no usage qualifier, or if the associated data object is empty, in front of a key reference, this indicates that this key reference does not support this feature, and it shall always be verified if enabled. The content of the PS_DO usage qualifier is defined in Table 9.4. From Table 9.4, the value to be used for user PIN verification is '08'.The usage qualifier of the Universal PIN is defined in the context of an application and may have different value in different applications.
The default usage qualifier of the Universal PIN after the ATR is set to "do not use" if all application PINs are enabled or if at least one of the applications where the application PIN is disabled has the Universal PIN usage qualifier set to "do not use". When no application is active on a given logical channel, the Universal PIN usage qualifier is evaluated as after the ATR.
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
00000000the verification requirement is not used for verification
1-------
  • use verification (DST, CCT)
  • use encipherment (CT)
  • use external authentication (AT)
-1------
  • use computation (DST, CCT)
  • use decipherment (CT)
  • use internal authentication (AT)
--1-----
  • use SM response (CCT, CT, DST)
---1----
  • use SM command (CCT, CT, DST)
----1---
  • use the PIN for verification (Key Reference data user knowledge based)
-----1--
  • use user authentication, biometric based
------xxRFU (default = 00)
The PS template DO is constructed as indicated in Table 9.5 and Table 9.6.
PS Template DO Tag L PS_DO Tag L V PS-byte(s) Key-reference tag L V Key-reference tag L V
'C6''90''83''01''83''01'
PS Template DO Tag L PS_DO Tag L V PS-byte(s) Usage Qualifier tag L V Key-reference tag L V Key-reference tag L V
'C6''90''95''01''83''01''83''01'
Up

9.6  LSE isolation  p. 78

Different LSEs on a UICC shall be isolated from each other. All features provided by an LSE shall be kept separate from those belonging to other LSEs:
  • file system;
  • applications;
  • AIDs;
  • CAT session;
  • security context;
  • runtime environment;
  • etc.
The terminal shall also keep this isolation:
  • To reset an LSE, the dedicated logical reset mechanism shall be used.
  • If an LSE requests a REFRESH proactive command with mode UICC reset, only this LSE shall be reset using the dedicated logical reset mechanism.

Up   Top   ToC