Sean Simpson

Thomas Groß

A Survey of Security Analysis in Federated Identity Management

Keywords: FIM, Survey, Dependability, MAFTIA, Microsoft Passport, OAuth, OpenID, Facebook Connect, SAML, Liberty Alliance

We conduct a systematic survey of security analysis in Federated Identity Management (FIM). We use a categorisation system based off the Malicious and Accidental Fault Tolerance framework (MAFTIA) to categorise security incidents in FIM. When security incidents are categorised, we can paint a picture of the landscape of problems that have been studied in FIM. We outline the security incidents that are happening across FIM protocols and present solutions to those security incidents as proposed by others.

Introduction

Federated Identity Management (FIM) aims to alleviate the problem of a user having to remember too many credentials by allowing the user to sign into multiple Service Providers (SP) using the same credentials which are provided by an Identity Provider (IdP). Typically in FIM, the user will attempt to access a SP which will then redirect the user to authenticate with the IdP which will vouch for the user, communicating with the SP to say that the user is who they say they are. FIM solutions are seeing increasing use and numerous attacks on protocols used in FIM have been found, which is motivation to do a survey in the area.

Protocols in FIM have been analysed by others in an attempt to find security problems. The issue is that there is a lot of different information on the analysis of security protocols in FIM that remains uncompiled. Our goal is to create a survey paper for security analysis in FIM. We review existing peer reviewed academic publications that perform security analysis on FIM protocols to establish a common ground and collect knowledge. In addition, we want to create a unified way of looking at security incidents in FIM and offer a framework to do that. We do this to provide insight on attacks that are seen on multiple protocol suites and state the solutions to security incidents as provided by the authors of the surveyed papers.

Related Work

Delft & Oostdijk presented a paper which collects the security issues that exist in OpenID [START_REF] Van Delft | A security analysis of openid[END_REF]. There is an additional need to examine security issues across FIM which is what we aim to do. There have been attempts to survey FIM in general. For instance, Ghazizadeh et al. [START_REF] Ghazizadeh | A survey on security issues of federated identity in the cloud computing[END_REF] survey issues within OAuth, OpenID and SAML. The FIM standards surveyed is somewhat limited because Liberty Alliance and WS-Federation are not considered. In addition, analysis on FIM implementations -such as Microsoft Passport -are not considered in the survey which also provide information on security issues in FIM.

Method

Aim

RQ1: Understanding the Security Landscape in FIM . What is the landscape of the security analysis in FIM? We investigate to what extent FIM vulnerabilities, attacks and intrusions can be modelled systematically in a fault-tolerance formalization to understand security issues in FIM. What areas in this landscape might be missing research attention? RQ2: Common Attack Classes. Which attack classes are prevalent across protocol suites? Do these attack classes apply to protocol specifications or implementations? Which papers go a step further and find a flaw in the specification and test it on implementations. RQ3: Solutions/Mitigations. What solutions have been proposed to mitigate attack classes?

Search Methodology

We have done a systematic literature review based on the foundations described by Kitchenham [START_REF] Kitchenham | Procedures for performing systematic reviews[END_REF] . We used two search engines to perform the literature search: Scopus and Google Scholar. We observed a number of key words being used and used synonyms. We based the protocols searched off of surveys done in the area of FIM protocols [START_REF] Pfitzmann | Federated identity-management protocols In International Workshop on Security Protocols[END_REF]. We needed a logically equivalent search in Google Scholar. Below is a part of the resulting search term. We executed the search term with the "search by relevance" radio option selected and the "where the words appear anywhere in the article" radio button selected. Protocol as can be seen in the template search below is substituted with the twelve FIM protocol terms that can be seen in the Scopus search.

Inclusion & Exclusion

Inclusion. We included papers returned from the search based on the following criteria:

-Be in the subject area of computer science.

-Reference FIM protocols.

-Be published as part of a peer-reviewed venue (i.e., workshop, conference or journal). -Be unique: some papers are published somewhere, and then a very similar version of that paper can appear from the same authors at other venues.

Exclusion. After the inclusion phase, we excluded papers based on the following criteria:

-We exclude secondary sources (hence, constrain the SLR to original research). -We exclude papers that do not offer a combination of vulnerabilities and anticipated exploits thereof. Claiming a vulnerability is not sufficient. -We exclude hypothetical analyses, which modify a standardized FIM protocol to conduct a "what-if" analysis. We want to collect security incidents for real FIM systems and not for proposed extensions which may or may not be acted upon. -We exclude security incidents that are put forward for FIM in general. The security incident has to be specific to a certain FIM protocol. The reason for this is to ensure that we get a representation of security incidents possible on real FIM systems.

Data Collection

After the inclusion/exclusion refinement we have a sample of 31 papers. From those papers, we manually code parts that describe security incidents and weak-nesses (e.g., vulnerabilities or attacks). These observations are classified using our categorisation system described in Sect. 3.6.

Malicious and Accidental Fault Tolerance (MAFTIA)

We categorised security incidents based on Malicious and Accidental Fault Tolerance(MAFTIA) principles [START_REF] Powell | Conceptual model and architecture of maftia[END_REF]. MAFTIA is built upon the foundation of dependability [START_REF] Avizienis | Fundamental concepts of dependability[END_REF]. The dependability area is concerned with understanding what happens when a system fails in order to apply fault tolerance to avoid a failure. While dependability focuses on accidental failures, MAFTIA adapts the founding notions of dependability for use in understanding how systems fail under the influence of a malicious adversary. We use the notions founded by the dependability community to understand and thereby categorise security incidents in FIM. We introduce a number of key terms from MAFTIA which we use to build our categorisation system.

Definition 1. Adversary Malicious person or organizations at the origin of attacks. Vulnerability A fault that is created during the development or operation of the system that if exploited causes an intrusion. Attack A malicious interaction fault that attempts to exploit a vulnerability.

Can be thought of as an intrusion attempt. Intrusion An adversary-introduced fault. An intrusion is created as the product from an attack successfully exploiting a vulnerability by an adversary. Failure When the system is adjudged to not be offering correct service.

Our Categorisation System

While MAFTIA terms help us understand a security incident, they are too low level to be used for categorisation. In addition, there are some additional aspects to a security incident in FIM that are desirable to capture which are not considered by the MAFTIA framework. We therefore introduce our categorisation system for use in categorising security incidents in FIM. The categorisation system has six dimensions Vulnerability , Attack Class, CIA Failure, Target Protocol, Incident Type, and Solution Presented. The term Vulnerability has already been defined in Sect. 3.5. We will go on to define what the rest of these terms mean.

Definition 2. Attack Class A collection of attacks, intrusions and resultant errors in a system that form casual chains from vulnerabilities to a security failure if the errors are not dealt with.

Considering a casual MAFTIA fault-error-failure tree for vulnerabilities, attacks, intrusions, errors and ultimately security failures, the attack class contains the trunk of the tree. An attack class is an abstraction of the adversary attack which attempts to exploit a vulnerability -therefore it is separate from the vulnerability -and all of the resulting intrusion states and further attacks (which sometimes can be trivial, like entering a user password) that produce errors in a system -up until the point at which a failure occurs. The purpose of the attack class is to capture the essence of what an adversary does and abstract away from the unimportant details. The unimportant details being the order of attack events, intrusions and errors occur in and slight variations in what errors, intrusions and errors actually occur. There is always a critical attack event which the attack class derives it's handle from and the surrounding details can vary. It is often the case that certain vulnerabilities lead to certain attack classes (i.e., Weak DNS leading to DNS Poisoning) but that is not always the case (i.e., a replay attack class can be caused by unencrypted communications or from a lack of binding) -which is why we distinguish between the vulnerability and attack class.

Definition 3. Confidentiality, Integrity, Availability (CIA) Failure We view a system to have failed when the confidentiality, integrity or availability of a service is violated for a user.

In essence we translate what a failure would mean in a FIM system. We want to know how a user is affected by a security incident in order to discern the impact of intrusions. Also of note is that an account can be compromised by a security incident, in this case, the confidentiality, integrity and availability of the service can all be affected.

We also consider the target FIM protocol, the incident type -was the security incident found at the protocol level, the implementation level, or found at the protocol level and tested on the implementation -and whether a solution was proposed -sometimes that solution is implemented before the publishing of the paper and this will be stated when it happens. The introduced terms have evolved to capture six different dimensions in a surveyed security incident: What is the weakness in the system (Vulnerability)? What does the adversary do to attack the system (Attack Class)? ) How does the security incident affect the user (CIA Failure)? What FIM protocol is the subject of the attack (Target Protocol )? Is the incident due to an implementation or design flaw (Incident Type)? Was a solution put forward by the author (Solution Presented )? We use all of these terms to describe surveyed security incidents in FIM in subsequent sections.

Limitations of Survey

We performed a systematic literature review on Scopus and Google Scholar. The limitations of this is that we might miss things. We are aware of one notable paper which did not appear from our search in Microsoft Passport by Kormann and Rubin [START_REF] David | Risks of the passport single signon protocol[END_REF]. We included this paper in the survey as an exception. This is the only paper we made this exception for and the reason we did this for this one paper is because we consider it a cornerstone in analysis of FIM systems. A number of other security analysis papers cite the paper by Kormann and Rubin and it was the first paper, to the best of our knowledge, to bring security issues in FIM to light.

We do not attempt to discern the quality of the reviewed papers. This introduces the fact that security incidents, which some may deem to be trivial, are represented in the survey. In addition, we cannot guarantee that every security incident is correct because if we begin to use our judgement to discriminate what we perceive as incorrect results we risk compromising the survey.

Surveyed Papers

In this section we briefly outline the landscape of what we have seen, sorted by targeted FIM protocols that we have considered in the survey in order to address RQ1. We can see if attack classes are occurring at the protocol or implementation level which relates to RQ2. Some solutions proposed by the authors are also presented which relates to RQ3. The various protocols considered can have a number of different versions -to keep the survey into the protocols simple, we ignore this complication.

Microsoft

We are considering the papers that are concerned with the numerous attempts made by Microsoft to implement the concept of FIM (Passport .NET, Microsoft Accounts and Cardspace). We found four papers in this category [START_REF] David | Risks of the passport single signon protocol[END_REF][START_REF] Oppliger | Microsoft. net passport and identity management[END_REF][START_REF] Alrodhan | Improving the security of cardspace[END_REF][START_REF] Gajek | Risks of the cardspace protocol[END_REF] and all four papers proposed security incidents effective at the protocol level but did not test them on implementations. Three papers [START_REF] David | Risks of the passport single signon protocol[END_REF][START_REF] Alrodhan | Improving the security of cardspace[END_REF][START_REF] Gajek | Risks of the cardspace protocol[END_REF] reported on the vulnerability of weak DNS being exploited by a DNS poisoning attack class which would force an unknowing user onto a malicious domain that is supposed to look familiar to them, in order to trick the user into logging on. The adversary will steal these credentials since the adversary owns the malicious domain and will then compromise the account of the user -leading to a myriad of CIA problems.

Alrodhan & Mitchell proposed a solution, which is the uptake of DNSSEC [START_REF] Alrodhan | Improving the security of cardspace[END_REF].

Two of these papers point out a bogus merchant attack class capitalising on the FIM no trust infrastructure vulnerability (there is no safe infrastructure list, meaning a user does not know who to trust) which would lead to compromised user accounts [START_REF] David | Risks of the passport single signon protocol[END_REF][START_REF] Gajek | Risks of the cardspace protocol[END_REF].

Alrodhan & Mitchell [START_REF] Alrodhan | Improving the security of cardspace[END_REF] brings up the possibility of a malicious providerwhich is a provider that wants to track the actions of a user -exploiting the centralised infrastructure vulnerability that FIM suffers from (IdP at the center of FIM system being able to track user actions). The malicious provider in control of the IdP will observe the SPs a user visits and build a profile. No solution was proposed by the author for this security incident. Kormann & Rubin also state that the centralised infrastructure vulnerability can lead to a Denial of Service (DDoS) attack.

OAuth

The papers that we found to have security incidents in this category [START_REF] Sun | The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems[END_REF][START_REF] Alotaibi | Enhancing OAuth services security by an authentication service with face recognition[END_REF][START_REF] Ferry | Security evaluation of the OAuth 2.0 framework[END_REF][START_REF] Li | Security issues in OAuth 2.0 SSO implementations[END_REF][START_REF] Shernan | More guidelines than rules: CSRF vulnerabilities from noncompliant OAuth 2.0 implementations[END_REF][START_REF] Yang | Model-based Security Testing: An Empirical Study on OAuth 2.0 Implementations[END_REF][START_REF] Grzonkowski | Security analysis of authentication protocols for next-generation mobile and CE cloud services[END_REF] widely report on a Cross-Site-Request-Forgery (CSRF) attack that capitalises on a weak SP vulnerability. The OAuth specification outlines things the SP must do to resist CSRF attacks, which some SPs do not do. In fact, five of the seven OAuth papers analysed reported this vulnerability [START_REF] Sun | The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems[END_REF][START_REF] Ferry | Security evaluation of the OAuth 2.0 framework[END_REF][START_REF] Li | Security issues in OAuth 2.0 SSO implementations[END_REF][START_REF] Shernan | More guidelines than rules: CSRF vulnerabilities from noncompliant OAuth 2.0 implementations[END_REF][START_REF] Yang | Model-based Security Testing: An Empirical Study on OAuth 2.0 Implementations[END_REF] on the implementations of OAuth. It was found that these security incidents were possible because of the implementations of the protocol themselves rather than fundamental problems with the OAuth protocol. All five papers suggested solutions to be implemented by the relevant providers -such as proposals to attempt to bind authorisation requests to browsers -and Ferry et al. [START_REF] Ferry | Security evaluation of the OAuth 2.0 framework[END_REF] reported that the CSRF attack had been addressed immediately upon the report.

Two papers [START_REF] Alotaibi | Enhancing OAuth services security by an authentication service with face recognition[END_REF][START_REF] Grzonkowski | Security analysis of authentication protocols for next-generation mobile and CE cloud services[END_REF] both point out the same security incident, which is the idea that a weak user credential vulnerability can be exploited by a brute force attack. Alotaibi & Mahmmod suggested a solution to this attack, which was to implement a biometric authentication system [START_REF] Alotaibi | Enhancing OAuth services security by an authentication service with face recognition[END_REF].

Sun & Beznosov pointed out a large number of security incidents for OAuth [START_REF] Sun | The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems[END_REF], which included the already mentioned CSRF incident. Additional vulnerabilityattack class relationships that are pointed out by this paper: Unencrypted communications (HTTP being used) leading to message modification (can tailor a message from an existing base message), automatic authorisation (if the user has granted a privilege it is automatically granted again) leading to Cross-Site-Scripting (XSS), a lack of binding (vulnerability where a sent message is not sufficiently tied to the sender) allowing a message to be modified with a public URL which is used to authenticate a user, a lack of binding vulnerability leading to session swapping (an honest user is logged in to an adversary account -potentially divulging confidential information). All of the security incidents relating to these vulnerability-attack class relationships were possible at the implementation level.

OpenID

The first notable thing about the surveyed OpenID papers [START_REF] Grzonkowski | Security analysis of authentication protocols for next-generation mobile and CE cloud services[END_REF][START_REF] Oh | The security limitations of sso in openid[END_REF][START_REF] Sovis | Security Analysis of OpenID[END_REF][START_REF] Feld | Security analysis of OpenID, followed by a reference implementation of an nPA-based OpenID provider[END_REF][START_REF] Sun | Systematically breaking and fixing OpenID security: Formal analysis, semi-automated empirical evaluation, and practical countermeasures[END_REF][START_REF] Abbas | Systematically breaking and fixing OpenID security: Formal analysis, semi-automated empirical evaluation, and practical countermeasures[END_REF][START_REF] Hsu | WebCallerID: Leveraging cellular networks for Web authentication In Journal of Computer Security[END_REF][START_REF] Krolo | Marin and Srbljić Siniša Security of web level user identity management[END_REF][START_REF] Li | Analysing the Security of Google's implementation of OpenID Connect[END_REF][START_REF] Mainka | Do not trust me: Using malicious IdPs for analyzing and attacking Single Sign[END_REF] is how the message formatting (a parameter or part of the message is not signed properly -common in OpenID) vulnerability is exploited by the message modification (possible because the message is not protected properly) attack class for the purposes of compromising a user account. For instance, an adversary could modify parameters such as Openid.ext1.value.email as shown by Wang et al. [START_REF] Wang | Signing me onto your accounts through facebook and google: A traffic-guided security study of commercially deployed single-sign-on web services[END_REF]. Oh & Jin [START_REF] Oh | The security limitations of sso in openid[END_REF] exploit this and note an issue with the protocol specification that allows for this security incident to take place and tests it on a real implementationbut no solution is offered. Sovis et al. [START_REF] Sovis | Security Analysis of OpenID[END_REF] only goes as far to note the possibility of the attack at the protocol level without appearing to test it on a real system. Sun et al. [START_REF] Sun | Systematically breaking and fixing OpenID security: Formal analysis, semi-automated empirical evaluation, and practical countermeasures[END_REF] formally analyses the specification to find flaws and then exploits those flaws on real implementations to make the incident type testedin addition, a solution is suggested for this security incident which is to further cryptographically protect the message.

Another notable vulnerability-attack class combination is observed. The notrust-infrastructure being exploited by a bogus merchant to compromise user accounts -three papers put forward this idea [START_REF] Feld | Security analysis of OpenID, followed by a reference implementation of an nPA-based OpenID provider[END_REF][START_REF] Abbas | Systematically breaking and fixing OpenID security: Formal analysis, semi-automated empirical evaluation, and practical countermeasures[END_REF][START_REF] Hsu | WebCallerID: Leveraging cellular networks for Web authentication In Journal of Computer Security[END_REF] on the protocol level.

Feld & Pohlmann [START_REF] Feld | Security analysis of OpenID, followed by a reference implementation of an nPA-based OpenID provider[END_REF] put forward an identity card solution to counter the bogus merchant. Abbas et al. [START_REF] Abbas | Systematically breaking and fixing OpenID security: Formal analysis, semi-automated empirical evaluation, and practical countermeasures[END_REF] proposes a challenge-response scheme based on public key cryptography. Hsu et al. [START_REF] Hsu | WebCallerID: Leveraging cellular networks for Web authentication In Journal of Computer Security[END_REF] leverages mobile phones to provide a physical token.

Mainka et al. [START_REF] Mainka | Do not trust me: Using malicious IdPs for analyzing and attacking Single Sign[END_REF] pointed out two security incidents at the implementation level which compromised user accounts. The first exploited a lack of binding by launching a MITM attack and had a suggested solution. The second incident (described as three incidents, but can be broadly boiled down) involves a lack of binding vulnerability which can be exploited by a message modification attack.

Two papers listed a large number of attacks too numerous to list here. Krolo et al. [START_REF] Krolo | Marin and Srbljić Siniša Security of web level user identity management[END_REF] puts forward five security incidents at the protocol level with suggested solutions and one affected the availability of the service while the others compromised user accounts. Li & Mitchell [START_REF] Li | Analysing the Security of Google's implementation of OpenID Connect[END_REF] introduces seven security incidents at the implementation level with suggested solutions and two incidents affected user confidentiality and the other five resulted in a compromised user account.

Sun et al. [START_REF] Sun | Systematically breaking and fixing OpenID security: Formal analysis, semi-automated empirical evaluation, and practical countermeasures[END_REF] also provides two more security incidents that were tested on real implementations: a lack of binding leading to a replay attack and a vulnerable SP leading to a CSRF attack -recommendations for the SP to follow were suggested to counter these attack classes.

SAML

Out of the five SAML analysis papers we found [START_REF] Armando | Formal analysis of SAML 2.0 web browser single sign-on: breaking the SAML-based single sign-on for google apps[END_REF][START_REF] Groß | Security analysis of the SAML single sign-on browser/artifact profile[END_REF][START_REF] Kumar | A lightweight formal approach for analyzing security of web protocols[END_REF][START_REF] Mayer | Guardians of the Clouds: When Identity Providers Fail[END_REF][START_REF] Mainka | Your software at my service: Security analysis of saas single sign-on solutions in the cloud[END_REF], three show how a lack of binding can be exploited by a MITM attack class to compromise a user account. Armando et al. [START_REF] Armando | Formal analysis of SAML 2.0 web browser single sign-on: breaking the SAML-based single sign-on for google apps[END_REF] pointed out the discovered incident at the protocol level and that that by the time the paper is published Google implemented a fix. Groß [START_REF] Groß | Security analysis of the SAML single sign-on browser/artifact profile[END_REF] described a protocol level incident -which also exploited a weak DNS vulnerability with a DNS poisoning attack class to progress to the MITM attack which a solution was presented for. Mainka et al. [START_REF] Mainka | Your software at my service: Security analysis of saas single sign-on solutions in the cloud[END_REF] shows that when the adversary has access to a valid access token several MITM style scenarios are possible that were fixed upon publication.

Two more security incidents are introduced by Groß [START_REF] Groß | Security analysis of the SAML single sign-on browser/artifact profile[END_REF] at the protocol level: an unencrypted message vulnerability is stated to be exploitable by a message modification attack class which sniffs the message and then modifies a part of it to send to a SP which will compromise the account of a user; and a lack of binding vulnerability exploitable by a replay attack to compromise a user account. A countermeasure to the replay attack class was proposed to check the IP address of the sender. A countermeasure was also proposed for the message modification attack class, it is suggested that the referrer tag is dropped by browsers.

Mayer et al. [START_REF] Mayer | Guardians of the Clouds: When Identity Providers Fail[END_REF] put forward two unique security incidents. The first exploits a vulnerable IdP and is referred to as an ACS Spoofing attack class which is similar to a bogus merchant attack class but the bogus merchant in the ACS Spoofing variant steals the user credentials and logs into many SPs -rather than requiring the user to manually enter credentials. A vulnerable IdP is exploited again by a UI redressing attack class, which involves tricking a user into clicking a malicious web element through a transparent web element. Both of these incidents were said to be because of poor implementations and compromise the user account. The paper also reviews several countermeasures.

Liberty Alliance

We found two papers describing security incidents in Liberty Alliance [START_REF] Pfitzmann | Waidner Analysis of liberty single-sign-on with enabled clients[END_REF][START_REF] Ahmad | Trusted Computing based open environment user authentication model[END_REF]. Pfitzmann & Waidner [START_REF] Pfitzmann | Waidner Analysis of liberty single-sign-on with enabled clients[END_REF] exploits the vulnerability lack of binding by launching a MITM attack of which the aim is to compromise the user account. The security incident was shown to be possible on the protocol level but was not tested on real implementations. A fix was implemented before the paper was published because Liberty Alliance acknowledged the issue and acted quickly although it was not stated which solution of the list of possible solutions outlined in the paper Liberty Alliance chose.

Ahmad et al. [START_REF] Ahmad | Trusted Computing based open environment user authentication model[END_REF] outlined that a centralised infrastructure can be exploited by a malicious provider who wants to breach user confidentiality. The incident was proposed at the protocol level and no solution was presented.

Facebook Connect

We are considering the papers that claim to find security incidents [START_REF] Miculan | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF][START_REF] Manuel Urueña | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF][START_REF] Wang | Signing me onto your accounts through facebook and google: A traffic-guided security study of commercially deployed single-sign-on web services[END_REF] for Facebook's FIM protocol -Facebook Connect. Two papers that we found to have security incidents in this category [START_REF] Miculan | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF][START_REF] Manuel Urueña | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF] were found to have the unencrypted communications vulnerability. The unencrypted communications vulnerability was exploited by two different attack classes: the replay attack class [START_REF] Miculan | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF] and communications sniffing (being able to read a message, but not being able to modify it or replay it) attack class [START_REF] Manuel Urueña | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF]. The replay attack class was proposed as possible on the protocol level but the communications sniffing attack class was tested in practice. Miculan & Caterina [START_REF] Miculan | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF], suggests a solution where a Diffie-Hellman key exchange is added to the protocol. Urueña et al. [START_REF] Manuel Urueña | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF] suggests forcing HTTPS.

A centralised infrastructure vulnerability pointed out by Urueña et al. [START_REF] Manuel Urueña | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF] was exploited by a malicious provider attack class which would affect the confidentiality of the user. The attack class was proposed at the protocol level and no solution suggested.

Wang et al. [START_REF] Wang | Signing me onto your accounts through facebook and google: A traffic-guided security study of commercially deployed single-sign-on web services[END_REF] states a message formatting vulnerability which can be exploited by a message modification attack class which aims to compromise the account of the user. The attack class was tested in practice, reported to Facebook, who fixed the issue before the publishing of the paper. This same kind of security incident was also found to be possible on Google Accounts.

Google Accounts

There were two papers [START_REF] Armando | Formal analysis of SAML 2.0 web browser single sign-on: breaking the SAML-based single sign-on for google apps[END_REF][START_REF] Wang | Signing me onto your accounts through facebook and google: A traffic-guided security study of commercially deployed single-sign-on web services[END_REF] with security incidents in Google Accounts but we discuss these in the SAML and Facebook section.

Shibboleth

Chadwick [START_REF] David | Federated identity management[END_REF] points out that Shibboleth can be exploited by a bogus merchant attack class with the aim of compromising a user account. The author notes that this is because there is no trusted infrastructure list for Shibboleth (unlike Microsoft Cardspace, which the author advocates). The security incident is stated at the protocol level and no solution is presented.

Results

Vulnerabilities & Attack Classes in FIM

We found 11 unique vulnerabilities and 14 unique attack classes from our survey which can be seen in Tab. 1. We consider attacks and vulnerabilities the main raw output from our categorisation system. Where it might not be clear what a vulnerability or attack class is, we define them in their first appearance in Section 4.

Cross-Protocol Issues

This answers RQ2. We identify 14 different cross protocol issues (cf. Tab. 2). We identify a cross-protocol issue when the same vulnerability, is exploited by the same attack class and creates the same CIA failure across at least one additional protocol.

The Numbers

Sample Size: When we conducted our SLR search of security analysis of FIM protocols initially we included 145 papers. We excluded papers that did not present security incidents until we had 31 papers left and 60 security incidents were found from the papers. CIA: The proportion of security incidents which had a CIA failure listed as "Compromised Account" was 83.3%.Confidentiality breaches accounted for 13.3% and availability denials 13.3%. Solution Offered: Of the incidents proposed by authors, 16.6% of those authors provided evidence that the protocol was fixed before the paper was even published. 66.6% of authors at least suggested a solution while 16.6% offered no solution.

6 Discussion

6.1 The landscape of security analysis of FIM

We discuss this to address RQ1. In the majority of security incidents we survey, the "Compromised Account" was the most common CIA failure. This also happens to be the CIA failure with the most impact, seeing as an adversary can potentially compromise any CIA property from a compromised user account. In addition, we do not observe many security incidents that exploit solely integrity or availability (without first compromising an account).

We have seen a fair balance between security incidents at the protocol, implementation, and tested (where a protocol flaw is found and then tested on real implementations) level. It is important to continue to evaluate both Protocols and the implementations in FIM because one can not succeed without the other.

Some protocols have received more attention from analysts than others (such as OpenID, OAuth) and we can therefore paint a clear history of the security issues for those protocols. Other protocols have not received such wide spread attention, especially WS-Federation which our survey did not turn up a security analysis that presented a security incident. There is work in the area, such as work done by Groß [START_REF] Groß | Security analysis of the SAML single sign-on browser/artifact profile[END_REF] that demonstrates the protocol is secure under certain assumptions, but work investigating the flaws in WS-Federation seems to be missing. Other low attendance protocols are Shibboleth and Google Accounts. Are these low-attention protocols more secure or are researchers turning a blind eye to them for one reason or another i.e., perception of less people using these protocols?

A positive story is that the majority of security analysis are not only pointing out vulnerabilities and attack classes which can be used to exploit those vulnerabilities, solutions are attached also with only 16.6% of authors not claiming a solution.

Cross-Protocol Issues

We discuss this to further answer RQ2. There were 14 security incidents we found that were cross protocol. Of these 14, some were not surprising as they capitalise on well known FIM weaknesses. Cross-protocol incident 2, happens across FIM protocols because if an IdP is malicious, they can easily track a user. Cross-protocol incident 4 is also not a surprising find, it is well known that user credentials suffer from low entropy and in addition user credentials will generally be more valuable for an IdP in a FIM system because of the potential to more deeply compromise a single user. In a FIM system, the burden of authenticating a user is merely shifted to the IdP and so the cross-protocol incident 6, which involves a bogus merchant attack class, is still a menace. In fact, it could be argued that it's made worse because of the interconnected nature of FIM systems. In a similar vein, 10 involves a DNS poisoning attack which is also arguably more effective on a FIM system. All of the aforementioned crossprotocol issues are not surprising to be found to be happening cross-protocol.

Liberty Alliance is built on SAML and we can also see that the same security issue 8 has been reported for both of these protocols. OpenID and OAuth also have this relationship and the same issue is also reported in 13.

What is surprising is that vulnerabilities such as "unencrypted communications" are not just seen on one protocol but across Facebook and Microsoft as can be seen by this cross-protocol issue 3. It is worrying that such large ubiquitous organisations harbour these sorts of vulnerabilities. Cross-protocol issue 11 is also observed on Facebook and in this case confidential information is sent without protection and can therefore be intercepted and used by an adversary.

One creative issue is issue 12 where an adversary gets a user to sign into the attacker's account. The attacker hopes that the user will divulge confidential information because the user thinks they are safely using their own account. This highlights the importance of an in-depth security analysis because without it, unexpected issues like this would likely be overlooked.

Another worrying sign is brought to light by 7, where vulnerable SPs have been exploited by CSRF attack classes on OAuth, OpenID and SAML. What we observed is that even though the protocol itself is thought of as secure, a bad implementation can create risks for users. This is worrying because not only is OAuth, OpenID and SAML ubiquitous on the web, but a single bad implementation could spell trouble for a user as shown by the numerous papers presented by our survey that demonstrate the CSRF attack class on real implementations.

Solutions/Mitigations

We concentrate on the solutions for dealing with the vulnerabilities and attack classes shown to occur cross protocol in order to address RQ3. This is in no way a survey of how these attack classes can be mitigated, we simply use a solution provided in the already surveyed literature. Cross-Protocol issue 1: The basis of this attack class lies in the fact that the OpenID message (which is used in Facebook and Google implementations) can be modified by an adversary. Sun et al. [START_REF] Sun | Systematically breaking and fixing OpenID security: Formal analysis, semi-automated empirical evaluation, and practical countermeasures[END_REF] present a Diffie-Hellman key exchange to mitigate the attack class. The IdP also has to sign an assertion for the Diffie-Hellman key exchange to be secure. Cross-Protocol issue 2: The malicious provider profiling a user is difficult to stop so most of the papers do not present a solution for it. There is one exception, Feld & Pohlmann [START_REF] Feld | Security analysis of OpenID, followed by a reference implementation of an nPA-based OpenID provider[END_REF] reference a German identity card called nPA where a person attests to another person who they are using biometrics. Cross-Protocol issue 3: The solution to the replay attack as put by Miculan & Caterina [START_REF] Miculan | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF] is to ensure SSL/TLS is used. Cross-Protocol issue 4: Alotaibi & Ausif Mahmmod [START_REF] Alotaibi | Enhancing OAuth services security by an authentication service with face recognition[END_REF] state that biometrics can be used as a solution to weak user credentials. Cross-Protocol issue 5: Messages can be modified if they are not properly protected. Sovis et al. [START_REF] Sovis | Security Analysis of OpenID[END_REF] suggest ensuring all relevant message parameters are protected by a MAC code.

Cross-Protocol issue 6: According to Feld & Pohlmann [START_REF] Feld | Security analysis of OpenID, followed by a reference implementation of an nPA-based OpenID provider[END_REF], the German based identity card nPA can address bogus merchants by introducing a higher level of authentication. Cross-Protocol issue 7: Sun et al. [START_REF] Sun | Systematically breaking and fixing OpenID security: Formal analysis, semi-automated empirical evaluation, and practical countermeasures[END_REF] suggest binding requests to the session taking place by hashing a secret together with a session id and appending that token into a hidden field in the login form as a solution to CSRF. Cross-Protocol issue 8: When access tokens are not explicit to single SPs a MITM attack class can be launched. Pfitzmann & Waidner [START_REF] Pfitzmann | Federated identity-management protocols In International Workshop on Security Protocols[END_REF] propose (amongst other methods) a way of binding the token to the SP it is intended for. Cross-Protocol issue 9: Groß [START_REF] Groß | Security analysis of the SAML single sign-on browser/artifact profile[END_REF] suggests binding the IP address to a request to stop Replay attacks. Cross-Protocol issue 10: Alrodhan & Mitchell [START_REF] Alrodhan | Improving the security of cardspace[END_REF] point out that the widespread use of DNSSEC could mitigate the difficult to address DNS Poisoning attack. Cross-Protocol issue 11: Manuel Urueña et al. [START_REF] Manuel Urueña | Formal analysis of Facebook Connect single sign-on authentication protocol[END_REF] suggest disabling the HTTP referrer tag which is known to leak information. Cross-Protocol issue 12: Lie & Mitchell [START_REF] Li | Analysing the Security of Google's implementation of OpenID Connect[END_REF] suggest adding a state value to bind a message in order to mitigate Session Swapping. Cross-Protocol issue 13: We have observed that an XSS attack which results in an account being compromised requires two vulnerabilities : a Vulnerable SP and Automatic Authorisation. Sun et al. [START_REF] Sun | The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems[END_REF] state that inputs should be properly sanitized in order to prevent an injection. Cross-Protocol issue 14: Sun et al. [START_REF] Sun | The devil is in the (implementation) details: an empirical analysis of OAuth SSO systems[END_REF] note that SPs do not actually check some credentials which allow an attacker to engineer fake credentials, so the SP checking those credentials is a mitigation to the problem.

Conclusion

We put forward three research questions RQ1-RQ3 and these have been answered. We emphasise the contribution of providing a landscape of security incidents (RQ1) and common attack classes across protocols (RQ2). These contributions together provide overall insight into security issues in FIM on the whole but also particular issues that are affecting different FIM systems.

Fig. 1 Fig. 1 :

 11 Fig. 1: Overall search term used in Scopus, modulo plural forms.

PFig. 2 :

 2 Fig. 2: Overall search term in Google Scholar, modulo plural forms.

Table 1 :

 1 Coded Vulnerabilities & Attack Classes in FIM

		(b) Coded Attacks
	(a) Coded Vulnerabilities	Attacks
	Vulnerabilities	Replay Attack
	Unencrypted Communications Centralised Infrastructure Lack of Binding No Trust Infrastructure Weak DNS Vulnerable SP Vulnerable IdP Automatic Authorisation Message Formatting Automatic Authorisation Weak User Credentials	Communications Sniffing Malicious Provider MITM Message Modification Bogus Merchant Brute Force XSS Session Swapping DNS Poisoning DDoS CSRF ACS Spoofing
		UI Redressing

Table 2 :

 2 Cross-protocol issues in FIM

	ID Vulnerability Attack Class	CIA Failure Affected Protocols
	1 Message Format Message Modification	Compromised	Facebook,	Google,
			Account	OpenID
	2 Centralised	Malicious Provider	Confidentiality Facebook, Liberty, Mi-
	Infrastructure			crosoft, OpenID
	3 Unencrypted	Replay	Compromised	Facebook, Microsoft
	Communication		Account
	4 Weak User Cre-	Brute Force	Compromised	OpenID, OAuth
	dentials		Account
	5 Unencrypted	Message Modification	Compromised	OAuth, OpenID, SAML
	Communications		Account
	6 No trust infras-	Bogus Merchant	Compromised	Microsoft,	OpenID,
	tructure		Account	Shibboleth
	7 Vulnerable SP CSRF	Compromised	OpenID, OAuth, SAML
			Account
	8 Lack of Binding MITM	Compromised	Liberty, SAML
			Account
	9 Lack of Binding Replay	Compromised	OpenID, SAML
			Account
	10 Weak DNS	DNS poisoning	Compromised	Microsoft, SAML
			Account
	11 Unencrypted	Communications Sniffing Confidentiality Facebook, OpenID
	Communications
	12 Lack of Binding Session Swapping	Confidentiality OAuth, OpenID
	13 Vulnerable	XSS	Compromised	OAuth, OpenID
	SP, Automatic		Account
	Authorisation
	14 Lack of Binding Message Modification	Compromised	OAuth, OpenID, SAML
			Account


Carlos Rodrigo Gómez Rodríguez
email: carlos.gomezrodriguez@ucr.ac.cr

Elena Gabriela

Using Differential Privacy for the Internet of Things

Keywords:

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The data collected in the context of the Internet of Things (IoT), is being incorporated in the business model of many companies, as it takes advantage of the millions of devices freely collecting and distributing data on a daily basis. CISCO states that in year 2015, 563 millions of new mobile devices and connections were added to the 7.3 billion that were already there in 2014 [START_REF]Cisco: Cisco Visual Networking Index : Global Mobile Data Traffic Forecast Update[END_REF]. Data traffic reached 3.7 exabytes per month at the end of 2015, 1.6 times more than 2014, originating in 97 million of wearable devices that generated 15 petabytes of monthly traffic. It is projected that by 2020 the monthly mobile data traffic will reach 20.6 exabytes per month. All this ecosystem composed by people, smart devices, sensors, data collectors, data analyzers, predictors and applications might cause an inappropriate exposure of personal information that the user is not aware of [START_REF] Ukil | Negotiation-based privacy preservation scheme in internet of things platform[END_REF]. One possibility is to allow data consumers and producers to negotiate privacy agreements in advance, and then use these agreements to try to satisfy, in the best possible way their requirements.

We are interested in the following scenario: IoT data producers (for example, residential users of smart meters) and IoT data consumers (for example, recommender or safety applications) negotiate a privacy agreement through a third trusted party (TTP), a hypothetical privacy broker. The broker will administer the aggregate full data-base of records generated by all data producers. The existence of such a third party is not a new concept [START_REF] Yusuf | Survey of Publish Subscribe Communication System[END_REF] and it could work even on a decentralized environment [START_REF] Zyskind | Decentralizing Privacy: Using Blockchain to Protect Personal Data[END_REF].

The privacy broker will use some sort of negotiation protocol between the interested parties, and will record privacy agreements as rules between each user and each consumer. For example, producer requirements could be coded as permissions over some data attributes, and consumer requirements could be given by one or more information loss metrics. Producer requirements will always have a higher priority, given that a violation could expose sensitive data. Although there are one-to-one agreements between consumers and producers, when a consumer requests data corresponding to several producers, the calculation of a joint result that satisfies all individual producer privacy requirements is not trivial, and can cause severe information loss.

We propose a hybrid model where the broker has two privacy-preserving methods to define what to communicate to a requesting consumer: (1) a default, record-by-record descriptor method [START_REF] Cormode | Anonymized data[END_REF][START_REF] Angiuli | How to de-identify your data[END_REF] (also called syntactical de-identification [START_REF] Clifton | On syntactic anonymity and differential privacy[END_REF]) that will be used when the satisfaction of producer requirements generates an information loss within the threshold required by the data consumer; and (2) an alternative ("statistical") method that will create a set of statistical descriptors for the original data [START_REF] Dinur | Revealing information while preserving privacy[END_REF]. These aggregate results are the ones that will be used to answer the consumer query if the information loss exceeds the agreed threshold. The statistical method has to be also privacy-preserving, such as Differential Privacy [START_REF] Dwork | Differential privacy[END_REF].

The motivation for the proposed model is the fact that data consumers are also an important part of the IoT ecosystem, so for cases when satisfying joint producer requirements result in a large information loss, our model could at least provide an aggregate result that might be useful to the consumer, instead of returning a useless set of records. For example, a recommender app might be able to continue functioning even in the presence of intermittent aggregate statistics instead of more granular data.

To further specify the model, we decided to use a privacy-negotiation environment such as the one proposed by Ukil et al in [START_REF] Ukil | Negotiation-based privacy preservation scheme in internet of things platform[END_REF], and take some other elements from their model. The constraints resulting from the application of negotiated parameters to a given set of data to be published provide us with a natural source of varying requirements. For our proof of concept we use k-anonimity as the syntactic de-identification method [START_REF] Sweeney | k-anonymity: A Model for Protecting Privacy[END_REF], and Differential Privacy (DP) [START_REF] Angiuli | How to de-identify your data[END_REF] as the statistical privacy-preserving method. Finally, as information loss metric we use the one proposed by Iyengar in 2002 [START_REF] Iyengar | Transforming data to satisfy privacy constraints[END_REF].

The rest of the paper is organized as follows: Section 2 describes the proposed model; Section 3 presents the proof of concept prototype; Section 4 describes an IoT scenario for the model; and Section 5 presents two examples of prototype use. Finally, in Section 6 there is a discussion and possibilities for future work are outlined.

Proposed model

Following Ukil et al. [START_REF] Ukil | Negotiation-based privacy preservation scheme in internet of things platform[END_REF], our scenario considers two actors: (1) the data producer, that is, the individual that is exposing information gathered automatically by devices like sensors; and (2) the data consumer, which requests gathered IoT data for analysis.

The actors communicate through a third party broker that stores consumer data and receives, evaluates, and answers requests for access, originating with data producers. The broker is also responsible for negotiating and reaching privacy agreements between producers and consumers. This third party must have global rules incorporating local laws and good practices. For example, the release of any personally identifiable information (PII) should be excluded from any privacy agreement by default. Furthermore, depending on the privacy-preserving release method the broker must use the settings most appropriate to defend consumer privacy. For example, the model in [START_REF] Ukil | Negotiation-based privacy preservation scheme in internet of things platform[END_REF] uses the rules given in Lodha et al. [START_REF] Lodha | Probabilistic anonymity[END_REF] to define the type and degree of deidentification to be applied for the syntactic anonymization methods used.

The particular negotiation agreements between each producer and consumer could be coded as complex rules over data semantics, or be as simple as permissions given over data attributes, which is the approach used in [START_REF] Ukil | Negotiation-based privacy preservation scheme in internet of things platform[END_REF]. Their rule representation is an access matrix that relates all the relevant attributes to specific data consumers using a single permission flag.

After privacy agreements have been set up, the high-level view of our model is that data consumers will query the broker for data belonging to a group of data producers. The broker will first check if the data requested could be provided under any global rules, and, if so, will query its aggregate producer database. The table resulting from this query will then be syntactically anonymized [START_REF] Clifton | On syntactic anonymity and differential privacy[END_REF] (for example, with k-anonymity) using the particular rules triggered by the consumers that are part of this particular response. Once the anonymization is complete, an information loss metric would be calculated. If the data loss is within the threshold negotiated with the consumer, the anonymized table is sent. Otherwise, a set of aggregate statistical descriptors is calculated from the original resulting table using a privacy-preserving method (for example Differential Privacy), and the set of statistical descriptors is sent as response to the data consumer. This way, some useful information is still returned to the consumer.

Proof of concept prototype

As proof of concept for the model we implemented a prototype in which we use kanonymization [START_REF] Sweeney | k-anonymity: A Model for Protecting Privacy[END_REF] as the syntactical model, and Differential Privacy (DP) [START_REF] Dwork | Differential privacy[END_REF] as the statistical anonymity model. In particular, for k-anonymization, we used a simple implementation locally developed, and for DP, we used PINQ, the McSherry implementation [START_REF] Mcsherry | Privacy Integrated Queries: An Extensible Platform for Privacy-Preserving Data Analysis[END_REF]. As the information loss metric we used the one proposed by Iyengar [START_REF] Iyengar | Transforming data to satisfy privacy constraints[END_REF] because it works on generalization hierarchies.

The prototype does not currently collect data from producers and consumers, and neither executes negotiation processes. Instead, it feeds on a given dataset, a given agreement set, and reads the parameters for the global rules. Given the restrictions imposed by the McSherry implementation, the dataset is stored in a Microsoft SQL Server. The logical architecture for the prototype is shown in Figure 1. To represent privacy agreements between consumers and producers we use a matrix similar to the one in [START_REF] Ukil | Negotiation-based privacy preservation scheme in internet of things platform[END_REF], but the semantics of the permission flag is taken as a permission to include in a syntactical result. That is, if a producer sets the flag to 0 on a specific attribute for a given consumer, that attribute for that producer could not be included in an anonymized table independently of the degree of k. The matrix is filled using a simple user interface, as the negotiation process in itself is outside the scope of this paper. Given the matrix semantic, the information loss is calculated in two phases: the first one after eliminating all records of users that were not willing to share an attribute required by the query, and the second one after applying kanonymization to the remaining records. For the first one the information loss is calculated as the percentage of deleted records with regard to the total returned by the query. In the second phase, Iyengar´s information loss is applied as if the remaining records were the original dataset. The process followed by our proof of concept is depicted in Figure 2. It starts with a data consumer making a data request (1). This request generates a query, and the data resulting from the application of the query is then analyzed using the attribute access matrix, and filtering all the records that must be removed from the query as determined by the application of the privacy rules generated during the negotiation (2).

After this reduction, the data loss is computed as a percentage of records lost with respect to the original query answer (3). If the data loss threshold is reached (4), a set of predefined statistical descriptors are calculated on the original query response using a DP implementation ( 5) and delivered to the Data Consumer as response [START_REF] Iyengar | Transforming data to satisfy privacy constraints[END_REF]. Otherwise (4), the filtered response is de-identified using -again-the applicable privacypreserving rules [START_REF] Angiuli | How to de-identify your data[END_REF] and the data loss (Iyengar) for this process is calculated (7) added to the loss of the first filtering process [START_REF] Dinur | Revealing information while preserving privacy[END_REF], and compared against the data loss threshold [START_REF] Dwork | Differential privacy[END_REF]. If this integrated loss estimation reaches the threshold, the set of statistical descriptors of the original query is calculated using a DP implementation ( 5) and delivered to the Data Consumer as response [START_REF] Sweeney | k-anonymity: A Model for Protecting Privacy[END_REF]. To determine the feasibility of the proposed model, we describe a possible IoT application scenario, then choose a real dataset that fits the proposed scenario, implement a prototype and show its use for a simple, and then a larger case.

An IoT scenario for the model

The composite data collected from IoT sensors and devices in different households has the potential to create unexpected (and unwanted) disclosures. For example, Greveler et al. [START_REF] Greveler | Multimedia content identification through smart meter power usage profiles[END_REF], presents a case where energy consumption data transmitted to the service and application support layer, allows intrusive identification about devices located inside the households of data producers (TV set, refrigerator, toaster, oven). For example, depending on the frequency of analysis of the electricity usage profile (for instance at a 0.5-1s sample rate) the data can reveal what channel a TV set in the household is displaying. Therefore, something that at first sight looks inoffensive, like taking part into an electricity consumption survey, could reveal information that the house owner might not have wanted to share. Despite the huge importance and knowledge that can be generated understanding consumption patterns for power at home, data collected from these devices can also be used as a surveillance tool.

Given the findings in [START_REF] Greveler | Multimedia content identification through smart meter power usage profiles[END_REF], the scenario in which we situate the model is electricity consumption data. Each sensor sends its data to servers over the Internet, which in turn uses the data to show users their current energy consumption and estimate the monthly bill on a real-time basis. The data producer is the application that reads the sensor and sends the data it produces over the Internet. The data owner, and by extension the producer, is the user that installed the sensor: possibly the inhabitant of the house. The value for the producer of sending the data is the possibility to use the energy resources more efficiently or to get access to new technologies that could improve living. To execute calculations, the application requires permission to sense the data of all appliances in the household. Analysis of the sensed data could be used to recommend improvements to other users of the system. Furthermore, the application will need to process information gathered from different households on a particular region. The data could be very detailed and enable the profiling of people living in the house.

This paper only intends to provide evidence that the proposed model could be instantiated in a working prototype, but not yet investigate its usefulness in real environments. However, given that next step, to test the prototype, we used the collection published by the Department of Industry, Innovation and Science of Australian Government (DIIS) under the project name "Sample household electricity time of use data", that can be accessed in https://data.gov.au/dataset/sample-householdelectricity-time-of-use-data. The objective of DIIS for this project was to ensure that households have enough information to improve the use of electricity network. The dataset contains 10,828,120 energy readings for 808 several types of users.

The collection includes electricity use (in kwh) measured approximately every 30 minutes for a year using a smart meter to collect this information. It also provides basic demographic information, that could be used to infer customers. Customer demographic information includes customer ID (that allows to create a relationship between consumption and customer), address region, income range, appliances in house, people in house, and others. As mentioned before, with just the electricity consumption, it can be determined what appliances are being used in the household.

Examples of model application

The first example is presented to provide a step-by-step description of the model application. Table 1 shows a 18-record hypothetical result table (we proceed directly to the processing after the Privacy Broker has extracted the raw data corresponding to the consumer request).

Suppose we also have a previously negotiated matrix of data access for a given data consumer from each of the data providers. The matrix contains a column for each quasi-identifier (QI), and a value of 0 or 1 indicating whether the user is willing to share the QI in a release or not. The matrix is shown in Table 2.

Table 2. Example privacy matrix

Customer Id County Sex Age

1 1 1 1 2 1 1 1 3 1 0 1 4 0 1 0 5 1 1 1 6 1 1 0 7 1 1 1 8 0 0 0 9 1 1 1 10 1 1 1 11 1 1 1 12 1 0 0 13 0 0 1 14 1 1 1 15 1 1 0 16 1 1 1 17 1 1 1 18 1 0 0
The resulting table has to be filtered against the preset values from the privacy matrix shown in Table 2. In this case, a total of 8 records must be removed from the result table, since those data producers will not allow to show information for at least one of the requested columns. The records that must be removed are shown with a shadow on them.

The first information loss calculation is just the number of removed records divided by the total number of records that should be considered. For this particular case the loss for the first pass is 0.444. For a 0.5 threshold, the de-identification process has to proceed.

To provide k=2 k-anonymity the quasi-identifiers were categorized as follows:

County: 100 to 101, and 102 to 103; Sex: * (suppressed); Age (years): less than 32, 32 to less than 40, 40 to less than 48, 48 to less than 56, 56 to less than 64, and 64 and more. Any combination of these quasi-identifiers ranges provides 2 or more records, accomplishing the k=2 requirement. The information loss metric was calculated for this as 0.44. Table 3 shows the 2-anonymized data.

Table 3. Result of filtering the data in Table 1 given the restrictions in Table 2. Using k=2 kanonymity. ID is an identifier value, QI are quasi-identifiers.

Adding both information loss metrics, it results in a value of 0.95, exceeding the preset threshold of 0.5. So in this particular case, the privacy selection process had to deliver DP aggregated functions to the data consumer. For the purpose of showing the noise induced by DP, six consecutive answers are shown in Table 4. Attribute Customer Identification is a direct identifier, so it is not included in the negotiation, and it is automatically suppressed from any result. Attributes Reading Time and Reading Value are assumed to be the sensitive values, and Region Name and Appliance Name are the ones taken to be the quasi-identifiers and therefore included in the negotiation.

As an approximation to the negotiation values reflected by the matrix, we used the classification of privacy concern given by Humphrey Taylor based on a telephone survey by Harris Poll, conducted on a USA nationwide cross section of 1,010 adults [START_REF] Taylor | Most people are "privacy pragmatists" who, while concerned about privacy, will sometimes trade it off for other benefits[END_REF]. Taylor concludes that 26% of respondents were "privacy fundamentalists", 10% were "privacy unconcerned", and 64% were "privacy pragmatists". Based on this classification, around 26% of the 222 users (58) were randomly assigned with a negative decision on the sharing of both quasi-identifiers, around 10% of the users had a positive sharing decision on both quasi-identifiers (22), and the remaining approximately 64% of the population (142 users) were assigned random decision values for the quasi-identifiers (all positive, one of them positive, both negative).

For the test, we assumed a data consumer query for the electrical readings of 22 users (10%) randomly chosen users in the week between the 8 and 15 of February of 2014. The privacy matrix of each of those users revealed 8 users with a do-not-share preference, 4 asserting a use-everything preference, and 10 users that allowed access to one attribute but not the other. In this test the filtering interprets the matrix as "do not communicate anything from users with both attributes hidden", so we remove all the records belonging to the do-not-share users which correspond to 12,863 out of a total of 23,610 readings for this query. Therefore, the first-step total data loss was slightly over 35%, which is still within the preset threshold. Afterwards, a k=60 anonymization was performed, and the loss metric (LM) was calculated as 0.118. Combining this with the first-step, the combined loss is still below 50% so we communicate the anonymized results to the data consumer.

Discussion and Future Work

We have proposed a hybrid model to deliver data with privacy protections to consumers, and presented a particular implementation just to test its feasibility. Both the model and the prototype provide us with a flexibility in the semantic of the negotiation, the application of either semantic or statistical anonymization.

Taking into account the high volume of data generated by IoT, and that this data could have traces of private information that producers are not aware of, it is important to provide privacy protection. Privacy negotiation might provide usable methods of accomplishing this goal. To satisfy not only data producer but also data consumer requirements, in this paper DP is added to the negotiation model to be able to provide some utility in constrained settings, without sacrificing privacy. An implementation of this design was shown.

Extending DP implementations like PINQ could help to adhere this privacy protection layers to different contexts. So far, PINQ has few aggregated computations (count, sum, average, statistic order and median), and even when DP seems to have increased its application in different scenarios recently, Microsoft left behind new implementations for PINQ, and even when current version 0.1 is fully functional, it lacks of many other functions to provide even more utility to the data consumers. It was last released back in 2009, but it is still downloadable from the Microsoft official web site and it is supported in Windows 10, their latest operating system.

It would be very valuable if the attribute two-dimensional matrix, could be improved to a multidimensional matrix that can represent not only data fields and consumers with binary resolutions, but also consider time, purpose of queries, data age, etc. Also, settings could be more than just 1's and 0's, but adding different levels, for instance, k values (k-anonymity parameter) and/or epsilon and privacy budget (DP parameters) values.

There are many complexities involved in the application of hybrid models. It is not known, for example, if -in the long run-the intermittent application of each would lead to unintended disclosures. This is a well-known problem for any hybrid model, and needs to be studied in this case.

A less theoretical, but equally important issue is to be able to establish if the data that a statistical model returns to the data consumer would be useful at all, that is, would reduce the negative impact of this privacy protection. Acceptance from reasonable data consumers is important for the dissemination of these models.

On a different level, for the test case we made many assumptions, so it is necessary to experimentally explore what would be the effect of different queries on the threshold.

For example, what percentage of the time the prototype returns a k-anonymized da-taset instead of a DP summary. This requires a careful tuning of the k and the threshold to reflect more realistic values.

Figure 1 .

 1 Figure 1. Prototype logical architecture

  Somewhat arbitrarily, both losses are added to calculate total loss before deciding what to return to the consumer. The global privacy rules included were: (1) The elimination of PIIs; (2) A given classification of non-PII attributes in quasi-identifiers and sensitive data; (3) A choice of k by the prototype operator for k-anonymization; (4) A choice of DP parameters by the operator (epsilon and privacy budget); and (5) A choice of information loss threshold for each consumer. Rule 1 is executed manually. For rule 2, the respective columns are marked in advance. Values for rules 3, 4, and 5 are read through several interfaces. The interfaces were implemented in ASP.NET, using Microsoft Internet Information Services 7 on Microsoft Windows 7 Professional and running on an Oracle Virtual Box engine version 5.0.16. The whole process is encapsulated in the same ASP.NET application, using the C# class library as well and invoking PINQ 0.1.0.0 and LINQ 4.0.0.0 libraries and ADO.NET 4 to finally access the MS SQL Server 2008 R2

Figure 2 .

 2 Figure 2. Protection method selection process.

Table 1 .

 1 Example result table.

	Cust. Id	County	Sex	Age	Reading Value	Outlet
	1	101	M	47	393	TV
	2	101	F	42	423	TV
	3	101	F	55	231	TV
	4	101	M	49	554	TV
	5	103	M	31	334	TV
	6	102	M	42	676	TV
	7	103	F	29	445	TV
	8	101	F	25	332	TV
	9	102	M	43	553	TV
	10	103	M	44	445	TV
	11	103	F	29	765	TV
	12	102	F	57	432	TV
	13	101	F	47	113	TV
	14	101	M	31	455	TV
	15	103	M	57	321	TV
	16	102	M	33	334	TV
	17	103	F	34	654	TV
	18	103	F	54	442	TV

Table 4 .

 4 Results from DP computation for 6 identical requests performed by the data consumer. Data Request = Information from all records that County equals {101, 102,103} and Out-let='TV'

	•	Request Nbr	1	2	3	4	5	6	Actual
									Data
	•	Record Count	16.00	20.00	15.00	16.00	19.00	15.00	18.00
		Percentile 25	28.00	26.00	33.00	30.00	26.00	27.00	31.00
	Age	Percentile 50	43.50	42.50	41.50	47.50	43.50	37.50	42.50
		Percentile 75	48.25	53.25	50.25	48.25	50.25	45.25	50.25
	Reading Value	Percentile 25 Percentile 50 Percentile 75	330.50 437.00 554.25	331.50 436.00 552.25	335.50 435.00 551.25	330.50 439.00 554.25	335.50 435.00 556.25	332.50 438.00 551.25	333.50 333.50 333.50
	•	Sum	7,794.00	7,545.00	7,068.00	6,945.00	6,481.00	5,787.00	7,902.00

Acknowledgements

This work was partially supported by the Programa de Posgrado en Computación e Informática (PCI), the Escuela de Ciencias de la Computación e Informática (ECCI), the Centro de Investigaciones en Tecnologías de la Información y Comunicación (CITIC), and the Sistema de Estudios de Posgrado (SEP) all at the Universidad de Costa Rica (UCR), the Ministerio de Ciencia, Tecnología y Telecomunicaciones (MICITT), and by the Consejo Nacional para Investigaciones Científicas y Tecnológicas (CONICIT) of the Government of Costa Rica.