Secure access for widgets to resources and privileged APIs

A position paper for Security for Access to Device APIs from the Web

• Arve Bersvendsen, Opera Software ASA

Abstract

This document briefly describes a description of identity and trust model for widgets with some suggested requirements for a security model consisting of a widget's declaration of intent with an accompanying security policy document. The position is based on Opera's prior implementation experience with widgets.

Identity models

In the discussion of identity models here, the definition of identity does not correspond with any similarily named concept in the set of widget specifications. It is not the identity of a single widget, but rather the identity of the authoring or issuing party of a widget or client-side web application.

By and large, there are two categories of assigning identity to a widget; origin-based identity, where the identity is a property of the medium the widget is delivered from, and signature-based identity, where the transfer method or medium is irrelevant, instead relying on a verifiable signature embedded within the widget, used to assign identity.

Origin-based identity

Origin-based identity may be formed whenever the widget is delivered from any source, and the strength of the identity is based on a number of implicit criteria:

• Is the delivery method secure?
• How verifiable is the identity of the delivering party?

In the majority of the cases, we can assume that the origin will be a widget delivered over http or https, using the domain the widget is served from forming the base of the identity.

The strength of this model is that it's extremely simple for authors, as there are no further concerns for the author beyond deploying the widget.

The weakness of the model lies in it's simplicity:

1. When deploying widgets in out-of-band scenarios, such as users forwarding widgets through bluetooth or other means, the origin is not guaranteed or preserved, and it is left entirely up to the user or runtime vendor to decide how to build a trust model on such security.
2. It relies on the communication between the origin of the widget and the end-user being secure and not suspectible to man-in-the-middle attacks.

Signature-based identity

The other form of identity is based on signing the widget package, widget signatures, preferably in accordance the Widget Digital Signatures 1.0. The strength of this identity model are numerous:

1. Regardless of a signature chain (or the lack of such a chain), the integrity of the widget package is guaranteed, insofar that only those in possession of the signing key are able to change the package.
2. Certificate chains may be used to further strengthen the identity of the author of the widget.
3. With signed widgets, the origin, as described in the previous paragraph becomes largely irrelevant: The widget can be guaranteed to be the same, independent of how it's delivered.

The downside to a signature-based model is that it places a small, extra toll on the developer who will have to sign the widget.

Trust model

It should be noted that the established identity of the widget itself does not imply any trust is pre-delegated to the widget, or widgets from a certain origin, or by a certain widget signer.

Determining trust for a widget with verified identity may vary from vendor to vendor, and criteria such as vendor business concerns, partnerships, QA processes, community trust and user decisions come into play. It is thus believed that a one-size-fits-all model for assigning trust may be difficult to achieve.

Security policy

Based on identity and trust, any of the interested parties may provide a security policy that should apply to the widget. This model is required to mitigate a number of factors:

1. The consequences of any security flaw within the widget itself must be minimized.
2. To prevent malicious out-of-band widgets from accessing or destroying sensitive data, such widgets should only be granted minimal access.

A security policy needs to be based on the following components.

1. The widget's declaration of intent with regard to the network or access to privileged APIs.
2. One or more policy documents (or UA settings) on the device or platform that determine which APIs and resources are available to widgets.

Requirements

A common syntax for expressing a declaration of intent must be developed. This language must be contained within the widget package itself, either as part of config.xml. This declaration syntax must provide authors the ability to:

• Request access to normally restricted resources
• Allow authors to specify API-access on a per-API level.
• Securely lock the widget down, so that it can only access the resources the widget author has approved
• Allow authors to lock widget network access to a single domain, port, protocol, IP range, or any combination or set thereof.

It is highly preferable that the syntax for declaration is kept simple, as history shows that authors are still often hand-editing code, or using copy-and-paste to author markup.

Upon installation of a widget, a User Agent should examine the identity of the widget, and provide a mapping between this identity and a policy document that describes the privileges this widget may have. Installation of the widget should be determined based on the result of comparing the declaration of intent and the policy. Should the widget require something the policy can't allow, installation should preferably fail.

As with the intent language, it is desirable to have a common policy language, mostly from a perspective of reuse and integration with other toolchains. The main requirement for such a policy language is that it is able to provide a one-to-one mapping with a language for declaration of intent.