Software Components for Secure Mobile Web Application Platforms
Security for Access to Device APIs from the Web - W3C Workshop
10-11 December 2008, London
Authors: Patrik Persson & Björn Johansson
(Ericsson Research, Lund, Sweden)
Introduction
We focus on access control mechanisms for device APIs:
mechanisms for deciding whether to grant a given application access to
an API or not.
In this work, we assume some APIs to be completely open, with no
restrictions on which applications can use them, and other APIs to be
restricted to signed applications (such as the W3C's definition of signed
Widgets). Open, public APIs are important to maintain the low barrier for
developing web applications, but we acknowledge network operators' and
device manufacturers' needs to limit certain functionality to trusted
parties.
A separate policy specifies whether access to an API requires
an application to be trusted or not. In this respect, our approach
resembles that of Java ME. Although there has been some debate on the
security model in Java ME, we believe that much of that debate really
concerns the policy (what to allow, when to ask the user) rather than the
mechanism (protecting APIs from unauthorized invocations). In this work,
we concern ourselves with a general access control mechanism, and expect
the policy to be defined by device manufacturers and operators.
Proposed Architecture
For this discussion, we define a layered platform architecture as depicted in Figure 1. The layers have the following responsibilities:
The application layer executes web applications and/or Widgets
within a browser engine.
The shim layer provides a JavaScript implementation of APIs.
This layer is implemented in terms of primitives provided by the
underlying platform, thus allowing for quick adaptation of new device
APIs (possibly over the air).
The context layer maintains the identity and security level
of the invoking application.
The access control layer decides whether the invocation is
to be allowed or not.
The platform layer provides an actual implementation of the
functionality.
Figure 1 depicts this architecture, and outlines the flow of a method
invocation from JavaScript via an access control decision down to the
actual device API implementation in the platform.
Figure 1: Layered security architecture for device API access control
Applying Software Component Technology
We consider software component technology (e.g., COM and COM-like
technologies) particularly attractive in this context, for several
reasons:
Language independence (at least, support for mixing
languages). In particular, the platform would typically be
implemented in C/C++, whereas applications are implemented in
JavaScript/ECMAScript or something else. In general, the area of
language bindings for such component models is well understood.
Vendor neutrality: mobile platforms and web-based execution
environments need not commit to specific implementations, but rather
agree on a shared component model.
Separation of platform, browser and API. The platform
implementation could be executing in a dedicated address space,
whereas applications execute within the context of a web browser.
A single entry point (method invocation mechanism) allows for
strict access control.
Deployed properly, such a component-based architecture would allow for
device manufacturers to provide native device APIs more easily. In
particular, explicit integration to a particular browser environment
would no longer be required: as long as a device API is formulated
to conform to the component model, the remaining architecture exposes
the functionality in a secure manner to JavaScript applications.
In the architecture of Figure 1, this means that the context and access
control layers are responsibilities of the component runtime system
itself. The platform layer provides interesting APIs expressed as
component interfaces, and the shim layer adapts the JavaScript
representation of the platform API to the form expected by the
application. The effect is a clear separation of concerns for
functionality, specific API details, security, and applications.
Challenges ahead
Several challenges arise when using software components in such a
secure architecture:
Performance. Our experience tells us this technology is
sufficiently light-weight for mass-market mobile devices, but care
must be taken to ensure any computational resources are used
wisely.
Footprint. The footprint overhead (in terms of RAM and flash
memory) of exposing a device API in this way must be kept at a
minimum, to avoid increases in device cost.
User Experience. Recommendations for the presentation of
consent requests and access control granularity for helping the
user in making informed decisions when trusting an certain
application to access a device API.
Agreeing on an open architecture that allows device
manufacturers, platform providers, and application developers to
collaborate.
Maintaining application run-time identity, required for an
informed access control decision. This is easiest in the case of
locally installed Widgets, and more complex in the case of web
applications.
We are confident that these challenges can be successfully addressed; however,
while some are the concern of the mobile platform provider, others will
benefit from collaboration between mobile platform providers, browser
vendors, and application developers.