We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Security.Data Handling Generic Enabler - FIWARE Forge Wiki

FIWARE.OpenSpecification.Security.Data Handling Generic Enabler

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Security.Data Handling Generic Enabler
Chapter Security,
Catalogue-Link to Implementation [N/A ]
Owner SAP, Slim Trabelsi

Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.

Copyright

  • Copyright © 2014 by SAP

Legal Notice

Please check the following FI-WARE Open Specification Legal Notice (essential patents license) to understand the rights to use this open specification. As all other FI-WARE members, SAP has chosen one of the two FI-WARE license schemes for open specifications.

To illustrate this open specification license from our SAP perspective:

  • SAP provides the specifications of this Generic Enabler available under IPR rules that allow for a exploitation and sustainable usage both in Open Source as well as proprietary, closed source products to maximize adoption.
  • This Open Specification is exploitable for proprietary 3rd party products and is exploitable for open source 3rd party products, including open source licenses that require patent pledges.
  • If the owner (SAP) of this GE spec holds a patent that is essential to create a conforming implementation of the GE spec (i.e. it is impossible to write a conforming implementation without violating the patent) then a license to that patent is deemed granted to the implementation.

Overview

The Data Handling GE is a privacy-friendly attribute-based access control system, which targets mainly sensitive data. It permits to store information together with an attached privacy policy, which regulates its usage. Thus, the Data Handling GE can reveal certain attributes, according to specific supplied conditions. The Data Handling GE supports integrated data handling (two-sided detailed data handling), that takes into account specific preferences/policies expressed using PPL (Privacy Policy Language)[PPL]. PPL is based on the XACML standard [XACML]. Data usage purpose must always be declared, as it is a relevant part of the policy that must be expressed, as well as downstream usage, i.e., whether one can disclose collected data with third parties. PPL supports the enforcement of a number of obligations, which are bound tightly to data. For instance, one can impose a specific retention period, as well as the production of user's notifications and/or logging under certain conditions.

For the third release of this GE, we propose a new feature called Identity Based Data encryption. This feature offers the possibility to ecrypt the data that will be stored in the database. We use the identity of the receiver or the delegate as public key for encryption. Only the owner of this identity will be able to decrypt the data with the private key associated to its identity.

Target usage

The Data Handling GE provides a mechanism for controlling the usage of attributes and data (more precisely, of Personal Identifiable Information or PII) based on the concept of ‘sticking’ a data usage policy to the data to which it applies. When the data is accessed by an application, an access control technology is then used to verify that the intended use of the data matches the scope defined in the usage policy. Therefore, the Data Handling GE can be used by any application or service that would offer a transparent data handling policy to users and third parties. In the example scenario (see next section), we propose to use the API of the Data Handling GE for a file storage website that is collecting private data of the subscribed users.

Basic Concepts

Relevant Concepts and Ideas

In this section, the more important concepts are explained. The used terminology is coherent with definitions in the European Parliament Directive 95/46/EC, "on the protection of individuals with regard to the processing of personal data and on the free movement of such data". More detailed information is provided in the Terminology section.

Data Controller

The Data Controller indicates the entity which (alone or jointly with others) determines the purposes and means of the processing of personal data.

Data Subject

The Data Subject is the person whose personal data are collected, held or processed by the Data Controller.

The Data Subject has the right to access his data and to require the Controller to rectify without delay any inaccurate or incomplete personal data. The Data Subject has the right to require the Controller to erase data if the processing is unlawful.

Personal Data (Personal Identifiable Information, or PII)

Personal Data means any information relating to an identified or identifiable natural person or Data Subject.

An identifiable person is someone who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his or her physical, physiological, mental, economic, cultural or social identity.

User Agent

A software system (such as a web browser) acting on behalf of a user. The user agent acts on user preferences when dealing with a server acting on behalf of a Data Controller.

PII and PPL

The Data Handling GE regulates the access to sensitive data, collected from users. This can be achieved through the association of a set of preferences/policies to each PII; privacy policies are expressed using the PPL. PPL is used:

  1. at PII collection time, as each information that enters the Data Handling GE must come along with a PPL policy;
  2. at each usage of data, that is regulated according to the associated PPL policy.

In fact, for each data access, the Data Handling GE evaluates its purpose, which must always be declared. Access purpose is a relevant part of the policy that must be expressed, and if and only if there is compatibility between the data policy and the request policy, the information is provided to the requester. The Data Handling GE is also responsible for fulfilling obligations contained in PPL policies, like for instance, sending an email to the data owner at each access.

PPL Architecture

The PPL engine used as core reasoning and enforcing engine for access control and usage control policies has the following structure: image:Architecture.jpg

  • Policy Enforcement Point (PEP) formats and then dispatches the messages to the associated components according to the state of the execution process. The decision made by the PDP is enforced in the PEP, meaning that if the PDP decided to provide a data or enforce the access of a resource, this data/resource is collected, formatted and sent to the receiver through the PEP.
  • Policy Decision Point (PDP) is the core of the PPL engine. All the decisions regarding processing of policies are taken in this component. The Access control engine is in charge of the application of the access control rules related to the local resources. It analyses a resource query, checks the access control policy of the requested resource and decides whether or not the requestor satisfies the rule.
  • Obligation handler is responsible for handling the obligations that should be satisfied by the data controller/third party. This engine executes two main tasks: Set up the triggers related to the actions required by the privacy preferences of the data subject. Executes the actions specified by the data subject whenever it is required.
  • Event Handler: monitor all the events executed on the data and informs the Obligation Handler in order to check for an Obligation related to an event.
  • Ecryption Module (called PPL-IBE): feature added in the Release 3 of the Data Handling GE is in charge of encrypting/decrypting data stored in the DB.

Example Scenarios

Use Case: Privacy Aware Online File Store

In this scenario we describe how the Data Handling Generic Enabler can be used jointly with an online file store service (de ployed in the cloud or in a server) in order to provide the access and usage control functionalities. The data handling GE offers to the user of a traditional file store the possibility to select the users with whom he wants to share his files. He can specify a retention period for his data or his sharing permission. He can configure notification messages alerting him about the access to his files.


Image:DHGE.jpg

The scenario is executed on two main steps:

Store Data with Sticky Policies

The user who wants to store his data in a secure manner defines: the list of delegates who can access his data, the deletion period or life time of his data in the store, and a contact medium to be notified on the activities and events happened to his data. The data owner can encrypt the data with the identity of the delegate. Once his data is saved in the store (encrypted or not), a sticky policy representing his privacy preferences will be stored together with the files and the obligation engine of the Data Handling GE service executes the obligation (retention period) monitoring system.

File:DHGE Store v3.jpg

Retrieve Data from the file store

The delegates receive a notification when they have access to new files in the store. They can access to the shared files through the file navigator. If the data is encrypted, the receiver has to use the private key related to his identity in order to decrypt the data. Once they access and retrieve accessible files, the Data Handling Service will send a notification to the data owner to inform him about the access details (who accessed, when, where, etc.). The Data Handling GE is in charge of enforcing the Access Control rules imposed by the data owner and execute the obligations on the usage of the data.

Image:DHGE retreive V3.jpg

Main Interactions

Architecture

Block Diagram

Image:Data Handling GE block diagram v4 (2).png

Every actor in this figure is running an instance of the Data Handling GE combined with their web application

Sequence Diagram

Image:Sequence diagram.jpg

Description:

This sequence diagram reflects the use case depicted above. This explanation keeps the same concepts, focusing on detailing the main execution steps, however the numeration of the sequence diagram does not reflect exactly the one of written in the Use Case. Data Subject and Data Controller are distinguished instances of the Data Handling GE.

  1. Encrypt Data: 'This step is optional'. Before storing the data to protect with PPL, the data subject has the possibility to ecrypt the data with the Identity Based Encryption Module. The Data Subject uses the identity of the delegates as public key to encrypt the data.
  2. Store Data: The data subject can use PPL to safely store her data. During this storage phase, the data subject attaches a sticky policy containing usage and access control constraints related to her (encrypted) data.
  3. Request Data: The data controller requests the data to the PPL engine. If the Data controller is entitled to access this data, the PLL engine send her the (encrypted) data.
  4. Request private key: if the data provided by the PPL to the data controller is encrypted, the Data controller has to ask for a private key related to his identity (an identity can be for example an e-mail address). The PPL-IBE can send the private key embedded into a X509 certificate, or in a String mode (non protected).
  5. Decrypt the Data: If the data requested is encrypted, the data controller uses the private key provided by the PPL-IBE in order to decrypt the data.

Basic Design Principles

The Data Handling GE permits to protect information according to a specific privacy policy. The Data Handling GE safeguards data, storing them together with the respective privacy policies. Any access to the protected resources can happen only declaring explicitly its purposes (using again a description encoded in a privacy policy). The Data Handling GE evaluates the two policies (data and access requests), and transmits the requested information if and only if the policies match.

Detailed Specifications

The following is a list of Open Specifications linked to this Generic Enabler. Specifications labeled as "PRELIMINARY" are considered stable but subject to minor changes derived from lessons learned during last interactions of the development of a first reference implementation planned for the current Major Release of FI-WARE.

Open API Specifications

Appendix

References

EC Data Protection directive http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML
PPL http://www.primelife.eu/results/documents/153-534d
XACML http://xml.coverpages.org/xacml.html

Architecture Description of the Accountability Feature

Copyright

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications.

Overview

The Accountability Feature is an extension to the Data Handling GE (see its overview above). It consists of a log analyser that analyses PPL data usage logs and checks their compliance against joint (sticky) policies. Accountability of the data controller towards data subjects is realised by forcing the data controller to demonstrate, through mechanised compliance, that data handling proceeded accordingly to predefined rules.

Target usage

The Accountability Feature, used in conjunction with the Data Handling GE (see its target usage above) increases the trust of users about their privacy by providing them with strong guarantees and transparency about the actual processing of their personal data. The log analyser could be used by an accredited third party on behalf of a data subject.

Basic Concepts

Relevant Concepts and Ideas

Accountability

In the Article 29 Working Party[1] Opinion on the principle of accountability, the principle of accountability is defined as showing how responsibility is exercised and making this verifiable. From a legal perspective, accountability refers to obligations of a party (here, the data controller) with respect to another (here, the data subject) in terms of justification and demonstration with respect to a norm.

Here the goal is to increase the balance of power between those two entities. In particular, concerning data protection, our goal is to put in place effective measures to ensure compliance with privacy policies (both official regulations and the policies declared by the data controller). In fact, there is a need to record information reflecting the actual execution of the system (through logs) and to prove compliance, in order to enable effective, external audits.

Compliance Check of a PPL Log

This diagram depicts the interaction of the Accountability Analyzer, which implements the Accountability Feature, with its environment. The Data Subjects owns PII.


  1. The Data Controller and the Data Subject agree (by automated matching performed by the PPL engine) on a joint agreement called Sticky Policy.
  2. The Data Subject then provides his PII to the Data Controller. Data handling operations generate, via the PPL Logger, a trace of data handling events (the log).
  3. The Accountability Analyzer takes as input both the log and Sticky Policy and performs a compliance check based on the semantics of PPL. The Analyzer then concludes whether the sequence of events was compliant with the Sticky Policy, or whether it breached it.

Main Interactions

The main interaction between this Feature and the Data Handling Generic Enabler is the use of the Feature to analyse traces of data handling events (logs) generated by the Data Handling Generic Enabler. The Feature takes as input a set of PPL log files: both the logs from the Event Handler, and the logs from the MySQL database. It checks their compliance against the relevant Sticky Policy and outputs a conclusion about the compliance of the data handling with the initially defined Sticky Policy.

The feature does not use APIs but a single executable, loganalyser, which takes as a parameter a PiiId (an integer).

Basic Design Principles

The Accountability Feature checks data handling logs against corresponding Sticky Policies. The logs must be in the format produced by the PPL engine, unaltered. Sticky Policies are stored in XML files. The Accountability Feature's main component, the Analyzer, inspects the log and concludes that it is either compliant or non-compliant with the sticky policy.

In terms of design, the Analyzer parses log files and policies, and outputs its result according to predefined compliance semantics.

Appendix

References

Article 29 Opinion on accountability http://ec.europa.eu/justice/policies/privacy/docs/wpdocs/2010/wp173_en.pdf
  1. The group of representatives of European data protection authorities.

Re-utilised Technologies/Specifications

The Repository GE is based on RESTful Design Principles. The technologies and specifications used in this GE are:

  • RESTful web services
  • HTTP/1.1
  • JSON and XML data serialization formats


Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions


  • Access Control: This means to control access to resources such as web pages. This may be on the basis of the identity of the entity requesting access, or more generally the presentation of a set of credentials, and possibly some representation of the purpose for accessing the resource, as well as other contextual information, such as the time of day and properties of the resource itself.
  • Credentials: A credential is an attestation of qualification, competence, or authority issued to an individual by a third party with a relevant de jure or de facto authority or assumed competence to do so. In this document, we define digital credentials to be lists of attribute-value statements certified by an Issuer. Here we abstract from the concrete mechanism (cryptographic or other) by which the authenticity of the attribute values can be verified. We do not impose any restrictions on which attributes can be contained in a credential, but typically these either describe the identity of the credential's owner or the authority assigned to her.
  • Personal Data (Personal Identifiable Information, or PII): Personal Data means any information relating to an identified or identifiable natural person or "Data Subject". An identifiable person is someone who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his or her physical, physiological, mental, economic, cultural or social identity. The processing of special categories of data, defined as personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and of data concerning health or sex life, is prohibited, subject to certain exceptions (see Article 10 of Regulation (EC) 45/2001). (From the European Directive on the protection of personal data, Regulation (EC) 45/2001, article 2. OJ L 281, Nov. 23, 1995, available here)'
  • Data Controller: The Data Controller means the entity which alone or jointly with others determines the purposes and means of the processing of Personal Data. The processing of Personal Data may be carried out by a Data Processor acting on behalf of the Data Controller. This document describes the means for a User Agent acting on behalf of a user to reach an agreement with a Data Controller over the obligations incurred by the controller for any personal data collected about that user.
  • Downstream Data Controller: When a Data Controller passes personal data to a third party, that third party incurs obligations in respect to the Data Subject, and is referred to in this document as a "downstream data controller".
  • Data Subject: The Data Subject is the person whose personal data are collected, held or processed by the Data Controller. The following strictly speaking refers to EC institutions not generally to EU companies etc. The controller must give the Data Subject the following information about the data being processed:
    1. confirmation as to whether or not data related to him or her are being processed;
    2. information about the purposes of the processing operation, the categories of data concerned, and the recipients or categories of recipients to whom the data are disclosed;
    3. communication of the data undergoing processing and of any available information as to their source;
    4. Knowledge of the logic involved in any automated decision process concerning him or her.
    • The Data Subject has the right to access his data and to require the Controller to rectify without delay any inaccurate or incomplete personal data. The Data Subject has the right to require the Controller to erase data if the processing is unlawful.
  • Data Subject’s privacy preferences: The expectations of a Data Subject in terms of how her personal data should be handled.
  • Authorization and Obligations: Authorizations and Obligations define how and in which way a Data Subject authorizes a Data Controller to process her personal data. Obligations are negotiated together with Authorizations, and define what operations the Data Controller will perform at each authorized data usage. A specific process enables the Data Controller to propose obligations to the Data Subject, which matches them against her preferences. If the Data Subject is satisfied with the match, she will then authorize the Data Controller to proceed. The Data Controller is then required to implement the agreed obligations in respect to the Data Subject's personal data.
    In a variant of this approach, the Data Subject could propose obligations to the Data Controller, who would then match them against her policies, and inform the Data Subject if the proposal is acceptable. The end result is the same — a binding agreement on the obligations for the Data Controller, to handle the Data Subject's personal data.
  • Sticky Privacy Policy: It is an agreement between Data Subject and Data Controller on the handling of personal data collected from the Data Subject. Sticky policies (as well as privacy preferences and privacy policies) define how data can be handled. A privacy policy becomes "sticky" to the data it regulates, after a specific negotiation process between Data Subject (the data owner) and Data Controller. Sticky policies define different aspects:
    1. Authorizations:
      • Usage: what the Data Controller can do with collected data (e.g. use them for a specific purpose).
      • Downstream sharing: under which conditions data can be shared with another Data Controller.
    2. Obligations: what the Data Controller must do.
  • Privacy Policy Language (PPL): The Privacy Policy Language (PPL) expresses access and usage control rules. It is based on the XACML standard. It permits to define privacy policies that regulate and specify obligations for the usage of personal identifiable information (PII).
  • DHP: This term refers to an acronym of Data Handling Policy/Preference. It is a policy configuration file stating the usage condition and handling of a targeted data. In the case of Policy it refers to the description of how the Data Controller will handle the data collected. In the case of Preference, the Data Subject specifies how his data should be handled after being collected.
  • User Agent: A software system (such as a web browser) acting on behalf of a user. The user agent acts on user preferences when dealing with a server acting on behalf of a Data Controller.
Personal tools
Create a book