Security Policy Providers

Introduction

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 or LIBlet 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 or LIBlet 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:

• The required trust model for devices
• The Client number and structure, as reflected in the device security policy
• Capabilities of applications based on permissions
• Application behavior in the roaming network
• Application behavior when a SIM/USIM is changed

Security Protection Domains

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 a single Client, a LIBlet to one or more Clients. How an application suite or LIBlet is assigned to a Client depends on the Security Authentication Provider used by this implementation. Application suites or LIBlets that cannot be authenticated as per the Security Framework MUST be assigned to a predefined "Untrusted" Client. This is only true if they declare themselves as being untrusted. In case they pretend to be trusted and authentication fails, they MUST NOT be installed at all.

If application suites can be identified via more than one way, they will be assigned to a single Client as well. How it is decided to which Client they will get assigned inthis case, is implementation-dependent. If LIBlets can be identified via more than one way, they will be assigned to all resulting Clients.

Each LIBlet that is a dependency of one or more applications MUST be assigned to each Client any of those applications is assigned to, or to the privileged "Root" or "root" Client, otherwise the installation of the respective application suite will fail. The set of Clients used during provisioning (if supported) is used 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.

The "Untrusted" Client

Application suites and LIBlets that do not try to be authenticated will be assigned to a virtual "Untrusted" Client. As mentioned in the description of the Security Trust Model it is up to the Authentication Provider to determine how restrictive the access to protected APIs or functions is.

The "Untrusted" Client for untrusted application suites and LIBlets MUST generally allow access to the following packages (if available) though:

The Security Policy Provider is free to make more functionality available for untrusted applications or LIBlets, it is in the responsibility of the implementor to estimate and consider the risks caused by that.

The Root Client

The Security Policy Provider is free to define a special Root client. The words "Root" and "root" are handled as reserved names for a client and must not be used by any other client as defined by third party or using explicit means of definition (like in a policy file).

The purpose of the Root Client is that the Authentication Provider can assign application suites or LIBlets (if supported) to it, which opens unlimited permissions for the respective applications and LIBlets. In particular, a LIBlet assigned to the Root client can be used by any application without the need of assigning this LIBlet to the Client the application is assigned, which would be necessary without having assigned the LIBlet to the Root client.

Permissions for Application Suites

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.

Mapping Permissions onto Function Groups for Clients

The high level functions essentially capture and reflect the actions and consequences of the underlying individual permissions. These so-called function groups are used in MEEP 8 only to make permission declarations more comprehensive and open a possibility to group permissions belonging to the same "kind" of activities. The usage of the groups is optional. The following function groups are pre-defined:

• Network/cost-related groups:
  • Phone Call — the group represents permissions to any function that results in a voice call.
  • Call Control — the group represents permissions to any function that results call setup or teardown of a restricted network connection.
  • Net Access — the group represents permissions to any function that results in an active network data connection (for example GSM, GPRS, UMTS, EDGE, WiMax, etc.); such functions MUST be mapped to this group.
  • Low Level Net Access — the group represents permissions to any function that results in an active low level network data connection (for example Sockets, etc.); such functions MUST be mapped to this group.
  • Messaging-Receive — the group represents permissions to any function that allows receiving messages (for example, SMS, MMS, etc.)
  • Messaging-Send — the group represents permissions to any function that allows sending messages (for example, SMS, MMS, etc.)
  • Restricted Messaging - Receive — the group represents permissions to any function that allows receiving messages from a restricted messaging service (for example, Cell Broadcast, etc.)
  • Restricted Messaging - Send — the group represents permissions to any function that allows sending messages to a restricted messaging service
  • Application Auto Invocation — the group represents permissions to any function that allows an application to be invoked automatically (for example, push, timed application, 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.)
  • Authentication — the group represents permissions to any function that gives an application suite access to authentication functionality.
• User-privacy-related groups:
  • Multimedia recording — the group represents permissions to any function that gives an application suite the ability to do any kind of multimedia recording (for example to record audio clips).
  • File System Read — the group represents permissions to any function that gives an application suite the ability to read files or directories in the file system.
  • File System Write — the group represents permissions to any function that gives an application suite the ability to write files or directories in the file system.
  • PIM Read — the group represents permissions to any function that gives an application suite the ability to read phone books, calendars or any other personal databases accessible using the PIM API.
  • PIM Write — the group represents permissions to any function that gives an application suite the ability to add or modify items in phone books, calendars or any other personal databases accessible using the PIM API.
  • Smart Card Communication — the group represents permissions to any function that gives an application suite the ability to communicate with the smart card.
  • Location — the group represents permissions to any function that gives an application suite access to Location information.
  • Landmark — the group represents permissions to any function that gives an application suite access to Landmark information.
  • Private Sensor Access — the group represents permission to any function that gives an application suite access to data from private sensors. An example of a private sensor could be a heart rate monitor sensor.
  • Mobile Broadcast Service — the group represents permission to any function that gives access to mobile broadcast services. This may include reading and modifying broadcast service and tuner related data, managing recordings and obtaining information about purchased subscriptions and other information about viewing habits.
• Resource protection-related groups:
  • NFC Write Access — the group represents permissions to any function that gives an application suite the ability to write a Near Field Communication (NFC) compliant tag.

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 can be defined.

If a new function group is added, it should not introduce any redundancy to the existing groups.

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-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.

Auto Invocation And Push Registry Security Requirements

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 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-Permission-1: javax.microedition.io.PushRegistryPermission "socket:" "static,dynamic"
    MIDlet-Permission-2: javax.microedition.io.SocketProtocolPermission "socket://"
    

Requirements on Restricted APIs

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.

Mobile Media Client Policy

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.

Application Download and Execution While Roaming and After Changing the Smart Card

All previously authorized and installed application suites and LIBlets 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 or LIBlets 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.

Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.