This chapter sketches the cornerstones of a Security Policy architecture.
All code running under MEEP 8 must be verified upon loading, execute in the Java VM sandbox and must be verified to be authorized before granting access to restricted APIs and resources. This verification is done by permission checks, and the Security Policy Provider is the part of the MEEP 8 implementation providing the policy being the basis for those checks.
All implementations of a Security Policy Provider MUST follow the security framework specified in Security for Applications. The details depend very much on the chosen Authentication Provider. This chapter describes general rules for the implementation of a Security Policy Provider.
One possibility to implement a Security Policy Provider is the mechanism defined in MIDP 3.0, where an application suite is bound to security protection domains based on its signature (and therefore on the client) and then the appropriate permission set for an application is determined. This is the default Security Policy Provider in MEEP 8, and it MUST be supported, if the implementation does not provide an individual one. Details can be found in this chapter. This mechanism expects the default Authentication Provider of MEEP 8 as is defined here or another certificate based authentication provider.
Implementation are free to use the default Security Policy Provider or to provide an individual one. There must be only one Security Policy Provider at any given time though and the implementation of this provider must remain unchanged throughout the runtime of the system. A string describing the current Security Policy Provider can be retrieved as the value of the microedition.security.policy system property as defined in the system properties chapter .
Security for Applications defines the framework for authenticating the source of an application suite and authorizing an application 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, it specifies the common rules for APIs that can be used together with this specification but are defined in other specifications. This chapter defines extensions to the base application suite security framework in the following areas:
A Client is associated with a Security Protection Domain that defines a policy with a set of permissions that can be granted to an application. The representation of a Security Protection Domain and its security policy is implementation specific. If among the required permissions are those not known to the implementation though, the Security Protection Domain MUST NOT be installed. A concept of unresolved permissions is not supported in MEEP 8, nor is the Security Policy Provider allowed to silently ignore unknown permissions.
An application suite MUST be assigned to one and only one Client. How an application suite is assigned to a Client depends on the Security Authentication Provider used by this implementation. Application suites that cannot be authenticated as per the Security Framework MUST be assigned to a predefined "Untrusted" Client.
If application suites can be identified via more than one way, it depends on the definition of the Security Authentication Provider, which Client the application suite is assigned to.
Each LIBlet that is a dependency of an application is assigned to the Client of the application and is also authenticated by the authentication mechanism of the application. The set of Clients used during provisioning (if supported) to determine which LIBlets may be bound as a Service then. See the provisioning step for resolving service dependencies.
Applications assigned to the "Untrusted" Client run in an unprivileged environment with a policy refusing access to any sensitive APIs and features. In contrast to this, applications assigned to an authorized and trusted Client run in a privileged environment. However, the privileges given to an application might still depend on the specific policy defined in the Security Protection Domain assigned to the Client the application is assigned to.
Potential consequences of a change of the smart card are described in Application Download and Execution While Roaming and After Changing the Smart Card.
Application suites that cannot be authenticated will be assigned to a virtual "Untrusted" Client.
This "Untrusted" Client for untrusted application suites MUST allow access to the following packages (if available):
Table 8-1 : Packages Allowed for the "Untrusted" Client |
|
---|---|
API (if supported by the implementation) |
Description |
|
RMS APIs |
|
Application Lifecycle APIs |
|
Audio Media APIs (only playing) |
Everything not mentioned in the table above SHOULD NOT be available for untrusted applications in order to avoid damage to be caused by malicious applications.
The security policy and permissions applied to all application suites that are installed on a device MUST conform to the requirements listed in this section, whether those application suites were preloaded or preinstalled or subsequently provisioned after device manufacture.
The high level functions essentially capture and reflect the actions and consequences of the underlying individual permissions. These so-called function groups are as follows:
Whenever new features are added 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 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 adequately a new function group MUST be defined in this document by requesting an update to this document from MSA or this specification as appropriate.
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. The new function group SHOULD be sufficiently future-proof to contain new features added by future APIs and should not only concern the features being initially included in it.
Table 8-4 presents individual permissions and maps them to the function groups specified in this section. An individual permission MUST occur in only one function group.
Table 8-4 : Mapping Permissions to Function Groups |
||
---|---|---|
Permission |
Protocol |
Function group |
javax.microedition.io. |
http |
Net Access |
javax.microedition.io. |
https |
Net Access |
javax.microedition.io. |
datagram |
Low Level Net Access |
javax.microedition.io. |
datagram server (without host) |
Low Level Net Access |
javax.microedition.io. |
socket |
Low Level Net Access |
javax.microedition.io. |
server socket (without host) |
Low Level Net Access |
javax.microedition.io. |
ssl |
Low Level Net Access |
javax.microedition.io. |
comm |
Local Connectivity |
javax.microedition.io.PushRegistryPermission("*", "static,dynamic,alarm"). |
All |
Application Auto Invocation |
imc |
Local Connectivity |
Table 8-5 collects permissions that are not mapped to any function group and sets access level for Clients. Permissions indicated as Permitted are granted to application suites as shown in the Table. Permissions indicated as Not Permitted are those that MUST NOT be mapped to any function group, and MUST NOT be available if not explicitly permitted by the policy defined in the Security Protection Domain associated with the Client.
Table 8-5 : Permissions Not Mapped To Function Groups |
||
---|---|---|
Permission |
Assigned to a trusted Client |
Assigned to the "Untrusted" Client |
java.util.PropertyPermission |
Permitted |
Not Permitted |
java.util.PropertyPermission |
Permitted |
Not Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
javax.microedition.event.EventPermission |
Permitted | Permitted |
javax.microedition.event.EventPermission |
Permitted | Permitted |
javax.microedition.event.EventPermission |
Permitted | Not Permitted |
javax.microedition.event.EventPermission |
Permitted | Not Permitted |
javax.microedition.io.HttpProtocolPermission("http://localhost"); |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.cellular.CellularPermission |
Permitted | Not Permitted |
javax.microedition.cellular.CellularPermission |
Permitted | Not Permitted |
Permitted | Not Permitted | |
javax.microedition.power.PowerStatePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission("*"). See java.lang.Thread.checkAccess(). Defined in [CLDC]. |
Not Permitted | Not Permitted |
Not Permitted | Not Permitted |
The PushRegistry is the primary Auto Invocation mechanism subject to the security policy.
The PushRegistry
is protected using the security framework
and permissions. The application suite must have the
javax.microedition.io.PushRegistryPermission
to register
an alarm based launch, to register dynamically using the
PushRegistry
, or to make a static registration in the
application descriptor.
The push mechanism uses protocols in which the device is acting as the server and connections can be accepted from other elements of the network. To use the push mechanisms the application suite will need the permission to use the server connection in addition to the {@code PushRegistryPermission}. For example, to register a program that can be started via push might use the following attributes in the manifest:
MIDlet-Push-1: socket://:79, com.oracle.example.Sample, * MIDlet-Permissions-1: javax.microedition.io.PushRegistryPermission "socket:" "static,dynamic" MIDlet-Permissions-2: javax.microedition.io.SocketProtocolPermission "socket://" |
When permission is granted to a function group, this action
effectively grants access to all individual permissions that have
been requested under this function group. An implementation MUST
guarantee that a SecurityException
is thrown when
the caller has not been granted the appropriate security permissions.
If an application uses the capabilities defined in this and other APIs,
the following rules MUST apply:
All the external API functions that need to be protected by the security framework MUST have permissions defined in those JSRs, and follow the naming rules identified in this specification.
The functions that are not deemed security-protected by specification can be accessed explicitly by untrusted application suites, as per general security rules.
If an external API does not define permissions for security-protected functions because the API specification is released earlier than IMP-NG, access is granted even to any functions that relate to network access.
All Licensee Open Classes (aka LOC, aka OEM Specific Classes, proprietary packages that do not logically fall into the category of a Java ME configuration, profile, or optional package) MUST adhere to the permission framework as defined in this document.
The permissions needed to deploy the [JSR 135] APIs are defined in the Multimedia Security Addendum to JSR 135 Mobile Media API, version 1.2 of [JSR 135].
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 and HTTPS.
All previously authorized and installed application suites MUST act in accordance with the policy defined in the Security Protection Domain associated with this Client when the device is roaming, or when the device smart card is changed.
Newly downloaded application suites are authenticated to a Client currently available either on the device or at the specified location on the smart card (for example, SIM, USIM or WIM) and are authorized in accordance with the security policy.
If device roaming or a smart card change causes a failure to access network resources that the application was previously authorized to access, then the implementation MUST NOT throw a SecurityException. This failure is not related to application suite authorization, so the implementation MUST throw an IOException instead.
If an application suite cannot be executed due to a smart card
change, the implementation MUST NOT delete the application suite. In case
of a trial to execute the application suite without a successful
authentication, a SecurityException
MUST be thrown.