Runtime security

The availability of the root certificate is checked at application launch, if application to be launched is digitally signed. Also the validity of the application signature is checked. It means that the application deployment package (JAR) stored in device has not been tampered with.

Note: In Symbian, signature checking at launch is done only when an application is installed on non-protected media, for example a memory card.

The following table defines possible error cases encountered during application launch and respective error notes.

**Table:** Error cases
Case	Symbian user note	Series 40 user note
Root certificate not available at launch	Short error message: The certificate is not available. Detailed error message: If the root was disabled by user: The certificate used to authenticate the application has been disabled. You may want to enable the certificate or uninstall the application. If the root was deleted by user: The certificate used to authenticate the application has been deleted therefore the application can not be used anymore. You should uninstall the application. The certificate used to authenticate the application resides on a SIM which is not currently available. You may want to reinsert the correct SIM or uninstall the application.	Certificate not on phone or SIM
Application signature not valid anymore	Short error message: The application has been tampered. Detailed error message: The application's deployment package has been modified. Application is not trusted anymore therefore it can not be used. You may want to uninstall the application.	Invalid application

When has been started and it an application needs to access sensitive operations, the Java implementation decides whether end user needs to be prompted before granting access or not, based on the application security settings. From Java Runtime 2.1 for Symbian onwards there are two different modes that affect the level of end user prompting:

Default mode - where the number of security prompts shown to the end user is optimized to minimum possible. Detailed Java security settings for the applications are hidden.
User defined mode - where the user is in full control. Detailed Java security settings for the applications are visible and prompting behaves fully according to the settings.

Series 40 implements only the "User defined mode".

These levels can be changed in Application Manager per application (Settings —> Application manager —> Installed applications —> Suite settings). See screenshots in Managing security settings.

Symbian security prompt

The security prompt in Java Runtime for Symbian is formatted as follows: it includes the name of the application and a lock icon (open for unsigned applications and closed for signed applications), the actual text of the security prompt and two answer options Yes and No. Answering No means that access to the requested sensitive operation is denied. The next time when the application is started, the prompt is shown again. Answering Yes means that access is allowed. Depending on the operational mode (Default mode versus User defined mode) answering Yes has further impact:

Default mode – answering Yes automatically sets the user interaction mode of the function group to maximum available
User defined mode – no changes in security settings

The actual security prompt text depends on the level of access. For example in case of User defined mode with Oneshot as the interaction mode, access to a certain file translates into a very specific security prompt text, whereas the same operation with Session interaction mode translates into more general security prompt text.

Figure: Security prompt for file access with Oneshot interaction mode

Figure: Security prompt for file access with Session interaction mode

For more information on function groups and interaction modes, see MIDP security terms and concepts.

Series 40 security prompt

The format of the security prompt is as follows: the main text describes the operation that the MIDlet is attempting to perform and the user is offered a choice to select Yes(to accept the operation) or No (to reject the operation) to the prompt. The user can also select Details and view additional details about the operation and the MIDlet (for example to view if it is trusted and list certificate details) The actual security prompt text and the result of answering Yes and No depends on the Application Access settings (Ask first time or Ask every time, or Always allowed). If the Application Access setting is Ask every time the prompt is very specific and if the user accepts the prompt they will be asked again the next time the MIDlet attempts that operation. If the Application Access setting is Ask first time, the prompt is more general, and if the user accepts the operation, the prompt is not shown until the MIDlet is stopped and restarted. Note that if the Application Access setting is set to Always allowed then there will no security prompts. (for that particular operation)

Figure: Run time security prompt

Changing the setting to Always allowed is generally only possible for trusted third party MIDlets. This is dependent on the security policy of the product.

Note that the actual name of the Application Access sub menu varies on a product to product basis ( App. Permissions or App. Access or Application Access). However this sub menu is found by selecting (highlighting) the MIDlet and selecting Options.

Checking permission status at runtime

Java applications can query status of permissions with the method javax.microedition.midlet.MIDlet.checkPermission(java.lang.String).

For example, querying a permission which belongs to a function group of type User with interaction mode Session returns one of the following values depending on the time of the query:

-1 if user was not prompted yet to allow access to that particular function group
0 if the user was prompted already to allow access to that particular function group but the user denied access
1 if the user was prompted already to allow access to that particular function group and the user allowed access