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)


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:

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.

image/svg+xml Platform domain / Trusted native code Application domain / JavaScript (interface identity + method identity + arguments) Authenticated invocation of platform functionality API primitive with context API primitive invocation JavaScript function call Mapping:interface -> required access Identity/access level of currently executing application Access decision PlatformLayer Access controlLayer ContextLayer ShimLayer (JavaScript) ApplicationLayer

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:

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:

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.