Security for Applications

Introduction

Security for applications builds on a Client-based trust model that is a generalization of the domain based trust model introduced in IMP-NG, and adopts the class based permissions from the rest of the Java platform. The Client model is used to assign application suites and LIBlets to Clients and Security Protection Domains associated to them. The Domain defines the permissions that can be potentially granted to an application and the LIBlets used by it.

The Permission classes used in the other Java™ Platform Editions are leveraged to provide extensible Permissions, for example to be able to provide access to a single property, resource or function. In contrast, former permission models provided only boolean permissions. Refer to the backward compatibility section for IMP-NG Security.

The use of Permission classes allows the APIs in this specification and in separate optional package specifications to have a single consistent Permission definition on all configurations and profiles. Currently, optional packages that must be defined for CLDC, or CDC and Java SE must have different permission definitions depending on the configuration they are used with. The unification of Permissions simplifies specification, implementation, developer use and conformance testing.

Sensitive APIs and functions use permissions to restrict access. Each API defines the Permissions needed to allow access to the API. Any API or function of this specification which is not security sensitive, having no permissions defined for them, are implicitly accessible by all application suites.

Application Suite Trust Model

Security for application suites is based on Clients. Each Client has an associated Security Protection Domain defining the permissions that may be granted to an application suite that is assigned to this Client. The Security Authentication Provider specifies how the device identifies and verifies that it can trust an application suite or LIBlet and assign it to the Client.

An application suite is assigned to a Client during installation and MUST remain bound to the same Client until it is deleted.

A LIBlet is assigned to one or more than one Client as well during installation:

In case the LIBlet is installed during the installation of an application suite, because the installation suite (or one of the LIBlets it depends on) has declared a dependeny from this LIBlet using a dependency attribute, the authentication provider MUST check if the Client the LIBlet is about to be bound to is identical to the Client the application suite is bound to, or if the Client the application suite is bound to is among the the Clients the LIBlet is about to become bound to. If this check fails, the LIBlet MUST NOT be installed, and the installation of the application suite MUST fail as well.
In case the LIBlet is explicitly installed, it is bound to a Client or to more than one Client during installation. If an application suite is installed later, and the installation suite (or one of the LIBlets it depends on) has declared a dependeny from the prviously explicitly installed LIBlet using a dependency attribute, the authentication provider MUST check if the Client, the explicitly installed LIBlet is bound to, is identical to the Client the application suite is about to become bound to, or if the Client the application suite is about to become bound to is among the Clients the explicitly installed LIBlet is bound to. If this check fails, the installation of the application suite MUST fail. An exception of this rule has to be considered, if the explicitly installed LIBlet is bound to the privileged "Root" or "root" Client. In this case, the authentication provider MUST allow installation of the application suite (if itself has been successfully authenticated), not dependent on to which Client it is bound. With other words, an explicitly installed LIBlet that is bound to the privileged "Root" or "root" Client, is handled as if it were bound to any Client.

As a consequence, if application suites assigned to different Clients want to share a LIBlet, this LIBlet has to be assigned to all Clients any of the application suites is assigned to, respectively, or to the privileged "Root" or "root" Client.

The mechanisms the device uses to identify and trust application suites and LIBlets are defined separately to allow them to be selected appropriately to the device, network, and business case. Application suites and LIBlets that are identified as untrusted must execute assigned to a predefined "Untrusted" Client that is assigned to an Untrusted Security Protection Domain. This domain describes a restricted environment with limited access to protected APIs or functions. How restricted this access is, including the possibility of no access to any protected APIs or functions, has to be determined by the Authentication Provider. There is some basic functionality though defined as unprotected. Access to this functionality MUST be generally granted for the Untrusted Client. For details, see here. The Security Policy Chapter defines one model of a policy for Clients. Implementations are free to use other policy models being defined outside this specification. Implementations are also free to configure the provider of the policy and the mechanism of the provision of policies. This is out of scope of this specification as well.

Application Suites Trust Model Using X.509 PKI describes one possible mechanism for identifying trusted application suites and LIBlets through signing and verification. Implementations of this mechanism MUST recognize application suites and LIBlets as being signed.

Application suites and LIBlets

MAY be signed using PKI as trusted application suites or LIBlets, respectively, and if this is the case, they MUST be verified according to the formats and processes specified in Application Suites Trust Model Using X.509 PKI.
MAY be identified as trusted application suites or LIBlets, respectively by other mechanisms. Implementations of MEEP 8 MAY define such as authentication via a back-end mechanism or via a mutually trusted network connection. The definition of those mechanisms is out of scope of this specification though.
This includes the possibility to handle application suites and LIBlets generally as trusted (e.g. if the platform is only accessible by trusted application and LIBlet providers and authentication is not needed).

Table 6-1 : Definition Of Security Terms
Term	Definition
Client	The "originator" of an application suite or LIBlet, being associated with a Security Protection Domain that defines which permissions may be granted to an application suite if it requires them. The association between Client and security protection domain cannot be changed.
Permission	A Permission class defined for an API or function to prevent it from being used without authorization
Function group	A collection of Permissions protecting similar resources or functions. Primarily used for optimizing user experience.
Trusted Application Suite or LIBlet	An application suite or LIBlet that is a) allowed to be installed, and b) for which the authenticity and the integrity of the JAR can be verified by the Authentication Provider, and c) that is assigned to a Client (or several Clients in case of a LIBlet) not being the predefined "Untrusted" Client untrusted application suites are assigned to. Implementations can decide that all application suites are trusted, or can recognize application suites as being signed using PKI as specified in Application Suites Trust Model Using X.509 PKI, or it can recognize trusted application suites by other mechanisms, defined outside the scope of this specification.
Untrusted Application Suite or LIBlet	An application suite or LIBlet that is a) allowed to be installed, and b) for which the authenticity and the integrity of the JAR cannot be verified by the Authentication Provider and c) that is assigned to the pre-defined "Untrusted" Client that is assigned to a Security Protection Domain not granting access to any sensitive APIs and functionalities to applications. This applies only if the implementation requires an authentication and verification of JARs in order to recognize an application suite or LIBlet as being trusted, otherwise all application suites and LIBlets are a priori trusted.
Authentication Provider	Authenticates Clients as well as Application Suites and LIBlets and assigns Application Suites and LIBlets to Clients based on a mechanism being configurable at the time of system level configuration. One possible implementation is the PKI x.509 certificate based authentication as known from MIDP 3.0.
Security Policy Provider	Determines the per-application Permission set of an Application by determining the protection domain an application is bound to (identified by the Client the Application Suite is assigned to) and then intersecting the permissions requested by the application and the LIBlets used by it. One possible implementation is policy file based mechanism as known from MIDP 3.0.
Blacklisting	The possibility to prevent access to sensitive functionality for a particular Application or all applications assigned to a particular Client by removing the privileged Permissions of this application(s). This includes the immediate termination of the affected application, or of all applications assigned to the affected Client, respectively. This can happen using CRL or OCSP, but also using implementation-defined mechanisms such as "push" blacklisting.

Authorization Model

The basic authorization of an application suite is established by the relationships between the following elements:

The Client associated with a Security Protection Domain that defines a set of permissions that MAY be granted to the application suite if they are required by it.
A set of Permissions requested by the application suite in MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, MIDlet-Permissions, and MIDlet-Permissions-Opt attributes

Assumptions

Application do not need to be aware of the security policy except for security exceptions that may occur when using APIs.
An application suite or LIBlet is assigned to a single Client and its permissible actions. LIBlets may be assigned to more than one Client but while used by a particular application, they behave as if they would be assigned only to the Client the application is assigned to.
The internal representation of permissions granted for the Client may be implementation specific.
The details of how authentication results and configuration settings are presented to the user in a user interface (if any) are implementation dependent and are outside the scope of this specification.
The device must protect the security policy and Client assignment information stored in the device from modification except by authorized parties.
Security policy allows an implementation to restrict access but MUST NOT be used to avoid implementing functionality. For example, unimplemented protocols under the Generic Connection framework MUST throw ConnectionNotFoundException.

Clients

A Security Protection Domain defining a set of Permissions is assigned to a Client. This assignment cannot be changed. Those permissions explicitly allow access to a given protected API or function for an application suite being associated with this Client. In the MEEP 8 profile user interactions MUST NOT be required by the implementation. If the application developer wants to require user confirmations (in case an appropriate user interface is available), he has to code this individually.

Permissions

Permissions are the means to protect access to a single property, resource or function which require explicit authorization before being executed. Whenever such protection is needed, each API must define the Permission classes and parameters of each protected function. Permissions are subclassed from java.security.Permission. Each API may define new Permission subclasses or may use existing Permission classes such as java.security.BasicPermission. New Permission classes should be defined in the package they protect. Permission checks are performed by calling java.security.AccessController.checkPermission. Permissions MUST be checked by the implementation during the execution of the protected function. By calling java.security.AccessController.checkPermission an application is able to check if a certain permission is allowed by the security policy or not.

Permissions for APIs use and extend the Permission classes defined in the underlying configuration CLDC 8. Applications check if a Permission is allowed by the security policy using the checkPermission method of java.security.AccessController. When a Permission is not granted the java.security.AccessControlException, a subclass of java.lang.SecurityException, is thrown.

For more detail please refer to the CLDC 8 specification.

Recommendation for Permissions for Optional Packages

Each API in this specification that provides access to a protected function defines the needed Permissions. For APIs defined outside this specification, there must be a single document that specifies the permissions and the behavior of the API when it is implemented with this specification. New API specifications and maintenance releases of existing APIs targeted at CLDC 8 configuration MUST define the permissions and require those permissions to be used if the underlying configuration includes the java.security.Permission class. To work with existing versions of APIs that have not yet defined Permission classes however, simultaneous use of both named permissions and Permission classes is allowed. The use of named permissions is deprecated though.

Authentication Provider

The part of the MEEP 8 implementation that authenticates Clients as well as Application Suites and LIBlets in order to determine whether they come from a trusted source or not is called an Authentication Provider. The Authentication Providers chapter of this specification defines general rules about how an authentication provider works and which requirements it has to fulfill.

The Application Suites Trust Model Using X.509 PKI chapter of this specification describes one possible implementation of an Authentication Provider as it is known from MIDP 3.0.

Security Policy Provider

The part of the MEEP 8 implementation that determines the per-application permission set of an application by determining the protection domain an application is bound to (identified by the Client the application is assigned to) and then intersecting the permissions requested by the application, is called an Security Policy Provider. The Security Policy Providers chapter of this specification defines general rules about how an security policy provider works and which requirements it has to fulfill.

The Security Policy File Model chapter of this specification describes one possible implementation of an Security Policy Provider as it is known from MIDP 3.0.

Requesting Permissions for an Application Suite

All application suites that require access to protected APIs or functions MUST request the corresponding Permissions with the MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, MIDlet-Permissions, and MIDlet-Permissions-Opt attributes:

Permissions requested using zero or more MIDlet-Permission-<n> and MIDlet-Permissions attributes are critical to the function of the application suite and it will not operate correctly without them. In some cases, it is not possible to request permissions for specific resource names in the attributes; for example, the file paths corresponding the application suite's private data may not be known. In other cases, the policy defined in the Security Protection Domain assigned to this Client may vary from device to device and access to a particular resource may not be consistently allowed; for example, access to the property containing the device or user identification. In these cases, the application must defer until runtime the identification of the resource and be prepared to handle its absence or the lack of access due to device policy.
If the application suite can function correctly without access to the resources requested by the Permission(s), it should request them using the MIDlet-Permission-Opt-<n> and MIDlet-Permissions-Opt attributes. The application suite is granted only as much access as allowed by the policy of the Security Protection Domain assigned to its Client, which will in some cases be less than was requested. The application suite must be able to operate correctly without access to the resources requested in the permissions. All requested permissions are checked against the policy as specified in Granting Permissions to Application Suites.

Each MIDlet-Permissions and MIDlet-Permissions-Opt attribute contains a list of one or more IMP-NG named permissions. Multiple permissions are separated by a comma (Unicode U+002C). Leading and trailing whitespace (Unicode U+0020) and tabs (Unicode U+0099) are ignored.

IMP-NG named permissions are recommended to be mapped to permissions based on java.security.Permission as described in Permissions. For permissions defined in IMP-NG, each named permission can be mapped to a Permission as described below in Named Permissions to Class Permission Mapping. This is recommended as named permission are deprecated. As other JSRs may have not changed their permission model to Permission classes yet, the mapping is not mandatory though. The default Security Policy Provider as described here MUST accept both, Permission classes and the (deprecated) named permissions.

Each MIDlet-Permission-<n> and MIDlet-Permission-Opt-<n> attribute contains a single Permission request. The lowest value of <n> MUST be 1 and consecutive ordinals MUST be used. The first missing attribute terminates the list. Any additional attributes MUST be ignored. The value of the attribute has the following fields separated by whitespace:

Classname – the fully qualified name of a subclass of java.security.Permission. The Classname is required. For example, javax.microedition.io.HttpProtocolPermission.
Name – the name of the protected resource. The Name is required if the Classname constructor requires one or more arguments. The name field must be either null or requires surrounding double-quotes, and no double quote is allowed as part of the name field. For example, "http://server/index.html".
Action – the action(s) requested. The Action field is required if the Classname constructor requires two or more arguments. The Action value must be either null or a list containing zero or more actions as specified by second argument of the constructor of Classname. In case it is a list, the action field requires surrounding double-quotes, and no double quote is allowed as part of the action field. The individual actions are delimited by commas. All white spaces will be ignored in the action string, so that " read, write " is parsed with the same result as "read,write". For example, in a java.util.PropertyPermission, the action "read".

Some examples of class-based Application Permissions are :


    MIDlet-Permission-1: javax.microedition.io.HttpProtocolPermission "http://*:*"
    MIDlet-Permission-2: javax.microedition.io.SocketProtocolPermission "socket://:4321"
    MIDlet-Permission-Opt-1: java.lang.PropertyPermission "*" "read"
    MIDlet-Permissions: javax.microedition.io.Connector.sms,
                        javax.microedition.io.Connector.cbs

MEEP class based permissions must be requested via MIDlet-Permission-<n> and MIDlet-Permission-Opt-<n> attributes. Named permissions must be requested via MIDlet-Permissions and MIDlet-Permissions-Opt attribute ONLY. A mix of both styles of attributes is allowed, and all requests have the same priority. It is up to application developer to avoid contradictory requests.

LIBlet Permissions

LIBlets MUST declare their required access to protected APIs or functions by requesting the corresponding permissions. Critical permissions are declared using zero or more LIBlet-Permission-<n> and LIBlet-Permissions attributes. Non-critical permissions are declared using zero or more LIBlet-Permission-Opt-<n> and LIBlet-Permissions-Opt attributes. Each LIBlet-Permission-<n> and LIBlet-Permission-Opt-<n> attribute contains a single permission request and SHOULD be used over their LIBlet-Permissions and LIBlet-Permissions-Opt counterparts if the requested Permissions class exists. For the value of the attribute, see Requesting Permissions for an Application suite.

The LIBlet can be granted the same permissions (if required) as the application it is bound to. The LIBlet-Permission-<n> and LIBlet-Permission-Opt-<n> attributes MUST NOT be treated as a permission request to the AMS. It is the application that makes the permission requests using MIDlet-Permission-<n> and MIDlet-Permission-Opt-<n> attributes.

LIBlet-Permission-<n>, LIBlet-Permission-Opt-<n>, LIBlet-Permissions and LIBlet-Permissions-Opt attributes are used for declarative purpose; that is, an application suite developer can instantly see which protected APIs or functions a given LIBlet needs to access. Since a LIBlet itself is able to depend on other LIBlets, it is crucial that all permissions requested in the application dependency chain are listed under MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, LIBlet-Permissions and LIBlet-Permissions-Opt attributes. Only permissions requested in an application suite will be validated at installation time. Permissions requested in MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, LIBlet-Permissions and LIBlet-Permissions-Opt attributes are the union of Permissions required by application suite and all LIBlets in the dependency declaration chain. If any LIBlet-Permission-<n>, LIBlet-Permission-Opt-<n>, LIBlet-Permissions, or LIBlet-Permissions-Opt permissions requested by a LIBlet are not also requested by dependent application suite, then a runtime security exception may occur.

Named Permission to Class Permission Mapping

The Configuration ([CLDC] defines the Permission classes that allow access to networking protocols in the Generic Connection Framework.

Table 9-1 : Named Permission to Class Permission Mapping
Named Permission	Permission
javax.microedition.io.Connector.socket	javax.microedition.io. SocketProtocolPermission(“socket://:”)
javax.microedition.io.Connector.serversocket	javax.microedition.io. SocketProtocolPermission(“socket://:*”)
javax.microedition.io.Connector.http	javax.microedition.io. HttpProtocolPermission(“http://:”)
javax.microedition.io.Connector.https	javax.microedition.io. HttpsProtocolPermission(“https://:”)
javax.microedition.io.Connector.ssl	javax.microedition.io. SSLProtocolPermission(“ssl://:”) javax.microedition.io. SSLProtocolPermission(“ssl://:*”)
javax.microedition.io.Connector.datagram	javax.microedition.io. DatagramProtocolPermission(“datagram://:”)
javax.microedition.io.Connector.datagramreceiver	javax.microedition.io. DatagramProtocolPermission(“datagram://:*”)
javax.microedition.io.Connector.comm	javax.microedition.io. CommProtocolPermission(“comm:*”)
javax.microedition.io.PushRegistry	javax.microedition.io. PushRegistryPermission (“*”, “static,dynamic,alarm”)

Example Mapping Named Permissions to Class Permissions

For example, if the application attributes for an IMP-NG application suite included the following :


    MicroEdition-Configuration: CLDC-1.8
    MicroEdition-Profile: MEEP-8.0
    MIDlet-Permissions: javax.microedition.io.Connector.http,
                        javax.microedition.io.Connector.https

The security mechanisms and policy are evaluated as specified in Granting Permissions to Application Suites using the equivalent permissions as if the application attributes were :


    MicroEdition-Configuration: CLDC-1.8
    MicroEdition-Profile: MEEP-8.0
    MIDlet-Permission-1: javax.microedition.io.HttpProtocolPermission "http://*:*"
    MIDlet-Permission-2: javax.microedition.io.HttpsProtocolPermission "https://*:*"

Recommendation for Permissions for Optional Packages

Each API that provides access to a protected function defines the needed Permissions. For APIs defined outside of this specification there must be a single document that specifies the permissions and the behavior of the API when it is implemented on IMP-NG. Optional package specifications must also specify the mapping from IMP-NG named permissions to the corresponding Permissions.

Authorization of Application Suites to be Installed

If the MEEP implementation supports Provisioning, and an applications suite has been provisioned and is now about to be installed, it has to be authorized and in parallel permissions are granted to this application suite. The authorization process is determined by the following:

During installation the application suite MUST have been assigned to a Client and remains bound to the same Client until it is deleted.
During installation the requested Permissions are identified from the MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, MIDlet-Permissions, and MIDlet-Permissions-Opt attributes.

Authorization of application suites uses Client related information and critical and non-critical Permissions requested in the application suite. Verification of requested Permissions results in failed installation of an application suite and the Status Code 910 (Application authorization failure) returned in the status report if any of the following errors occur:

For each MIDlet-Permission-<n> ("Critical Permission"), if a constructor with the appropriate number of arguments cannot be found or is inaccessible or the arguments supplied would fail the static requirements of the constructor, then the installation MUST fail.
If the Permission class has only a zero argument constructor, then it is an error to supply the Name field, the installation MUST fails as well.
If the Permission class has only a one argument constructor, then it is an error to supply the Action field, the installation MUST fails as well.
If any of the requested critical Permissions are not granted in the Security Protection Domain of this Client then the application suite does not have sufficient authorization and the installation MUST fail.
If any of the requested critical permissions are unknown to the device, then the application suite MUST NOT be installed.

If one of the situations described above are applicable to a non-critical Permissions (MIDlet-Permission-Opt-<n>) though, then the application suite MUST be installed unless there are other errors.

Authorization of Pre-Installed Application Suites

Pre-installed application suites cannot be authorized at installation time. For MEEP implementations that do not support Provisioning, all applications suites are pre-installed. But also in MEEP installations with Provisioning support, the manufacturer can pre-install single application suites.

As there is no installation process for those application suites, authorization has to take place before application is started the first time, otherwise the AMS MUST NOT attempt to invoke any application of the application suite. The point in time, when the authorization is performed for those application suites, is implementation dependent. The authorization process is determined by the following:

During authorization the application suite MUST have been assigned to a Client and remains bound to the same Client until it is deleted.
During authorization the requested Permissions are identified from the MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, MIDlet-Permissions, and MIDlet-Permissions-Opt attributes.

Authorization of application suites uses Client related information and critical and non-critical Permissions requested in the application suite. Verification of requested Permissions of a pre-installed application suite results in failed invocation if any of the following errors occur:

For each MIDlet-Permission-<n> ("Critical Permission"), if a constructor with the appropriate number of arguments cannot be found or is inaccessible or the arguments supplied would fail the static requirements of the constructor, then the AMS MUST NOT attempt to invoke any application of the application suite.
If the Permission class has only a zero argument constructor, then it is an error to supply the Name field, the AMS MUST NOT attempt to invoke any application of the application suite.
If the Permission class has only a one argument constructor, then it is an error to supply the Action field, the AMS MUST NOT attempt to invoke any application of the application suite.
If any of the requested critical Permissions are not granted in the Security Protection Domain of this Client then the application suite does not have sufficient authorization and the AMS MUST NOT attempt to invoke any application of the application suite.
If any of the requested critical permissions are unknown to the device, then the AMS MUST NOT attempt to invoke any application of the application suite.

If one of the situations described above are applicable to a non-critical Permissions (MIDlet-Permission-Opt-<n>) though, then the applications of the suite MUST be invoked unless there are other errors.

Granting Permissions to Application Suites

The Permissions granted to an application suite during authorization are based on those granted by the Security Protection Domain associated with its Client and the Permissions requested in the application suite. The Permissions granted to the application suite are established by the following:

For each Permission requested using MIDlet-Permission-Opt-<n> attributes, if either
- the Permission is not among those granted in the Security Protection Domain associated with this Client,
- or the Permission class cannot be found,
- or a constructor with the appropriate number of arguments cannot be found for this Permission class, or is inaccessible, or the arguments supplied would fail the static requirements of the constructor
then firstly no permission is granted to the application suite.
Then each permission granted in the Security Protection Domain associated with this Client with the same permission class is compared with the requested permission to select the least privileged permission.
- If the requested permission is implied by the ones granted in the Security Protection Domain associated with this Client then the requested permission is granted to the application suite.
- If the permission granted in the Security Protection Domain associated with this Client is implied by the requested permission then the permission granted in the Security Protection Domain associated with this Client is granted to the application suite.
- If the requested permission and the permission granted in the Security Protection Domain associated with this Client do intersect, then the permission granted to the application suite is this intersection of the permissions.
If none of the above applies, then no permission is granted to the application suite.
For each MIDlet-Permissions-Opt attribute, if any of the requested permissions are unknown to the device, they are removed from the requested permissions.
For each Permission requested using MIDlet-Permission-<n> attributes, the Permission.implies methods are used to check that some Permission granted in the Security Protection Domain associated with this Client "implies" each requested permission. Each requested permission that is implied by the policy defined in the Security Protection Domain associated with this Client is granted to the application suite.
The permissions granted to the application suite are the intersection of the requested permissions with the allowed permissions.
During execution, every protected API or function MUST check that the appropriate Permission is implied by some Permission granted to the application suite. This is necessary because in the time between authorization (at installation time for provisioned application suite, or at an implementation-dependent point of time before first invocation for pre-installed application suites), the granted permissions may have changed, e.g. as a consequence of black-listing.

Example of Granting Permissions to Application Suites

An example illustrates the steps used to determine the permissions granted to an application suite. It focuses on the permissions that are available to the application.

For these examples the policy defined in the Security Protection Domain associated with this Client contains permissions:


    grant allowed "NetAccess" {
        permission javax.microedition.io.HttpProtocolPermission "http://*";
    }
    grant allowed "PhoneCall" {
        permission CallPermission "tel://*";
    }
    grant allowed "PrivateFiles" {
        permission javax.io.FilePermission "file:///User1/Home" "read,write";
    }
    grant allowed "WriteLog" {
        permission java.util.PropertyPermission "Logfile" "read,write"
        permission java.util.PropertyPermission "microedition.*" "read";
    }

Permission Example Using Required and Optional Permissions

In the first example, the application suite requires access to the network and to a property and makes optional requests to read all properties and access all files:


    MIDlet-Permission-1: javax.microedition.io.HttpProtocolPermission "http://myhost.com"
    MIDlet-Permission-2: java.util.PropertyPermission "Logfile" "write"
    MIDlet-Permission-Opt-1: java.util.PropertyPermission "*" "read"
    MIDlet-Permission-Opt-2: javax.io.FilePermission "file:///*" "read,write"

When the application suite is executed the resulting set of permissions granted is in conformance with the verification steps described in section Granting permissions to Application Suites". The permissions granted are:


    grant allowed "NetAccess" {
        permission javax.microedition.io.HttpProtocolPermission "http://myhost.com";
    }
    grant allowed "PrivateFiles" {
        permission javax.io.FilePermission "file:///User1/Home" "read,write";
    }
    grant allowed "WriteLog" {
        permission java.util.PropertyPermission "Logfile" "write"
        permission java.util.PropertyPermission "microedition.*" "read";
    }

In this first example, the java.io.FilePermission requests access to all possible files but because it is requested in the MIDlet-Permission-Opt-2 attribute the access granted is the narrower of the request and the policy defined in the Security Protection Domain associated with this Client. The CallPermission granted in the Security Protection Domain associated with this Client is not granted to the application suite, because it did not request it. The javax.microedition.io.HttpProtocolPermission is granted only to the requested host even though the policy defined in the Security Protection Domain associated with this Client allows access to any host. The java.util.PropertyPermission to write the "Logfile" property is granted because it is requested and is allowed by one of the java.util.PropertyPermissions in the policy defined in the Security Protection Domain associated with this Client. The application suite is granted access to the "microedition.*" properties since it was requested in the MIDlet-Permission-Opt-1 attribute, but only for the narrower of the requested permission and the permission policy defined in the Security Protection Domain associated with this Client.

Permission Example Using Only Required Permissions

In the second example, the application suite requires all permissions to operate correctly and uses only the MIDlet-Permission-<n> attributes.


    MIDlet-Permission-1: java.util.PropertyPermission "*" "read"
    MIDlet-Permission-2: javax.io.FilePermission "file:///*" "read,write"

In this second example, the installation fails because permissions are denied. The java.io.FilePermission requires access to all possible files. But because the policy permission in the Security Protection Domain associated with this Client is narrower, access must be denied. The java.util.PropertyPermission requires access to all properties. But because the policy permission granted in the Security Protection Domain associated with this Client is narrower access must be denied.

External Client Policy Format

An external representation for Client's policies allows clear communication between several Clients that may have certain roles like manufacturer, operator, etc. Implementations MAY use the external policy format to configure security policy and MAY support other policy representations. Provisioning of security policy is outside the scope of this specification.

The format includes all aspects of a policy including the Client's name, optional bindings to Client's Root Certificates (if the binding is certificate based), and permissions grouped when applicable.

The policy format uses the UTF-8 encoding and semantics for granting permissions to eligible applications. A policy consists of a number of “grant” clauses; each clause contains one or more Permissions. The grant clauses define which permissions requested by applications are granted.

The general form of the format is :

The Client described by name optionally followed by the distinguished names of the corresponding Client's Root Certificates following the syntax specified in [RFC2253] (if a certificate based mechanism is used).
The name of the Client must not be "Root" or "root" as this name is reserved for special purpose (see here for details).
One or more grant clauses
Each grant clause MUST include a directive containing a name and permissions that are granted only if the application has requested the permission.
Each grant group includes one or more Permissions. Each regular permission is the name of a subclass of java.security.Permission optionally followed by arguments for name and action. Besides, MEEP 8 also allows named permissions (see the Legacy compatibility chapter for details), although being deprecated.

The following is an ANTLR grammar of the external Client's policy format. For information about ANTLR, see www.antlr.org.


    grammar client_policy;

    client_policy:      client+;
    client:     'client' Identifier root_dn_subjects? ';' grant+;

    root_dn_subjects: bracketed_root_dn_subject ( bracketed_root_dn_subject )*
    bracketed_root_dn_subject: '[' root_dn_subject ']'

    grant: 'grant' 'allowed' grant_name? permissions;

    grant_name: '"' Identifier '"';

    permissions: '{' permission+ '}';

    permission: 'permission' permission_class target_name? target_action? ';';

    permission_class: Identifier ( '.'  Identifier)*;
    target_name: 'null' | '"'  ( .~('"')*) '"';
    target_action: 'null' | '"' ( .~('"')*) '"';

    start       :       .+;

    ALPHA:      ('a'..'z'|'A'..'Z');
    DIGIT:       '0'..'9';
    SYMBOL      :       ('*' | ':' | '/' | '.' );
    Identifier: ALPHA (ALPHA | DIGIT)*;
    WS: (' '|'\t'|'\n'|'\r')+ ;

Syntax of root_dn_subject as specified in [RFC2253].

A brief example below illustrates the format. Refer to Appendix B for security policy examples using this format.


    client Sample1 [CN=Before\0DAfter,O="Test#Test",C=GB] [CN=Steve Kille,O=Isode Limited,C=GB];
    grant allowed {
        permission java.util.PropertyPermission “java.version”;
    }

    grant allowed {
        permission javax.microedition.io.HttpProtocolPermission “http://*”;
    }

Blacklisting

Blacklisting is the possibility to prevent access to sensitive functionality for a particular application or all applications assigned to a particular Client by removing the privileged permissions of this application(s). In case of blacklisting a Client, the removal of privileged permissions of the applications assigned to this Client takes place even if some of those applications are assigned also to other (not blacklisted) Clients at the same time.

This can happen using CRL or OCSP, but also using implementation-defined mechanisms such as a simple "push" blacklisting. It is up to the implementation which mechanism is chosen to realize blacklisting.

Implementations MAY also offer to roll back blacklisting for applications as well as for Clients under certain circumstances. Whether this can be done, under which exact circumstances and which way, is implementation dependent.

Black-listing a Client has to include the following steps:

Immediately terminating execution of all applications assigned to this Client. As this is a security relevant incident, a hard deletion is necessary.
Revoking the Authentication of this Client.
Removing the security policy of all applications assigned to that Client.
Registering this Client and all applications assigned to it as black-listed in order to prevent future access to protected APIs or resources. This takes place also for applications being assigned to other, not blacklisted Clients at the same time.
Preventing all further installations of applications by that Client.
In case provisioning is supported by this implementation, deinstalling all application suites assigned to this Client, if possible. (This may be not always the case, e.g. there may be pre-installed application suites among them.)

Black-listing an Application has to include the following steps:

Immediately terminating execution of any and all running instances of the specified application - not dependent on the Client they are assigned to. As this is a security relevant incident, a hard deletion is necessary.
Removing the security policy (and therefore the authorization) of the specified application's suite.
Registering the specified application as black-listed in order to prevent future access to protected APIs and resources.
In case provisioning is supported by this implementation, deinstalling the specified application's suite, if possible. (This may be not always the case, e.g. a pre-installed application suites may be blacklisted after it has been detected that it is erroneous.)

Remark: Other applications assigned to the same Client and the Client itself are not affected by black-listing a single application!

Combined Usage of Recent and Previous Security Models

As optional JSRs are gradually updated to incorporate the permission model of this specification and provide the appropriate Permission classes, developers may face situations where the JSRs used by the application have not yet provided the appropriate Permission classes. As a transitional mechanism, the simultaneous use of both the IMP-NG permission attributes and MEEP 8 permission attributes is allowed.

The MIDlet-Permission-<n> or MIDlet-Permission-Opt-<n> attributes may appear in the same JAD and JAR Manifest as the MIDlet-Permissions and MIDlet-Permissions-Opt attributes. In such a case, all permissions requested by all MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, MIDlet-Permissions, and MIDlet-Permissions-Opt attributes MUST be verified against the permissions granted in the policy defined in the Security Protection Domain associated with this Client. If the application suite does not have sufficient authorization for any of the critical permissions requested by MIDlet-Permission-<n> and MIDlet-Permissions attributes, the installation MUST fail and return the Status Code 910 (Application authorization failure). For permissions requested via the MIDlet-Permission-Opt-<n> and MIDlet-Permissions-Opt attribute, the application suite will be granted only as much access as is allowed by the policy defined in the Security Protection Domain associated with this Client, which will in some cases be less than was requested.

The LIBlet-Permission-<n> or LIBlet-Permission-Opt-<n> attributes may appear in the same JAD and JAR Manifest as the LIBlet-Permissions and LIBlet-Permissions-Opt attributes. These permission attributes are declarative and MUST NOT be treated as a permission request to the AMS.