WebVM - Security policy for device API access

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.