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 applications to Clients and Security Protection Domains associated to them. The Domain defines the permissions that can be potentially granted to an application.
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.
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 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. The mechanisms the device uses to identify and trust application suites are defined separately to allow them to be selected appropriately to the device, network, and business case. Application suites that are identified as untrusted must execute assigned to a predefined "Untrusted" Client that is assigned to an Untrusted Security Protection Domain. This domain does not grant any access to protected APIs or functions. 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 through signing and verification. Implementations of this mechanism MUST recognize application suites as being signed.
Application suitesThis includes the possibility to handle application suites generally as trusted (e.g. if the platform is only accessible by trusted application providers and authentication is not needed).
Table 6-1 : Definition Of Security Terms |
|
---|---|
Term |
Definition |
Client |
The "originator" of an application suite, 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. |
An application suite that is a) allowed to be installed, and b) for which the authenticity and the integrity of the JAR can be verified by the device, and c) assigned to a Client 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. |
|
An application suite that is a) allowed to be installed, and b) for which the authenticity and the integrity of the JAR cannot be verified by the device and c) 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 as being trusted, otherwise all application suites are a priori trusted. |
|
Authenticates Clients as well as Applications and assigns Applications 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. |
|
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. One possible implementation is policy file based mechanism as known from MIDP 3.0. |
|
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. |
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
Application do not need to be aware of the security policy except for security exceptions that may occur when using APIs.
An application suite is assigned to a single Client and its permissible actions.
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
.
A Security Protection Domain defining a set of Permissions is assigned to a Client. Thias 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 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.
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 part of the MEEP 8 implementation that authenticates Clients as well as Applications 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.
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.
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 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.
Each MIDlet-Permission-<n>
and MIDlet-Permission-Opt-<n>
attribute contains a single Permission request and SHOULD be used over
their MIDlet-Permissions
and
MIDlet-Permissions-Opt
counterparts if the requested
Permission class exists. 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.
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 contain one or more actions
as specified by second argument of the constructor of
Classname
.
For example, in a java.util.PropertyPermission
,
the action read
.
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" |
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:
MIDlet-Permission-Opt-<n>
requested that is not critical to the application suite,
if either the Permission is not granted in the Security Protection
Domain assigned with this Client or the
Permission class cannot be found, then the attribute is ignored.
For each remaining MIDlet-Permission-<n>
, 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 one argument constructor, then
it is an error to supply the Action
field.
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 by itself will not be assigned to any Client independently.
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.
The Permissions granted to an application suite are based on those granted by the Security Protection Domain associated with its Client and the Permissions requested in the application suite. The Permission granted to the application suite are established by the following:
MIDlet-Permission-<n>
,
MIDlet-Permission-Opt-<n>
,
MIDlet-Permissions
, and
MIDlet-Permissions-Opt
attributes.
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, then the attribute is ignored.
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 not, then 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 neither permission implies the other then neither is granted to
the application suite.
MIDlet-Permissions-Opt
attribute, if any of
the requested permissions are unknown to the device, they are
removed from the requested permissions.
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.
MIDlet-Permissions
attribute, if any of
the requested permissions are unknown to the device, then the
application suite MUST NOT be installed or invoked.
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"; } |
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.
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.
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 :
java.security.Permission
optionally followed
by arguments for name and action.
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: Identifier ( ',' Identifier )* ; grant: 'allowed' grant_name permissions; grant_name: '"' Identifier '"'; permissions: '{' permission+ '}'; permission: 'permission' permission_class target_name? target_action? ';'; permission_class: Identifier ( '.' Identifier)*; target_name: '"' ( .~('"')+) '"'; target_action: '"' ( .~('"')+) '"'; start : .+; ALPHA: ('a'..'z'|'A'..'Z'); DIGIT: '0'..'9'; SYMBOL : ('*' | ':' | '/' ); Identifier: ALPHA (ALPHA | DIGIT)*; WS: (' '|'\t'|'\n'|'\r')+ ; |
A brief example below illustrates the format. Refer to Appendix B for security policy examples using this format.
client Sample1; grant allowed { permission java.util.PropertyPermission “java.version”; } grant allowed { permission javax.microedition.io.HttpProtocolPermission “http://*”; } |
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).
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.
Black-listing a Client has to include the following steps:
Black-listing an Application has to include the following steps:
Remark: Other applications assigned to the same Client and the Client itself are not affected by black-listing a single application!
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.