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.

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.