D3.6: webinos Phase II Security Framework¶

Abstract¶

The webinos project defines and delivers an open source web application runtime compatible with a wide range of smart devices, including smartphones, tablets, PCs, in-car systems and set-top boxes. A key aim of the project is building a platform which is both secure and protects user privacy. This document describes the security and privacy rational, threat model and architectural risk analysis used by the project. It is a companion document to the webinos system and API specifications (D3.3 and D3.4) and explains why certain security and privacy controls exist and what risks remain. It provides a set of recommendations and describes the outstanding weaknesses and issues of which webinos stakeholders may need to be aware.

Contents¶

• Introduction
  • Intended audience
  • Document structure
  • Security and Privacy Mission
  • Key Changes from D3.5
• Terminology
• Architectural Risk Analysis
  • Motivation
  • Approach
  • Attack Resistance Analysis
  • Ambiguity Analysis
  • Weakness Analysis
  • Data Security
  • Summary
• Threat Model
  • Sources of Threat Data
  • Threat Model and Trusted Components
• API Security and Privacy Analysis
  • API Analysis Methodology
  • API Security and Privacy Analysis Summary
• Cloud Security and Privacy
  • Introduction
  • Background
  • webinos in the cloud
  • Summary and conclusion
• Recommendations
  • For Identity Providers
  • For PZH Providers
  • For Device Manufacturers
  • For Application Developers
  • For Users
• Conclusion
  • Summary of results
  • Making use of these findings in webinos
  • Making use of these findings outside of webinos
  • Future security and privacy activities in webinos
• References
• Appendices
• Background
  • Related Security and Privacy Architectures in Industry
  • Related Academic Work
  • Related Webinos Deliverables
• API Security Analysis
• Components
• Attack Surface metrics
• Contextualised Attack Patterns
• Attack Patterns Not Included in the Architectural Risk Analysis
• Complete List of Actions Defined in the Trust Model

Introduction¶

The webinos project delivers a cross-platform web application runtime environment; it provides standard JavaScript APIs as well as inter-device communication and interaction. The development of this runtime environment will help to provide a seamless end-user experience for web applications across multiple devices. The webinos consortium aims to make several innovations in the runtime environment and, as a research project, it aims to go beyond the current state of the art in web application technology.

One of the most important areas for improvement in existing web application technology is the provision of better security and privacy. webinos-enabled web applications will be able to support important and high value functionality such as electronic payment and may store confidential and valuable information belonging to companies or individuals. At the same time, vulnerabilities in web technology are being discovered regularly, with large projects such as OWASP (OWASP) dedicated to cataloguing and mitigating the most common and severe. Furthermore, user privacy is an increasing concern, and mobile applications frequently appear in the news for violating user expectations for how their data are collected and used (Leyden2011).

A key challenge facing the webinos project is that existing threats to security and privacy could potentially have a greater impact on webinos than on existing systems, due to the capability for cross-device interaction and standardised architecture. From the outset we have been aware that an insecure webinos platform could result in the creation of cross-device malware. This malware could capture sensitive private information or commercially valuable data or even create a large, cross-platform botnet capable of launching denial of service attacks against people and organisations. These threats are real, and must be solved in the webinos architecture. The webinos project has therefore been considering security and privacy issues from the beginning, and this document represents the rationale behind the webinos specifications with regards to security and privacy.

There is another compelling reason for the creation of a webinos security and privacy architecture: the standardisation of security and privacy controls and interfaces which will increase usability and reduce development effort. At present, each device manufacturer provides different interfaces and conceptual models for securing applications and protecting users. This makes the task of securing all personal devices challenging for users. By unifying the interface and allowing the management of security policies on all devices to be done on the most appropriate platform (on a device with a large screen and keyboard, for example) users will be able to make better decisions than they can at present.

In a departure from the approach taken in the previous year's report (the D3.5 deliverable), this document does not provide specification material relating to the webinos security and privacy framework. This can be found in related specifications (Webinos-D33) and (Webinos-D34) and aims to be a precise, implementable description of how webinos is designed and should work in practice. Instead, this document describes the rationale and background to the webinos specifications with regards to security and privacy. It identifies the risks and threats facing webinos, explains how these are mitigated and what the residual issues are. It contains detailed information about cloud security an privacy issues and how they affect the webinos architecture. It also lists specific security and privacy concerns with the APIs being developed by webinos and ways of mitigating them. This document is closely related to the specifications given above as well as the previous updates to webinos requirements (Webinos-D25) and the User Expectations of Security and Privacy deliverables (Webinos-D27,Webinos-D28).

Intended audience¶

This deliverable provides informative content for implementers of the webinos platform and webinos applications. This will help with any security and privacy analysis performed by individual stakeholders and organisations who may be considering deploying webinos.

Perhaps more importantly, this deliverable is useful for the webinos project itself in making sure that security and privacy threats are being mitigated by the architecture. It provides immediate recommendations and feedback to platform developers and API designers. This document represents a snapshot of the overall webinos development process, with some security and privacy issues in webinos addressed already and others still in progress. It is hoped that this work will be continued into the third year of the project.

Document structure¶

This document attempts to present the methodology and findings within the main sections, followed by references and an appendix containing source data. We begin by introducing the architectural risk analysis process, describing the methodology followed and the main results. These include an attack resistance analysis, ambiguity analysis, weakness analysis and additional work on securing data at rest. We then outline the threat model that has been adopted in the webinos architecture, defining the trusted and untrusted features of each component. Next, we address security and privacy issues directly related to APIs and their implementations, as well as how these have been addressed. Following this we present a substantial chapter on cloud security, relating primarily to webinos' use of cloud services. We then make a set of recommendations to webinos stakeholders, and in the final section we conclude.

Attached are a set of appendices containing:

• Background on related systems, academic papers and webinos deliverables
• The full list of API threats
• Architectural risk analysis data, including architectural components, attack surface metrics, and contextualised attack patterns
• Additional draft attacks and attack patterns that are yet to be fully included in the analysis
• A complete set of actions> used to inform the threat model

Security and Privacy Mission¶

The webinos project has security and privacy as a primary goal. In this section we attempt to define the broad, overall objective of security activities in webinos which help to define whether we have succeeded or not.

Encouraging the development and deployment of secure web applications¶

• Allow developer with good intentions to create secure applications without introducing new security overheads.
• Create sensible default rules which make it harder to develop insecure applications and easier for users to protect themselves.
• Introduce a secure personal network infrastructure which protects data in transit and properly authenticates endpoints, allowing for distributed applications which do not need to provide inter-application security features themselves.
• Allow for the creation and use of secure distributed services based on shared web APIs

Limiting the impact of insecure applications¶

• Mobile and web malware is a genuine threat: webinos must try to mitigate the impact of a malicious application on a user's devices.
• Security requirements from all relevant stakeholders (as defined by the consortium) should be taken into account, including - manufacturers, users, developers and network operators.
• Follow the principle of least privilege by making sure that applications define the privileges they are requesting and are given nothing more.
• Allow for revocation of permissions by users who may change their mind about an application or component.

Mitigating the most likely risks to user data and personal devices¶

• Identify the key risks and threats and have convincing mitigations for as many as possible.
• Make the remaining risks public by sharing the security analysis and source data.
• Make assumptions and expectations on other components clear.
• Make security and privacy part of the design process - influence the architecture such that key risks are balanced against functionality.

Making sure that webinos only enhances online privacy¶

• Limit the potential for webinos to be used to fingerprint end users and reveal personally identifiable information without consent.
• Create APIs which reveal only the data that developers require, and no more.
• Minimize the potential for surprise generated by new multi-device information sharing.
• Encourage the storage of personal data in areas owned by the user, both for their sake and for developers data handling obligations.

Ensuring that the security and privacy functionality within webinos does not conflict with usability¶

• Design based on a consistent set of personas, assets, threats and attackers.
• Balance the need for informed user consent with expectations: enable safe APIs where sensible and highlight those where additional consideration is required.
• Avoid the impact of 'click through' such that goal-orientated users are not expected to make all-or-nothing decisions about access control.

Providing security and privacy features in an open environment¶

• Allow for open source development without sacrificing the integrity of the security and privacy architecture
• Create security and privacy controls which are appropriate for the web and do not depend solely on a closed ecosystem such as an 'app store'

Key Changes from D3.5¶

This document replaces D3.5 as the security and privacy framework for the webinos platform. There are several changes between the documents, both in the structure of the framework and in the content.

Structure¶

In the first phase of specification, the security and privacy specifications were split between both the D3.1 and D3.5, with D3.1 containing details on policy management and authentication, and D3.5 containing everything else. In this set of documents, D3.6 contains purely informative sections whereas all normative parts of the specification are now in D3.3 and D3.4. This make it clear where implementers need to go for definitive information.

Furthermore, the focus of D3.6 has been narrowed to contain the rationale behind the platform in terms of how it achieves security goals and how it mitigates threats. It also includes specific analysis of key topics, such as cloud security.

The following table outlines where each section of the security framework and specifications can be found:

Platform integrity protection has been removed because integrity assurance was considered unlikely to be implemented within the time scale of webinos. Considering the number of supported platforms this was overly ambitious in phase 1. Further investigations as part of standards activities may re-open this possibility. Extension handling has been removed from webinos in general.

Framework changes¶

The main changes in the webinos specifications with relation to security and privacy are given below. In general, we have aimed to reduce the scope and complexity of the security and privacy framework and remove ambiguity.

Expanded certificate and key hierarchy¶

The webinos overlay network is secured using TLS connections between all endpoints. The full key hierarchy for this is now specified in Deliverable D3.3. It has also been extended to support client and server certificates in browsers and widget renderers. The kye hierarchy has also been designed to allow for multiple user identities such that the use of a specific key does not necessarily reveal linkable user information. More details can be found in D3.3.

Improvements to the authentication system¶

Authentication in webinos has now been clarified. Authenticating to the personal zone in general is implemented through a combination of OpenID as well as the device keys described in the personal zone key infrastructure. An important novelty of webinos is that we have avoided introducing any new usernames and passwords: users can re-use their existing credentials from other identity providers. Locally, webinos will provide user to device authentication through the authentication API. This can also be used internally. A full description of the authentication framework can be found in D3.3.

Removal of the attestation API¶

The attestation API was removed from webinos in phase 2 due to the perceived difficulties in implementing it across multiple platforms. We intend to continue investigating it in our research, but do not expect to specify its use in the rest of the project.

Removal of webinos-provided secure storage¶

The phase 1 specifications included secure storage. However, on further analysis (see the Data Security section in the risk analysis) we concluded that implementing encryption at the webinos level would, in most cases, be unnecessary, lower performance and be a time consuming task not directly related to the main focus of the project. This is motivated by the increase in dull disk encryption products available on Android, Windows and Linux. Instead, we have defined the key requirements for platforms implementing webinos.

Changes to the policy architecture with respect to privacy and exceptions¶

The policy framework now includes an 'exceptions' policy file on each device which is not editable or synchronised by the rest of the personal zone. This mitigates the impact of a personal zone device being malicious, as well as the potential for misuse should the personal zone hub be compromised.

We have also updated the specifications of privacy policies to align with work from PrimeLife and integrate better into the widget manifest. This replaces the reduced P3P proposals from Deliverable 3.5. More information is available in the "Policy" section of Deliverable D3.3.

Terminology¶

Throughout this document we will use terminology described in the Webinos-D33). In particular we reference:

• Security goals, such as confidentiality, integrity, availability and accountability.
• Access control terms, such as authorisation, authentication and identification.
• Privacy goals, such as anonymity, unlinkability, undetectability, unobservability and pseudonymity.

We would also like to draw the readers attention to the following definitions which are important for the understanding of this document:

Architectural Risk analysis terms¶

Trust¶

Architectural Risk Analysis¶

Motivation¶

The design of webinos did not start with a blank page, but with a bricolage of different model elements. By re-using existing software components, we introduced design elements into our architecture. Assumptions about possible attacks might also influence architectural decision making. Even designers with a good understanding of both the problem and solution domains may not appreciate the implications of protocol selection, or the wording of requirements. Moreover, because the abstractions used by a designer don't always match those used by an attacker then flaws missed by the former may be found and exploited by the latter. Consequently, we need tools that help us assess the security consequences of bringing together different model elements.

The aim of an architectural risk analysis is to identify design-level flaws in a software architecture. This process was first described by McGraw (McGraw2006), and motivated by the claim that design flaws account for a significant number of security problems; such flaws cannot be identified by code-inspection alone. An architectural risk analysis shares many of the characteristics of classic risk analysis: it emphasises tangible assets of business value and, as a process, is knowledge intensive, requiring knowledge of both the problem domain and security expertise about potential flaws and attacks. In other respects, however, architectural risk analysis is more challenging. It relies on additional knowledge about solution-based models that form the basis of a software architecture, along with a sense of the requirements and constraints implicitly assumed when these are adopted.

In D2.7 and D2.8, we illustrated how the IRIS meta-model can deal with risks in the broader socio-technical environment within which a software system is situated. The IRIS (Integrating Requirements and Information Security) meta-model was developed at the University of Oxford to integrate concepts from Usability, Security, and Requirements Engineering (Faily2010b); this laid the foundations for subsequent work that evaluated the security and usability implications of mitigating risks (Faily2010b), and representations for archetypical attackers behind these risks (Atzeni2011). This work has also contributed to the development of the open-source Computer Aided Integration of Requirements and Information Security (CAIRIS) requirements management tool (CAIRIS), which has been validated using real-world case studies, e.g. (Faily2010c, Faily2011a).

Two further augmentations are needed for undertaking a more detailed analysis of software architectures. First, although the IRIS meta-model provides substantial support for modelling the problem domain, solution domain concepts are limited to the notion of assets. While modelling assets is necessary for architectural risk analysis, it is not sufficient as many features of an architecture warrant analysis in their own right; these include the architecture's attack surface -- the measure of its exposure to attack -- and the properties of connections between its elements. Second, model representations are needed for specifying the elements of software architecture and the attacks these need to resist. These representations need to match the thinking that designers might have about different perspectives of a system, and it should be possible for them to quickly evaluate the consequences that attack and defence elements might have on each other.

Approach¶

The approach prescribed by McGraw for carrying out an architectural risk analysis involves carrying out three steps. In the first step, an attack resistance analysis is carried out to identify general flaws from the literature and knowledge bases of known attacks and, based on these, identifying potential risks and their viability. In the second step an ambiguity analysis is carried out to discover new risks resulting from ambiguity and inconsistency in a design. In the final step, a weakness analysis identifies weaknesses that might arise due to the impact of the architecture's dependencies. Interested readers may wish to refer to (McGraw2006) for a more detailed presentation of this process, although Khan et al. (Khan2011) provide a more recent illustrative example based on an analysis of the Chromium browser.

To support a model-driven architectural risk analysis, we build two model-based constructs: architectural patterns and contextualised attack patterns. The following sections describe how these constructs are defined and used.

Architectural patterns¶

Architectural patterns were proposed by Buschmann et al. (Buschmann1996) to express a model of a software system, provide a set of pre-defined sub-systems, specify responsibilities, and include rules and guidelines for organising the relationships between model elements. To capture the elements of an architectural design pattern, we introduce new concepts to the IRIS meta-model, while making use of existing concepts and relationships. Collectively, the architectural patterns meta-model in Figure 1 provides three different views of an architectural pattern.

Figure 1: Architectural Pattern Meta-Model

The first of these is a component and connector view, which is expressed using UML component diagrams. This captures the runtime attributes of a system in terms of its computational elements (components) and the interaction pathways between them. Components are attached to connectors via interfaces; these are services or methods through which component interaction takes place. Interfaces are associated with an access right to indicate the level of authorisation needed to use the interface. Interfaces also have a particular privilege level. Connectors, like components, are characterised by their access rights and also by the protocol upon which the connector runs. These meta-model components are closely aligned with the model of software architecture described by Gennari & Garlan, which was recently adapted to capture the elements of a software architecture's attack surface (Gennari2012). This involves specifying the model elements associated with components and connectors, and assigning numeric privilege, access right, and protocol values to these elements. These values range between 0 and 10 and represent an element's exposure to attack; the higher the value, the greater the exposure. These values make it possible to formally evaluate the damage potential associated with interfaces, data transmitted through a connector, and untrusted data items with respect to restrictions placed on the data they contain. This model is described in more detail in the ambiguity analysis section.

The second is a goal view, and is characterised by the system requirements that motivate or constrain the architectural components; within the IRIS meta-model, these system requirements are expressed using KAOS (Knowledge Acquisition in automated Specification) goals and goal models. (VanLamsweerde2009). KAOS responsibility links describe the roles responsible for satisfying the behaviour associated with requirements, while concern links are used to describe instances where requirements reference or constrain assets.

The third view is based on a module view of assets. These assets are salient concepts of value that are specific to components or connectors; this view is expressed using UML class diagrams.

Contextualised attack patterns¶

Attack patterns are descriptions of common methods for exploiting software that both provide an attacker's perspective, together with guidance towards mitigating them (CAPEC). In recent years, work on attack patterns has been popularised by the development of open-source intelligence Common Attack Pattern Enumeration and Classification (CAPEC) (CAPEC) and Common Weakness Enumeration (CWE) (CWE) repositories. Although these repositories offer a wealth of useful attack data, the patterns are deliberately abstract in order that they can be applicable in as many contexts as possible. To provide this context and re-use as much existing model data as possible when applying these patterns, we have developed a meta-model for contextualised attack patterns. These model both the attack and design elements necessary to instantiate an attack within a specific context of use.

The model upon which contextualised attack patterns are based is the Gang of Four design pattern template (Gamma1995). However, the meta-model is based exclusively on existing concepts and associations in the IRIS meta-model. As such, when a contextualised attack pattern is introduced into CAIRIS, it introduces a new risk, together with the IRIS model elements that act as its rationale. The relationship between the contextualised attack pattern structure and the meta-model is illustrated in Figure 2 by the UML comment nodes denoting the name of the pattern elements.

The intent and consequences elements are used to describe the overall intent of the attack, and the external impact of the attack being successful. This impact is broader than the impact of a particular architectural pattern and is described using terminology that all system stakeholders can understand. The applicability element states the environment within which the attack pattern will be introduced. This is also the same environment within which architectural patterns will be situated to determine whether the design elements are resistant to this or other attack patterns within the environment.

The structure element describes the details of the attack itself. Attacks and Exploits are drawn from both CAPEC and CWE. The structure is closely complemented by the participant element, which models information about the attack; this includes the attacker's capabilities and motives for carrying out the attack. This information is derived from personas that have been created for possible attackers. Personas are specifications of archetypical user behaviour that are grounded in empirical data collected from representative users (Pruitt2006). These add a substantial amount of context to the analysis because not only do these add a human face to the attackers behind attack patterns, these are grounded in data sources about real attackers.

To describe how the attack defined by the structure might be implemented, leaf obstacles are associated with threats and vulnerabilities and a KAOS obstacle model is defined to describe how these might arise. Like the KAOS goal model in the architectural pattern, these obstacles might concern assets, and responsibility associations describe the roles responsible for satisfying obstacles.

As van Lamsweerde et al. have observed (VanLamsweerde1998), a KAOS obstacle model can be seen as a goal-driven form of a fault tree. However, unlike fault trees, our approach to obstacle modelling is closely tied to other artifacts such as previous knowledge about attacks and information about the attackers that might carry these out. Collectively, where useful statistical data about possible attacks exists, this information can help us predict the likelihood of particular obstacles being satisfied. When a probability value is specified for this likelihood then a rationale statement also needs to be provided to justify it. This is necessary because, when attack patterns are imported into a CAIRIS model, it may not be immediately obvious that the obstacle or the obstacle model arose from them. By proving this justification, we have some way of understanding the thinking that motivated this value. Based on these values, we can evaluate the probability of a particular cut of an obstacle tree based on the same equations used to evaluate the faults in a fault tree. For example, for an obstacle O_x with leaf goals O_1 and O_2, the probability of O_x (i.e. P(O_x)) where O_1 and O_2 are AND-refinements is O_1 x O_2; where O_1 and O_2 are OR-refinements then P(O_x) is O_1 + O_2.

Like classic design patterns, the collaboration concept describes the classes necessary to achieve the designer's intent. However, in the case of attack patterns, the classes are assets and the designers are attackers. As such, the collaborating assets are those which are targeted by threats or exploited by vulnerabilities. Closely aligned with this concept are motivating security properties of interest to an attacker realising this pattern.

Figure 2: Attack Pattern Meta-Model

Architectural Risk Analysis Process¶

For D3.6, we have applied an architectural risk analysis process which is based on that proposed by McGraw. These are described in more detail in the following steps.

Attack resistance analysis¶

In this step, we begin to populate the contextualised attack pattern template based on potential security concerns that may be associated with the pattern. This includes searching the imported knowledge bases for the pattern structure elements, and identifying attacker personas with the ability to carry out the identified attack. If the existing attacker personas do not have either the capabilities or motives for carrying out the attack, then it may be necessary to create a new, more meaningful attacker persona. The process for doing this is beyond the scope of this paper, but is described in more detail by (Atzeni2011).

To illustrate how each attack pattern comes about, KAOS obstacle models are developed to illustrate the conditions that make the attack possible. Where appropriate, attack and exploit elements are associated with root or leaf obstacles in the obstacle model. As further obstacles are elicited, these are refined to identify other potential threats and vulnerabilities. As this model evolves then, where possible, probability values are assigned to obstacles, and potential goal and responsibility links are assigned to known system assets and roles referenced in the contextualised attack pattern.

Once the attack patterns were finalised, the leaf obstacles in each attack pattern obstacle model were noted for subsequent ambiguity analysis. These would either need to be satisfied by the software architecture, or their non-satisfaction would need to be motivated.

Ambiguity analysis¶

For a specific areas of architectural significance, architectural patterns are created to encompass the component and connector, requirement, and asset views associated with this area. As McGraw suggests (McGraw2006), this is the most intellectually demanding part of the process because the information necessary to populate the pattern needs to be elicited from various sources, including design documentation and source code. It is also necessary to involve other designers and domain experts to validate the architectural pattern as it is specified. For this reason, the pattern itself will invariably be revised throughout the architectural risk analysis process.

Once the architectural patterns have been finalised, the Damage Effort Ratios (DER) were calculated for each architectural pattern. The DERs are a ratio of the potential damage done by exploiting resources over the amount of effort an attacker expends to access it (Gennari2012). Building on previous work by Gennari and Garlan [ibid], it is possible to evaluate the damage potential across the interfaces (DER_m), channels (DER_c), and untrusted surfaces (DER_i) are calculated. These formulae for these ratios are defined below:

• DER_m: Privilege / Access right
• DER_c: Protocol / Access right
• DER_i: Surface type / Access right

These ratios not only provide a high-level quantative measure of the webinos attack surface, their automatic evaluation also provides a quick spot check for unexpected results that might suggest an incomplete analysis, or hitherto unaddressed areas of the architectural risk analysis. If there are unusual or unexpected values, the source architectural patterns can be reviewed and, where appropriate, revised before proceeding.

The next step in this analysis involves taking the leaf obstacles from the attack resistance analysis, and eliciting one or more requirements that mitigate them. Each mitigating requirement is categorised with the affected architectural pattern component/s, an indication of whether it is satisfied or not, and the rationale for how the mitigating requirement is treated. Where mitigating requirements are satisfied, the requirements are added to the architectural patterns and incorporated into the KAOS goal model associated with each component. A KAOS resolution link is also added to the attack pattern obstacle model to indicate that the leaf obstacle has been mitigated. Where mitigating requirements are not satisfied, a KAOS domain property object is created to capture the rationale for not addressing the requirement. These domain properties represent hypothesis or assertions about the environment that assume as part of our analysis, e.g. that a particular requirement is out of scope. Like mitigating requirements, the KAOS obstacle model associated with the respective attack pattern is updated to reflect that the obstacle is resolved [albeit imperfectly] by the domain property.

Weakness analysis¶

The final step in the architectural risk analysis considers whether any residual weaknesses remain in each architectural pattern. This analysis involves considering assets that are associated with both architectural and contextualised attack pattern, and -- for threats or vulnerabilities associated these assets -- whether the software architecture adequately addresses them. For each architectural pattern, the measures in place to address the affected threats or vulnerabilities are described.

Figure 3: Asset, Goal and Component Views of Contextual Policy Management Architectural Pattern

Tool-support¶

To support it, we modified CAIRIS to support the aforementioned changes to the IRIS meta-model. We have also modelled architectural patterns and contextualised attack patterns as XML Data Type Descriptions; these facilitate the import of both types of artifact directly into CAIRIS. Because these patterns make use of existing models from previous work from other deliverables, D2.4, D2.5, D2.7, and D2.8) as well as open-source intelligence from CAPEC, CWE and OWASP, we have stored these pattern files in the webinos WP 2 git repository, and have updated the specification build scripts (developed for D2.5) to import both the patterns and directories of potential threats and vulnerabilities into CAIRIS. More information about CAIRIS's facilities for importing threat and vulnerability directories can be found in (Faily2011b).

Attack Resistance Analysis¶

The security concerns which formed the basis of the attack resistance analysis were initially drawn from the misuse cases in D2.8. However, these were also supplemented by several additional security concerns which had been identified by the project in the last year. These concerns were used to populate 16 contextualised patterns.

The definitions for the attack patterns and their supplemental obstacle models can be found in the appendix, but these patterns -- and the leaf obstacles arising from them -- are summarised in the table below.

Ambiguity Analysis¶

Based on our review of the webinos software architecture, we have defined 7 architectural patterns that characterise the webinos attack surface. For brevity, these are defined within the appendix, but are summarised in the table below:

Based on both the pattern specifications and the damage effort ratio formula defined the methodology, the quantitative attack surface of webinos is summarised in the below table:

At a one-day workshop held in Berlin in August 2012, the leaf obstacles resulting from the attack resistance analysis were reviewed and, based on these, 71 mitigating requirements were elicited. Each requirement was analysed to determine its affected components and whether these were adequately addressed by the webinos software architecture. A summary of this analysis is documented in the table below:

Weakness Analysis¶

To validate the results of the attack and ambiguity analysis, the below table summarises the mitigations in place within the webinos architecture for addressing related threats or vulnerabilities.

Data Security¶

The webinos platform uses and stores data which may have security and privacy requirements. For example, many of our personas may use webinos applications to monitor health data, to read personal emails, or to store valuable work files. As such, it is important to address threats and mitigations to vulnerabilities affecting data at rest.

Some of this analysis has been included in the main Architectural Risk Analysis process, but some still remains separate.

Where and what data are stored in webinos?¶

Applications (The File API)¶

Applications may store data locally on each device, as well as using data (such as media files) exposed by each device. To support this, webinos provides the File API. The File API will expose to each application an application-specific, isolated storage area. In addition, the File API can also expose arbitrary data storage. However, access to arbitrary data storage will be mediated by policies and require a different permission. Isolated storage from one application is never exposed to another through webinos.

Local devices and PZPs¶

Each device with a PZP will store some or more of the following:

1. Application data
2. Data in policies, certificates, and preferences. This may include the names of applications the user has installed, the devices they use and their friends identities. It is therefore considered private.
3. Browser histories and system logs
4. Context data (a temporary log file), if enabled.
5. Downloaded widget data containing potentially valuable intellectual property

Cloud-based components (PZH, online services)¶

Cloud-based components may store:

1. Context data
2. Data in policies, certificates, and preferences. This may include the names of applications the user has installed, the devices they use and their friends identities. It is therefore considered private.
3. Application data (outside of webinos control)

This is discussed in more detail in the cloud security analysis section.

What are the threats?¶

Two obstacles in the existing architectural analysis are relevant:

• "Application data intercepted" - Application data from webinos widgets is intercepted in the widget renderer.
• "Application data readable" - Application data from webinos widgets is readable outside of the widget renderer.

In addition, the following threats exist:

Mitigations¶

Webinos-provided mitigations¶

The webinos platform mitigates some of these threats in the following ways:

Device-provided mitigations¶

We suggest the following mitigations should be provided by webinos device platforms.

As this table demonstrates, the majority of threats we suggest mitigating at the device level, not the webinos level.

Current situation¶

At present, the following webinos platforms provide some of the aforementioned mitigations

Windows

Linux

Android

Summary¶

We have analysed the webinos architecture based on 14 attack patterns motivated by the findings of Deliverable 2.7 and 2.8, as well as ongoing development and emerging security and privacy issues. This provides a substantial range of attacks and obstacles to consider in the architecture. Indeed, all of the leaf obstacles obtained during this process have been included in the analysis and shown to either be satisfied by a goal supported by the architecture or shown to be lacking a solution at present. Our process is sufficiently rigorous that we are now able to draw several conclusions about the design of the architecture. However, more attack patterns and architectural patterns should be developed in the coming months in order to provide a more complete analysis and to prioritise future development of security functionality. It is also important to note that this analysis refers primarily to the specification of the system rather than the implementation. We have not analysed the level in which the specifications are implemented, nor have we considered the strength of the implementation against known code-level vulnerabilities.

Based on the findings of the attack-resistance, weakness and ambiguity analysis, we have made the following conclusions.

Application rendering¶

At present, our architecture does not fully address attacks on content rendered by widget renderers and browsers. This leaves webinos and webinos applications vulnerable to attacks such as content injection (cross site scripting, for example). This is primarily due to the re-use of existing web browsers as opposed to customising a browser with a webinos-specific extension. Customisation would allow additional rules and restrictions to prevent some of the more prevalent and likely attacks.

Comparative exposure of personal zone hubs and proxies¶

Based on the quantitative analysis of the attack surface in the ambiguity analysis, the webinos attack surface associated with setting up personal zone hubs is greater than the surface exposed when enrolling devices to personal zones; this is largely due to the attack surfaces of the assets associated with each architectural pattern rather than the damage potential associated with component interfaces or connectors. While a lot of emphasis has been placed on the device-side webinos architecture, the webinos hub-side architecture is less well understood with undefined surface types for the administration console and the potential for rendering engine weaknesses compromising traffic to/from a personal zone hub.

Reliance on OpenID authentication¶

The webinos platform is novel in its approach to authentication: we introduce no new passwords or usernames into the system and delegate most authentication tasks either to the underlying operating system or to an OpenID provider. However, this puts many mitigations out of scope, and the system is at risk when a weak or insecure OpenID provider is used. We believe this to be a reasonable approach, but it also means that webinos personal zone hub providers ought to limit the number of OpenID providers they support for security reasons, despite the negative impact on interoperability.

Policy management remains crucial¶

The policy-based access control system remains an important aspect of webinos and is responsible for satisfying at least 15 goals from the ambiguity analysis. This means that additional effort should be spent making sure that policy features are implemented in the platform, and that appropriate tools and user interfaces are provided. It is also true that default policy settings will be important to mitigate several obstacles, and these may need to be improved based on experience and the findings from Deliverable 2.8.

Privacy and service discovery¶

A privacy issue that has been discovered throughout the analysis is the use of the findService call, which returns persistent device identifiers and could potentially be used to re-identify the user, breaking unlinkability requirements. This problem has been reported to the rest of the project, and motivates further improvements and investigations of the Web Intents alternatives, as discussed in Deliverable D3.3.

Protecting webinos source code¶

The current webinos development process must protect users against the potential for a malicious contributor from adding back-door vulnerabilities to the platform. While this is solved (to some extent) through the gate-keeping implemented as part of the GitHub development process, further improvements are needed. In particular, creating a larger distinction between tests and platform code and making it easy to remove testing code from deployments of the platform.

A related issue is that of code quality and input sanitisation. Any communication with the PZP should be thoroughly checked and validated against a provided schema to prevent malicious code injection exploiting the runtime. This should be part of the requirements for accepting new code into the webinos source code repository.

Denial of service issues¶

Several of the attack patterns we considered in this analysis relate to denial of service issues. We believe that the architecture mitigates denial of service attacks in the following way:

1. Because the PZP does not rely on having a PZH available for local functionality, loss of the PZH doesn't prevent use of the PZPs. The PZH being made unavailable is, therefore, less important in many situations than a PZP being made unavailable. Indeed, the PZH is not required for local, peer-to-peer interaction between devices.
2. Support for downloadable widgets means that application can be used offline, and can be designed to be resistant to loss of network connectivity. Installing applications does not require an internet connection.
3. Process isolation between the web browser or widget renderer and the PZP should make the PZP harder to attack directly.
4. Restrictions on widget content should make content-injection DoS attacks harder to perform.
5. The use of long-term certificates means that credential expiration is not an availability issue.

However, we remain aware of the following issues with respect to availability:

1. The policy system is vulnerable to misconfiguration, which could make PZPs unable to communicate.
2. The availability of the OpenID provider is important, but is out of the control of webinos.
3. Attacks on platform integrity from malware is not something we can mitigate.
4. API-specific resource exhaustion attacks may be a problem. These are discussed in the API Security and Privacy Analysis section.

Data storage¶

The security of data used within webinos is largely dependent on the devices running webinos, and therefore is largely outside of the scope of the webinos architecture. The webinos implementation has avoided providing additional data encryption tools on grounds that most platforms already provide these options. In most cases, users have the tools available to protect themselves. The outstanding threats include:

• Protecting valuable IPR stored within downloaded widgets. A solution to this problem would require Digital Rights Management. This is hard to implement across multiple platforms and is no longer within the scope of webinos.
• Isolated data storage on windows and Linux. Native malware may be able to access webinos data as it is not protected on these systems by default.
• PZH implementations may have varying levels of security from online attacks. We refer to the cloud security section to provide more details on potential solutions.

Threat Model¶

Sources of Threat Data¶

We have used the following sources of data to identify threats, vulnerabilities and attacks that may relate to webinos:

CAPEC¶

The Common Attack Pattern Enumeration and Classification (CAPEC) is a database of methods for attacking systems based on the style of Design Patterns. Attack Patterns try to be sufficiently abstract that they can be translated between different systems. For webinos, the CAPEC database has been imported into the CAIRIS tool and used as a source of threats. The webinos attack patterns are defined with the additional details of the webinos architecture but are often inspired and closesly related to CAPEC attack patterns. (CAPEC)

CWE¶

The Common Weakness Enumeration (CWE) provides a "unified, measurable set of software weaknesses". The CWE database of vulnerabilities was added to the CAIRIS tool and aligned with attack patterns. (CWE)

OWASP¶

The Open Web Application Security Project (OWASP) provides a wealth of data on attacks and threats to web applications. Dozens of threats and attacks have been added to the CAIRIS tool based on the OWASP project and then aligned with attack patterns. (OWASP)

Threat Model and Trusted Components¶

In this section we describe the activities and actions that each of the core webinos components are trusted or explicitly not trusted to perform. The value of this threat model is that it makes explicit the assumptions behind which components we are relying on and, therefore, how each may be exploited to attack the overall system. The threat model helped to inform the attack patterns and obstacles described in the risk analysis.

This trust model is taken from the perspective of a webinos personal zone user.

The following components are covered in this model:

• Personal Zone Proxy (PZP)
• Personal Zone Hub (PZH)
• Identity Provider
• Name resolution service
• Platform: device + OS + other applications
• Widget Renderer
• Browser
• Widget Processor
• Applications

A complete list of potential actions and activities is given in the appendix. Some actions are generic and therefore a modifier may exist to explain what this action refers to in this context. For example, "Storing data - confidentiality" may have the modifier "policies" referring to the fact that this component is trusted to store policies confidentially. This is represented as a separate column.

Personal Zone Proxy (PZP)¶

Users need to trust the PZP to have almost complete control of the local device, and to access all local APIs it provides. However, as designers should be wary of trusting every PZP absolutely. The inability of a PZP to protect itself against malware makes the possibility of a zone being hijacked by a rogue PZP extremely likely. It should also not be overly trusted for authenticating the end user: different devices will have different capabilities with regards to authenticating users.

There is also a significant threat from a device being joined into a malicious personal zone without the user's knowledge. This is why it is trusted to maintain the integrity of certificates and policies.

Trusted for

Sometimes trusted for

Explicitly not trusted for

Personal Zone Hub (PZH)¶

The Personal Zone Hub is trusted with some of the most important aspects of the personal zone. It is not given access to individual device private keys (this allows any device to implement its own storage and generation mechanism) or allowed to edit local policies on individual devices, but almost everything else is permitted.

Trusted for

Sometimes trusted for¶

Explicitly not trusted for

Identity Provider (OpenID Provider)¶

We require that the user has a trustworthy identity provider. However, the webinos framework has no way of enforcing this, and therefore must trust that users select an appropriate option. In addition, we have no mitigation for attacks resulting from flaws in OpenID

Trusted for

Explicitly not trusted for

Name resolution service (WebFinger / User lookup service)¶

The name resolution service converts user identities into personal zone hub URLs. We assume that the name resolution service is either provided by a well known authority (such as webinos.org) or the identity provider themselves.

Trusted for

Platform: device + OS + other applications¶

The webinos PZP software will run on an existing platform, including an operating system and applications. This is the source of many potential attacks, particularly related to malware. Device operating systems and applications are responsible for protecting themselves against malware. However, this is often shown not to be reasonable as new malware and vulnerabilities are published frequently. As such, a key threat is the presence of malware on a device and therefore on webinos.

Trusted for

Explicitly not trusted for

Widget Renderer¶

The widget render displays widgets to the end user. They may be vulnerable to a wide range of attacks from malicious users or applications, including:

• Shoulder-surfing attacks
• Widgets could be designed to exploit the renderer code, either by modifying what is rendered or by launching attacks on the underlying system
• XSS, CSRF, session hijacking

Trusted for

Explicitly not trusted for

Web Browser¶

Applications in webinos may be displayed from within a web browser. These are vulnerable to a wide range of attacks, similar to a widget renderer.

Trusted for

Explicitly not trusted for

Widget Processor¶

Widget processors unpack widget packages and install them onto the personal zone. They must be able to validate signatures and maintain records of trusted applications. A widget processor may be part of a widget runtime environment (WRT).

Trusted for

Applications¶

Applications are generally not trusted with user data or APIs unless granted explicit permission. They can be a significant attack vector, as well as being attacked themselves.

Applications can be attacked through:

• Content injection attacks such as XSS and CSRF
• Code could be stolen by competing developers
• Content could be stolen
• Any tokens or secrets contained within the application may be stolen

Applications can be attack vectors:

• Stealing user data
• Privacy violations - monitoring, tracking
• Acting as a botnet client
• Denial of service attacks on the end user
• Exploiting vulnerabilities in the renderers

We have not tried to account for attacks on content within the application.

Trusted for

Sometimes trusted for

Explicitly not trusted for

API Security and Privacy Analysis¶

API Analysis Methodology¶

The API Security and Privacy analysis was carried out using the following methodology and process.

Several partners were invited to review APIs, either due to their security expertise or their involvement with the development of the API and therefore insights into potential threats. These partners included Telecom Italia, Polito, BMW F&T, Sony, and The University of Oxford. Most analysis data was reviewed by another partner before it was considered finished. Participants were invited to fill in the template given below while studying the API specification carefully. The template provided suggestions as to the personas, data sources and attack vectors to consider. Creativity was encouraged as part of this exercise.

The following two data sources were recommended:

• The Mozilla WebAPI security analysis (MozillaWebApi)
• The related W3C / WAC / Other "security and privacy" sections of specifications

Once the process had concluded, the findings were conveyed as a series of recommendations and reported to the API developers and rest of the specification and implementation teams. At the time of writing, several recommendations are still under consideration.

Analysis Template¶

Overview of API¶

Link to API - http://dev.webinos.org/specifications/new/example.html

Brief description of the API

Threats¶

API-Specific threats and misuse cases

1. These are the obvious threats that misuse of this API could cause for users.
2. I have elicited these by considering the assets that the API gives access to, as well as what happens if the API is excessively used.
3. I have taken into consideration several personas.
4. I have looked at the Mozilla approach for this/a similar API - (MozillaWebApi).
5. I have taken into consideration any "security and privacy considerations" section of related specifications.

Threats based on remote invocation of this API from another device

1. When this API is called from another device, what are the additional security concerns?
2. When this API is called from another user on another device, what are the additional security concerns?

Implementation threats and possible attacks

1. Based on my experience in implementation in phase 1, the following attacks might be possible...

Threats to apps and developers using this API (E.g. Jimmy and Jessica)

1. How might a developer be caused harm by relying on this API?
2. How might an app be damaged or attacked through this API?

Threats to device manufacturers, operators, other stakeholders

1. How might other stakeholders be affected - for example, could it cause excessive traffic?

Mitigations¶

1. How should the API be designed, implemented or constrained such that the threats are mitigated?
2. Should the API be turned off by default?
3. Should the API require authorisation always?
4. Should the API result in some kind of notification or logging event?

Recommended default policy rules for applications¶

The following 'types' of application are supported in webinos:

For each application type, one of the below API default policies is recommended. This applies to an application which explicitly requests access to this API.

Several iterations of this table may exist if the API provides distinctly different methods or permissions.

API Security and Privacy Analysis Summary¶

The API security and privacy analysis makes the following suggestions which are not yet incorporated into the API specifications or webinos platform, including:

Investigate a more privacy-friendly way to implement the Discovery API¶

An issue also highlighted as part of the architectural risk analysis, the Discovery API is privacy-invasive because due to its use of persistant identifiers for webinos services; this facilitates user fingerprinting. For applications needing only relatively impersonal services, this API provides unnecessary information. We propose that web intents would be a potential alternative.

Provide an alternative interface to the Messaging API¶

For applications which require only visibility to certain incoming patterns and the need to send occasional messages, an alternative API should be available. The current API is more invasive than may be strictly necessary. A new API might include greater restrictions - such as only being able to send a message if it has first been viewed by the end user - but could also be allowed by default to applications.

Provide an alternative interface to the Calendar API¶

The Calendar API, like the Messaging API, exposes a great deal of information to requesting applications. This is unnecessarily dangerous for an application which requires only the free/busy status of an application rather than precise entry details.

Create a 'system level' and 'web app level' distinction¶

A final consideration for webinos is that there are two quite separate use cases considered by the APIs.

• Smaller applications requiring only slightly more functionality than that provided by the web browser. These are currently given more resources than they need by the Messaging, Calendar and Discovery API.
• System-level applications which are more trusted and need to have greater access to device features. More needs to do more to ensure their webinos runtime environment is secure and immune to attacks on any hosted components.

'web app level' apps should be allowed to run in the browser, and use a more privacy-friendly discovery system. At the same time, these apps should restrict access to some APIs completely.

'system level' apps should run exclusively in a widget renderer, but have the potential to access more APIs. We recommend these only be installed from app stores and must be pre-vetted.

Cloud Security and Privacy¶

Introduction¶

Cloud computing has emerged as a distributed system of choice for many use cases. As a utility, cloud platforms enable a pay-per-use basis, while their dynamic scalability attributes enable automated increase or decrease of resources for a particular service in response to increasing or falling demand, respectively. However, security and privacy remains one of the biggest challenges (Kandukuri-cloud-sec-09); as a result many organisations are reluctant in adopting cloud computing, especially when it comes to critical or sensitive applications.

Despite these challenges, significant strides have been made in the adoption of cloud computing as can be seen by an increase in cloud service offerings in the area of storage (Dropbox), communication and social networking. It is therefore impossible for webinos to completely ignore cloud computing; several applications running on webinos-enabled devices will use cloud services, others applications may be hosted on the cloud or indeed some components, such as the Personal Zone Hub (PZH), may be deployed in the cloud. For example, see the possible PZH deployment profile in the D3.3 informative specifications (Webinos-D33). However, in order for webinos to successfully take advantage of cloud computing or indeed work with services on the cloud, it is important that security and privacy implications are understood.

This section aims to meet this goal by investigating how the use of cloud computing could affect the security and privacy of webinos. More specifically, the section investigates the possible assets that could exist in a cloud-based PZH and how these are affected by common threats and vulnerabilities associated with cloud computing.

The investigations are based on the following scenario. Alice is a technology enthusiast who always wants to take advantage of new technology to make her life easier. She has been encouraged by cloud computing's promise of on-demand provision of resources, global accessibility and pay-per-use model. She recently signed up to Amazon Web Services and has now started using these services; she has so far managed to deploy a gaming application and streaming service. Alice has realised that there are some free compute cycles on her account and she has decided to use those for webinos. Depending on how this goes, she may decide to offer this as a service to her friends. However, before she can do that she needs to understand what the impact of this move on the security of her data and her privacy would be.

To help Alice decide on whether or not it would be ok to use cloud computing, the section begins with some background on general cloud computing issues including its definition and some of the top threats to its adoption. Following this, a security and privacy analysis is performed on a cloud-based Personal Zone Hub. This analysis identifies the assets that may exist in a cloud environment and then investigates how these assets are affected by some of the common threats identified in the background. The section then describes how these threats might be realised.

Background¶

Cloud computing has emerged as one of the hot topics in distributed computing. However, there is still confusion on how cloud computing is defined. Some suggest that it is a new architecture and approach, while others argue that it is simply a modification of the business models rather than a new computation paradigm. In order for the analysis to be useful, this section needs to make clear the view of cloud computing adopted; with the hope that this view will be shared with Alice. For this reason, the next section covers the definition and taxonomy of cloud computing before discussing the security challenges of using it.

Cloud definition, taxonomy and examples¶

Despite significant attempts at defining cloud computing, there is still no consensus on its definition. However, one commonly accepted definition is that from NIST (NistCloudDefinition2011):

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

Central to this definition is the idea of on-demand provision of computational resources (CloudSecMather2009, CloudCompRittinghouse2010) so that users can start with a minimal set of resources, which can be dynamically increased or decreased depending on demand. This enables a pay-per use model where users only get to pay for the amount of resources used rather than for the ownership of those resources. To support this, cloud computing is designed with a number of characteristics.

Service Models¶

Cloud computing services can be provided using three main models:

• “Software as a service” (SaaS) - the customer does not purchase software, but rather rents it for use on a subscription or pay-per-use model
• “Platform as a service” (PaaS) - the vendor offers a development environment to application developers, who develop applications and offer those services through the provider’s platform
• “Infrastructure as a service” (IaaS) - the vendor provides the infrastructure to run the applications, but the cloud computing approach makes it possible to offer a pay-per- use model and to scale the service depending on demand.

• “Communication as a service” - a subtype of Software-as-a-Service model, where providers are responsible for the management of hardware and software, e.g. VoIP, instant messaging, and
• “Security as a service” - a vendor offers security functionalities like e-mail and web content filtering, vulnerability management, etc.

Essential Characteristics¶

NIST identifies five key characteristics of cloud computing including:

1. On-demand self-service - users can request more services any time and the system used can provide these services automatically without requiring human interaction.
2. Broad network access - the services can be globally accessed using standard network mechanisms, enabling users to use different devices such as mobile phones, tablets, laptops, and workstations.
3. Shared resource - a multi-tenant model enables resources to be shared among a number of users while giving an illusion that each user owns the resource.
4. Rapid elasticity - the capabilities and/or capacity of resources can be increased or decreased automatically without affecting the availability of the services.
5. Measurable services - resources used can be transparently monitored and measured for the purpose of billing and monitoring of service-levels

Cloud security models¶

Security concerns about cloud computing include a mix of old and new threats, targeting software bugs, exploiting social engineering, and involving network security and access controls. These exist at different levels including: network, host and application. Sensitive data must be adequately secured at each level to avoid confidentiality and integrity breaches. Furthermore, proper access control, accountability identity and access management must be designed in order to achieve efficient procedures, mitigate complexity, improve user experience, and reduce errors and insecure short-cuts.

Cloud security - network¶

Like all network-based systems, cloud systems expose significant risk at network level. Data in transit to and from the cloud infrastructure may suffer from confidentiality and integrity problems resulting from activities by malicious agents along the path. Unauthorized access can also be problematic when cloud providers do not adopt effective IP address reallocation mechanisms (DHCPDynamicIPAddressing) that ensure that an IP address that was originally assigned to a resource that is no longer needed cannot be used to access that same resource. As a result of this, customers cannot assume that network access to their resources is terminated upon release of its IP address, opening the path to unwanted access.

Cloud system must also guarantee high availability. For example, BGP hijacking (BGPAttacks04) can affect the availability of cloud-based resources, while the use of external DNS querying exposes clouds to DoS attacks.

The use of cloud systems also introduces new and different security boundaries. The established model of network zones and domains is replaced with less precise and firm “security groups”, “security domains” or “virtual data centers”. Conceptually, this allows separation between tiers, but these need to be properly understood if security breaches and improper use is to be avoided.

Network security hardening is necessary to avoid common network attacks. For example, confidentiality and integrity can be assured by appropriate encryption and digital signature, network filters (e.g., firewall) should be shaped and managed by cloud providers. For the sake of accountability and forensics, provider-managed aggregation of security event logs is desirable, and to timely address ongoing problems, network-based intrusion detection system/intrusion prevention system is useful.

Cloud security - host level¶

Although there are few new host level security threats and vulnerabilities, some are inherited from related environments, e.g. some virtualization security threats carry into the public cloud computing environment. Even if the threats are not conceptually new, cloud computing harnesses the power of thousands of compute nodes, combined with the homogeneity of the operating system employed by hosts. This means threats can propagate quickly and easily.

Different cloud models imply slightly different security requirements.

In SaaS and PaaS, host security is opaque to customers. The responsibility of securing the hosts is relegated to the CSP (Cloud Service Provider), who institutes the necessary security controls. These include restricting physical and logical access to hypervisor and other forms of employed virtualization layers.

In the IaaS cloud model, the CSP has to secure the virtualization layer. A vulnerable hypervisor could expose all user domains to malicious insiders. The customer guest OS (or virtual server) is also a point of interest. It has an operating system provisioned on top of the virtualization layer that customers have full access to. Since the virtual server may be accessible to anyone on the Internet, access mitigation steps should be taken to restrict access to virtual instances. It is therefore necessary to adopt a secure-by-default configuration; this includes tracking the inventory of VM images and OS versions that are prepared for cloud hosting.

Cloud security - application level¶

In addition to well known application vulnerabilities, and well known attack types, cloud-based systems can experience other attacks. For example, an application-level DoS attack could manifest itself as high-volume web page reloads, XML web services requests, or protocol-specific requests supported by a cloud service. These kinds of attacks can be particularly dangerous because it is difficult to selectively filter the malicious traffic without impacting the service as a whole (AppLayerDDOSXie). This is because attackers use legitimate HTTP requests to the victim, which are indistinguishable from requests coming from genuine users (AppLayerDDOSXie, AppLayerDDOSMonitor09). DoS attacks on pay-as-you-go cloud applications could result in an increased cloud utility bill due to increased use of network bandwidth, CPU, and storage consumption. Therefore, sufficient protections need to be put in place to prevent resources used by a hijacked or exploited cloud accounts from being enrolled into botnets.

End users should be conscious about security and take appropriate steps to protect their web browsers from attacks. They must install patches and updates in a timely basis to mitigate threats related to browser vulnerabilities. However, as cloud-based services become widespread, relying on users alone will not be sufficient, so providers need to give some kind of assurance of adequate security. This assurance might be in the form of legal responsibility; for example, SaaS providers are largely responsible for securing the applications and components they offer to customers, while customers are usually responsible for operational security functions, including user and access management as supported by the provider.

In a PaaS context, developers need to become familiar with specific APIs for deploying and managing software modules to enforce security controls as part of their product life cycle. In theory, developers should expect CSPs to offer a set of security features, including user authentication, single sign-on (SSO), authorization, and SSL or TLS support, made available via the API. In the IaaS model , however, matters are predominantly left in the hands of end users. Customers should not expect any application security assistance from CSPs beyond basic guidance on firewall policies that may affect the application’s communications with other applications, users, or services within or outside the cloud. customers are responsible for keeping their applications and runtime platform patched to protect the system from malware and hackers scanning for vulnerabilities to gain unauthorized access to their data in the cloud, and highly recommended to design and implement applications with a “least-privileged” runtime model.

Cloud security alliance Top Threats¶

Several organisations and communities have invested significant effort in identifying and characterising cloud computing security issues. An example of such an effort is that by the Cloud Security Alliance (CSA) who have identified top threats to cloud computing (CSA-TopThreats), discussed below.

Abuse and nefarious use of cloud computing¶

The registration process offered by some devices accept anyone with a valid credit card or even worse offer limited trial periods, which may allow spammers, worm author and criminals in general to conduct unauthorized activities with relative anonymity and impunity. This particularly affects IaaS and PaaS models. This threat can be mitigated by employing stricter registration and validation processes, e.g. monitoring of fresh credit card frauds, monitoring of user network traffic (possibly in aggregate form, to respect privacy issue) and monitoring procedures.

Insecure interfaces and APIs¶

Providers should be very careful in exposing software interfaces to interact with cloud services, and design these interfaces adopting proper encryption, authentication, access controls and monitoring to avoid policy circumvention, like anonymous access and or reusable authentication tokens, monitoring and logging capabilities unable to identify key events, unknown service and API dependencies. This kind of problem is quite generic and involve Cloud models of IaaS, PaaS and SaaS types.

To mitigate such a problem, knowledge of dependency chain associated with the API, as well as mandatory strong authentication in concert with encrypted transmission is needed.

Malicious insiders¶

IaaS, PaaS and SaaS models suffer from the convergence of services and customers under a single management domain, often combined with lack of transparency of providers internal processes. In this way, opportunities for harvesting confidential data or to gain unauthorized control over the cloud service can be achieved with little risk of detection.

This is remediable by a proper organizational (e.g. a strict supply chain management with associated supplier assessment) and legal (specification of resource requirements as part of legal contracts) framework. Clear, transparent and well-established information security management, compliance reporting as well as security breach notification processes also contribute towards mitigation of this issue.

Shared technology issues¶

Shared technology must implement strong isolation properties for a multi-tenant architecture. Access of resources should be mediated by the virtualization hypervisor, which manages guest operating systems and prevents improper resource access or control on the underlying system. However, even hypervisors can be flawed, and cause unwanted influence of the underlying platform by the guest operating system.

To prevent this critical issue, which is especially sensitive in IaaS model, security best practice must be adopted when installing and configuring the system. Monitoring system must adequately identify unauthorised changes and suspect activities. Strong authentication and fine-grained access controls should enforce proper administrative access and operations. Vulnerability scanning and configuration audit should be performed periodically, and a proper threat management process should ensure prompt patching and vulnerability remediation.

Data loss or leakage¶

Since data in the cloud can possibly be physically unbound to local users, cloud-based data management must avoid alteration of records with no backup, as well as loss of encoding keys (which may result in effective data destruction) and unauthorized access to sensitive data. This is a general problem which any of IaaS, PaaS and SaaS model have to prevent.

This kind of problem can be mitigated by some security best practice, like detailed API access control, encryption and integrity protection of data in transit (driven by a careful analysis of data protection scheme both at design and run time), implementation of secure key generation and life cycle management (e.g. storage and destruction procedures). An appropriate legal framework is useful as well (e.g. contractual obligations for providers to wipe persistent media before releases of sensitive data, contractual specification of backup and data retention strategies)

Account or service hijacking¶

Being a network based model, clouds are vulnerable to phishing, fraud and software vulnerability exploitation. Given that credentials and password are often reused, the impact of such attacks is amplified. This is because account owners are often unaware that their accounts have been exploited to form the basis of further malicious actions. All IaaS, PaaS and SaaS can suffer of these issues.

A mandatory policy on credentials (e.g. prohibit sharing of passwords or credentials between users and services), and leveraging multi-factor authentication techniques (whenever possible) as well as proactive monitoring to promptly identify unauthorized entities can alleviate impact of this threat.

Unknown risk profile¶

A detailed knowledge of security posture is important for threat prevention. Understanding the software, software updates, security practices, intrusion attempts, and employed security controls are important factors in understanding current risk level and planning adequate modifications. The temptation of employing security by obscurity should be avoided as opaque designs make in-depth analysis difficult. This is a general concern that is valid for all cloud models.

Mitigating practices include providing information about who is sharing the infrastructure, disclosure of network intrusion logs, redirection attempts (and success), and partial/full disclosure of infrastructure details (e.g. patch level, firewalls, etc). Even if not intuitive, these processes foster a more vulnerability-free and secure system.

webinos in the cloud¶

Although webinos is designed to run on devices such as in-car systems and mobile devices, it relies on inter-device connectivity for several aspects of its operation. In particular, keeping a list of preferences synchronized across a user's devices or sharing media content requires the devices to connect to each other or to a mediating component. These devices could be geographically distributed across the globe. As a result, webinos relies on global scale infrastructure such as the Internet to provide connectivity. However, such infrastructures are faced with a multitude of security and privacy problems. webinos' use of these infrastructures imply that it will also be exposed to these problems, and its cross device nature would make it an even more attractive target for attackers. For this reason it is important to understand the impact of webinos' reliance on these infrastructures on the security and privacy of both webinos devices and the data they handle.

Why in the cloud?¶

The webinos architecture proposes to make use of cloud infrastructure to host personal zone hubs (PZHs). The primary requirement of a PZH is that it is constantly available via the internet and is at a known address. High availability is one of the key selling points of a cloud, so this implementation choice makes sense. Alternative scenarios such as a PZH being on a home router are also possible, but unlikely to be as available for users such as our personas Georg and Clara (since these users are quite mobile and may require global access to their PZH).

A cloud-based PZH would need to be provided by a cloud service provider. This would be a service which inevitably cost money, perhaps as part of a mobile contract or with home broadband connection providers. The service could be charged on a per usage basis or as a one-off fee. Cloud hosting would allow for many additional bundled services, such as cloud storage and backup or enhanced security and assurance (see later).

Deploying services on a cloud infrastructure has some widely recognized barriers, which seems acceptable in the webinos case for the following reasons:

1. Availability of service: since the use is limited to a single person, the assurance level provided by cloud providers is acceptable for a personal zone. The synchronisation and data caching features provided by personal zones may be seen as a way of mitigating availability issues. However, in the case of a personal zone hub used by an entire organisation (and 'enterprise zone hub'), it is likely this assumption should be discarded. In that case, one possible risk mitigation strategy would be to have this enterprise hub hosted on multiple cloud providers. In this case, some functionality to synchronising between the two personal zone hubs (hosted by different cloud providers) would be desirable.
2. Data lock-in: occurs when a cloud provider stores or manages a user's data in a way that is only compatible with their system, so that it becomes difficult for the user to move away from the provider. To avoid this problem, the user can export the PZH data and to import it in another cloud. This can be achieved by either directing transferring data between providers or exporting it in some format and re-importing at the other providers.

One of the main expected use of cloud systems in webinos is the hosting of PZHs. For this reason, the following sections provide more comprehensive analysis of the threats and attacks related to running a PZH in the cloud.

Cloud-based personal zone hub and hub provider¶

A personal zone hub (PZH) is a key component in webinos. It provides a consistent means of communication among devices; through its API and services such as synchronization. In this section, we investigate the security and privacy impact of running a cloud-based PZH --- where cloud-based implies that the PZH has been deployed on a cloud infrastructure.

Security Analysis¶

Security analysis is based on previous work described in D2.7 and D2.8. More specifically, the assets, threats and vulnerabilities identified in the two tasks are used as input into the analysis. These are analysed to identify how they are affected by the adoption of a cloud environment.

Analysis approach¶

In order to understand the implications of running a PZH in the cloud, a three-staged analysis approach was taken.

The first stage identified the threats faced by a cloud-based PZH design and the assets that may reside on or be transmitted through a PZH. Using the literature on cloud computing security as it relates to web applications, common vulnerabilities that may exist on a cloud-based PZH were identified, together with the possible attacks that might result from compromising these vulnerabilities. The output of this stage is a list of threats that webinos could be exposed to as a result of running a cloud-based PZH.

Stage 2 involved analysing the current design of the PZH to (i) mine architectural patterns currently in use in the PZH design, and (ii) identify which or to what extend these patterns addressed the threats identified in stage 1.

Stage 3 used the catalogue of architectural patterns to identify the patterns that could be applied to the PZH design. This stage also included an analysis of how these patterns and the ones identified in stage 2 impacted security, privacy, performance and scalability. This analysis produced a matrix specifying the relation of each pattern to its security, privacy, performance and scalability impact on webinos. The matrix was used to identify deployment profiles for PZHs. The figure below illustrates the input and output of each stage as well as the aspects considered in each stage. However, stages 2 and 3 are outside the scope of this document, and will instead be documented on an on-going basis.

Asset Model¶

D2.7 and D2.8 identified a number of assets and assigned security and privacy values associated with each assets in a particular environment. These assets where defined at higher level of granularity, i.e. system level. This section is focused on understanding the impact of running a PZH in the cloud. The PZH is a component of webinos and therefore, to understand the threats associated with it, we would need to firstly map the assets to a granularity suitable for a component.

The approach adopted for specifying the granularity is subclassing, where each asset is broken down into subtypes that are as specific as possible. For instance, an asset such as SynchronisedAppData could be broken down to subtypes such as Media, UserProfile and LocationData. Subclassing allows the association of assets to components to be as specific as possible, thus enabling better analysis.

There are several assets used, generated or stored on a PZH. For simplicity, we categorise the assets into two categories, namely: credentials and functionality-related.

Credentials exist in many forms including certificates, passwords and cryptographic keys. The diagram below illustrates the assets that fall into this category.

The PZH is intended to provide certain key functionality (though the functionality can be extended). As a result of the services it offers, the PZH comes into contact with a number of assets. The diagram below shows the key assets associated with the functionality of the PZH.

Security and privacy requirements for the PZH¶

Before conducing the analysis, however, we need to understand what the requirements are for the PZH towards the assets identified above. Below, we discuss some of the crucial ones.

• Credentials must be held securely, including
  • Certificate authority keys
  • Any passwords or tokens used to access other services and devices - e.g. OAuth tokens
  • Lists of trusted certificates
• Personal data stored on the PZH must be protected. While only the minimum has been specified, webinos may store a wide variety of data such as:
  • Contacts
  • Photos, videos and media
  • Location data
  • The context database
  • Lists of available applications and services
  • Personal settings and information, such as date of birth, home address, identities on other social networks
• The PZH will provide access control through policies and lists of trusted users. These lists are both private and have integrity requirements: they must not be modifiable by another party
• The PZH to some extent represents user identity.
  • Unauthorised access to this identity would allow impersonation and potential identity fraud.
  • Disclosure of this identity may enable a user to be tracked by applications or other devices.

Threats to a cloud-based PZH¶

Significant effort by organisations such as Mitre Corporation (Mitre), NIST (NIST), cloud security alliance (CSA) and other communities, has been directed towards identifying and classifying common threats that impact computer systems. Some of the most significant threats that exist in a cloud environment were discussed earlier. These threats affect different parts of a system including input, output and in memory. The PZH is not immune to these attacks. Moreover, some of the design choices for the PZH, such as running it in the cloud, could make the risks of these threats greater. For this reason, it is important to understand the threats that affect the PZH, especially in relation to its cloud adoption.

In this section, we analyse the common threats to identify which of these affect the PZH and in which instances they do so.

Insider credential misuse

In the asset model discussed above, several credentials were identified. For example, the private key used to sign digital certificates issued to devices connecting to the PZH was identified to both be highly confidential and requiring high integrity. These credentials may be required to be stored in the PZH to enable it to provide its services. The CSA includes malicious insiders as one of the top threats to cloud computing. A PZH deployed in the cloud could suffer from this threat and allow malicious insiders to steal the credentials. Alternative, non-malicious users, eg. administrators, may unwittingly expose these credentials, eg. through backups. These leaked credentials can be used to impersonate the PZH instance (eg. when its private key is compromised) or issue certificates on behalf of the PZH.

Unauthorised PZH duplication

One of the main advantages of cloud computing is the ease of service provisioning, enabled by mechanisms such as migration and virtual machine cloning. This feature enables PZHs to be easily instantiated in response to client requests for PZH instances. Additionally, new PZH instances can also be created in response to increased demand for services from a particular PZH. In this case provisioning of a PZH may be achieved by either cloning an existing PZH or using a standard PZH template. In the former, data stored within the PZH may be exposed as a result. Alternatively sensitive PZH configurations may be leaked. In the latter, PZH may end up sharing configurations, which if if insecure and not modified, may result in break-once-run-everywhere kind of attacks.

Loss of data such as synchronisation data

A PZH once deployed provides a number of services such as synchronisation and routing. These services handle various data such as media, personal media preferences or contacts. This data does not have high availability requirements, but if stored on the PZH alone, could have significant effects on usability if lost. The issue with cloud computing, as discussed in the data loss threat from CSA, is that it provides a number of interfaces through which data may flow and thus increasing the attack surface.

Misuse or compromise of interfaces

Cloud infrastructures are complex in nature. To manage this complexity, cloud infrastructure provide several abstraction layers which hide the underlying complexity by limiting accessibility of the services to specially designed interfaces. These interfaces may, however, be poorly designed or have vulnerabilities which may lead an attacker to either misuse them (eg. sending well crafted exploit code) or access services they are not authorised to access. Deployment of a PZH in the cloud magnifies this problem. This is because the PZH itself, provides a number of interfaces through which its services may be accessed. These interfaces interact with with interfaces provided by the underlying cloud infrastructure. Therefore any weakness or flaws in either the interfaces of the cloud infrastructure or the PZH itself could lead to compromise of the PZH or the assets stored on it.

PZH integrity compromise resulting from insecure isolation

A PZH deployed on the cloud would have to share the resources with possibly other PZHs or other applications. While cloud computing relies on virtualization to provide isolation, several attacks have demonstrated that virtualisation may not always provide complete isolation between services hosted on the same physical resource. CSA identifies this as a threat resulting from sharing technology.

In the asset model, several PZH components were identified to be assets as well, due to their relationships with other assets. For example, the session Manager handles authentication and also comes into contact with other assets such as private keys. A compromised session manager could easily expose sensitive data or compromise its integrity. For this reason, the integrity of some of the PZH components is considered to be critical for the well functioning of the PZH. The threat of shared technology could affect the integrity of the PZH components. In other words PZH instances running in the cloud may not be securely isolated from other services sharing the same resources, resulting in the compromise of the PZH integrity.

Privacy breach as a result of identifiable PZH

When hosted in the cloud, the PZH will need to be linked to the user for the purpose of billing. For this same purpose, PZH providers may need to monitor activities on a PZH instance, e.g. to enable pay-per-use of particular added-on services. As a result of this, PZH cloud providers may be able to deduce sensitive information about the activities of the PZH owner such as the services they accessed, leading to a privacy breach. Furthermore, as indicated in the account or service hijacking threat, attackers may perform certain activities which would be traced back to the owner of the PZH.

Sensitive residue migration data

The use of cloud computing for the deployment of a PZH makes it easy to switch from one provider to another; this is achieved through migration services provided by most cloud offerings. This means that a PZH instance can be migrated from one provider to another or from one platform to another, i.e. as part of load balancing. Migrating a PZH instance may involve moving the entire execution environment, such as virtual machine, from one system to another or copying data that is specific to a particular PZH instance into another environment capable of running a PZH. In both cases residue data, which could potentially include sensitive data such as keys, database backs or PZH configurations, may be left on the original host. This data could be used to mount attacks on the new PZH instance or leak sensitive information.

Data leakage by VM replication

Similar to the threat of residue migration data, sensitive data could also be leaked by cloning a PZH instance. Suppose Alice requires high availability for her PZH, then as a solution, a cloud provider could create several instances of the PZH, each with a copy of all of Alice's data, so that in an event that the main instance goes down, eg. for maintenance, any of the cloned instances could be provisioned to serve any incoming requests. The main threat here is that of an increase in the attack surface. So that if any of the cloned instances have some misconfiguration, then an attacker could take advantage of that and exploit the PZH.

Compliance and Unauthorised Data Disclosure

One of the challenges faced in cloud computing is that of data location (Kandukuri-cloud-sec-09, Binning-top-cloud-issues-09). Whereas traditional dataware mechanisms provide visibility of the location of data, the use of a cloud environment makes this completely transparent. This means that data could be stored in a data centre anywhere in the world. This means that information may cross the border, raising concerns about forced data disclosure.

In Alice's case, the PZH could be running on a server where the cloud provider might be forced, under laws such as the Patriot Act (USPatrioticAct-UnderFire-04), to release the data to government agencies. This has the potential to disclose all the sensitive information such as Alice's activities and behavioural patterns and media content.

Cloud specific vulnerabilities¶

The previous section presented some possible threats to a PZH running in the cloud. However, in order for an attacker to realise these into attacks, there has to be some exploitable vulnerabilities in the system. One of the challenges in analysing the security and privacy impact of cloud computing is understanding if at all there are specific vulnerabilities that exist solely because of the use of a cloud environment. Grobauer et al. (Understanding-cloud-vulns) specifies the characteristics of cloud specific vulnerabilities to include:

• is intrinsic to or prevalent in a core cloud computing technology,
• has its root cause in one of NIST’s essential cloud characteristics,
• is caused when cloud innovations make tried-and-tested security controls difficult or impossible to implement, or
• is prevalent in established state-of-the-art cloud offerings.

Using this characterisation, they identify some vulnerabilities specific to cloud environment as well as how some common vulnerabilities equally apply to cloud. These vulnerabilities are summarised in the table below, which also indicates relationship to CWE where possible.

Extending the PZH functionality¶

While the PZH is designed to provide services necessary to support cross device connectivity, it is not hard to imagine instances where such a design may be insufficient (i.e. in terms of features). Furthermore, it is hoped that webinos will inspire some creativity, some of which will be applied to the PZH functionality. For example, Alice may come up with value-added services and offer her PZH to other people, for a fee. These services may be implemented as applications which are strongly tied to a particular PZH instance, PZH farm or PZH session. In order to understand the security and privacy implications of a cloud-based PZH, it is necessary to expand the scope of a PZH to include applications that may be integrated into it. These applications may be vulnerable to certain kinds of attacks, and thus may expose webinos to even more attacks.

Alice could decide to integrate one of the applications that she uses to manage her documents with webinos, so that all the preferences and documents could be synchronized on her devices. This application may need to know about the nature of Alice devices, for example to create versions of documents compatible with each device. To achieve this, the application would need to communicate with the PZH, enrol into the personal zone and discover information about other services in the personal zone.

webinos supports web applications that are downloadable widget packages as well as fully web-based hosted applications. Hosted web applications are often cloud based, relying on cloud storage, databases, or even hosted on a cloud infrastructure. The design and structure of these applications is largely out of scope. However, the project will be considering the security and privacy of the concept applications, as well as how webinos infrastructure can assist cloud-hosted applications to make them more trustworthy.

Hosting such an application could be beneficial for Alice, as she could use it on-demand and only pay according to how much she uses. However, the question of the implication on the security and privacy of assets still remains. Firstly, the application could be considered a virtual PZP. In this case, the application might have access to all the data in the personal zone, including contacts, personal preferences, location data and API usage data. Most likely, such an application will be designed to store this information in a database. Therefore, even though the PZH could be secure, flaws in such an application or the underlying database system might lead to compromise of asserts in the personal zone.

The application might also incorporate other services from unknown or untrusted providers. These services may have access to the data handled by the application and therefore to the asserts. Storage mechanisms used by the application could also be another source of concern. Furthermore, the authenticity of the application and the trustworthiness of the developers deserve some attention. And finally, the level of permissions given to such virtual PZPs could lead to them accessing data they should otherwise not be expected to access or perform actions that they should not.

Mitigations and opportunities¶

This section has identified a number of threats and vulnerabilities that could be used to compromise the assets on a PZH. The question that this raises is, how well placed is webinos to counteract these threats? webinos already employees some mechanisms to counteract these threats. However, more needs to be done in order to adequately cater for each of these issues. Some of the important ones are discussed below:

• webinos credential storage - credentials have been identified as one of the main assets in a PZH, which if compromised could have significant impact on the security and privacy or other aspects of webinos. These credentials could be accessed due to insufficient protection mechanisms on them. For example malicious insiders could access the credentials and use them to impersonate the PZH. For this reason, better protection mechanisms should be put in place to prevent these attacks. A common principle that might help with this problem is isolating the credentials from the data and or services to which they are applied.

• Better credential management - in addition to secure storage, the use of the credentials also needs to be properly controlled. Any key that is used must be tied to a well specified usage policy and must explicitly be specified with an expiry period after which the key should be considered compromised. Any backup procedures used for the keys must also be implemented to avoid leakage of these keys. Furthermore, when a PZH instance is migrated, the previous keys must be carefully destructed and new ones created.

• PZH instance life-cycle management - a PZH will run on VM instances that may be incorrectly configured or have outdated software. In order to avoid the attacks resulting from exploiting the underlying environment in which a PZH runs, it is important the that life-cycle of each VM used to host webinos is properly managed. This involves putting in place effective patch and configuration management processes as well as transparency in the creation process of these VMs.

• Potential for cloud-based attestation of devices - the devices used in a personal zone could also be attested to ensure that they have some minimum configurations that ensure protection of personal zone asserts. The Attestation API, already implemented in webinos, could be used more often to identify devices and their configurations. This could also serve as a basis for identifying the possible behaviour of virtual PZPs before admitting them to the personal zone.

• Use of cloud based intrusion detection and traffic analysis - the issue of inadequate logging and monitoring facilities in the cloud has significant impact on the security and privacy of the PZH. For this reason, it is essential that logging and tracking mechanisms are employed to track events on a cloud host and to detect and find the cause of breaches. Dedicated log servers and intrusion detection systems capable of collecting security relevant events must be used all the time.

• Reclaiming cloud-based data - one advantage that cloud-based web applications may gain from webinos is the ability to store data reliably on the user's own platform. At present, web applications such as Google Docs store data centrally, to provide access from anywhere, backup, and synchronisation. As webinos will provide these through the PZH and its own infrastructure, private data can be reliably stored using browser local storage. This has advantages for privacy: while this data is still accessible to the application, if the user decided to delete it, the data is no longer available. Furthermore, the user can enforce their own policies for passing data to a third party. This may be an advantage for application providers, as they will be able to avoid data protection requirements by not holding personal data themselves.

• Better and verifiable VM provenance - the VMs used to host the PZH might introduce vulnerabilities due to improper configuration or use of vulnerable components. For this reason, the provenance of the VMs must be securely collected in a manner that enables verification of key properties (NamilukoVMProvenance2012). This provenance should include the origin and integrity of the components used, the configurations applied and operations performed to prepare the VM in readiness for use in hosting a PZH.

• PZH architecture considerations - the PZH could be designed using several approaches. For example, the current implementation is such that the PZH operates similar to a monolithic kernel - storing all the data and providing all the services from a single component. Other alternative designs should be careful considered and evaluated to determine how they fair against cloud related threats. This work will be performed as part of stages 2 and 3 in the analysis, as discussed above.

Summary and conclusion¶

The promise of unlimited resources, on-demand service and pay-per-use model of cloud computing is significantly attractive to webinos. However, the use of cloud computing has the potential to expose webinos to significant security and privacy risks. While several attempts have been made to identifying and classifying cloud-related security and privacy issues, these need to be put into context in order to understand how the use of a cloud could affect webinos. This understanding enables users to make informed decisions about the choice of a cloud environment for webinos. To a user thinking about deploying a PZH in the cloud, understanding the kinds of assets such as credentials and synchronisation data that could exist in the cloud and the threats that these could be exposed to is vital in deciding whether or not the risks of running a PZH in the cloud are worth taking. To a provider, or indeed some one thinking about offering PZH services to other users, this understanding is vital in deciding the level of risk that their customers would be exposed to as well as in deciding how much of the responsibility they would be willing to carry. This section provides information necessary to develop such an understanding. By analysing the functionality of a PZH, several critical asserts were identified. These include media content, credentials such as private keys used in authentication, PZH users list and calendar data such as contacts and appointment schedules.

Key Findings¶

The key findings of the investigations in this section can be summarised as follows:

• webinos can take advantage of flexible, on-demand and pay-per-use services enabled by the adoption of a cloud-based system,
• security and privacy issues must, however, be identified, characterised and addressed before webinos can take full advantage of cloud computing,
• the analysis demonstrates that significant number of assets may be exposed to common security and cloud-specific threats and therefore require careful consideration of the risks involved,
• vulnerabilities in the underlying infrastructure or environment used to host a PZH or resulting from inherent characteristics of cloud computing or the technology it employs could be exploited to compromise the security and privacy of the assets on a PZH,
• a number of mitigations could be employed to reduce or eliminate some of the threats, such as better architecture for the PZH that employs principles such as separation of concern and security in-depth. However, certain kinds of threats such as compliance and jurisdiction may be outside the reach of webinos, instead, webinos would have to hope for a quicker maturity in the cloud offerings.

Recommendations¶

This section has presented the threats and vulnerabilities that a cloud-based PZH could be exposed and which Alice would have to aware about. But what does this mean to Alice, or anyone thinking about using webinos in the cloud? Based on the analyses performed, the following recommendations are provided:

• Minimal PZH services - the architecture of the PZH must be designed with a minimal set of services following the principle of separation of concern. The impact of the architecture of the PZH on security and privacy will be investigated as part of stages 2 and 3
• Secure design principles - well known security principles such as security in-depth and separation of concern must be employed in the design of the PZH, while other principles such as security by obscurity must be avoided.
• Transparency - cloud offerings must be more transparent to allow the users to see the configurations of their instances, staff hiring procedures and management processes involving their data and credentials.
• More research in personal clouds - webinos bridges the gap between a user's devices, allowing them to share data and services. The use of the cloud makes this more interesting, inspires creativity and opens up a number of challenges in terms of how this personal space, which was initially restricted to physical devices, can be securely managed. This calls for further research. Perhaps more collaboration with projects such as TClouds could have mutual benefits to webinos and other projects.
• To Alice on hosting a cloud-based PZH - Alice can go ahead and set-up a personal zone with minimal devices and keep her VM up to date. Furthermore, she must take advantage of current security mechanisms such as secure cloud storage and take advantage of the latest advancements in cloud security.

How will this analysis be useful in the future?¶

One of the efforts that have already began is putting the attacks within the context of the webinos architecture. For example the Architectural Risk Analysis involved creating attack patterns for various aspects of webinos and linking them to architectural patterns for the purpose of understanding how the architecture deals with these threats. The work presented in this section could be used as a first step towards understanding webinos architecture's readiness for the cloud.

Recommendations¶

This section gives advice and recommendations to stakeholders responsible for certain aspects of the webinos environment in order to minimize security and privacy concerns. These are in addition to general best practice guidelines on security and privacy. A list of webinos stakeholders can be found in the (Glossary) accompanying the main D3.3 specification.

For Identity Providers¶

Identity providers are highly trusted with the webinos architecture as their ability to authenticate users is relied upon to protect the personal zone. Compromise of an OpenID identity used to manage a personal zone would result in a potential loss of data, personal privacy and could be used to perform a number of other attacks.

We therefore recommend that identity providers do the following:

1. Implement OpenID PAPE extensions. This allows webinos to dictate when a user should re-authenticate, rather than relying on the OpenID provider to correctly implement authentication caching.
2. Provide and encourage two-factor authentication. The threat of identity theft and compromise of OpenID credentials is significant and hard for webinos to mitigate. A solution, however, might involve integrating the webinos PKI infrastructure with OpenID in order to provide a second factor of user identity.
3. Provide recovery mechanisms based on secure out-of-band communication methods. This will help avoid attacks based on a malicious user recovering the credentials of another person, an attack we cannot mitigate in webinos.
4. Follow best-practice guides (OpenIDBest) to avoid insecure implementations of OpenID protocols.

For PZH Providers¶

Personal zone hub providers are trusted in the webinos architecture with the ability to control a user's personal zone. In the T3.3 informative sections on PZH deployment we describe several potential architectures which can mitigate some of the trust placed in webinos personal zone hubs.

For a provider attempting to offer services and preserve user privacy and security, we suggest the following:

1. Store all user data on encrypted disks. Do not allow any third parties to access this data directly.
2. Monitor incoming connection traffic to detect potential attacks on web interfaces and PZH TLS servers.
3. Only support OpenID providers who follow the recommendations specified above
4. Support trusted hardware modules in order to secure keys and credentials

For Device Manufacturers¶

1. Provide user-to-device authentication methods which will mitigate threats from devices places in shared environments. For example, providing PINs or locks that are easy to use yet provide some real resistance from casual attackers. This is important in webinos as access to the device is sufficient, in some cases, to access part of the entire personal zone.
2. Provide disk encryption by default. Webinos makes no attempt to encrypt application data, recognising that this is something that can be provided more effectively by devices. Enable the disk encryption facilities of the device before shipping it with webinos.
3. Use an operating system that provides process isolation. The webinos platform assumes that processes are isolated from each other and is more secure if each application has its own area of protected storage. This can be found in operating systems such as Android and iOS, and can be configured in Linux using Linux Security Modules such as SELinux and AppArmor. Native malware is a threat that webinos cannot protect against, and therefore operating systems must provide isolation between processes and data used by each process.
4. Provide data backup solutions.

For Application Developers¶

There are numerous guidelines and recommendations for the secure and privacy-preserving development of web applications. Secure software development is a topic covered by hundreds of books and articles which we do not repeat here. However, we suggest that developers are aware of the following existing literature:

• The OWASP development guide (OWASP-Guide)
• W3C "Web Application Privacy Best Practices" - (W3CAppPriv)

We also encourage application developers to request as few webinos feature permissions as possible, and to register their applications with well-known app stores.

Finally, for hosted applications we recommend the WebSand project (WebSand) as a source of useful security guidance.

For Users¶

Users of webinos should be aware that webinos is only as secure as the various components and entities it relies upon. As such, users should be careful in choosing:

1. The devices they use webinos with. If webinos is to be used securely, devices should provide disk encryption. Devices should also either be used only by the zone owner, or offer user accounts which separate users from each other. For shared devices, such as TVs, users should be careful to avoid granting them too many permissions
2. The OpenID provider they use. We recommend the use of an OpenID provider who offers two-factor authentication
3. The PZH Host they choose. PZHs are highly trusted within the architecture, and users should not choose a provider they do not believe to be reliable
4. The applications they grant privileges to. Applications are a major source of threats, and we recommend that applications are not granted privileges without reason.

However, most of these responsibilities should not be shouldered by the user as (in many cases) they are not in a good position to make informed decisions. As such, these recommendations should primarily be followed by device manufacturers, service providers and app stores.

Conclusion¶

This deliverable presents the results of a large analysis of the webinos architecture with respect to security and privacy. We have incorporated data from related systems, academia, other webinos deliverables, the OWASP, CAPEC and CWE projects in order to assess the resistance of webinos to attacks and how it can be improved in the future. The document departs from the format of D3.5, in that all specifications for functionality can now be found in the D3.3 specification documentation.

As part of this work we have performed an architectural risk analysis, developed a threat model, analysed the majority of webinos APIs for security and privacy issues, performed an in-depth analysis of how webinos is affected by the use of cloud components, and presented a set of recommendations for stakeholders. In this final section we present our overall conclusions.

Summary of results¶

The webinos architecture, as specified in Deliverables 3.3 and 3.4 is resistant to several of the attacks described by attack patterns in the architectural risk analysis. While some unmitigated obstacles were found as part of the architectural risk analysis, many of these can be delegated to other entities such as the identity providers, operating systems and browser developers. Denial of service issues do not appear to be a great threat, and primarily affect components outside of webinos. Cloud security and privacy issues have been considered, including threats from hosting providers, errors in service migration and misuse of complex interfaces. However, assuming that best practices in cloud security are followed and that the scope of a webinos personal zone hub does not increase too dramatically this seems a reasonable risk considering the potential benefits. Furthermore, there is an opportunity for further research into mitigating some of the risks to cloud-based personal zone services. Finally, a significant number of API-related issues were identified and several mitigations have been designed and proposed for developers and specifiers.

Our analysis should not be considered final or complete. We have considered 14 attack patterns and 24 API specifications, but more exist and will need to be specified in the coming months. Our models of the webinos architecture can also be expanded to include more areas. However, the data we have presented is accurate, grounded in the specifications and results of previous deliverables, and covers a wide variety of functional areas in webinos.

The following changes to webinos may be considered as a result of this deliverable. Firstly, support for unmodified web browsers in webinos might be dropped in favour of customised webinos extensions. This will help satisfy many of the goals in the ambiguity analysis. The introduction of "Sensor Widgets" as described in (Gibraltar) may be considered in the final phase of the project to counter many API-specific misuse cases. Some APIs could be improved for less trusted applications, such as the messaging and discovery APIs. With regards to the overall system architecture, the webinos personal zone hub could benefit from restructuring to minimise the burden placed on any individual cloud provider.

Making use of these findings in webinos¶

These findings can be used by webinos in the following ways:

1. The threat model can be used to check design decisions and to justify the placement of new features
2. Obstacle models and the leaf obstacles can be used to motivate and encourage the development of the platform
3. The API analysis will be used by implementers and specifiers to avoid the threats identified.
4. This process can be integrated with the requirements update process to make sure that new features, proposed internally or externally, do not violate any of the security assumptions or existing mitigations in the architecture
5. The recommendations from the 'summary' page of the architectural risk analysis can inform the roadmap of webinos deliverables

Making use of these findings outside of webinos¶

Because the process followed in the architectural risk analysis is novel and based on publically-available data on threats and weaknesses, we intend to publish our findings and data on a public GitHub repository. This will allow other projects to identify how we have performed our analysis and compare with their own. It will also allow implementers, application developers, platform integrators and others to assess the risks involved with using webinos and whether it matches their environment. We also believe it will be useful as a source of material for academic data.

We have also proposed a set of recommendations for stakeholders within webinos, with particular emphasis on identity providers, pzh providers, device manufacturers and application developers. We have also outlined some key mitigations to security issues associated with the APIs being standardised by webinos which will be useful for any developers wishing to extend the platform.

Future security and privacy activities in webinos¶

The work described in this deliverable provides a consistent framework for changing and updating the security and privacy features in webinos. Security and privacy activities in webinos continue after August 2012, and during the remaining time we intend to do the following:

1. Integrate the data security and API analysis with the formal CAIRIS-based process
2. Create more attack patterns and integrate the draft patterns using CAIRIS.
3. Search for more input from outside sources of threats and weaknesses, such as the Cloud Security Alliance and privacy literature.
4. Analyse the remaining APIs not covered in this deliverable.
5. Begin the process of addressing the weaknesses and ambiguities identified in the system specifications.
6. Update the attacker personas; these were found useful during the creation of attack patterns - to represent more relevant attackers. In particular, attackers of cloud systems.
7. Make use of the premortems approach described in (Faily2012)

References¶

Akhawe2012¶

Devdatta Akhawe, Prateek Saxena, and Dawn Song
Privilege Separation in HTML5 Applications
USENIX Security Symposium, 2012
https://www.usenix.org/conference/usenixsecurity12/privilege-separation-html5-applications

Anderson2008¶

Ross Anderson,
Security Engineering: A Guide to Building Dependable Distributed Systems, 2nd edition,
John Wiley & Sons, August 2008.

AndroidManifestPermission¶

Android Developers Reference: Manifest.permission API
Fetched June 2011
http://developer.android.com/reference/android/Manifest.permission.html

AndroidOverview¶

Sunitha Medayil Vijayamma,
A Security Overview in Google’s Open Source Android Phone
2009
http://www.scribd.com/doc/25036401/A-Security-Overview-in-Google-s-Android-Phone

AndroidSecurity¶

Android DeveloperGuide: Security and Permissions
Fetched June 2011
http://developer.android.com/guide/topics/security/security.html

AndroidSecurityOverview¶

Android Security Overview
Google, 2012
http://source.android.com/tech/security/index.html

AndroidSurvey¶

Kamran Habib Khan and Mir Nauman Tahir,
Android Security, A survey. So far so good.
July 2010
http://imsciences.edu.pk/serg/2010/07/android-security-a-survey-so-far-so-good/

AppleIosSec¶

iOS Security
Apple
May 2012
http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf

AppLayerDDOSXie¶

Yi Xie; Shun-Zheng Yu;
A Novel Model for Detecting Application Layer DDoS Attacks
Computer and Computational Sciences, 2006. IMSCCS '06. First International Multi-Symposiums on , vol.2, no., pp.56-63, 20-24 June 2006
doi: 10.1109/IMSCCS.2006.159
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4673677&isnumber=4673661

AppLayerDDOSMonitor09¶

Yi Xie and Shun-Zheng Yu.
Monitoring the application-layer DDoS attacks for popular websites.
IEEE/ACM Trans. Netw. 17, 1 (February 2009), 15-25. DOI=10.1109/TNET.2008.925628
http://dx.doi.org/10.1109/TNET.2008.925628

Atzeni2011¶

Andrea Atzeni and Cesare Cameroni and Shamal Faily and John Lyle and Ivan Flechais
Here's Johnny: a Methodology for Developing Attacker Personas
Proceedings of the 6th International Conference on Availability, Reliability and Security
IEEE Computer Society, 2011
pp. 722--727

B2GAppSec¶

Boot 2 Gecko App Security
Mozilla
August 2012
https://wiki.mozilla.org/Apps/Security

B2GAppSecDis¶

Boot 2 Gecko App Security Model Discussion
Mozilla
May 2012
https://wiki.mozilla.org/Apps/Security/Discussion

B2GRuntimeSec¶

Boot 2 Gecko Runtime Security
Mozilla
June 2012
https://wiki.mozilla.org/B2G/Architecture/Runtime_Security_Model

BGPAttacks04¶

Ola Nordstr\&\#246;m and Constantinos Dovrolis
Beware of BGP attacks.
SIGCOMM Comput. Commun. Rev. 34, 2 (April 2004), 1-8. DOI=10.1145/997150.997152
http://doi.acm.org/10.1145/997150.997152

Binning-top-cloud-issues-09¶

Bin09 David Binning, Top Five Cloud Computing Security Issues, Computer Weekly, April
24, 2009, <URL: http://www.computerweekly.com/Articles/2010/01/12/235782/Topfive-cloud-computing-security-issues.htm>.

BONDI¶

BONDI Architecture and Security Requirements
July 2009
http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_v1_01.pdf

BONDIv1.1¶

BONDI Architecture and Security Requirements v1.1
January 2010
http://bondi.omtp.org/1.11/security/BONDI_Architecture_and_Security_v1.1.pdf

Buschmann1996¶

Frank Buschmann and Regine Meunier and Hans Rohnert and Peter Sommerlad and Michael Stal
Pattern-oriented software architecture: a system of patterns
Wiley, 1996

CAIRIS¶

Computer Aided Integration of Requirements and Information Security
August 2012
http://github.com/failys/CAIRIS

ChromeNpapiExtensions¶

Google Chrome Extensions: NPAPI Plugins
Fetched June 2011
http://code.google.com/chrome/extensions/npapi.html

CAPEC¶

The MITRE Corporation
Common Attack Pattern Enumeration and Classification (CAPEC) web site
July 2012
http://capec.mitre.org

Carlini2012¶

An Evaluation of the Google Chrome Extension Security Architecture
Nicholas Carlini, Adrienne Porter Felt, and David Wagner
USENIX Security Symposium 2012
https://www.usenix.org/conference/usenixsecurity12/evaluation-google-chrome-extension-security-architecture

ChromeHosted¶

Hosted Applications Documentation
Google
June, 2012
https://developers.google.com/chrome/apps/docs/developers_guide

ChromeUserId¶

Chrome User Identification
Google, 2012
Originally: http://developer.chrome.com/trunk/extensions/apps/app_identity.html
Now: https://developers.google.com/chrome/web-store/docs/identify_user
(On the 30th August Google changed and broke many of their links, causing some of these pages to move or be deleted)

ChromePackaged¶

Packaged Apps - Disabled Web Features
Google, 2012
Originally: http://developer.chrome.com/trunk/extensions/apps/app_deprecated.html
(On the 30th August Google changed and broke many of their links, causing some of these pages to move or be deleted)

ChromeManifest¶

Chrome Manifests
Google, 2012
Originally: http://developer.chrome.com/trunk/extensions/apps/manifest.html
Now: http://developer.chrome.com/extensions/manifest.html
(On the 30th August Google changed and broke many of their links, causing some of these pages to move or be deleted)

ChromeCSP¶

Chrome CSP for Packaged Apps
Google, 2012
Originally: http://developer.chrome.com/trunk/extensions/apps/app_csp.html
(On the 30th August Google changed and broke many of their links, causing some of these pages to move or be deleted)

ChromePermission¶

Chrome API Permission Warnings
Google, 2012
Originally: http://developer.chrome.com/extensions/permission_warnings.html
(On the 30th August Google changed and broke many of their links, causing some of these pages to move or be deleted)

ChromiumSec¶

Chromium OS Security Overview
Google, 2012
http://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview

Cloudberry¶

Taivalsaari, Antero; Systä, Kari.
Cloudberry: An HTML5 Cloud Phone Platform for Mobile Devices
In IEEE Software, Volume 29, Issue 4, August 2012
http://dx.doi.org/10.1109/MS.2012.51

CloudCompRittinghouse2010¶

John W. Rittinghouse and James F. Ransome
Cloud Computing. Implementation, Management, and Security
CRC Press, 2010

CloudSecMather2009¶

Tim Mather, Subra Kumaraswamy, and Shahed Latif
Cloud Security and Privacy, an Enterprise Perspective on Risks and Compliance
O'Reilly, September 2009

Cox2006¶

Cox, Richard S. and Gribble, Steven D. and Levy, Henry M. and Hansen, Jacob Gorm
A Safety-Oriented Platform for Web Applications
In Proceedings of the 2006 IEEE Symposium on Security and Privacy
Pages 350 - 364
IEEE Computer Society Washington, DC, USA
http://dx.doi.org/10.1109/SP.2006.4

CSA¶

Cloud Security Alliance
https://cloudsecurityalliance.org/Cloud Security Alliance (CSA)

CSA-TopThreats¶

Cloud Security Alliance (CSA),
Top Threats to Cloud Computing V1.0 Prepared by the Cloud Security Alliance, March 2010
https://cloudsecurityalliance.org/topthreats/csathreats.v1.0.pdf

CSP-MOZILLA¶

Using Content Security Policy
June 2011
https://developer.mozilla.org/en/Security/CSP/Using_Content_Security_Policy

CWE¶

The MITRE Corporation
Common Weakness Enumeration (CWE) web site
July 2012
http://cwe.mitre.org

CVE-2011-2107¶

Security update available for Adobe Flash Player: APSB11-13 / CVE-2011-2107
June 2011
http://www.adobe.com/support/security/bulletins/apsb11-13.html

Dakin2011¶

Dakin, S.
Privacy Policies, What Good Are They Anyway?
ApplicationPrivacy.org, June 2011
http://www.applicationprivacy.org/?p=764

DeGrouf2012¶

Willem De Groef, Dominique Devriese, Nick Nikiforakis and Frank Piessens.
FlowFox: a Web Browser with Flexible and Precise Information Flow Control.
To Appear at the 19th ACM Conference on Computer and Communications Security (ACM CCS)
October 2012
http://www.securitee.org/files/flowfox_ccs2012.pdf

DHCP
The Internet Engineering Task Force (IETF)
Dynamic Host Configuration Protocol
http://tools.ietf.org/html/rfc2131¶

DoNotTrack¶

J. Mayer, A. Narayanan and S. Stamm
Do Not Track: A Universal Third-Party Web Tracking Opt Out
IETF Network Working Group Internet-Draft
March 7, 2011
http://tools.ietf.org/html/draft-mayer-do-not-track-00

Draft-iab-priv¶

A. Cooper et al.
Privacy Considerations for Internet Protocols
draft-iab-privacy-considerations-03.txt
IETF IAB Network Working Group
July 2012
http://www.ietf.org/id/draft-iab-privacy-considerations-03.txt

dropbox¶

Dropbox website
https://www.dropbox.com/

ENISA2011¶

A Security Analysis of Next Generation Web Standards
ENISA
July 2011
http://www.enisa.europa.eu/act/application-security/web-security/a-security-analysis-of-next-generation-web-standards/at_download/fullReport

FaceNiff¶

FaceNiff Website
June 2011
http://faceniff.ponury.net/

Faily2010a¶

Shamal Faily and Ivan Flechais
A Meta-Model for Usable Secure Requirements Engineering
Proceedings of the 6th International Workshop on Software Engineering for Secure Systems
IEEE Computer Society, 2010
pp.126--135

Faily2010b¶

Shamal Faily and Ivan Flechais
Analysing and Visualising Security and Usability in IRIS
Proceedings of the 5th International Conference on Availability, Reliability and Security
IEEE Computer Society, 2010
pp. 543--548

Faily2010c¶

Shamal Faily and Ivan Flechais
Barry is not the weakest link: eliciting secure system requirements with personas
Proceedings of the 24th BCS Interaction Specialist Group Conference
British Computer Society, 2010
pp. 124--132

Faily2011a¶

Shamal Faily and Ivan Flechais
User-Centered Information Security Policy Development in a Post-Stuxnet World
Proceedings of the 6th International Conference on Availability, Reliability and Security
IEEE Computer Society, 2011
pp. 716--721

Faily2011b¶

Shamal Faily
A framework for usable and secure system design
DPhil thesis University of Oxford, 2011

Faily2012¶

Shamal Faily‚ John Lyle and Simon Parkin
"Secure System? Challenge Accepted: Finding and Resolving Security Failures Using Security Premortems"
To appear in proceedings of the BCS HCI workshop on Designing Interactive Secure Systems. 2012.
http://www.cs.ox.ac.uk/files/4880/premortem.pdf

Farrell2011¶

Farrell, N.
More security woes hit Apple's iOS
TechEYE.net, May 2011
http://www.techeye.net/security/more-security-woes-hit-apples-ios

Firesheep¶

Butler, E.
Firesheep Website
October 2010
http://codebutler.com/firesheep

Gamma1995¶

Erich Gamma and Richard Helm and Ralph Johnson and John Vlissides
Design patterns: elements of reusable object-oriented software
Addison-Wesley, 1995

Garfinkel1996¶

Garfinkel, S.
Public key cryptography
Computer, June 1996, 29, 101 -104
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=507642&tag=1

Garfinkel2005¶

Garfinkel, S. L.
Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable
PhD Thesis, Massachusetts Institute of Technology, May 2005
http://simson.net/thesis/

Gennari2012¶

Jeffrey Gennari and David Garlan
Measuring Attack Surface in Software Architecture
Carnegie Mellon University Technical Report CMU-ISR-11-121, 2012

Gibraltar¶

Kaisen Lin, UC San Diego; David Chu, James Mickens, Li Zhuang, Feng Zhao and Jian Qiu
Gibraltar: Exposing Hardware Devices to Web Pages Using AJAX
In the proceedings of the Third USENIX Conference on Web Application Development (WebApps’12), June 2012.
http://research.microsoft.com/apps/pubs/default.aspx?id=161386

GlobalPlatform2010¶

TEE Client API Specification
GlobalPlatform Device Technology, Document Reference: GPD_SPE_007
Version 1.0
July 2010
http://www.globalplatform.org/specificationdownload.asp?id=7339

Gollmann2010¶

Dieter Gollmann,
Computer Security, 3rd edition,
John Wiley & Sons, 2010.

Goodin2011¶

Goodin, D.
Android app brings cookie stealing to unwashed masses
The Register, June 2011
http://www.theregister.co.uk/2011/06/03/android_cookie_stealing_app/

Goodin2011a¶

Goodin, D.
Google Web Store quietly purged of nosy apps
The Register, May 2011
http://www.theregister.co.uk/2011/05/26/google_web_store_privacy_threats/

GoogleNativeClient¶

Google Native Client (NaCl): Technology Overview
Fetched June 2011
http://code.google.com/intl/de-DE/games/technology-nacl.html

GuiffySureMerge¶

Ritcher, B.
Guiffy SureMerge - A Trustworthy 3-Way Merge
September 2004 http://www.guiffy.com/SureMergeWP.html

ICO-Privacy¶

Information Commissioner's Office (ICO),
Privacy Impact Assessment Handbook, version 2.0,
http://www.ico.gov.uk/for_organisations/data_protection/topic_guides/privacy_impact_assessment.aspx.

IETF-TLSWG¶

IETF Transport Layer Security Working Group,
Fetched June 2011
http://datatracker.ietf.org/wg/tls/charter/

IntelTXT¶

Technology Overview: Intel® Trusted Execution Technology
Fetched June 2011
http://www.intel.com/technology/security/downloads/TrustedExec_Overview.pdf

iOS-TechOverview¶

iOS Developer Library: iOS Technology Overview Introduction
November 2010
http://developer.apple.com/library/ios/#documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/Introduction/Introduction.html

iPhoneOS-swcuc3m¶

Escribano, R. M. & Almena, J. P.
iPhone OS Tutorial
Fetched June 2011
https://sites.google.com/site/swcuc3m/home/iphone/iphoneos_en

Kandukuri-cloud-sec-09¶

Kandukuri, B.R.; Paturi, V.R.; Rakshit, A.; , "Cloud Security Issues," Services Computing, 2009. SCC '09. IEEE International Conference on , vol., no., pp.517-520, 21-25 Sept. 2009
doi: 10.1109/SCC.2009.84
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5283911&isnumber=5283890

Khan2011¶

Mati Ullah Khan and Mansoor Munib and Umar Manzoor and Samia Nefti
Analyzing Risks At Architectural Level
2011 International Conference on Information Society
IEEE Computer Society, 2011
pp. 231--236

Lederer04¶

Lederer, S.; Hong, I.; Dey, K. & Landay, A.
Personal privacy through understanding and action: five pitfalls for designers
Personal Ubiquitous Comput., Springer-Verlag, November 2004, 8, 440-454
http://dx.doi.org/10.1007/s00779-004-0304-9

Leyden2011¶

Leyden, J.
Wave of Trojans breaks over Android
The Register, June 2011
http://www.theregister.co.uk/2011/06/01/android_trojan_rash/

Lindholm2001¶

Lindholm, T.
A 3-way Merging Algorithm for Synchronizing Ordered Trees -- the 3DM merging and differencing tool for XML
Helsinki University of Technology, September 2001
http://www.cs.hut.fi/~ctl/3dm/thesis.pdf

Lyle2010¶

Lyle, J.
Trustable Services Through Attestation
DPhil Thesis, Department of Computer Science, University of Oxford, June 2011.
http://www.cs.ox.ac.uk/people/John.Lyle/thesis-final-25-06-11.pdf

LyleBlog2012¶

Lyle, J.
Do Garfinkel’s design patterns apply to the web?
(Web page) Department Of Computer Science, University of Oxford
March 2012
http://www.cs.ox.ac.uk/blogs/sss/2012/03/23/garfinkel-design-patterns-for-the-web/

MacOSX-SecurityArchitecture¶

Mac OS X Developer Library: Security Architecture
July 2010
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/Security_Overview/Architecture/Architecture.html#//apple_ref/doc/uid/TP30000976-CH202-TPXREF101

MacOSX-SecurityServices¶

Mac OS X Developer Library: Security Services
July 2010
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/Security_Overview/Security_Services/Security_Services.html#//apple_ref/doc/uid/TP30000976-CH204-CHDDJIDG

MAP¶

TNC IF-MAP Binding for SOAP Specification
Trusted Computing Group Website, Version 2.0, revision 36
http://www.trustedcomputinggroup.org/resources/tnc_ifmap_binding_for_soap_specification

McGraw2006¶

Gary McGraw.
Software Security: Building Security In,
Addison-Wesley Longman, Amsterdam, The Netherlands, 2006.

MeegoSec¶

The Meego Security Architecture
June 2011
http://wiki.meego.com/Security/Architecture

MicrosoftPrivacyGuide¶

Microsoft Corp., Privacy Guidelines for Developing Software Products and Services, v3.1,
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c48cf80f-6e87-48f5-83ec-a18d1ad2fc1f&displaylang=en.

Mitre¶

Mitre Corporation
http://www.mitre.org

MozillaAppManifest¶

Application Manifest format for Open Web Applications
Mozilla
October 2010
https://wiki.mozilla.org/Labs/Apps/Manifest

MozillaPluginDirectory¶

Mozilla Wiki Plugins: Plugin Directory
March 2010
https://wiki.mozilla.org/Plugins:PluginDirectory#Goals

MozillaPrivacyRoadmap¶

Mozilla Privacy Roadmap 2011
May 2011
https://wiki.mozilla.org/Privacy/Roadmap_2011

MozillaProcessIsolation¶

MozillaWiki: Security Process Isolation
April 2009
https://wiki.mozilla.org/Security/ProcessIsolation

MozillaWebApi¶

Web API
Mozilla
August 2012
https://wiki.mozilla.org/WebAPI

MozillaWebAppSec¶

MozillaWiki,
WebAppSec/Secure Coding Guidelines,
https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines.

Munawar2006¶

Munawar Hafiz,
A collection of privacy design patterns,
Proceedings of the ACM 2006 conference on Pattern languages of programs, October 2006.

NamilukoVmProvenance2012
Provenance-Based Model for Verifying Trust-Properties
Cornelius Namiluko and Andrew Martin
TRUST, 2012
http://www.springerlink.com/content/4q296203515854x0/¶

NIST
National Instituent of Standards and Technology (NIST)
http://www.nist.gov¶

NistCloudDefinition2011¶

Peter Mell and Timothy Grance
The NIST Definition of Cloud Computing
NIST, 2011
http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

NoScript¶

NoScript: JavaScript/Java/Flash blocker for a safer Firefox experience
Fetched June 2011
http://noscript.net/

O'Brien2011¶

O'Brien, T.
FaceNiff makes Facebook hacking a portable, one-tap affair
Engadget, June 2011
http://www.engadget.com/2011/06/02/faceniff-makes-facebook-hacking-a-portable-one-tap-affair-vide/

OMTP¶

OMTP App Security Framework
Version 2.2
June 2008
http://www.omtp.org/OMTP_Application_Security_Framework_v2_2.pdf

OpenIDBest¶

OpenID Security Best Practices
PauAmma, 2010
http://wiki.openid.net/w/page/12995200/OpenID%20Security%20Best%20Practices

OWASP¶

OWASP: The Open Web Application Security Project Website
Fetched June 2011
https://www.owasp.org/

OWASP-ASVS¶

Open Web Application Security Project (OWASP),
OWASP Application Security Verification Standard 2009, June 2009,
https://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf.

OWASP-CRG¶

Open Web Application Security Project (OWASP),
OWASP Code Review Guide V1.1, February 2009,
https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project.

OWASP-ESAPI¶

OWASP ESAPI: The OWASP Enterprise Security API
Fetched June 2011
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

OWASP-Guide¶

Open Web Application Security Project (OWASP).
A Guide to Building Secure Web Applications and Web Services, 27 July 2005,
https://www.owasp.org/index.php/OWASP_Guide_Project#tab=Downloads.

OWASP-Top10¶

Open Web Application Security Project (OWASP),
OWASP Top 10 – 2010 – The Ten Most Critical Web Application Security Risks, 2010,
http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf.

PalmWebOS-swcuc3m¶

Macias, S. G. & Gutiérrez, B. J.
Palm webOS Tutorial
Fetched June 2011
https://sites.google.com/site/swcuc3m/home/webos/english-version

PermissionsDAP¶

Byers, P.; Hirsch, F. & Hazaël-Massieux, D.
Permissions for Device API Access: W3C Working Draft
October 2010
http://www.w3.org/TR/api-perms/

Pearson2010¶

Siani Pearson, Yun Shen,
Context-Aware Privacy Design Pattern Selection,
LNCS, Volume 6264, 2010, Springer-Verlag.

Perry2011¶

Perry, M.
Improving Private Browsing Modes: "Do-Not-Track" vs Real Privacy by Design
Tor Project Blog, June 2011
https://blog.torproject.org/blog/improving-private-browsing-modes-do-not-track-vs-real-privacy-design

PorterFelt2011¶

Adrienne Porter Felt, Matthew Finifter, Erika Chin, Steve Hanna, and David Wagner
A survey of mobile malware in the wild
Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices
October 2011
http://doi.acm.org/10.1145/2046614.2046618

PorterFelt2012¶

Adrienne Porter Felt, Serge Egelman, Matthew Finifter, Devdatta Akhawe, and David Wagner
How To Ask For Permission
USENIX Workshop on Hot Topics in Security (HotSec) 2012
http://www.eecs.berkeley.edu/~afelt/howtoaskforpermission.pdf

PorterFelt2012b¶

The Effectiveness of Application Permissions
Adrienne Porter Felt, Kate Greenwood, and David Wagner
USENIX Conference on Web Application Development (WebApps) 2011
http://www.cs.berkeley.edu/~afelt/felt-permissions-webapps11.pdf

PorterFelt2012c¶

Android Permissions: User Attention, Comprehension, and Behavior
Adrienne Porter Felt, Elizabeth Ha, Serge Egelman, Ariel Haney, Erika Chin and David Wagner
Symposium on Usable Privacy and Security (SOUPS) 2012
http://www.cs.berkeley.edu/~afelt/felt-androidpermissions-soups.pdf

PrimeLife¶

PrimeLife Project Website
Fetched June 2011
http://www.primelife.eu/

PRiMMA¶

The Privacy Rights Management for Mobile Applications (PRiMMA) Project Website
Fetched June 2011
http://www.open.ac.uk/blogs/primma/

Pruitt2006¶

John Pruitt and Tamara Adlin
The persona lifecycle: keeping people in mind throughout product design
Elsevier, 2006

rfc2560¶

Myers, M.; Ankney, R.; Malpani, A.; Galperin, S. & Adams, C.
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
The Internet Society, June 1999
http://www.ietf.org/rfc/rfc2560.txt

rfc5246¶

Dierks, T. and Rescorla, E.
The Transport Layer Security (TLS) Protocol
IETF Website, version 1.2, August 2008
http://tools.ietf.org/html/rfc5246

rfc6462¶

A. Cooper
RFC 6462: Report from the Internet Privacy Workshop
Internet Architecture Board (IAB)
ISSN: 2070-1721
http://tools.ietf.org/html/rfc6462

Rooney2011¶

Rooney, B.
More Android Malware Uncovered
The Wall Street Journal Website, TechEurope, June 2011
http://blogs.wsj.com/tech-europe/2011/06/06/more-android-malware-uncovered/

Sailer2004¶

Sailer, R.; Zhang, X.; Jaeger, T. & van Doorn, L.
Design and Implementation of a TCG-based Integrity Measurement Architecture
Proceedings of the 13th USENIX Security Symposium, USENIX, 2004, pages 223-238
http://www.usenix.org/publications/library/proceedings/sec04/tech/sailer.html

Saltzer75¶

Saltzer, J. & Schroeder, M.
The protection of information in computer systems
Proceedings of the IEEE, September 1975, 63, 1278 - 1308

SEAndroid¶

Security Enhanced (SE) Android
August 2012
http://selinuxproject.org/page/SEAndroid

Shields2011¶

Shields, T.
Mobile Apps Invading Your Privacy
Veracode: ZeroDa Labs Blog, April 2011
http://www.veracode.com/blog/2011/04/mobile-apps-invading-your-privacy/

Singh2010¶

Singh, Kapil; Moshchuk, Alexander; Wang, Helen J.; Lee, Wenke.
On the Incoherencies in Web Browser Access Control Policies
Proceedings of the 2010 IEEE Symposium on Security and Privacy (SP), vol., no., pp.463-478,
16-19 May 2010

TCG2007¶

TCG Architecture Overview, Version 1.4
August 2007
http://www.trustedcomputinggroup.org/resources/tcg_architecture_overview_version_14

TCGMobile¶

TCG Mobile Trusted Module Specification
Version 1.0, Revision 7.02
29 April 2010
http://www.trustedcomputinggroup.org/resources/mobile_phone_work_group_mobile_trusted_module_specification

TClouds¶

TClouds "Trustworthy Clouds" Project
Fetched June 2011
http://www.tclouds-project.eu/

TizenManifest¶

Application installation and Manifest
Tizen, August 2012
https://wiki.tizen.org/wiki/Security/Application_installation_and_Manifest

TizenSec¶

Tizen Security Framework Overview
Tizen, May 2012
http://download.tizen.org/misc/media/conference2012/tuesday/ballroom-c/2012-05-08-1600-1640-tizen_security_framework_overview.pdf

TrustZone¶

ARM TrustZone Webpage and API
Fetched June 2011
http://www.arm.com/products/processors/technologies/trustzone.php

Understanding-cloud-vulns¶

Grobauer, B.; Walloschek, T.; Stocker, E.; , "Understanding Cloud Computing Vulnerabilities," Security & Privacy, IEEE , vol.9, no.2, pp.50-57, March-April 2011
doi: 10.1109/MSP.2010.115
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5487489&isnumber=5739630

USPatrioticAct-UnderFire-04¶

USA Patriot Act Comes under Fire in B.C. Report, CBC News, October 30, 2004,
URL: http://www.cbc.ca/canada/story/2004/10/29/patriotact_bc041029.html

VanLamsweerde1998¶

Axel van Lamsweerde and Emmanuel Letier
Integrating obstacles in goal-driven requirements engineering
Proceedings of the 1998 International Conference on Software Engineering
IEEE Computer Society, 1998
pp. 53--62

VanLamsweerde2009¶

Axel van Lamsweerde
Requirements Engineering: from system goals to UML models to software specifications
John Wiley & Sons, 2009

W3CApiPriv¶

Proceedings of the W3C Workshop on Privacy for Advanced Web APIs
12/13 July 2010, London
http://www.w3.org/2010/api-privacy-ws/papers.html

W3CApiSec¶

http://www.w3.org/2010/api-privacy-ws/papers.html
Proceedings of the W3C Workshop on Security for Access to Device APIs from the Web
December 2008
http://www.w3.org/2008/security-ws/papers/

W3CAppPriv¶

Frederick Hirsch
Web Application Privacy Best Practices
W3C Working Group Note
03 July 2012
http://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/

W3CDAP-Perms¶

Byers, P; Hirsch, F & Hazaël-Massieux, D.
Permissions for Device API Access, W3C Working Draft
W3C Website, October 2010
http://www.w3.org/TR/api-perms/

W3CDataMinimization¶

W3C Technical Architecture Group (TAG),
Data Minimization in Web APIs,
http://www.w3.org/2001/tag/doc/APIMinimization.html.

W3CFeaturePermissions¶

Gregg, J. & Gombos, L.
Feature Permissions, W3C Editor's Draft
W3C Website, May 2011
http://dev.w3.org/2009/dap/perms/FeaturePermissions.html

W3CMobileWebApp¶

W3C Recommendation,
Mobile Web Applications Best Practices,
http://www.w3.org/TR/mwabp/.

W3CPatternsPriv¶

Robin Berjon and Daniel Appelquist
Patterns for Privacy by Design in Javascript APIs
W3C Draft TAG Finding
06 June 2012
http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis

W3CWARP¶

W3C Widget Access Request Policy Candidate Recommendation
W3C Website, April 2010
http://www.w3.org/TR/widgets-access/

WAC¶

WAC 2.0 Core Specification: Widget Security and Privacy
January 2011
http://www.wacapps.net/web/portal/wac-2.0-spec

Wang2009¶

Wang, Helen J. and Grier, Chris and Moshchuk, Alexander and King, Samuel T. and Choudhury, Piali and Venter, Herman
The multi-principal OS construction of the gazelle web browser
Proceeding of the 18th USENIX security symposium (SSYM'09), 2009
Pages 417-432

Webinos-D21¶

Webinos Deliverable: D2.1 Use Cases and Scenarios
January 2011
http://webinos.org/archives/744

Webinos-D22¶

Webinos Deliverable: D2.2 Requirements & developer experience analysis
March 2011
http://webinos.org/archives/704

Webinos-D25¶

Webinos Deliverable: D2.5 Updates on Requirements and Available Solutions
February 2012

Webinos-D27¶

Webinos Deliverable: D2.7 User Expectations of Security and Privacy
March 2011
http://webinos.org/blog/2011/03/16/d2-3-industry-landscape-ipr-licensing-governance/

Webinos-D28¶

Webinos Deliverable: D2.8 User Expectations of Security and Privacy (update)
June 2011
http://webinos.org/blog/2011/11/01/webinos-repot-user-expectations-of-security-and-privacy-phase-2/

Webinos-D31¶

Webinos Deliverable: D3.1 System Specifications
August 2011
http://webinos.org/blog/2011/11/01/webinos-report-phase-i-architecture-and-components/

Webinos-D32¶

Webinos Deliverable: D3.2 API Specifications
August 2011
http://webinos.org/blog/2011/11/01/webinos-report-phase-i-device-network-and-server-side-api-specifications/

Webinos-D33¶

Webinos Deliverable: D3.3 System Specifications
Working Draft
August 2012

Webinos-D34¶

Webinos Deliverable: D3.4 API Specifications
Working Draft
August 2012

Webinos-D35¶

Webinos Deliverable: D3.5 Security and Privacy Framework
August 2011
http://webinos.org/blog/2011/08/04/webinos-report-phase-1-security-framework/

WebOSIntro¶

Mobile Application Security : WebOS Security - Introduction to the Platform
February 2011
http://programming4.us/mobile/3158.aspx

WebSand¶

WebSand Project Website
August 2012
https://www.websand.eu/

WidgetSignatures¶

Cáceres, M.; Byers, P.; Knightley, S.; Hirsch, F. & Priestley, M.
XML Digital Signatures for Widgets: W3C Working Draft
June 2011
http://www.w3.org/TR/widgets-digsig/

WidgetUpdates¶

Cáceres, M.; Tibbett, R. & Berjon, R.
Widget Updates: W3C Working Draft
September 2010
http://www.w3.org/TR/widgets-updates/

XACML¶

Moses, T.
eXtensible Access Control Markup Language (XACML) Version 2.0
February 2005
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf

Zhou2012¶

Yajin Zhou, Xuxian Jiang
Dissecting Android Malware: Characterization and Evolution
pp.95-109, 2012 IEEE Symposium on Security and Privacy, 2012
http://www.computer.org/portal/web/csdl/doi/10.1109/SP.2012.16

Appendices¶

Background¶

To provide context for the security and privacy analysis in webinos we give the following background summary of related projects, academic papers and webinos deliverables.

Related Security and Privacy Architectures in Industry¶

This page summarises the main related work in industry on mobile web application security and privacy, as well as some summaries of how this has affected webinos design.

Web Application Systems¶

WAC and BONDI Security architectures

• WAC Core Specification: Security and Privacy (WAC)
• OMTP App Security Framework (OMTP)

From WAC we borrow much of the widget handling specifications and installation behaviour with regards to signatures and identities. The webinos policy architecture is also based on the WAC approach, but with modifications for cross-platform flows and privacy.

Google Chrome

• Hosted Applications Documentation (ChromeHosted)
• Chrome User Identification (ChromeUserId)
• Packaged Apps - Disabled Web Features (ChromePackaged)
• Chrome Manifests (ChromeManifest)
• Chrome CSP for Packaged Apps (ChromeCSP)
• Chrome API Permission Warnings (ChromePermission)

From these references we intend to follow recommendations on limitations to javascript within web applications, such that inline javascript and 'eval' statements are not permitted.

Boot2Gecko / FirefoxOS / OpenWebDevice and Mozilla Web APIs

• Boot 2 Gecko Runtime Security (B2GRuntimeSec)
• Boot 2 Gecko App Security (B2GAppSec)
• Boot 2 Gecko App Security Model Discussion (B2GAppSecDis)
• Application Manifest format for Open Web Applications (MozillaAppManifest)
• Mozilla Web APIs (MozillaWebApi)

Recommendations and specifications on web privacy from the W3C and IETF

• Patterns for Privacy by Design in Javascript (W3CPatternsPriv)
• Report from the Internet Privacy Workshop (rfc6462)
• Privacy Considerations for Internet Protocols (Draft-iab-priv)
• Do Not Track: A Universal Third-Party Web Tracking Opt Out (DoNotTrack)

Based on these guidelines, we intend to try and avoid introducing APIs which allow for fingerprinting without any form of user consent. I.e., web applications should not be able to gain additional information about a user, or any form of user identity, unless the policy architecture allows it. We also intend to make information flows more visible to users by encouraging developers to explain their data handling policies when requesting data.

Security analysis by ENISA

We focus on one of the recommendations given by ENISA in their report (ENISA2011) - End User Policing. From the report:

Several specifications depend on the end user to ensure security, typically by means of a permission system. With the rapid development of new APIs offering new functionality, this approach is reaching its limits. Typical web users are unable to assess the ramifications of granting certain permissions to certain origins. Additionally, involving the user too often might quickly lead to blindly approving permissions.
A first recommendation is to require an awareness indicator, so the user knows when a site is using a granted permission (e.g. when a site is locating the user). Currently, this is only included as a suggestion in the Geo-location API and is missing from other APIs, such as the System Information API.
A second recommendation is to offer the users a way to select predefined security profiles or to create a security profile (e.g. by means of a wizard, which could explain the ramifications of sharing your location and then provide the option to allow this or not.). Once a security profile is chosen, it is used to determine the appropriate actions when a site requests permission for an action.

Web intents

An analysis of web intents security issues can be found in the D3.4 deliverable.

Mobile application security and privacy frameworks¶

While the following projects are less directly applicable, they provide an important context for webinos applications. In particular, we borrow concepts from the Android permission system.

Android

• Android Security Overview (AndroidSecurityOverview)
• Security Enhanced Android (SEAndroid)

iOS

• iOS Security (AppleIosSec)

Chromium OS

• Chromium OS Security Overview (ChromiumSec)

Meego security architecture

• The Meego Security Architecture (MeegoSec)

Tizen security architecture

• Security Overview Presentation (TizenSec)
• Application installation and Manifest (TizenManifest)

Summary¶

The webinos security framework is informed by all of the sources given above. In particular, we make use of recommendations from WAC, Chrome, W3C and ENISA to try and avoid threats that they have identified.

Related Academic Work¶

This section covers the key related academic material and concludes with an explanation for how these have been taken into account in the webinos security framework.

Papers¶

Exposing additional capabilities to web browsers¶

The Gibraltar system (Gibraltar) takes a similar approach to webinos in exposing device-level capabilities to web browsers. This work takes a capability approach (issuing tokens to trusted sites) in contrast to the policy-based system implemented in webinos.

Cross-device synchronisation¶

The Cloudberry system (Cloudberry) is related to webinos but is more cloud-driven.

Access control, permissions and API security¶

• "On the Incoherencies in Web Browser Access Control Policies," (Singh2010)
• "How to ask for Permission" (PorterFelt2012)
• "Android Permissions: User Attention, Comprehension, and Behavior" (PorterFelt2012b)
• "The Effectiveness of Application Permissions" (PorterFelt2012c)
• "An Evaluation of the Google Chrome Extension Security Architecture" (Carlini2012)
• "Privilege Separation in HTML5 Applications" (Akhawe2012)

Web Browsers¶

• The Gazelle Web Browser (Wang2009)
• The Tahoma Web Browser (Cox2006)
• FlowFox (DeGrouf2012)

Mobile Malware¶

• An analysis of Android malware is presented in (Zhou2012)
• A wider survey of mobile malware can be found in (PorterFelt2011)

Principles and Design patterns¶

• Chapter 10 of (Garfinkel2005), and an analysis of their application to the web by The University of Oxford (LyleBlog2012).
• We aim to avoid the Privacy Pitfalls described by Lederer et al. (Lederer04)
• We also aim to follow the principles outlined in the classic Saltzer and Schroeder paper (Saltzer75).

More details of our guiding principles are available in the D3.5 deliverable.

Workshops¶

W3C API Security and Privacy Workshops from 2010 and 2008

• (W3CApiSec)
• (W3CApiPriv)

Recommendations for webinos¶

• The principle of least privilege should be followed through the policy architecture.
• Motivations and attacks based on existing mobile malware should be fed into risk analysis.
• Recommendations for web application based on the Google Chrome Extension Security Architecture should be considered as part of the security architecture.
• Garfinkel's design patterns - install before execute - are relevant for webinos.
• We recommend the use of status icons ("Sensor Widgets") based on the Gibraltar paper for consideration as a future webinos security control.

Related Webinos Deliverables¶

Before compiling this document we used input from Deliverable 2.7 and 2.8: User Expectations of Security and Privacy

• Personas to contextualise attacks and risks
• Attacker personas to provide motivation and potential capabilities of attackers
• Misuse cases and Tasks to provide inspiration for attack patterns
• Environment models and Asset models to inform the architectural patterns
• Attack trees to generate attack patterns

As part of this we also developed several more attack trees before beginning our main architectural risk analysis. They are included here as an addendum.

Unauthorised access to APIs¶

Unauthorised access to the PZH¶

API Security Analysis¶

This section describes an individual analysis of each API and the security and privacy issues they have.

Authentication API¶

Overview of API¶

http://dev.webinos.org/specifications/new/authentication.html

Provides information to applications about the current authentication status of users, based on their authentication to the local device. This API may also be used within webinos to ask the runtime to authenticate the user.

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used to monitor the current state of the user. e.g., requesting an authentication might show that the end user is present.
2. Authentication method and Last Auth Time could be used for fingerprinting the user.
3. If this is mapped to device authentication, users could be inundated with authentication requests. It also might confuse them into clicking-through or automatically entering passwords when prompted. This would be a particularly big problem if this password/code is reused on other systems.
4. The authentication prompt could be spoofed by an application.

Threats based on remote invocation of this API from another device¶

1. Remote invocation could be misused to monitor the user's activity - e.g., to work out whether the user was active on the device.
2. Misuse of authentication - if all authentication requests are delegated to a device which does not support (or only weakly supports) the Authentication API, this might be unexpectedly weak or strong.

Implementation threats and possible attacks¶

1. The current implementation means that authentication applies to all apps at once - a user authenticating in one App will automatically be authenticated for others. This may be confusing if the API is misused as authorisation.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. The use of this API could create false expectations for developers. It is meant to be used to re-assert the users identity as the owner of the PZP in question. However, it is not supposed to be a strong authentication statement, as the method will be device-specific. Developers must be aware that it is weak, and may not correlate with the current user precisely. It should not be used to protect high-value or high-risk events.
2. Similarly, authentication is not necessarily authentication for the current action - a user may have authenticated for another reason. It should not be confused with authorisation.
3. Authentication time-outs and delays are platform-specific, and developers need to be aware that they should check the 'lastAuthTime' parameter to see how fresh it is.

Threats to device manufacturers, operators, other stakeholders¶

Mitigations¶

1. Provide examples for the correct scenarios in which the API should be used. Make sure that authentication is not confused with authorisation. Consider adding authorisation methods to this API.
2. Allow plausible deny-ability - callbacks should trigger after timeouts of random periods (within certain limits) to avoid user monitoring.
3. Secure UI - make sure the webinos prompt is not spoofable.
4. Do not make use of the authentication credentials in any way.
5. Make sure that authentication API implementations do not allow for excessive querying of the user. Authentication caching is required.
6. Make explicit which application is asking for authentication when authentication is requested.

Recommended default policy rules for applications¶

Context API¶

Overview of API¶

http://dev.webinos.org/specifications/new/context.html

Allows access to a user’s context data through either explicit queries or a subscription model. Context events include all API calls.

Threats¶

API-Specific threats and misuse cases¶

1. Privacy loss - any application can monitor what the user is doing and has done, and can react to particular events. This might be used for targeted adverts, physical or cyber stalking, targeted theft or burglary, identity theft.
2. Confidentiality loss - any application potentially see which files have been opened, where the user has been, contact information, etc. Depending on implementation, this could include the content of files and more. An application might use this to gain access to APIs it does not have permission for.
3. Non-repudiation. Users may want to go unmonitored and need to turn off context collection at times. If this is hard to do or unclear, it might result in embarrassment, loss of reputation, etc.

Threats based on remote invocation of this API from another device¶

Because this API primarily uses a central database, remoting has no obvious implications.

Implementation threats and possible attacks¶

1. Availability - subscribing to common context events might slow down the platform considerably, rendering it unusable.
2. Availability - too many queries to the context API might over-use bandwidth and cause either a loss of battery power of expensive mobile phone bills

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. Context data could be inconsistent or misused to provide a false impression for developers. For example, if a user turns on and off their context data, it may make them appear to have different behaviour to reality.

Threats to device manufacturers, operators, other stakeholders¶

1. Availability - too many queries to the context API might over-use bandwidth and reduce battery life.

Mitigations¶

1. Turn off context collection by default
2. Provide controls for turning on/off collection and clearing the database
3. Optionally - provide more granular controls for users who are aware of aspects of their context they are happy to log to the database and make available. Allow for selective deletion.
4. Provide feedback for when applications query context data
5. Clean context data so that only a bare minimum of information about API calls is collected. This could be implemented through data tagging.
6. Integrate context querying permissions with permission to access the underlying data. Investigate how the data in the Context Database can be classified based on its sources.

Recommended default policy rules for applications¶

AppLauncher API¶

Overview of API¶

http://dev.webinos.org/specifications/new/launcher.html

Provides the capability to check if a webinos app is present on the device and to start it.

Threats¶

API-Specific threats and misuse cases¶

1. Start applications on the device until the system crashes;
2. Start a malicious application and send it to background; when it prompts for a permission, the user may allow it thinking it is requested by the main application;
3. Checking which applications are installed on the device can reveal personal information;
4. Using the AppLauncher API to invoke a known-vulnerable application and then stealing data or misusing its access to credentials.

Threats based on remote invocation of this API from another device¶

Remotely launching applications may cause excessive battery usage from the target device, or may be used as part of any of the above threats, but with the added difficulty that the user may not see what is happening.

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

Threats to device manufacturers, operators, other stakeholders¶

1. Starting applications that overload cpu, memory, network access can cause device dysfunctions; this can result in bad publicity for the manufacturer. This may also cause additional cost in fixing devices with malicious applications installed.

Mitigations¶

1. the user must be able to select which applications can be executed by a local or remote entity;
2. this can be achieved with a ui showing the list of applications; the user can enable each app to be locally or remotely executed (and select which entity can execute them);
3. make sure that the policy prompt clearly states which is the app requesting it;
4. Make sure that an explicit consent step is required before an application is launched. This consent request should include the calling application's name as well as the target application.

Recommended default policy rules for applications¶

Only applications selected by the user should be checkable or runnable (localy or remotely). This means that the policy must have a parameter identifying the invoked application.

Policy for general applications:

Policy for user selected applications:

Payment API¶

Overview of API¶

http://dev.webinos.org/specifications/new/payment.html

"This API provides generic shopping basket functionality to provide in-app payment. It is not linked to a specific payment service provider and is designed to be sufficiently generic to be mapable to various payment services like GSMA OneAPI, BlueVia, Android Payment API or PayPal."

Threats¶

API-Specific threats and misuse cases¶

• Misuse case from 2.8
• Misuse case from 2.8
• An application could add items to the shopping basket with user consent. This could result in the user being charged more money or purchasing something they didn't mean to.
• An application could remove items from the shopping basket without user consent. This would be irritating, and might put them off using this application or payment provider.
• An application could modify the item price, making it cost more for the end user. Alternatively, it could mean that the user thinks something is cheap. Or it could defraud the merchant.
• An application could fail to update the basket after a change, resulting in an incorrect total amount being displayed.
• An application could accidentally double-add items to the basket
• An application could use an inappropriate out-of-band authenticator with the payment provider, resulting in unauthorised payment
• The payment provider might use SMS-based authentication, which webinos could intercept and allow an attacker who has stolen one device to buy lots of things.
• The invocation of the API may be logged by the context DB. This might mean that a item purchased privately or semi-anonymously is then recorded in the user's personal history. This could cause embarrassment.
• An application might create and load a shopping basket without user consent.
• The process of authenticating might reveal user contact details or address information.
• The API could accidentally link payments through different mechanisms (e.g. PayPal and Visa) which would otherwise be anonymous.
• A child might misuse an app with access to the payment API - e.g. downloading pay-per-view content.

Threats based on remote invocation of this API from another device¶

• The API could be invoked remotely on another device owned by the user, resulting in the payment provider's authentication mechanism appearing on the wrong device. This could either be misused to trick the user into purchasing the wrong thing, or make it impossible for the user to properly authenticate.
• The API could be invoked on someone else's device, taking advantage of any credentials they have for authenticating to the payment provider.
• If the webinos web/widget runtime allowed unauthorised cross-origin communication, then the App might be able to eavesdrop or intercept key presses / input from the user during payment authentication.

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

• A failure of the payment API could result in the app developer missing out on revenue. E.g., the payment API does not work, or results in difficult to use behaviour, resulting in the user cancelling the payment.
• Misuse of the payment API might result in the developer appearing fraudulent.

Threats to device manufacturers, operators, other stakeholders¶

• Misuse of the payment API would cause bad publicity for any operator or manufacturer using/shipping webinos on their handsets.

Further considerations¶

• The payment provider's authentication mechanism may be fundamentally flawed, or make assumptions that do not hold in webinos.
• Payment doesn't fundamentally introduce anything new in webinos compared to the browser.

Mitigations¶

• Remove from webinos? Doesn't add any innovation, does add complexity and an attack vector?
• Do not allow remote invocation
• Require user consent and authentication before invoking the checkout operation. However, this ought to be provided by the service rather than necessarily by the policy framework.
• Recommend that a custom analysis on each payment provider is performed, to check that webinos is not introducing new attack vectors.

Recommended default policy rules for applications¶

Rationale: the payment API does not introduce anything new compared to regular browser payment.

Discovery API¶

Overview of API¶

http://dev.webinos.org/specifications/new/servicediscovery.html

"The Webinos Discovery API provide web applications with an API to discover services without any previous knowledge of the service. The Discovery API is not limited to discovery of local services but also enables discovery of remote services."

Threats¶

API-Specific threats and misuse cases¶

1. Privacy loss – any application can read out which type of services that are available in the personal zone or on local networks. The service description contains information such as service type, name and a description. This information could contain the model name of your home TV, which type of personal phone you have in your zone. This information can be used by applications for fingerprinting. Potential candidates are targeted advertising, targeted theft or burglary. If an application is authorized access to a service availability could be used to monitor availability of different services. This can be used to estimate what an end user is doing and potential whether the end user is at home or not.
2. Denial of Service – any application that is accidently authorized access to a service in the personal, could use this for DoS attacks and service Hijacking.
3. Masquerade service access – when finding a services the application can fake which services that are found and give the end user the impression that service x is selected whilst service y is choosen by the application.

Threats based on remote invocation of this API from another device¶

The discovery API is an enabler for doing remote invocation but the API as such should not be possible to invoke remotely.

Implementation threats and possible attacks¶

1. Currently there are no limitations in number of discovery operations that can be invoked in parallel. This could be misused, resulting in denial of service or exploiting a bug in an underlying service platform.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. Unreliable application behaviour. If the discovery API produces unreliable results then the application will appear unreliable and may be unpopular with users.
2. Discovery of privacy-invasive or insecure services. Application developers might be blamed for their applications making use of services which are invasive of their privacy or security. The discovery API has no way of presenting this information to the application.
3. Inappropriate use of an application-defined service. If Jimmy develops a service designed to take, for example, public data about sports results with very few security implications he may get in trouble if it is misused by users for private data.

Threats to device manufacturers, operators, other stakeholders¶

1. The API defines that service availability shall be reported as events. This could generate a lot of traffic of there a lot of services running in parallel and could potentially be devastating for the power consumption and load the network with traffic.

Further considerations¶

Mitigations¶

1. The API shall only be available for authorized applications or applications trusted by the end user.
2. Provide feedback when services are discovered and which services that are discovered.
3. There shall be means for end user to easily revoke access to the discovery API

Recommended default policy rules for applications¶

Generic Sensor API¶

Overview of API¶

Link to API - http://dev.webinos.org/specifications/new/sensors.html

The Webinos Generic Sensor API provides web applications with an API to access data from sensors in the device, connected to the device or in another device.

1. A sensor interface that provides attributes for the sensors and a method to configure a selected sensor.
2. A DOM level 3 event that provides sensor data.

Threats¶

API-Specific threats and misuse cases¶

1. Sensors may be receiving data from a wide range of sources or inputs. These might potentially be privacy-invasive, e.g.,
   1. A power-usage sensor might indicate the user's current activity
   2. A sleep monitor (motion sensor) has some obvious privacy issues
   3. Sensors might provide clues to the location of the end user - e.g. a temperature sensor at a known location during winter would expect to be warm when people are nearby and cold otherwise. This might be used by thieves to determine whether a house is occupied before a burglary.
   4. Sound sensors might be able to overhear conversations
2. Sensors might produce a large amount of data and therefore overuse the bandwidth or storage capacity of the device, resulting in slow network/device, high costs or denial of service altogether.
3. Sensors may be more or less accurate than expected. If used for security-related tasks (such as where a door is open or closed, or in establishing user presence) this could cause security violations.

There are likely to be more threats for each type of sensor - this threat analysis is vague by definition.

Threats based on remote invocation of this API from another device¶

1. Access to sensors on remote devices may be unexpected by the end user. They may not expect an application on a device in a different location to have access to this information
2. Remote eavesdropping or spying on someone else may be enabled by this device, even accidentally. For example, in a shared house it might inform one occupant of the activities of the other by accident. This could cause embarrassment or expose sensitive information. The assumption that a sensor is only accessible for the place where the sensor is has been violated

Implementation threats and possible attacks¶

This API has not been implemented.

Suspected implementation issues:

• The underlying sensor is going to be controlled by a device driver. This driver may be running in kernel mode. It may have implementation flaws which are exploitable from API invocation, such as buffer overruns or double free vulnerabilities. This could cause remote code execution from webinos APIs.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. No assurance is provided to developers of the trustworthiness of the sensor. This should not be relied upon by developers.
2. Apps could be fed a large stream of fake or unhelpful data by this API.

Threats to device manufacturers, operators, other stakeholders¶

1. Cross-zone API use could result in high network traffic, particularly if combined with the context API
2. If the sensor relates to the device itself - e.g. a sensor recording engine temperature - it could cause end users to believe their devices are faulty when they are not, or vice versa. This would be a problem for a manufacturer.

Mitigations¶

1. When adding a sensor to webinos, make it clear that this sensor is accessible from any device in the personal zone and provide users with the opportunity to disable this feature.
2. If the sensor relates to part of a product and is known to be unreliable, the manufacturer may want to allow access to it only from applications with the manufacturer's signature.
3. When roaming or using a mobile network, the amount of data being sent by this API might be limited
4. By default, user consent should be required when accessing this API both locally and remotely.
5. Use of this API by an application should be logged
6. Recommend to implementers of sensors that any free-form untyped text input ( sensorType and sensorId in the initSensorEvent method ) should be validated properly.
7. Recommend to implementers that rate limits are set where appropriate on sensors.
8. Display visual warnings on the device with the sensor when the sensor is in use, to avoid eavesdropping / privacy invasion by a remote or local app.

Recommended default policy rules for applications¶

For each application type, select one of these as the default policy for this API. This applies to an application which explicitly requests access to this API.

Local access:

Remote access:

Generic Actuator API¶

Overview of API¶

Link to API - http://dev.webinos.org/specifications/new/actuators.html

Threats¶

API-Specific threats and misuse cases¶

1. Misuse of an actuator could damage the underlying device or local environment. E.g., a motor could be used so frequently it gets too hot.
2. Misuse of a battery-powered actuator could cause a denial of service through exhausting the battery.
3. An actuator could be capable of harming people or the environment. E.g., actuators for home automation could cause temperatures to drop or rise too high
4. Actuators may through success or error callbacks reveal information about the underlying device which could, in turn, be privacy sensitive. E.g. an actuator that has recently been used might be unusable for several minutes. This would therefore be a covert channel.
5. An expensive to use actuator (e.g. one with a support service or one which uses a limited supply of raw materials) could be expensive for the end user if abused.
6. An application or webinos flaw could allow an attacker to misuse all the actuator APIs at once. This would be spectacular!

There are likely to be more threats for each type of actuator - this threat analysis is vague by definition.

Threats based on remote invocation of this API from another device¶

1. Remote invocation of an actuator could cause alarm or surprise by a user who is not expecting it.
2. Remote invocation could cause battery life issues or denial of service if the user did not realise they were remotely invoking it.
3. Remote invocation greatly increases the likelihood and success of many of the denial of service threats.

Implementation threats and possible attacks¶

This API has not been implemented.

Suspected implementation issues:

• The underlying actuator is going to be controlled by a device driver. This driver may be running in kernel mode. It may have implementation flaws which are exploitable from API invocation, such as buffer overruns or double free vulnerabilities. This could cause remote code execution from webinos APIs.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. The developer might design for the wrong kind of actuator and therefore accidentally damage the actuator that the API uses. They could be sued for this by angry users

Threats to device manufacturers, operators, other stakeholders¶

1. Actuators related to a device might be damaged through unauthorised or inappropriate use. This could cause expense or product recalls.

Mitigations¶

1. When the actuator is used it ought to notify the user on the device he or she is using it from as well as the device it is connected to.
2. Recommend to implementers of actuators that any free-form untyped text input ( actuatorType and actuatorId in the initActuatorEvent method ) should be validated properly.
3. Recommend to implementers that rate limits are set where appropriate on actuators.
4. User consent should be required at least the first time the actuator is used
5. When adding a new actuator, users should be alerted to warnings and, by default, policies should disallow access to this API remotely.
6. Use of this API by an application should be logged
7. If the actuator is expensive to use, or could be damaged through misuse, the manufacturer may want to allow access to it only from applications with the manufacturer's signature. A default policy might be bundled with the actuator driver

Recommended default policy rules for applications¶

Local access:

Messaging API¶

Overview of API¶

http://dev.webinos.org/specifications/new/messaging.html

Provides the capability to read, receive and send sms, mms, email and instant messages.

Threats¶

API-Specific threats and misuse cases¶

1. an application (or remote user) can read user sms/mms/emails/im; they may contain sensitive data (for example important information about their personal life or work activities).
2. an application (or remote user) can send sms/mms/emails; this may be used, for example, to subscribe the user to a paid service.
3. an application can modify/replace the message or the recipient list before sending it, causing embarassment or other problems to the user.

Threats based on remote invocation of this API from another device¶

1. Remote invocation of this API could have unexpected consequences as it might break the natural accountability that messaging would be expected to have. For example, an application might remotely invoke SMS functionality on a smartphone and the user, who is on their PC at the time, would only find out when they check their mobile device.
2. Remote invocation could be used to impersonate the user for second-factor out-of-band authentication. For example, letting the application read an SMS created by a payment provider, or reading an email password reset message.

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

Threats to device manufacturers, operators, other stakeholders¶

1. sending many sms/mms may consume user credit; this may cause disappointment with the operator or platform/application developer.

Mitigations¶

1. access to send functionalities by default should be prompted every time (and denied to untrusted apps);
2. should the prompt allow the user to check the message to be sure it's not modified by the application?

Recommended default policy rules for applications¶

The following features are defined for this api:

http://webinos.org/api/messaging (access to all functionalities)
http://webinos.org/api/messaging.send (access to send message)
http://webinos.org/api/messaging.find (access to find message)
http://webinos.org/api/messaging.subscribe (access to message subscription)
http://webinos.org/api/messaging.attach (access to message attachment)

The control of message sending should be more restrictive than the others.

Message send:

Other messaging methods:

NFC API¶

Overview of API¶

http://dev.webinos.org/redmine/projects/t3-4/wiki/NFC_API

Allows applications to read and write to NFC tags, to push messages to other NFC devices, and to establish a temporary bidirectional asynchronous message channel between the host device and another. NFC uses short range inductive radio frequency communication. The range is typically of the order of 4 centimetres. NFC tags lack batteries and are powered through inductive coupling. The webinos phase 2 API doesn't (yet) support more advanced techniques such as APDU messages for contact and contact-less smart cards, as used for electronic payments.

Threats¶

API-Specific threats and misuse cases¶

1. Privacy and confidentiality loss - An attacker could place a hidden antenna near enough to listen into the communication protocol between the NFC devices as NFC communications is typically unencrypted. In practice with a hand held NFC device like a mobile phone, and a handheld NFC tag (e.g. a smart card), the risk is low.
2. Loss of an NFC Tag - if data is held on an NFC Tag in an unencrypted form, there is a risk of the Tag falling into the wrong hands. This is analogous to losing a metro travel payment card (e.g. London's Oyster card), a credit card or a security access card used for access to restricted premises. A related scenario involves the loss of your NFC enabled smart phone.

Threats based on remote invocation of this API from another device¶

For this to work, the user would have to be persuaded to cooperate with physically moving the NFC device close to the other device, e.g. a phone or tag.

Implementation threats and possible attacks¶

NFC is sometimes used to exchange credentials for securing other protocols, e.g. WiFi networks or Bluetooth connections. NFC has also been suggested as part of the process for inducting new devices into the user's personal zone. Unencrypted communication between NFC devices could be used to compromise security, however, see above for the practical issues in doing so.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

NFC can be used as part of payment solutions, and web developers may feel unwarranted confidence in the security of NFC devices. We need to explain the limitations of basic NDEF NFC devices and point people are more secure solutions where appropriate, e.g. the use of NFC-SEC and APDU.

Threats to device manufacturers, operators, other stakeholders¶

1. Availability - NFC is low power and not a big factor in battery life.

Mitigations¶

The wireless connection can be safeguarded through the use of NFC-SEC as defined by ECMA-385 and ECMA 386, see:

• ECMA-385
• ECMA-386
• ECMA TC-47 NFC-SEC White paper

Note: ECMA 385, 385 have been republished as ISO/IEC 13157-1 and -2, respectively.

NFC-SEC provides for a Diffie-Helman secure key exchange, allowing NFC devices to set up a secure communication path. In principle, this could be subject to a man-in-the-middle attack, but that would be hard to achieve in practice due to the nature of the very short range radio frequency communication paths involved.

Further work is needed to explore how to integrate support for NFC-SEC in webinos, as this is dependent on the availability of support by the underlying libraries, e.g. libnfc and the Android SDK.

Recommended default policy rules for applications¶

The need for users to explicitly bring NFC devices close together acts as barrier to silent abuse of the NFC APIs, as a result user consent shouldn't be requested at run-time, except when the system needs to re-format an existing Tag. It may still be a good idea to ask users for consent to at install time as a reminder of the capability of the application in question.

The policy language could be designed to limit the APIs applications can use according to the need, e.g. if an application only needs to share personal contact data (an electronic business card) then it could be restricted to reading and writing such data to NFC devices/tags. The policy language could further limit the capabilities to applications that are authenticated by the host platform.

TV Control API¶

Overview of API¶

http://dev.webinos.org/specifications/new/tv.html

Interface for TV control and managment.

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used to monitor the current state of the broadcast service. Depending on time and channel information users could potentially be fingerprinted.
2. With knowledge of channel list the location of a user could be derived (e.g. local channels appear in list if terrestrial service is used)
3. Generation of user profiles, preferred channels (sports, adult shows, etc )
4. Annoyance - an application could change channel on the end user unexpectedly. This could also cause embarrassment - e.g., selecting a not-safe-for-work channel at the wrong time.

Threats based on remote invocation of this API from another device¶

1. In case one specific TV service is accessed from two or more apps then the user might experience a denial of service, e.g. user could be prevented from watching a desired channel by an other app changing programmatically to other channels. This is due to API implementation controlling one specific service, in other words: lack of exclusive usage of service.
2. Remote invocation might be used to monitor the user's presence, e.g. one could monitor if a user is changing channels?
3. Remote (mobile) access to streams could increase costs for internet access

Implementation threats and possible attacks¶

1. The current implementation means that TV API applies to all apps at once.
2. Currently, one implementation of TV API uses VLC as backend, which might introduce its own security issues (foreign code execution, due to application flaws)

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. As mentioned above ("lack of exclusive usage of service") an app developer could experience unexpected behavior in his apps

Threats to device manufacturers, operators, other stakeholders¶

1. Not a security threat, but some broadcasters could have concerns, as apps might filter them out, censor or hiding ads or overlaying content.

Mitigations¶

1. Provide examples for the correct scenarios in which the API should be used.
2. Provide a black-list option for some channels, making them unable to be selected by the API

Recommended default policy rules for applications¶

Vehicle API¶

Overview of API¶

Link to API - http://dev.webinos.org/specifications/new/vehicle.html

The API provides read access to vehicle specific data.

Threats¶

API-Specific threats and misuse cases¶

1. The API could be used to generate driving profiles of a user based on the trip computer data. this might be wanted by targeted advertisers trying to profile the user to send them product advertisements.
2. The API could be used to monitor the state of the vehicle (e.g. enginge-oil status and trip computer).
3. Inferring the location of the end user, based on vehicle data

Threats based on remote invocation of this API from another device¶

1. Vehicle properties with high update frequencies can slow down the communciation within the personal zone.

Implementation threats and possible attacks¶

1. One implementation of the Vehilce API has access to the MOST-Bus. Depending of the vehicle property the update frequency is short (a few ms). Registering listeners to more high frequency properties can crash the PZP.
2. Updates on a high frequency properties can freeze the GUI

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. Binding to too many vehicle properties can lead to unresponsiveness of the app, as the communication channel between PZP and browser is flooded with RPC messages of the API . The updates can also freeze the GUI of the application for a few seconds.

Threats to device manufacturers, operators, other stakeholders¶

1. bad publicity for device manufactures, especially as the car is still perceived as one system. Currently customers still do not distinguish between a problem with the engine or with a third application running on in-car headunit. It is perceived as a problem with the car.

Mitigations¶

1. Provide examples for the correct scenarios in which the API should be used.
2. Use thresholds for updates on high frequency vehicle properties
3. Limit the amount of vehicle properties an application can register listeners to.
4. Suggest that manufacturers consider only allowing signed apps from known authors or distributors to access this API

Recommended default policy rules for applications¶

For each application type, select one of these as the default policy for this API. This applies to an application which explicitly requests access to this API.

Webinos core interface¶

Overview of API¶

Link to API - http://dev.webinos.org/specifications/new/example.html

The webinos core interface is a way of accessing all the other interfaces.

Threats¶

API-Specific threats and misuse cases¶

1. Replacing this core interface with another, malicious core interface. This could access a different personal zone proxy, perhaps one that is not on the current device.

Implementation threats and possible attacks¶

1. Are there any threats due to the way the webinos.js shim is implemented?

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. A developer has little assurance that the webinos object is communicating with the right endpoint.

Threats to device manufacturers, operators, other stakeholders¶

No obvious threats.

Mitigations¶

1. Ensure that the browser can only talk to the right PZP through authentication of the IPC / WebSocket.

Widget API¶

Overview of API¶

http://dev.webinos.org/specifications/draft/widget.html

Provides informations about the widget, the capability to store preferences as well as methods to monitor and control widget status (start, stop, background, foreground). It also provides a method to install a child widget on any user's device. All data refers to the widget itself, so a widget cannot control or access data belonging to another widget.

Threats¶

API-Specific threats and misuse cases¶

1. This api can be used to track or change user preferences (only for the current widget);
2. It is not clear what happens if this api is called from a browser context. Can the deployChild be used to install a child widget from a web page?

Threats based on remote invocation of this API from another device¶

1. The method deployChild can be remotely called on the device where the widget should be installed; it can be used to install (maliciuos) widgets on all the devices discoverable by the user/device.
2. Other attributes/methods mainly provide informations about the current widget, it makes no sense to call it on a remote device.

Implementation threats and possible attacks¶

No particular threat identified.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

No particular threat identified.

Threats to device manufacturers, operators, other stakeholders¶

No particular threat identified.

Mitigations¶

1. Disable this api from the browser context;
2. Disable remote invocation of this api;
3. Require user consent before installing a child widget;

Recommended default policy rules for applications¶

At the moment this api does not define a feature for policy control.
Access to widget information or status is not a problem. Installation of child widgets should require user approval (on both devices?).

Policy for access to widget info or status:

Policy for child widget installation:

The W3C calendar module¶

Overview of API¶

http://www.w3.org/TR/2011/WD-calendar-api-20110419/

The Calendar API defines a high-level interface to access Calendar information such as events, reminders, alarms and other calendar information. The API itself is designed to be agnostic of any underlying calendaring service sources.

Security and Privacy considerations are already described in this part of the specification .

Threats¶

API-Specific threats and misuse cases¶

1. Distribution of user calendar details - privacy issues abound. Sharing with unauthorised parties may result in embarrassment, loss of income (meeting information may be valuable to businesses) or impact on the safety of the end user.
2. Targeted advertising based on calendar event information
3. Stalking possible if the wrong person is given access to calendar entries
4. Misuse case - Calendar details shared over unprotected communication medium and accessed by unauthorised parties, allowing them to rob the victim when they know he will be at an appointment.
5. Not all calendars are created equally - some will be used for business, others personal, others are common events. Granting access to one should not automatically grant access to them all.
6. The details of contacts who have been added to meetings or appointments might be revealed through use of the calendar API in an unexpected way.

Extended threats based on editing calendars¶

1. Spam through an unauthorised application adding calendar entries
2. Missing appointments or loss of information due to an application deleting entries or adding too many unwanted entries

Threats based on remote invocation of this API from another device¶

1. Peter might allow his application access to the Calendar on his PC, knowing that there is nothing important in it. However, it then has access to his mobile phone calendar, which is much more personal and sensitive.
2. There could be an unexpected ripple-effect when deleting a calendar entry - deleting it on one calendar could impact all calendars on all devices unexpectedly.

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

• The Calendar API might return enormous amounts of data, causing any Web Application to crash or fail.
• Calendar data from public calendars might be used to perform XSS or XSRF attacks.

Threats to device manufacturers, operators, other stakeholders¶

Mitigations¶

These apply: http://www.w3.org/TR/2011/WD-calendar-api-20110419/#security-and-privacy-considerations

1. User consent required for accessing each calendar
2. Separation of calendars is important - access to one calendar should not imply access to others
3. Could the API support "busy/free" invocation methods rather than precise information about each event? (this would involve a modification to the API)
4. Granularity is important
   1. Applications should state how much calendar information they will request and why.
   2. permission might be granted just for an application to see whether a particular time is free or busy, but not any details
   3. permission might be granted to view calendar items but not edit (editing is not technically in the specification)
5. Revocation of consent is necessary.
6. Suggest a three-phase policy per calendar: "allow all", "allow view busy/free", "deny"

Recommended default policy rules for applications¶

Rationale: accessing a calendar ought to require explicit consent, and most pages ought to deny it by default. For those pages and widgets which are from known sources, it is reasonable to expect that consent is likely to be granted after one question.

The W3C contacts module¶

Overview of API¶

http://dev.webinos.org/specifications/new/contacts.html

Provides the capability to read, write, update and delete user contacts.

Threats¶

API-Specific threats and misuse cases¶

1. an application can read all my contact details and send them to an attacker; this way the attacker can use it for spam or to collect sensitive information about contacts (not only phone number or email, but also address, birthday, photo, ...).
2. an application can modify or delete my contacts; for example change the phone number to a premium rate service.
3. giving an application/user access to a contact can give access also to other contacts; for example I share my work contacts, but accidentially I also give access to my family and friends contacts.
4. giving an application/user access to a contact phone number can reveal other personal information (address, birthday, photo...); for example I share the phone number of my sister, but also accidentally it gives access to her address and photo.
5. a malicious application (or remore user) can fill the address book with dummy data (this way the user cannot add other contacts);

Threats based on remote invocation of this API from another device¶

No particular threats identified.

Implementation threats and possible attacks¶

No particular threats identified.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. an application loading all contacts details (including photos) may risk memory problems;
2. data protection laws and issues might arise for remotely-hosted applications loading contact details.

Threats to device manufacturers, operators, other stakeholders¶

1. The privacy issues (ie the problems of private information being disclosed without control) convince potential users not to use the platform.

Mitigations¶

1. The policy must support parameters to select contacts (by name, by detail type, by organization...); this way only selected contacts can be accessed;
2. The policy must allow the user to share only some details of his contacts (for example share details with type="work"); this way only selected details can be accessed;
3. The user should be able to verify which data are available to applications/users;
4. Untrusted applications should not be allowed write access to contacts;
5. It may help to have an interface to show which contacts can be accessed by a particular application or user.

Recommended default policy rules for applications¶

Access to contacts.read feature:

Access to contacts.write feature:

The WAC devicestatus module¶

Overview of API¶

http://specs.wacapps.net/devicestatus/index.html

Provides information about various "aspects" of a device.

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used, accessing IMEI code or other device properties, to fingerprint the user of a personal device.
2. Operating System version and Web Runtime version can be used to exploit version-specific vulnerabilities.

Threats based on remote invocation of this API from another device¶

1. Remote invocation could be used to access personal information. E.g. language (OperatingSystem aspect, language property), country (CellularNetwork aspect, mcc property), mobile operator (CellularNetwork aspect, operatorName property)
2. It could be used to fine-tune remote DoS attack (e.g., the bettery level is a nice information to shape how much aggressive a DoS have to be). #

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. Wrong result of this API can influence the behavior of an application. The result can vary from an odd feeling from the user to severe application faults.
2. If the API can provide unverified results (so, especially in case of untrusted browser or widget) the information with the user can be partially compromised. E.g., an App which want to display a contract and a disclaimer. If the devicestatus does not provide the correct size of the screen, the disclaimer could be not showed to the user since "visualized" in a zone out of the screen.
3. If not wisely used, may lead to excessive power consumption (e.g. through watchPropertyChange() method)

Threats to device manufacturers, operators, other stakeholders¶

1. If the API provides wrong results from the sensors/components, components manufacturers could have bad reputation due to the suspects they components do not work well.

Mitigations¶

1. Main problem with this API, seems information leakage. Thus, remote access should be provided only to trusted entities, to avoid information leakage and attack finetuning
2. Set adequate limit to watch the properties change

Recommended default policy rules for applications¶

Local Invocations:

Remote invocations:

The WAC deviceinteraction module¶

Overview of API¶

Link to API - http://specs.wacapps.net/deviceinteraction/index.html

This module provides a mechanism to interact with the end-user through features such as: device vibrator, device notifier, screen backlight, device Wallpaper.

Threats¶

API-Specific threats and misuse cases¶

1. Excessive use of device notification features (vibrate, backlight) would drain battery and be annoying. This could render the device unusable, or make the user (such as Peter) turn off these features altogether at the OS level, affecting other applications.
2. Using notifications could embarrass the user or alert others to their presence, impacting their privacy. E.g., making the phone vibrate / notify in a public setting.
3. Changing wallpaper could cause embarrassment or alarm. E.g., setting it to something work-inappropriate, or setting Georg's phone wallpaper to have a picture of a woman who is not his wife...

Threats based on remote invocation of this API from another device¶

1. It could cause some panic or confusion if invoked from the wrong device
2. Sending a notification to the wrong device would also render the notification useless - this might result in a loss of integrity/availability of application functionality. It could result in someone missing an appointment or meeting.
3. Remote battery drain is quite possible, as the easiest mitigation for misuse of this API would be the fact that it is obvious if too much vibrating / screen light is used. If the device is remote, however, it will not be obvious

Implementation threats and possible attacks¶

TBC.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

Nothing obvious beyond loss of application functionality.

Threats to device manufacturers, operators, other stakeholders¶

Nothing obvious beyond loss of application functionality. Excessive use of certain features might damage devices?

Mitigations¶

Not a high risk API

1. Remote use of this API seems relatively unlikely. Suggest that it is denied by default for remote invocation.
2. Upon remote invocation of the setWallpaper API, have a mandatory confirm dialogue appear on remote devices.
3. Vibration API Mozilla analysis suggests limits on how often this make be invoked - e.g., don't allow hundreds of API invocations.
4. Limits should be placed on the light on / off command.
5. Require user consent before allowing the "setWallpaper" command.

Recommended default policy rules for applications¶

For the notify, vibrate and light LOCAL invocations:

For the notify, vibrate and light REMOTE invocations:

For setWallpaper LOCAL invocations:

For setWallpaper REMOTE invocations:

The W3C DeviceOrientation Event specification¶

Overview of API¶

http://www.w3.org/TR/2011/WD-orientation-event-20111201/
http://www.w3.org/TR/orientation-event/

Provides information about the physical orientation and motion of a hosting device.

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used to infer keystrokes on the touch screen.

Threats based on remote invocation of this API from another device¶

1. It could also be used to identify someone's general activities and whether they are moving. This might help narrow-down location, and give information about user habits, particularly if augmented by other information (e.g. what's the current user location plus some location specific information).

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

Threats to device manufacturers, operators, other stakeholders¶

Mitigations¶

1. Put the device on a hard surface when typing.
2. Don't use the default on screen keyboard.
3. Disable the orientation sensors during touch-screen keyboard operation, when possible.

Recommended default policy rules for applications¶

Other refs¶

http://static.usenix.org/events/hotsec11/tech/final_files/Cai.pdf

The W3C File API¶

Overview of API¶

http://www.w3.org/TR/2011/WD-FileAPI-20111020/
http://www.w3.org/TR/FileAPI/

Provides read-only file objects representation.

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used to access local files (read only) containing sensitive data.

This could be exploited, for example, by Harold, who develops a free and funny application which can provide the user a nice quote (from an external DB of quotes) chosen on the information present on the file system (e.g., retrieve the user name from the file system, and then look for quotes which contains the same name). To do so, the application access read the file system with the file API, whose behavior if not restricted allow access even to sensitive system sections (e.g. .webinos, where the private key is stored). Those private date can be sent outside during the exchange with the external quote database.

Threats based on remote invocation of this API from another device¶

1. This API could be used to access remote files (read only) containing sensitive data.
2. It may induce a false feeling in the user, which may assume that installing the application on one device limits what it can access to just that device, enabling access of sensitive information on other devices of the zone.
3. It is also a case of minimising the surprise to the end user - they may assume that installing the application on one device limits what it can access to just that device.

Implementation threats and possible attacks¶

1. Arguments are not validated, the Jimmy and Jessica have to provide by itself the proper validation.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. Certain UAs, i.e., Browsers. In order to manage origin-private filesystems within webinos, additional information is required
2. Encoding Subtleties: The W3C File API specification(http://www.w3.org/TR/FileAPI/) requires the IANA: Character Sets to be supported (http://www.iana.org/assignments/character-sets). Internally, JavaScript uses UTF-16; the implementation uses UTF-8 and currently ignores any given encoding. This direct manipulation have to pay attention to not introduce encoding mismatch.
3. unproper data read by applications could contain malicious code, exploit bugs and enable bad application behaviour

Threats to device manufacturers, operators, other stakeholders¶

1. it could be a first step (information leakage, device fingerprinting) for another threat which influence device reputation
2. reading malicious code that enable bugs could provide root access or system crash

Mitigations¶

1. For developers threats, provide examples which clarify how the API works for each ambiguous case
2. Each application could have a filesystem section devoted to its own files. File access outside this area should be denied. (This can be done via File API - Directories and System)
3. Files (or application's file system area) should be encrypted to avoid data disclosure to unauthorized readers.
4. Files' content should be parsed to avoid malicious code execution.

Recommended default policy rules for applications¶

Private Application file system

Non private application file system

The W3C File API - Writer¶

Overview of API¶

http://www.w3.org/TR/2012/WD-file-writer-api-20120417/
http://www.w3.org/TR/file-writer-api/

Provides write-only file objects representation.

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used to corrupt or forge local and remote files' content.
2. It can be used write data to fill the local or remote file system

This open the way to multiple threats, for example, by David to change system parameters or fill the available space of an in-car system, thus leading a not skilled user to frequently come back to the car repairer and spend lot of money.

Threats based on remote invocation of this API from another device¶

1. It is possible for a client to be impersonated, if not trusted identity is verified (and if many devices are regularly off).
2. Ethan, the spammer, could write exploit code in remote files (or in file which will be accessed by remote device), making possible creation of cross-device botnets

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. Certain UAs, i.e., Browsers. In order to manage origin-private filesystems within webinos, additional information is required
2. Encoding Subtleties: The W3C File API specification(http://www.w3.org/TR/FileAPI/) requires the IANA: Character Sets to be supported (http://www.iana.org/assignments/character-sets). Internally, JavaScript uses UTF-16; the implementation uses UTF-8 and currently ignores any given encoding. This direct manipulation have to pay attention to not introduce encoding mismatch.

Threats to device manufacturers, operators, other stakeholders¶

1. In specific device (e.g. In-car system) should be restricted to avoid integrity loss of important system data.

Mitigations¶

1. Each application could have a filesystem section devoted to its own files. File access outside this area should be denied. (This can be done via File API - Directories and System).
2. Files encryption can avoid data forgery but can't avoid data corruption.
3. cross-device IDS to identify cross-device exploits.

Recommended default policy rules for applications¶

Private Application file system

Non private application file system

The W3C File API - Directories and System¶

Overview of API¶

http://www.w3.org/TR/2012/WD-file-system-api-20120417/
http://www.w3.org/TR/file-system-api/

Provides means to navigate file system hierarchies.
Provides means to expose sandboxed sections of a user's local filesystem.

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used to navigate file system directories and other local applications directories.
2. It can take file system resources inappropriately using storage request API.
3. It can prevent legitimate data access moving local or remote files
4. it can delete data removing local or remote files

For example, if access to critical file, like credential ones (e.g. password or private key) is incorrectly allowed, Frankie (the alienated script kiddie) may be able to delete them, in fact "disconnecting" the device from the zone (since no longer able to authenticate versus the other devices), just to make "funny" annoyance to "friends"

Threats based on remote invocation of this API from another device¶

Implementation threats and possible attacks¶

1. Some operations invalidate the entry/blob used, e.g., remove. The implementation does not keep track of the entries/blobs returned, creating copies if the same entry/blob is requested multiple times, thus not propagating invalidation to all affected objects. The validation process is left to the underlying system. This could create integrity weaknesses (entries supposed to be deleted but yet there), and allow for persistent presence of entries, which could lead to information leakage if sensitive information are not properly deleted.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

Developers could experience some discrepancies between actual implementation and expected behavior

1. Certain UAs, i.e., Browsers. In order to manage origin-private filesystems within webinos, additional information is required
2. Encoding Subtleties: The W3C File API specification(http://www.w3.org/TR/FileAPI/) requires the IANA: Character Sets to be supported (http://www.iana.org/assignments/character-sets). Internally, JavaScript uses UTF-16; the implementation uses UTF-8 and currently ignores any given encoding. This direct manipulation have to pay attention to not introduce encoding mismatch.
3. Some operations, e.g., removeRecursively, could continue after the occurrence of an error or exception. This implementation works differently, aborting any operation that encounters an error or exception. Thus, an operation may partially succeed, e.g., removeRecursively may remove some (up to the occurrence of an error or exception) but not all children of a directory. The app developer have to understand and check the success of those commands to avoid damage and leave the system in inconsistent state.
   Presumably an inconsistent delete operation might result in private/valuable data not being deleted, which might cause embarrassment due to unexpected data disclosure. E.g., when selling an old device, or even affect valuable intellectual property.

Threats to device manufacturers, operators, other stakeholders¶

No obvious threats. Not much significantly, an attacker could navigate the OS file system and move or delete OS files, causing OS instability and bad user experience.

Mitigations¶

1. For developers threats, provide examples which clarify how the API works for each ambiguous case
2. Each application could have a filesystem section devoted to its own files. File system navigation, movement, copy and deletion outside this area should be denied, as well as "anonymous" file system access

Recommended default policy rules for applications¶

The W3C Gallery API¶

Overview of API¶

http://dev.w3.org/2009/dap/gallery/

Provides access to the media gallery.

NOTE: at the moment there is not implementation (deferred to phase 2) and no final decision about the specification (the W3C Gallery is a little outdated). Thus, only quite vague threats are mentioned.

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used to access sensitive multimedia data stored in a local or remote gallery.
2. Adding objects to the gallery an attacker could fill the file system.

An attack perpetrated by an evil person could discredit or embarrass a specific individual, accessing sensible photos and even allowing for ransom in the worst cases.
The integrity of photos and gallery must be assured as well, to avoid possible cases of vilification (e.g. by changing a photo with a modified one).

Threats based on remote invocation of this API from another device¶

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

Threats to device manufacturers, operators, other stakeholders¶

Mitigations¶

1. The Gallery implementation should impose restrictions to the gallery size,

Recommended default policy rules for applications¶

The W3C Geolocation API¶

Overview of API¶

Link to API - http://www.w3.org/TR/geolocation-API/

"This specification defines an API that provides scripted access to geographical location information associated with the hosting device."

Threats¶

API-Specific threats and misuse cases¶

1. Leaking of location to unauthorised parties (e.g. through advertising networks or through spoofing of app identity)
2. Misuse of location data by authorised parties (e.g. an app starts using location to track users rather than provide contextual functionality)
3. Unintentional authorisation of malicious parties (e.g., users select 'OK' to an app they didn't mean to. Or an app gains access through another app)
4. Unexpected consequences of geolocation data disclosure (e.g., the user reveals their location but then realises it was a mistake in retrospect)

More details:

1. This API gives applications access to the location of the end user, which could be privacy sensitive.
2. It may result in advertising that the user finds annoying, it might be given away to third party advertisers, or be used for customer/user analytics at a later date (profiling). This data could end up on unauthorised websites.
3. The application might publish this information in a way that the user has no control over, and therefore might be seen by unexpected people. E.g., someone's friends or family might see their location without the user's knowledge. This would be extremely bad if they were visiting a potentially sensitive or embarassing place, such as a hospital or police station. It may also be embarassing if someone learns about a relationship or interest the end user has but wishes to keep a secret.
4. Multiple location details could be correlated over time to build up a picture of user activities. This might be used for predicting future behaviour and be inaccurate or misleading. It might also reveal habits that the user is uncomfortable with knowing.
5. Thieves might use location data to find out whether someone is away from their house in order to burgle them. It could also tell a mugger where to wait for someone with an expensive phone, car or tablet device.
6. Stalkers might use disclosed location data to track their target and intimidate or threaten them.
7. In dangerous situations (e.g. in unstable countries with terrorists or unrest) this API could accidentally give away location data which would expose the end user.
8. Inaccurate information could cause accidents or mistakes if users rely too heavily on the output of this API.
9. Geolocation data could connect otherwise unlinkable user actions. E.g., a tweeting application and a online shopping application could correlate user identity by spotting that the user was in the same place at the same time.
10. Users might allow location data for one action, but not want to allow it forever. If the API made it easy for applications to gain and then reuse permission, this would be a problem.
11. Users might realise at a later date that their location information, as attached to some record somewhere online, was either inaccurate or privacy-invasive for some reason. E.g., it might have revealed their presence at a movie theatre when they had claimed to be unwell and off work.
12. This API might be used for a "find my phone" type application for lost or stolen devices. If it loses availability or is inaccurate, such a feature would be useless.

From Mozilla - https://wiki.mozilla.org/WebAPI/Security/Geolocation

Threats based on remote invocation of this API from another device¶

1. Remote invocation can result in unexpected revelation of data. E.g., an application might access location information about the users' car, when they were expecting it to be about their TV. Different devices will be in privacy sensitive or insensitive locations, so accidentally authorising the wrong one is a problem.
2. Remote geolocation would allow users to pretend to be in a location they are not. This might be a problem for applications relying on this information.

Implementation threats and possible attacks¶

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. A developer might base their app on geolocation in order to implement a security or privacy feature. E.g., only allowing access to certain parts of the app if they are at work, or in a certain place. This would be easy to circumvent.

Threats to device manufacturers, operators, other stakeholders¶

1. Geolocation drains battery and (if it is assisted GPS) might use bandwidth
2. Geolocation (if unconstrained) could slow down the phone

Mitigations¶

1. Users must be prompted before geolocation is first requested or used.
2. Revocation of permission to access geolocation must be possible and easy to access.
3. Insist on plausible deniability. E.g., it should always be plausible for the API to return a "no data" result.
4. Implement a cap on the number of one-off 'getCurrentPosition' requests allowed
5. Make it visible to the end user that their location is being watched or accessed by a particular app. Make it easy to turn off/on geolocation data
6. Make the geolocation service selection easy, and do not provide access to remote geolocation by default. Device-agnostic policies should either not be possible, or not be easy to end up with.

Recommended default policy rules for applications¶

The W3C Media Capture and Streams API¶

Overview of API¶

http://dev.w3.org/2011/webrtc/editor/getusermedia.html

This specification defines an API that provides access to the audio, image and video capture capabilities of the device. Development on the previously referred W3C Media Capture API (http://www.w3.org/TR/media-capture-api/) has stopped, and further work is taking place as part of Media Capture and Streams (http://dev.w3.org/2011/webrtc/editor/getusermedia.html).

Threats¶

API-Specific threats and misuse cases¶

1. This API could be used to compromise the privacy of the user, as the accessed media may contain private information, either directly in audio or video form or could be derived from the shown surrounding, e.g. location of the user, contact/dialogues with other persons or in the simplest case the presence of the user.
2. Accessed audio or video could be used to build user profiles, e.g. music/TV in background captured and delivered with the stream.
3. Users will expect the same security in Web based real-time communication as they are used to from traditional telephony service, e.g. the identification of callee and caller is up the application. A user may be communicating with someone else than he/she is expecting.

Threats based on remote invocation of this API from another device¶

1. Any mechanism that bypasses the user consent to allow the media capture could be misused by potentially malicious apps. As this API introduces programmatically privacy threats and was originally designed for the Web browser execution environment an user consent prompt is an inherent part of its rationale. Any remote invocation should therefore incorporate user consent as well. Implications of a remote prompt needs to be examined.
2. API usage could generate high costs through generation of high volume data

Implementation threats and possible attacks¶

In the first phase of the project this API was not implemented. Only theoretical assertions can be made currently.

1. The concurrent access to media capture devices could be made possible but could have consequences of the end user. For example, once a user has granted access within one application and switches to use a different application then the first one may still have access to the media capture devices. This leads to a requirement of exclusive usage of a specific device and revocation of granted access rights.

Threats to apps and developers using this API (E.g. Jimmy and Jessica)¶

1. In both cases exclusive and shared access to media capture devices unexpected behavior. Exclusivity may lead to denial of service and shared operation mode to non-transparency for the end user.

Threats to device manufacturers, operators, other stakeholders¶

1. Enabling audio and video communication in Web applications may have impact on the traditional telephony via mobile/fixed operated networks as well as VoIP networks
2. Device manufacturers may be forced to improve their products to support media processing for Web based communication (hardware media en/decoding) to lower the thread of high cpu usage and unresponsive devices

Mitigations¶

• Require explicit user consent before a service may be accessed
• Provide a notification when a device's media capture services are in use. Also make clear from the calling device where a media capture service is hosted (e.g., which device is providing the API).

Recommended default policy rules for applications¶

Components¶

This section was automatically generated based on the contents of the webinos WP 2 git repository at http://dev.webinos.org/git/wp2.git.

Application Client¶

Description¶

Application using webinos APIs.

Interfaces¶

Structure¶

Component Requirements¶

None

Certificate Manager¶

Description¶

Generates certificates for PZPs before device enrolement.

Interfaces¶

Structure¶

Component Requirements¶

None

Context API¶

Description¶

Context API client

Interfaces¶

Structure¶

Component Requirements¶

None

Context Database¶

Description¶

Database of context objects

Interfaces¶

Structure¶

Component Requirements¶

None

Context Manager¶

Description¶