The DAP working group is defining APIs designed to enable application access to device resources, including personal contact information such as calendar and contacts information, system information such as network information, and other information. Much of this information is sensitive and potentially misused. For this reason the DAP working group charter explicitly calls out the need to control access to this information, such as through the use of policy.
This is complicated by constraints in two dimensions, end user affiliation and application type.
End user affiliation plays a role in determining what a user is allowed to do. An end user might be an employee of a corporation or subscriber to an operator network. In either case, the corporation or network operator may wish to set constraints on what applications the user accesses may do, by defining and using an access control policy. Alternatively a user may not be acting as an employee and not subject to network operator constraints (at least for now with many Internet connections), but may wish to personally control what Internet applications are allowed to do.
Second, there are two types of application under consideration by the DAP WG. First, there are W3C widgets, applications that are created with certain constraints, that might be signed by a source, enabling source authentication. Second are full web applications, which may come from any web site the user may access. These two types of applications present different challenges and constraints.
Taken together, these two cases provide four different possibilities.
| Model/Environment | Widget | Web |
|---|---|---|
| User Controlled | Explicit permission by dialog, policy with trust based on signed widget or secured installation | Explicit permission by dialog, user mediated introduction, distributed trust mechanisms like OAuth (?) |
| Enterprise/Operator | Policy, Trust based on signed widget or secured installation | Policy with trust based on Federated Identity |
The following definitions are used in this document.
Controlled access to functionality or resources by a policy enforcement point based on rules defining which access is permitted. Enforcement can occur at runtime when supported by the API framework and is supported by applications declaring needed access.
An application is code that may make use of DAP Device APIs. For the purposes of DAP, such applications are either Javascript code contained in a web page or a W3C Widget.
A Device API is a collection of Javascript interfaces structured in terms of methods and properties. Device APIs are used by applications to access Device Capabilities.
A Device Capability is device functionality or device resource(s) exposed by standardized APIs.
Although there are simple Device APIs that provide access only to a single Device Capability, there are also more complex APIs that expose multiple Device Capabilities; examples might include a camera API that provides the ability to geotag a photo with the current location, or a messaging API that provides the ability to access documents stored locally and attach them to outgoing messages. Therefore, enabling or disabling access to a specific Device Capability may not directly correspond to enabling or disabling access to a single Device API interface.
Consent is a user action that indicates that the user agrees with an action, such as using an API to expose information to an application. Such consent may be explicit or implicit.
Explicit consent is a user action directly related to a query for the user's consent, for an action to be taken by the application, or for an application lifecycle action. An example of explicit consent for an application action is a positive user response to a query by the web runtime, asking whether an application should be allowed to take a photograph. Examples of explicit consent for an application lifecycle action include a positive user response to a query by:
Implicit Consent occurs when a user takes an action that implies their desire to have an action occur, implying permission for needed resources. An example is pressing a camera shutter to take a photograph, implying consent to the act of taking a photograph.
This section outlines use cases and requirements to support user controlled access control.
In this use-case:
This use-case is the expected case in most situations where there is no external policy authority such as a network operator or enterprise.
Although the initial configuration is "empty" (ie it only contains universal default rules), it is possible for the policy to be extended over time as the cumulative result of explicit user configuration and persistently remembered user decisions.
The configured policy, at any given time, may be stored locally on the device or may be stored remotely and be accessible via a network service, or both.
In this use-case:
The policy configuration provided by the external policy provider may be supplemented by user control as in PM1.
The configured policy, at any given time, may be stored locally on the device or may be stored remotely and be accessible via a network service, or both.
This use-case mirrors current practice with products such as virus scanners or other malware detectors.
A user may establish a policy configuration (through explicit configuration of preferences, and remembered decisions) and there is the option of reusing this configuration across multiple devices. A user with multiple devices may wish for their security preferences to be consistent (or to at least have the option of consistency) across those devices. Rather than have to manually configure the preferences on each device, it should be possible for there to be a seamless security experience across devices, e.g. by switching SIM card between devices and as a result automatically applying a policy resident on the SIM card or synchronizing with a network-based policy management system. A specific case is the case where a user wishes to transfer a configuration from an old device to a new device. This is relevant to Policy Management use cases PM1, PM2, PM3.
Prompts should be eliminated whenever possible. Many prompts do not provide any meaningful security because:
If prompts are shown and dismissed as a matter of routine, then the user is less inclined to take any security decision seriously, which further undermines the effectiveness of a user-driven access control system.
It is important to note that modal prompts (i.e. prompts that block all other user interaction until dismissed) seriously compromise the user experience. Modal security prompts SHOULD be avoided.
Any prompt or dialog that requests a user security decision at runtime (e.g. at the time a sensitive action is attempted) can be non-modal if the API that initiates it is asynchronous. DAP APIs MUST be designed so that all operations that could potentially trigger a prompt are asynchronous.
If user decisions are themselves expressible in the policy language, then they can be "remembered" by adding a policy-set and/or rule to the policy. Similarly, user configuration settings should be possible in the policy language. This means that the policy document is not just a way of creating an initial policy configuration, but can be the sole and complete representation of the access control configuration at any time.
User authorization vs other policy authority
Support for trust models other than user security decisions needed?
This issue is who makes security decisions; in particular whether the user is the sole authority for decisions (whether by configuration of settings, or responses to prompts, or both) or there is another authority that determines the rights given to an application.
Many existing ecosystems for mobile applications are based on a trust model in which a particular distributor (such as a network operator) certifies an application as trustworthy, eliminating run-time user prompts in some cases. This approach avoids the disadvantages of prompts, but at the expense of taking real-time control away from the user in those cases. Other approaches, such as BONDI, do not hard-code this type of trust model, but nonetheless provide for a policy authority to determine an access control policy, and this policy can require that certain decisions are made without reference to the user.
Although the role of any access control policy, and authority over it, are beyond the scope of this particular issue, DAP's approach to prompting must take these possibilities into account.
What is the correct granularity of security decisions presented to user? Perhaps this should be stated in policy. What is the linkage to application logic?
This issue is whether the user is presented with a single security decision that covers multiple operations, or independent prompts for individual operations. Blanket authorization for an application to use multiple APIs, as often as required, eliminates run-time prompts but also may leave the user without the context required to make a meaningful security decision. Also, a user may not be prepared to give blanket approval for a certain operation but may instead wish to give permission in specific circumstances only.
DAP should not presuppose that an approach involving blanket permissions only (e.g. implicit granting of blanket permission by allowing installation to occur, or an explicit blanket permission given when the application is first run) is the right answer. Different permission granularities have advantages for different use cases and we should require a system that supports all use cases effectively. DAP should follow industry practice in these cases, and provide permission granularities consistent with those widely deployed in the mobile market.
It should be possible for policy to be defined in a portable device-independent manner.
This section outlines use cases and requirements to support enterprise or network operator managed access control.
In this use case:
The external policy authority may configure the policy as part of the commissioning of the device (eg a network operator's configuration applied by the manufacturer prior to sale, or an enterprise configuring device policy using a secured device management interface).
In determining the policy, the policy authority has the opportunity to define a policy that supports a specific objective - such as to limit access to APIs to only those web applications that are themselves distributed by the policy authority (eg to control its exposure to the financial risk of abuse of device APIs).
In this case case, a single policy authority wishes to define and configure a security policy for multiple dissimilar devices. A typical network operator's portfolio many include tens or even hundreds of models, each based on different platforms, and different UAs. A commonly supported interoperable format for configuration of a policy dramatically impacts the practicality of achieving the desired configuration across all devices. This is relevant to Policy Management use case PM3.
Configuration of some parts of access control policy may be part of the overall configuration required to enable a particular application or service. This, along with many other configuration parameters, may be remotely configurable via device management. The configuration required to enable a service may be provided by the service provider as a policy fragment, to be added to the overall policy by the policy authority. An interoperable representation of such policy fragments would enable this to be done without authoring the configuration updates separately for each target device, platform, or UA.
These use cases relate to reading and writing of policy definitions in an interoperable format.
This section outlines some abuse cases for misuse of APIs.
The landscape that is being created is the enablement of cross-platform, cross-device, easy to develop, highly functional applications based on browser technology that has been proven repeatedly to be untrustworthy - a perfect recipe for evil. Will this meet all the criteria for really successful malware on mobile devices for example?
Up until now the measures taken by the mobile industry have proven highly successful in ensuring no major malware incident has affected the industry. There have been attempts: the MMS-spreading Commwarrior is probably the most infamous, along with the Spyware tool, Flexispy. An additional factor in ensuring the success of mobile security has been the fact that mobile platforms have been too fragmented and complex, therefore not representing an attractive target so far. Existing modus operandi from technology-related attacks can provide indicators as to the types of attack and abuse that can be expected on widgets and web applications as device APIs are opened up.
An application that gains access to locations, contacts and gallery, silently uploading the data in the background to a site owned by the attacker. This is something that has been a clear goal for attackers already. There have been numerous high-profile examples in the past in the mobile world. Celebrities such as Paris Hilton, Miley Cyrus and Lindsay Lohan have all had private pictures, phone numbers and voicemails stolen from devices or networks in clear breach of their privacy. There has been embarrassment for teachers who had their pictures and videos copied by the children in their class and spread around school. The most high-profile case in the UK of a mobile related privacy breach was that of the News of the World's use of voicemail hacking to gain access to private information about Royalty. The Royal editor, Clive Goodman was jailed for four months and the editor, Andy Coulson resigned over this blatant privacy breach. Given the appetite for breaching privacy, users need to be safe in the knowledge that their personal data will not leak in any way.
A widget that replaces the voicemail number with a premium rate number instead? There are number of reasons why an attacker would want to breach the integrity of the device. Simply changing the telephone number of the voicemail that is stored on the device could be enough to make an attacker a lot of money. Users usually have a shortcut key to their voicemail and may not notice for a long time that anything is wrong. A more sinister use could be to plant evidence on a device. Pictures, files and even criminal contacts could potentially be anonymously planted all without the user's consent or knowledge. Proving innocence could suddenly become very difficult. There are also a number of reasons why somebody would want to steal data. The contents of corporate e-mails would be very interesting to a competitor, as would sabotaging data stored in spreadsheets and presentations on the target phone.
A widget that replaces the voicemail number with a premium rate number instead? There are number of reasons why an attacker would want to breach the integrity of the device. Simply changing the telephone number of the voicemail that is stored on the device could be enough to make an attacker a lot of money. Users usually have a shortcut key to their voicemail and may not notice for a long time that anything is wrong. A more sinister use could be to plant evidence on a device. Pictures, files and even criminal contacts could potentially be anonymously planted all without the user's consent or knowledge. Proving innocence could suddenly become very difficult. There are also a number of reasons why somebody would want to steal data. The contents of corporate e-mails would be very interesting to a competitor, as would sabotaging data stored in spreadsheets and presentations on the target phone.
Declarative policy is used for access control decisions for various capabilities, such as actions that may be performed, as invoked by specific API calls for example.
Examples of device capabilities independent of API include the "read local filesystem" device capability or the "geolocation" device capability. A corresponding access control decision based on capability alone is a policy stating that an application shall have no access to geolocation, regardless of API used. Examples of feature access control include a messaging API that permits files to be attached to messages using the "read local filesystem" device capability, or a camera API that permits captured photos to be geotagged, using the "geolocation" device capability.
Capabilities need to be defined portably. Examples of granularity - a shared file needs to be distinguishable from an application's private file, and a Bluetooth port needs to be distinguishable from a USB serial port.
Features defined according to CRUD, one feature for Create, Read, Update, Delete?
Feature parameters to avoid explosion of capabilities and features? e.g. file open with either read or write parameter. ( see discussions in minutes of October 7 call )
It should be possible for policy to be integrity protected during various points in its life-cycle.
( see ISSUE-21 - OPEN ) Is access control at the feature level required or is access control at the device capability level adequate?
These use cases are specific examples of statements or rules that may be expressed in a policy.
weather.example.com can access
geolocation coordinates if the user says it’s OK.
weather.example.com widget can connect to
weather.example.com without
notifying the user, except when roaming.
evil.example.org.
Example web site use cases, to give examples of the types of policy that might be expressed:
mynetwork.example.com can read phone
status
properties.
evil.example.com cannot access any device APIs.
weather.example.com foo widget
can access geolocation coordinates but
only if it’s embedded on the foo home page.
The editors would like to extend special thanks to Nokia, OMTP BONDI, and PhoneGap for providing the foundation of the working group's requirements discussion.