This addendum is informative. However, all implementations of MIDP 2.0 on GSM/UMTS compliant devices are expected to comply with this addendum.
MIDP 2.0 defines the framework for authenticating the source of a MIDlet suite and authorizing the MIDlet suite to perform protected functions by granting permissions it may have requested based on the security policy on the device. It also identifies functions that are deemed security vulnerable and defines permissions for those protected functions. Additionally, MIDP 2.0 specifies the common rules for APIs that can be used together with the MIDP but are specified outside the MIDP. MIDP 2.0 specification does not mandate a single trust model but rather allows the model to accord with the device trust policy.
The purpose of this addendum is to extend the base MIDlet suite security framework defined in MIDP 2.0 and to define the following areas:
This specification is organized as follows:
Sections 2 to 4 establish the relationship between the device security policy, different protection domains, and requirements concerning certificate storage on smart cards. Section 5 specifies the function groups and identifies the permissions and the APIs that need to be protected using the MIDP 2.0 security framework. Sections 6 and 7 specify rules that must be followed when permissions are granted, and also requirements of user notifications. Finally Section 8 specifies the MIDlet behaviour during roaming and after changing the smart card.
GSM/UMTS compliant devices implementing this Recommended Security Policy MUST follow the security framework specified in the MIDP 2.0. Additionally, devices that support trusted MIDlets MUST follow the PKI-based authentication scheme as defined in MIDP 2.0 specification.
A protection domain is a way to differentiate between downloaded MIDlet suites based on the entity that signed the MIDlet suite, and to grant or make available to a MIDlet suite a set of permissions. A domain binds a Protection Domain Root Certificate to a set of permissions. The permissions are specified in the protection domain security policy, a policy has as many entries as there are protection domains available on the device. A domain can exist only for a Protection Domain Root Certificate that contain the id-kp-codeSigning extended key usage extension. MIDlet suites that authenticate to a trusted Protection Domain Root Certificate are treated as trusted, and assigned to the corresponding protection domain. A MIDlet suite cannot belong to more than one protection domain. The representation of a domain and its security policy is implementation specific.
This document specifies two different requirements as to how the MIDP permissions framework should be used, depending on the protection domain an application executes.
Manufacturer and Operator Domains – MIDlet suites SHOULD seek permission from the user when accessing security vulnerable APIs and functions. Permissions defined by MIDP 2.0 and other APIs give the guidelines of which functions are seen as security vulnerable and need protection. It is expected that operator trusted MIDlets will give prompts and notifications to the user when accessing these security protected functions as required.
Third Party and Untrusted Domains – The device implementation is responsible for prompting the user according to the security policies specified in Tables 1 through 6 in this document.
The trusted manufacturer Protection Domain Root Certificate is used to verify manufacturer MIDlet suites. The manufacturer Protection Domain Root Certificate MUST be mapped on to the security policy for the manufacturer domain on the device. A device MUST support the security policy for the manufacturer domain.
If the manufacturer Protection Domain Root Certificate is NOT available on the device, the manufacturer domain MUST be disabled.
The manufacturer Protection Domain Root Certificate can only be deleted or modified by the manufacturer, who may use an update mechanism whose details are outside the scope of this specification. Any new or updated manufacturer Protection Domain Root Certificate MUST be associated with the security policy for the manufacturer domain on the device. MIDlet suites verified by a previous manufacturer Protection Domain Root Certificate MUST be disabled.
Permissions in the Manufacturer domain are all marked as Allowed (see MIDP 2.0 for the definition). Permissions granted by the Manufacturer domain as Allowed imply that downloaded and authenticated manufacturer MIDlets suites perform consistently with MIDlets suites pre-installed by the manufacturer in terms of security and prompts to the user whenever events that require user acknowledgement occur. Manufacturer MIDlets SHOULD seek permission from the user when accessing security vulnerable APIs and functions. Permissions defined by MIDP 2.0 and other APIs give the guidelines of which functions are seen as security vulnerable and need protection.
At MIDlet suite installation, an implementation MUST present the user with the Organisation and Country fields within the Subject field of the manufacturer Protection Domain Root Certificate if the Organisation and Country fields are present. If the Organisation and Country fields are absent, the implementation MUST present the user with other appropriate information from the Subject field. An implementation MAY also present the user with additional information in the Subject field other than Organisation and Country in all cases. This user notification MUST take place at application installation.
The Manufacturer domain imposes no restriction on the capabilities specified in the MIDP 2.0 and other JSRs.
A trusted operator Protection Domain Root Certificate is used to verify operator MIDlet suites. There is no explicit limitation on the number of operator trusted Protection Domain Root Certificates available at the specified location in the SIM, USIM or WIM. Trusted operator Protection Domain Root Certificates MUST be mapped on to the security policy for the Operator domain on the device. A device MUST support the security policy for the Operator domain.
If an operator Protection Domain Root Certificate is NOT available on the specified location in the SIM, USIM or WIM; the operator domain MUST be disabled.
Trusted Protection Domain Root Certificates are read from the Certificate Directory File (CDF) for trusted certificates [WIM]. Protection Domain Root Certificate found in the trustedCertificates file on the WIM are mapped onto the Operator domain or onto the Trusted Third Party domain, depending on the trustedUsage field in the CommonCertificateAttributes associated with the certificate [PKCS#15]:
If the trustedUsage field is present and contains the OID for key usage “iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42)
products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operator(1)”, then the certificate is to be mapped onto the Operator domain.If the trustedUsage field is not present, or does not contain the OID for key usage “Operator Domain”, then the certificate is to be mapped onto the Trusted Third Party domain.
Operator trusted Protection Domain Root Certificates may be placed in the trustedCertificates Certificate Directory File (CDF) of a WIM, SIM, or USIM. If operator Protection Domain Root Certificates are stored directly on a SIM or USIM, that is, not under the WIM application, then they shall be stored in the EF trustedCertificates CDF located under DF(PKCS#15), as defined by [SCPROV]. Operator Protection Domain Root Certificates can be obtained only from the trusted CDF (the card holder can not update this directory) and not from any other directory of the smart card.
All operator Protection Domain Root Certificates MUST be mapped onto the same security policy for the operator domain on the device. The Operator domain cannot be deleted or modified by the user or any other party, except by a device provisioned capability.
A signed and authenticated MIDlet suite MUST be authorized to the Operator domain if the MIDlet suite was authenticated to the operator Protection Domain Root Certificate. The operator root public key MUST be obtained from a certificate in the trusted CDF of a currently inserted and enabled smart card and not from any other location on the smart card or on the device. At MIDlet suite installation, an implementation MUST present the user with the Organisation and Country fields within the Subject field of the operator Protection Domain Root Certificate if the Organisation and Country fields are present. If the Organisation and Country fields are absent, the implementation MUST present the user with other appropriate information from the Subject field. An implementation MAY also present the user with additional information in the Subject field other than Organisation and Country in all cases.This user notification MUST take place at application installation.
The security policy for the operator domain MUST contain all permissions implemented on the device as "Allowed". Permissions granted by the Operator domain as Allowed imply that downloaded and authenticated operator MIDlets suites perform consistently with other MIDlets suites installed by the operator in terms of security and prompts to the user whenever events that require user acknowledgement occur. Operator MIDlets SHOULD seek permission from the user when accessing security vulnerable APIs and functions. Permissions defined by MIDP 2.0 and other APIs provide guidelines as to which APIs and functions are seen as security vulnerable and need protection. The Operator domain imposes no restriction on the capabilities specified in the MIDP 2.0 and other JSRs.
MIDlet suites installed in the Operator domain MUST store, along with the application itself, a hash of the Protection Domain Root Certificate under which the signing certificate used to sign the application was issued. The hash algorithm to be used is the following, starting with the Protection Domain Root Certificate, compute the 20-byte SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits) of that certificate. This method is commonly used to compute key identifiers, especially to accelerate trust chain building [RFC3280, §4.2.1.2]. The implementation MUST NOT assume for optimization purposes that X.509 key identifiers or PKCS#15 labels are the correct value; and MUST compute the hash themselves. This hash MUST be used by the device to decide when a given MIDlet suite should be disabled, as specified in Section 8.
A trusted third party Protection Domain Root Certificate is used to verify third party MIDlet suites. There is no explicit limitation on the number of trusted third party Protection Domain Root Certificates available either on the device or at the specified location in the SIM, USIM or WIM (see section 3.2). A trusted third party Protection Domain Root Certificates MUST be mapped on to the security policy for the trusted third party domain on the device. A device MUST support the security policy for the trusted third party domain. If there are no trusted third party Protection Domain Root Certificates available either on the device or at the specified location in the SIM, USIM or WIM; the trusted third party domain MUST be disabled.
Third party Protection Domain Root Certificates downloaded after device manufacture MUST NOT be used for authentication of MIDlet suites. This does NOT prevent obtaining trusted third party Protection Domain Root Certificates from the specified location in the SIM, USIM, WIM.
At MIDlet suite installation, an implementation MUST present the user with the Organisation and Country fields within the Subject field of the signing certificate of a MIDlet suite if the Organisation and Country fields are present. If the Organisation and Country fields are absent, the implementation MUST present the user with other appropriate information from the Subject field. An implementation MAY also present the user with additional information in the Subject field other than Organisation and Country in all cases. This user notification MUST take place at MIDlet suite installation. When the user is prompted to grant permissions to an application, the prompt MUST identify the trusted source with the appropriate fields within Subject field of the signing certificate as stated above.
The user MUST be able to delete or disable trusted third party Protection Domain Root Certificates. If a third party Protection Domain Root Certificate is to be deleted, the implementation SHOULD warn the user of the consequence of the deletion adequately. The user MUST be able to enable a disabled third party Protection Domain Root Certificate. A disabled third party Protection Domain Root Certificate MUST NOT be used to verify downloaded MIDlet suites. Furthermore, if a third party Protection Domain Root Certificate is deleted or disabled (for example, revoked, deleted, or disabled by the user) the Third Party domain MUST no longer be associated with this Protection Domain Root Certificate. If the user chooses to delete or disable the Protection Domain Root Certificate, implementation may provide an option to delete the MIDlet suites authenticated to it.
The security policy for trusted third party domain MUST NOT granted any permissions on the device as Allowed. All permissions granted by the Third Party domainMUST be User permissions, that is, user interaction is required for permission to be granted. Table 1 specifies the function groups and the available user permission types for MIDlet suites in the Third Party domain. Tables 2 through 6 specify the mapping of permissions and APIs onto different function groups.
MIDlets suites that are unsigned will belong to the Untrusted domain. The implementation MUST inform the user whenever a new MIDlet suite is installed in the Untrusted domain. The notification MUST indicate that the application does not come from a trusted source. The user must be able to make an informed decision based on the available information before granting permissions to an application.
When the user is prompted to grant permissions to an application, the prompt MUST indicate that the application does not come from a trusted source.
Untrusted MIDlets suites MUST NOT gain read access directly to PIM data through the API defined in JSR 075 (see Tables 1 and 3 in Section 5). Interactions between an untrusted application and the PIM data can be enabled, however, by implementations of the javax.microedition.lcdui package: when the application programmer sets the constraint TextField.PHONENUMBER, an implementation of the TextField class MAY propose that the user look up a number in his or her phone book and copy it to the TextField item. For example, when the TextField item has input focus, the user can access a menu to enter the phone book; when the user selects an entry in the phone book, the contents of the selected entry are "copied and pasted" into the TextField item.
Table 1 specifies the function groups and the available user permissions for MIDlets suites in the Untrusted domain. Tables 2 through 6 specify the mapping of permissions and APIs onto different function groups.
The MIDP 2.0 specification defines the generic format for a policy file that can be read from removable media. GSM/UMTS compliant devices are not expected to use it in the first phase, but rather to use security policy resident on the device. The possibility of remotely located security policy files is left for further consideration.
A device with a small display may not be able to present all permissions to the user in a single configuration settings menu in a user friendly manner. Therefore the device is not required to present all individual permissions for user confirmation. Rather, a certain higher-level action triggered by the protected function should be brought to the user for acceptance. The high level functions presented to the user essentially capture and reflect the actions and consequences of the underlying individual permissions. The function groups are as follows:
Network/cost-related groups:
Phone Call – the group represents permissions to any function that results in a voice call.
Net Access – the group represents permissions to any function that results in an active network data connection (for example GSM, GPRS, UMTS, etc.); such functions must be mapped to this group.
Messaging – the group represents permissions to any function that allows sending or receiving messages (for example, SMS, MMS, etc.)
Application Auto Invocation – the group represents permissions to any function that allows a MIDlet suite to be invoked automatically (for example, push, timed MIDlets, etc.)
Local Connectivity – the group represents permissions to any function that activates a local port for further connection (for example, COMM port, IrDa, Bluetooth, etc.)
User-privacy-related groups:
Multimedia recording – the group represents permissions to any function that gives a MIDlet suite the ability to capture still images, or to record video or audio clips.
Read User Data Access – the group represents permissions to any function that gives a MIDlet suite the ability to read a user's phone book, or any other data in a file or directory.
Write User Data Access – the group represents permissions to any function that gives a MIDlet suite the ability to add or modify a user's phone book, or any other data in a file or directory.
Whenever new features are added to the MIDP they should be assigned to the appropriate function group. In addition, APIs that are specified elsewhere (that is, in other JSRs) but rely on the MIDP security framework should also be assigned to an appropriate function group. If none of the function groups defined in this section is able to capture the new feature and reflect it to the user adequately, however, then a new function group MUST be defined in this document.
If a new function group is to be added, the following should be taken into consideration: the group to be added MUST not introduce any redundancy to the existing groups, the new group MUST be capable of protecting a wide range of similar features. The latter requirement is to prevent introducing narrowly scoped groups.
It is the function groups and not the individual permissions that should be presented when the user is prompted. Furthermore, it is the function groups that should be presented to the user in the settings of a given MIDlet suite.
Table 1 presents the policy that must be enforced using the security framework as defined in MIDP 2.0. The table specifies the available permission settings for each function group defined. Settings that are effective at the time the MIDlet suite is invoked for the first time, and remain effective until the user changes them in the MIDlet suite's configuration menu, are called "default settings." Settings available to the user in the configuration menu, to which the user can change from a default setting, are called "other settings." Together, default and other settings form a pool of available configuration settings for the MIDlet suite. Default and other settings are presented for each function group and each protection domain. The naming of the function groups is implementation specific but MUST follow the guidelines of the function group names defined in this document as well as the definitions of these groups.
Tables 2 through 5 present individual permissions defined in the MIDP 2.0 and other JSRs, and map to the function groups specified in this section. An individual permission MUST occur in only one function group.
It is recommended that the manufacturer and operator trusted MIDlets suites adhere to the permission guidelines provided in the tables, and present appropriate prompts to the user for the functions identified as security protected.
|
Function group |
Trusted Third Party domain |
Untrusted domain |
||
|
Phone Call |
default setting |
Oneshot |
default setting |
Oneshot |
|
other settings |
No |
other settings |
No |
|
|
Net Access |
default setting |
Session |
default setting |
Oneshot |
|
other settings |
Oneshot, Blanket, No |
other settings |
Session, No |
|
|
Messaging |
default setting |
Oneshot |
default setting |
Oneshot |
|
other settings |
No |
other settings |
No |
|
|
Application Auto Invocation |
default setting |
Session |
default setting |
Session |
|
other settings |
Oneshot, Session, Blanket, No |
other settings |
Oneshot, No |
|
|
Local Connectivity |
default setting |
Session |
default setting |
Session |
|
other settings |
Blanket, No |
other settings |
Blanket, No |
|
|
Multimedia recording |
default setting |
Session |
default setting |
Oneshot |
|
other settings |
Blanket, No |
other settings |
Session, No |
|
|
Read User Data Access |
default setting |
Oneshot |
default setting |
No |
|
other settings |
Session, Blanket, No |
other settings |
No |
|
|
Write User Data Access |
default setting |
Oneshot |
default setting |
Oneshot |
|
other settings |
Session, Blanket, No |
other settings |
No |
|
The device MAY enhance and simplify the user experience by applying a single set of configuration settings (default or other), not just to a single MIDlet suite, but to all MIDlet suites for a given signer. This option MUST NOT compromise the function groups and available settings defined in Table 1. If such an option exists, the user will be prompted to save the settings and reuse them in future for MIDlets suites from the same source. Such a feature MAY also inform the user that a given source has already been accepted and has an alias to the saved configuration settings. For each trusted or untrusted application, the implementation MAY read requested permissions from the MIDlet-Permissions and MIDlet-PermissionsOpt attributes, notify the user which capability the application requires, and prompt the user to accept or reject installation of the application.
Blanket permission given for some combinations of Function groups can lead to higher risks for the user. For MIDlet suites in the Third Party domain the user MUST be notified of the higher risk involved and also acknowledge that this risk is accepted to allow such combinations to be set. The combination of Blanket permission in Function groups where this applies is:
This restriction need not apply to the Untrusted domain, since these combinations would be forbidden according to table 1.
Additionally, the Blanket setting for Application Auto Invocation and the Blanket setting for Net Access are mutually exclusive. This constraint is to prevent a MIDlet suite from auto-invoking itself, then accessing a chargeable network without the user being aware. If the user attempts to set either the Application Auto Invocation or the Network Function group to "Blanket" when the other Function group is already in "Blanket" mode, the user MUST be prompted as to which of the two Function groups shall be granted "Blanket" and which Function group shall be granted "Session".
For each Phone Call and Messaging action, the implementation MUST present the user with the destination phone number before the user approves the action. For the Messaging group, if the implementation maps a single API call to more than one message (that is, the implementation supports disassembly/reassembly), the implementation MUST present the user with the number of messages that will actually be sent out. This requirement is to ensure that the user always understands the network costs associated with running the program, whatever API calls are involved.
|
|
||
|
Permission |
Protocol |
Function group |
|
javax.microedition.io.Connector.http |
http |
Net Access |
|
javax.microedition.io.Connector.https |
https |
Net Access |
|
javax.microedition.io.Connector.datagram |
datagram |
Net Access |
|
javax.microedition.io.Connector.datagramreceiver |
datagram server (without host) |
Net Access |
|
javax.microedition.io.Connector.socket |
socket |
Net Access |
|
javax.microedition.io.Connector.serversocket |
server socket (without host) |
Net Access |
|
javax.microedition.io.Connector.ssl |
ssl |
Net Access |
|
javax.microedition.io.Connector.comm |
comm |
Local Connectivity |
| javax.microedition.io.PushRegistry | All | Application Auto Invocation |
|
|
||
|
Security Policy Identifier (Proposed Permission) |
Permitted Java API Calls |
Function group |
|
javax.microedition.pim.PIM.
|
PIM.listContactLists()
|
Read User Data Access |
|
javax.microedition.pim.PIM.
|
PIM.listContactLists()
|
Write User Data Access |
|
javax.microedition.pim.PIM.
|
PIM.listEventLists()
|
Read User Data Access |
|
javax.microedition.pim.PIM.
|
PIM.listEventLists()
|
Write User Data Access |
|
javax.microedition.pim.PIM.
|
PIM.listToDoLists()
|
Read User Data Access |
|
javax.microedition.pim.PIM.
|
PIM.listToDoLists()
|
Write User Data Access |
Table 3 Editor's Note: The necessary permissions to protect the PIM API are not specified in the PIM package. This table will be updated once these changes are incorporated into the PIM API package.
The implementation MUST ensure that the user is informed of the nature of the user data an application has access to (for instance, events or to-do lists) before allowing the application access to these functions. Whenever a MIDlet adds, deletes or updates a PIM entry under the Oneshot permission type, the implementation MUST display it to the user for acknowledgement.
|
|
||
|
Security Policy Identifier (Proposed Permission) |
Permitted API calls |
Function group |
|
javax.microedition.io.Connector.bluetooth.client |
Connector.open(“btspp://<server BD_ADDR>…”)
|
Local Connectivity |
|
javax.microedition.io.Connector.obex.client |
Connector.open(“btgoep://<server BD_ADDR>…”)
|
Local Connectivity |
|
javax.microedition.io.Connector.obex.client.tcp |
Connector.open(“tcpobex://<server IP_ADDR>…”) |
Net Access |
|
javax.microedition.io.Connector.bluetooth.server |
Connector.open(“btspp://localhost:…”)
|
Local Connectivity |
|
javax.microedition.io.Connector.obex.server |
Connector.open(“btgoep://localhost:…”)
|
Local Connectivity |
|
javax.microedition.io.Connector.obex.server.tcp |
Connector.open(“tcpobex://:<PORT>”)
|
Net Access |
Table 4 Editor's Note: The permissions proposed for Bluetooth API are yet to be defined in JSR82.
|
|
||
|
Security Policy Identifier (Proposed Permission) |
Permitted API calls |
Function group |
|
javax.microedition.io.Connector.sms.send |
Connector.open("sms://…", WRITE)
|
Messaging |
|
javax.microedition.io.Connector.sms.receive |
Connector.open("sms://…", READ)
|
Messaging |
|
javax.microedition.io.Connector.sms |
Connector.open("sms://…")
|
Messaging |
|
javax.microedition.io.Connector.cbs.receive |
Connector.open("cbs://…")
|
Messaging |
Table 5 Editor's Note: The permissions for Wireless Messaging API are yet to be defined in JSR120.
|
|
||
|
Security Policy Identifier (Proposed Permissions) |
Permitted API calls |
Function group |
|
javax.microedition.media.RecordControl.startRecord |
RecordControl.startRecord ( ) |
Multimedia recording |
|
javax.microedition.media.VideoControl.getSnapshot |
VideoControl.getSnapshot (…) |
Multimedia recording |
Table 6 Editor's Note: The permissions for Mobile Media API are yet to be defined in JSR135.
Implementations MUST ensure that I/O access from the Mobile Media API follows the same security requirements as the Generic Connection Framework, as specified in the package documentation for javax.microedition.io. Example methods include javax.microedition.media.Player.start, javax.microedition.media.Player.prefetch, etc. When these methods are used to fetch the content for the player via an HTTP connection, the implementation MUST enforce the security requirements specified for HTTP.
When the user grants permission to a function group, this action effectively grants access to all individual permissions under this function group.
An implementation MUST guarantee that a SecurityException is thrown when the caller does not have the appropriate security permissions.
If a messaging group is granted a Oneshot permission, it translates into a Blanket permission for javax.microedition.io.Connector.sms and javax.microedition.io.Connector.cbs, as well as to permissions that enable receiving the messages. Permission for sending the messages is still Oneshot, however; that is, the user grants permission to each message sent out by the MIDlet suite within an open connection. The same applies to the Session permission: functions related to sending the messages get Session permission, but other functions get Blanket permission." Blanket permission and No permission granted to the Messaging group apply to all individual permissions under this group.
If a MIDlet uses the capabilities defined in MIDP and other APIs, the following rules MUST apply:
As defined in the "Security for MIDP Applications" section of the MIDP 2.0 specification, MIDlet suite permissions are effectively the intersection of the domain permissions Midlet-Permission and Midlet-Permission-Opt found in the JAR manifest. The way in which a MIDlet suite's granted permissions are presented to the user is implementation-specific, but the following rules must apply:
A device MUST maintain security related data for each installed MIDlet suite, in addition to generic MIDlet suite information such as MIDlet suite name and version number. The data MUST include at least the following:
A device MUST be able to present information related to the application signer in a user-friendly manner.
The following rules MUST be followed in order to ensure informed user consent to MIDlet actions:
All previously authorized and installed MIDlet suites MUST act in accordance with the device policy when the device is roaming, or when the device smart card is changed. Newly downloaded MIDlet suites are authenticated to a Protection Domain Root Certificate currently available either on the device (only for third party applications) or at the specified location in the SIM, USIM or WIM (for operator and third party applications) and are authorized in accordance with the device policy.
If device roaming or a smart card change causes failure to access network resources that the MIDlet was previously authorized to access, then the implementation MUST NOT throw a SecurityException. This failure is not related to MIDlet suite authorization, so the implementation MUST throw an IOException instead.
The permissions assigned to MIDlet suites installed in the Manufacturer, Trusted Third Party, and Untrusted domains are not affected by changes of the (U)ICC [(U)ICC], but MIDlet suites installed in the Operator domain MUST NOT execute if, after a smart card change, the SIM no longer holds the certificate containing the operator root public key that was used to authenticate the MIDlet suite to the Operator domain (see Section 3.2, "Operator Domain").
Whether a MIDlet suite in the Operator domain can be executed depends on a comparison of "root key hash" values, computed as the 20-byte SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits) of a Protection Domain Root Certificate. The decision process SHOULD follow the following mechanism:
Note: In this mechanism, there are two steps the device performs after the smart card has changed:
An implementation MAY perform these two steps at any time, provided NO Operator domain MIDlet suite is executed after a smartcard change if its authenticating root key hash does NOT correspond to one of the new Operator-domain root key hashes. Step 2 MAY be performed right after Step 1; alternatively, Steps 1 and 2 MAY be separated in time, in which case the implementation SHOULD store the results of Step 1 securely to be used in in Step 2 at a later time.
If the Operator Protection Domain Root Certificate is not present at the specified location, the user MUST be informed that the application cannot be executed without the authorizing Protection Domain Root Certificate. The device SHOULD also give the user the option to get information on the Protection Domain Root Certificate that was used to authenticate the application to the Operator domain. This information SHOULD include the Subject field of the root certificate.
Although it is mandatory only to check whether authenticating roots are still present in the smart card when the smart card is changed, an implementation MAY check on more occasions, and accordingly disable MIDlets suites in the Operator domain as specified above. If a MIDlet suite cannot be executed because the authenticating Operator Protection Domain Root Certificate is absent, the device MUST NOT delete the MIDlet suite. The device MAY inform the user in advance via an appropriate mechanism whether a MIDlet suite could execute or not, for example using a "disabled" look and feel in the display. However, the user MUST be able to delete these disabled MIDlets suites.