Introduction

This section defines the security framework under which WebVM operates. Beyond the basic mechanism provided by WebVM for linking JavaScript to Java code, they key to its effectiveness lies in providing the appropriate level of access to the underlying services on the platform.

The extensive security infrastructure defined by MIDP2 and IMP-NG forms part of the mechanism for WebVM security, but on its own does not provide an appropriate security model for WebVM. This section highlights the issues that must be addressed, and defines the WebVM framework in detail.

MIDP vs browser security models

In general, a browser security model is typically different from the MIDP2 model defined for locally installed applications; WebVM itself introduces some additional issues for the browser security model. Further, browsers themselves differ in terms of the detailed security model, and WebVM must be capable of working within multiple browser environments. All of these factors must be taken into account to define a usable and effective security framework for WebVM.

Authenticity and trust

The MIDP2 security model uses cryptopgraphic signatures to verify the authenticity and integrity of a downloaded application. A certificate validation chain is established which links the certificate of the signer of the application to a root certificate from a known and trusted entity (such as a certification authority, or CA).

This public key infrastructure is typically used to verify the validity of the signature applied by the signer of the application, and hence the authenticity of the application package; having reliably identified the author, the user can then make a decision about the trust that can be placed in application. However, MIDP2 makes a significant simplifying assumption, that the level of trust can be decided on the basis of the owner of the root certificate in the certificate chain a€” that is, the identity at the other end of the certificate chain. By doing this, it really confuses authenticity and trust, and places control for determination of trust with the root certificate owners (ie the operator and device manufacturer) rather than the user.

There are several reasons why this approach is not appropriate for a browser- based application environment. Some of the problems are:

• scalability: there are very many individual site authors and they each might be given a different level of trust (in terms of the specific permissions) and it is not feasible to flatten this to a very small number (ie 2 or 3) trust domains with uniform default permissions;

• context: the level of trust placed in any given web application depends on a host of context-specific circumstances, such as whether the application is running within an intranet, the risk profile of the specific user, device and environment, the level of security of the connection, etc a€” so it is necessary to be able to establish a security configuration independent from the authenticity mechanism;

• platform and network independence: web applications must, as far as possible, be authored and secured in a way that can operate independently of the specific platform, manufacturer and operator;

• independence from certificate validation mechanism: the system makes it harder to make effective use of signature validation methods that do not rely on local root certificates, such as online signature verification;

• accepted practice: browsers on the desktop have evolved to include powerful and configurable security systems, and users are becoming familiar with their operation. It will be increasingly impractical for mobile browsers to adopt methods that conflict with those in use in the mainstream internet.

Page vs library permissions

Security considerations for a WebVM library are different from those for a standalone Java application. When a web application makes a request to a WebVM library, which in turn makes a call to a security-relevant platform API, the request is ultimately being made on behalf of the web application, not just the library. Therefore, it is not appropriate to grant permission for an operation solely on the basis of the trust assigned to the library; the identity and trust level of the originating web application must also feature in the security decision. A framework is needed that supports this.

Browser same-origin policy

Current browser security policies are based in part on a philosophy that regards the client code (in the browser) and the server code as a single composite entity; security-relevant actions that are confined within that composite entity (such as a connection request back to the originating website) are treated differently from actions that go outside that entity (such as a connection request to an unrelated domain). This is the basis of the same origin policy, wherein HTTP requests can be made by an app to servers in the same domain but not others, and there are similar restrictions in the visibility of JavaScript global variables. It must be possible under the WebVM framework to create security configurations that implement this same philosophy. (Note that under the usual MIDP2 security model this isna€™t possible, because granting permission to make HTTP connections does so without regard to the destination domain.)

Generic framework

The framework defined here is general enough to represent useful and effective security policies for WebVM-based applications; it is also believed to be general enough to represent security configurations for the wider browser environment and therefore it should be possible, with some development in the browser user interface, to create a unified model and user interfaces for configuration and interactive authorisation checks.

The concepts and principles behind this general framework are defined in this section.

Objects

The security framework is based on the notion of an object, which is anything that might attempt to perform a security-relevant action. Objects can include:

• HTML and XML pages;

• media such as images and audio clips, whether embedded in an HTML page or displayed by the browser directly;

• code objects, including WebVM elements.

An Object, then, is anything can be processed by the browser, either as the top-level document, or as an OBJECT element within another document processed by the browser.

Security context

An Object has a number of properties that are relevant to security, collectively referred to as its Security Context.

The properties are:

• Codebase: the URL from which the object was obtained;

• Distinguished Name: this is the X.509 distinguished name of validated identity of the originator of the Object, if available, obtained as follows:

• from the signer of the JAR containing the content if delivered within a JAR (using the jar: protocol, or as a Java archive);

• the verified CN of the server if the content was obtained using the https: protocol.

Rulesets

A Ruleset loosely corresponds to the idea of a security domain a€” that is, a collection of sites across which a particular set of permissions apply.

A Security Configuration comprises a number of Rulesets.

Each Ruleset includes at least one Rule and at least one Identity. A Ruleset exists to associate the Rules with their Identities.

Identities

The list of Identities associated with a Ruleset indicate when to apply the Rules in the Ruleset. When checking security permissions for a given Object, the Ruleseta€™s list of Identities is compared with the entries in that Objecta€™s Security Context.

An Identity may contain:

• an explicit URI to compare with the Objecta€™s URL;

• a URI Regular Expression to compare with the Objecta€™s URL; for example

• ^http:.* matches any http: URL;

• ^http://aplixcorp.com.* matches all URLs on the aplixcorp.com website;

• A Distinguished Name to compare with the Objecta€™s Distinguished Name.

If any of the Identities in a Ruleset match any of the identities in the Objecta€™s Security Context, then the Rules in the Ruleset apply to the Object, and further security checking takes place. Otherwise, the rules are ignored.

Rules

A Rule indicates whether or not permission for a particular Security Property (such as binding to a library or sending an SMS) should be granted or denied. The Rule can given three outcomes:

• permission is Granted;

• permission is Denied;

• the check should be referred to the User. In this case, a security prompt should appear, allowing the user to make the decision.

In each Ruleset, a Rule can be created for any or all of the Security Properties. (The Rules will only apply to Objects whose URI/DN matches one of the Identities.)

Different Security Properties require different Rules to govern them. The different types of Rule are as follows.

Basic Properties and Rules. These are used to govern security actions that can simply be configured to be enabled or disabled, such as whether or not it is permissible to read the current location.

Regular Expression Properties and Rules. Certain Security Properties are governed by more complex rules, and in particular grant or deny permission for a specific action based on some context information. The context information is presented as a string that includes contextual information about a specific attempted instance of a security-relevant action. An example would be an attempt to open a network connection, where the context information is the destination domain or address.

Security Properties that have context information associated with them can nonetheless be configured to be the subject of a Basic Rule, if the context information happens not to be relevant to the security decision for that configuration. For example, a security configuration may deny all network connection requests, irrespective of destination.

However, the context information can be used in Regular Expression Rules, which have a regular expression associated with them; when the context information matches the regular expression, the Rule applies.

A particular case of a regular expression Rule is a Same Origin Rule, where the context information is a URI, and the Rule applies if the URI of the Object matches the context URI.

If there is more than one Rule applicable for a given Security Property, all applicable Rules are evaluated and the Rule(s) with the most restrictive result is applied. Therefore, in order for permission to be granted, at least one Rule must apply and evaluate to a€oeGranta€, and no applicable Rules must evaluate to a€oeDenya€ or a€oeAsk the Usera€. Hence each security-relevant action is denied by default, and if there are conflicting Rules for the same operation then permission is denied.

Security Properties

Each action or operation that is potentially security-relevant is expressed as a Security Property. Security Properties can arise from several sources, such as:

• actions associated with specific Java platform APIs (eg send SMS);

• actions associated with operations in the browser (eg creation of a popup);

• operations associated with the WebVM plugin itself, such as binding a web page to a specific WebVM library.

Each of these sources effectively defines its own namespace of permissions. (For example, the Java API permissions namespace defined by MIDP2 is the dot- separated package/class/method name.)

In order to deal with this, Security Properties are defined in terms of a scheme plus a specific permission within the namespace defined by that scheme. The following schemes are defined.

Scheme

Namespace

Example

Comments

midp:

MIDP permissions, formed from dot-separated package/class/method name

midp:javax.microedition.io .Connector.sms.send

Most Security Properties in this scheme are basic properties but it may be possible to expose context information for many of these properties.

core:

A hierarchy of operations related to the core browser, DOM, and invocation of scripting engines

core:window.open

These are the properties that would be relevant if this general security model was applied to the browser as a whole, not just to the WebVM subsystem.

webvm-bind:

:

webvm-bind:google:maps

Context information is the most reliable available identity

webvm-lib:

::

webvm-lib:google:maps:findCurre ntLocation

This set is extensible to allow new schemes to be added as the need arises16.

Each WebVM binding effectively exposes a specific set of Security Properties for the Objects that use it; these are listed for each binding in section 2.

WebVM security models

WebVM effectively exposes a number of capabilities to scripts and some of these capabilities are security-relevant and therefore constitute new Security Properties. There are, however, different interpretations as to how a WebVM library gains authorisation to perform these actions.

The simplest model treats the WebVM library as a transparent extension of a script running in the context of a page. That is, WebVM allows requests by the script to be translated into actions at the Java level, but it simply makes those requests directly on behalf of the script a€” and it is the scripta€™s Identity (which, in effect, is the web pagea€™s Identity under the browser security model) that is used when deciding whether or not the action is permitted. This model, termed the pass-through model, effectively allows the web pagea€™s Identity and rights to a€oepass througha€ the WebVM library.

However, another model exists, in which the WebVM library uses certain lower level primitives to make a specific set of higher-level services available to calling scripts. The library is trusted to some extent not to abuse the primitive operations it has access to, and therefore the full generality of those lower level primitives cannot be exploited by scripts. For example, the library might use SMS to interact with a specific service a€” it only sends to a specific known address and can be trusted not to spam the SMS inboxes of other addressees in the usera€™s phonebook. The trusted library then exposes a different service to the enclosing app a€” say an SMS voting service. The library becomes a trusted subsystem, shielding the platform from abuse by web apps that make use of it. This is the trusted subsystem model.

In terms of the general security framework, the pass-through model is simple. A security configuration simply contains a number of Rulesets, and these indicate the rights available to any given Object based on its Security Context. The platform operations exposed (ie the midp:* Security Properties) are considered to be operations attempted directly by the enclosing web page, and are permitted based on evaluation of all Rulesets matching that pagea€™s Security Context.

In the trusted subsystem model, two different things happen:

• The WebVM library (ie the subsystem) has its own Identity a€” this is usually derived from the JAR signature (and is either the Distinguished Name of the signer or, in some security policies, the root certificatea€™s signer) a€” so its ability to perform the lower level actions is judged based on this identity, not that of the enclosing page.

• The WebVM library may declare further Security Properties of its own a€” if they are deemed sensitive operations. Separately, Rules need to be created to grant access to these new operations.

In this way, the Identity and rights of the library are separated from the Identity and rights of the web applications that bind to it.

The trusted library declares Security Properties of the form:

webvm-lib:::

where:

• is the Vendor of the IMlet suite;

• is the Name of the IMlet suite;

• is the specific action that is the subject of the Property, which is the name of the Scriptable Interface together with, optionally, the name of the called method.

The webvm-bind Security Property

The act of binding a specific web page to a WebVM library is itself considered a security-relevant action and hence is a Security Property, both for the pass-through model and the trusted subsystem model. web-bind: introduces a namespace of permissions of the form webvm-bind::. The URI or (if available) the Distinguished Name of the library form the context information for these Properties.