WebVM - Security policy for device API access

A position paper for Security for Access to Device APIs from the Web - W3C Workshop.

Introduction

This presentation provides an overview of WebVM, a product from Aplix. We’ll explain what WebVM does, and then look specifically at the security aspects of how it works.

WebVM in a nutshell

WebVM provides a way for JavaScript programmers to get access to platform features through device APIs - that is, specific JavaScript APIs that expose services of the platform or ancillary devices such as Geolocation, access to PIM data and access to the camera or to the Subscriber Identity Module(SIM). This JavaScript access is available, subject to access being granted, to websites (i.e. JavaScript code running within a remotely hosted document in a browser) as well as to widgets (in the sense of W3C widgets).

The idea of WebVM is that it does not by itself define any specific device APIs, but provides an enabling framework so that independently defined and implemented APIs can be referenced by a web application, bound to a specific context, and then invoked. The implementation of any given API can be in native code for the target platform - in C or C++ - but it is also possible to implement these APIs in Java. WebVM provides a “bridge” which transparently maps APIs implemented in Java into JavaScript, performing all necessary type conversions and synchronising the lifecycle of JavaScript objects with their Java peers.

This Java bridge offers a number of interesting features:

• Since most phones already have a Java environment that exposes a multitude of device APIs, these same services can be made available transparently and consistently to a JavaScript programmer.

• The implementation of any given API can be downloaded or upgraded and does not have to be frozen and embedded at the time of manufacture. This means that the definition and proliferation of APIs is not inhibited by the integration/manufacture/renewal cycle.

• The sensitive device operations that are available in the Java platform API can all be uniformly and securely mediated by an access control system, selectively granting access to specific features to only those websites or widgets that are authorised to access them.

WebVM is implemented as a plugin using widely supported plugin interfaces; NPAPI, and ActiveX in the case of the Microsoft browsers. The structure is illustrated below.

Security objectives and features

Without effective security measures, however, these device APIs have the potential to be the enablers for the most virulent and intrusive viruses yet seen. Addressing this in an effective but usable way is critical to the viability of any solution to the platform API requirement.

The security requirements are complex, and a framework needs to be able to deal with a wide range of competing requirements, including:

• the need to handle multiple specific policies of different manufacturers or network operators within a single technical framework;

• the need to maintain security, and ensure that the user remains in control of security-relevant operations that are performed on his behalf, without making the security checks unacceptably obtrusive;

• the need to establish reliably which sites are authorized to perform specific operations, and those that are not, when there are (effectively) infinitely many sites under multiple authorities, in the presence of different connection technologies;

• the need to allow the user to grant very specific rights to individual sites where these are legitimately required, without making the security configuration unwieldy or unmanageable.

We’ll look at a number of specific issues that the framework must deal with and explain the key features that WebVM has in order to address these challenges.

Fine-grained access control policy

Our belief is that in order to be effective, an access control system has to be able to model the required rights and the identified risks as faithfully as possible. We believe that this requires a system that supports fine-grained control over permissions, in terms of both the operations being attempted and the identity of the web application making the attempt.

There are examples of access control systems that could have been taken as defining a precedent for the WebVM permissions model - for example the JavaME recommended security policy for JSR 248: Mobile Service Architecture, or the Internet Explorer security “zones” - that offer a coarse-grained policy, based on classifying all subjects into one of a small number of trust zones or “protection domains”, each with a relatively static set of rights. Although these frameworks have rightly attempted to ensure that the configuration overhead associated with the access control policy is minimised, the effectiveness of those policies is severely weakened in common situations. Examples are where access is granted to a set of operations where only one is required, or where the user is prompted to make a decision because the security policy is unable itself to distinguish between legitimate and unwarranted requests.

WebVM therefore supports an approach which recognises a fine-grained set of permissions, together with fine-grained identification of subjects. The framework is general enough to be capable of representing a wide range of possible access control policies via a configurable policy definition. It is possible to configure policies that mirror a “traditional” mobile application trust and permissions model, but it is also possible to construct policies whereby access to specific operations is selectively allowed or denied for specific web applications (whether specific websites or specific widgets).

The basic set of device API permissions, the format for security policy configuration files, and many other of the security concepts, have been contributed to the OMTP BONDI initiative, with the aim of creating an advanced and robust common framework for secure device API access.

Multiple trust models

Many security models for mobile applications use cryptographic 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, many frameworks for mobile applications, including the MIDP Java environment, make 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; 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 (the operator and device manufacturer) rather than the user.

The MIDP Java environment has this kind of trust model hard-coded into the specifications, and it is not possible to construct any other trust model for API access. WebVM does not attempt to pre-judge the trust model that should be employed in any given situation, and allows a policy configuration to establish which subject attributes are used as the basis for assigning rights. It is possible to emulate a “traditional” mobile application trust model in a WebVM policy, but other trust models can also be represented.

Multiple identity types

In contrast with many existing efforts in the “Widgets” area, WebVM does not limit access to device APIs only to installed widgets. It is believed that many of the most valuable use-cases are for device API access from websites. An access control policy therefore must determine permissions based on different types of subject identity. WebVM identifies widgets using the widget identifier contained in the widget configuration document, and identifies websites using an identity derived from their URI (specifically, the combination of protocol, port and host).

It is therefore possible to grant access to specific device features selectively to certain sites where required; for example a web-based contacts organiser could be granted access to the PIM phonebook, or a local search site could be granted access to location.

Trust models for API implementations

WebVM allows code running in a web page (whether locally or remote) to call a device API and, ultimately, to perform actions on the underlying platform. WebVM access control applies to those low-level platform operations based on the identity of the calling page.

In the case that the device APIs are accessed via a Java library, the Java library is usually treated as a transparent extension of the calling web application from a trust perspective. All security-relevant actions attempted by the Java library are regarded by the framework as having been attempted directly by a script running in the containing page. Therefore, it is the script’s identity (which, under the browser security model equates to the page’s identity or origin) that is used in deciding whether or not to permit the action. In WebVM this default model is termed the pass-through model.

However, the Java environment, since it is a managed (or “sandboxed”) execution environment, also enables a different trust model. The trusted subsystem model aims to deal with the situation in which the WebVM library uses certain low level primitives to make a specific set of higher-level services available to calling scripts. The library is trusted (to some degree) 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 - it only sends to a specific known address and can be trusted not to spam the SMS inboxes of other addressees in the user’s phonebook. The trusted library then exposes a different service to the enclosing app - say an SMS voting service. The library becomes a trusted subsystem, shielding the platform from abuse by web apps that make use of it.

With the trusted subsystem model, the WebVM library and the containing page are considered as having separate identities. The identity of the library is the relevant identity when determining whether or not to permit security-relevant actions at the device API level; the identity of the containing page is then relevant to:

• the act of binding to the WebVM library;

• any new security-relevant actions that the library itself defines, corresponding to the higher-level services that it exposes.

In order for the trusted subsystem model to apply, the library itself must be signed and verified, and the library must be installed locally on the device.

Summary

Effective access control is a clear prerequisite to enabling device API access to web applications. ‘Effectiveness’ in this context relates not just to the reliability of the enforcing mechanisms - but to the ability of the framework to faithfully reflect the actual access control requirements and security risks.

WebVM provides an extensive and configurable access control framework in response to these requirements. The framework is capable of representing the coarse-grained models that have been used to date in most mobile application environments, but is also intended to enable much richer and fine-grained policies, which also then scale to support policies for access by websites as well as by installed widgets.

In addition to enabling the implementation of device APIs in native code modules, WebVM enables access to device APIs via a bridge to the Java environment. The Java runtime intercepts all attempts to make device API calls and these are subjected to access control checks by WebVM; this Java bridge also enables a trust model in which Java libraries, as implementations of specific device APIs, can be treated as trusted subsystems, which further improves the platform’s ability to express access control policies faithfully and enforce them reliably.