Sushant Agarwal

Developing a Structured Metric to Measure Privacy Risk in Privacy Impact Assessments

Keywords: Privacy risk, risk score, privacy impact assessment

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

Introduction

Privacy risk is defined as the risk of harm originating through an intrusion into privacy [START_REF]Information Commissioner's Office UK: Conducting privacy impact assessments code of practice[END_REF]. Not only can privacy breaches lead to lawsuits damaging a company's reputation and finances, but also can hamper trust of customers and overall brand perception. A PIA enables a company to identify risks pertaining to privacy and helps in adhering to data protection laws. Privacy Impact Assessments (PIAs) are crucial for companies using IT applications that process personal data of customers and employees. The European Commission acknowledges importance of PIAs and the proposed data protection regulations mandate PIAs where sensitive data is processed [START_REF]European Commission: Proposal for protection of individuals with regard to the processing of personal data and on the free movement of such data[END_REF]. Also, a lot of tools have been developed to conduct PIAs such as -GS1 tool [START_REF]GS1: GS1 EPC/RFID Privacy Impact Assessment Tool[END_REF], iPIA tool [START_REF] Oetzel | A systematic methodology for privacy impact assessments: a design science approach[END_REF], SPIA tool [START_REF]Introduction to the SPIA Program[END_REF] etc. to support and ease the process of these assessments.

Literature emphasizes that PIA should be considered as a continuous process, so that engineers and managers of a company can consider the possible privacy issues through the complete IT development lifecycle to minimize the privacy risk [START_REF] Spiekermann | The RFID PIA -Developed by Industry, Endorsed by Regulators[END_REF][START_REF] Wright | Privacy Impact Assessment[END_REF]. In most PIA reports, PIA results / outcomes are descriptive and long [START_REF]PIAw@tch: Significant Privacy Impact Assessment Report accessible online[END_REF]. If PIA is to be considered as a continuous process then it's important to have a metric for comparison over time.

Progress in terms of privacy risks should be easy to measure and monitor using PIA, which is currently difficult.

Though, in the field of security risk management, extensive research has been done to quantify risk. Many methodologies have been proposed to define a numeric risk metric: probability models [START_REF] Cheng | Fuzzy multi-level security: An experiment on quantified risk-adaptive access control[END_REF], decision-tree models [START_REF] Sahinoglu | Security meter: A practical decision-tree model to quantify risk[END_REF], and composite indices based on impact and likelihood [START_REF] Vose | Risk Analysis: A Quantitative Guide[END_REF]12]. These models stand in sharp contrast to the qualitative definition of privacy risk in most PIA methodologies [START_REF]GS1: GS1 EPC/RFID Privacy Impact Assessment Tool[END_REF][START_REF] Oetzel | A systematic methodology for privacy impact assessments: a design science approach[END_REF][START_REF]Introduction to the SPIA Program[END_REF]. For example, even though GS1 has a predefined number for the risk based on likelihood and impact and also a user selectable score for control effectiveness, the end score is still qualitative [START_REF]GS1: GS1 EPC/RFID Privacy Impact Assessment Tool[END_REF]. In UK's ICO code of practice for conducting PIAs, a template has been proposed which lacks a metric to score the privacy risks or to measure the improvements [START_REF]Information Commissioner's Office UK: Conducting privacy impact assessments code of practice[END_REF]. [START_REF] Oetzel | A systematic methodology for privacy impact assessments: a design science approach[END_REF] consider qualitative metric -low, medium, high for scoring privacy risk in the proposed iPIA tool [START_REF] Oetzel | A systematic methodology for privacy impact assessments: a design science approach[END_REF]. Though the process is modular and captures both customer's and company's point of view, score is unstructured and difficult to measure. Also the EU CEN standards for RFID PIAs focus on qualitative evaluation of threats based on financial factors [START_REF]CEN: Information technology -RFID privacy impact assessment process[END_REF]. Hence, as far as to my knowledge, a metric to provide guidance to score a PIA in measureable terms has not been provided in the current literature so far.

To fill this gap, this paper proposes a structured privacy score metric for the PIA process. In the field of risk management, two approaches are mainly used to compute the level of risk. On one hand, the qualitative approach considers assets, vulnerabilities and threats to estimate an approximate risk level (generally as low, medium or high) [START_REF] Yazar | A qualitative risk analysis and management tool--CRAMM[END_REF][START_REF] Vellani | Strategic Security Management: A Risk Assessment Guide for Decision Makers[END_REF]. On the other hand, the quantitative approach considers risk score numerically as the product of likelihood and impact [START_REF] Vose | Risk Analysis: A Quantitative Guide[END_REF]. Qualitative scoring is used when the level of risk is low and it's difficult to quantify risks. In contrast, quantitative scoring is used when ample information about risk is available and likelihood and impact can be quantified [START_REF] Stoneburner | Risk management guide for information technology systems[END_REF]. However, privacy risk levels can be high but at the same time it is difficult to quantify impact and likelihood [START_REF]Edelman: The costs, causes and consequences of privacy risk[END_REF]. Therefore, a semi-quantitative approach is considered for this paper as it combines both qualitative and quantitative approaches to estimate the risk score. Using this approach a relative risk scale is defined to represent the severity [START_REF] Borghesi | Risk management: How to assess, transfer and communicate critical risks[END_REF]. As the risk score obtained is relative, this cannot be used to compare two different applications. But, can be used to compare the different versions of the risk assessment for the same application. This semi-quantitative metric enables companies to better monitoring and tracking of privacy risks throughout a system's development lifecycle.

The remaining paper proceeds as follows: in section 2, existing PIA methodologies are briefly described Section 3 proposes a new 3-step process of risk identification, modeling and quantitative evaluation. Section 4 illustrates the proposed methodology with a case study. Section 5 draws conclusions.

Current Practices for Privacy Risk

In the literature, many different methodologies [START_REF]Information Commissioner's Office UK: Conducting privacy impact assessments code of practice[END_REF][START_REF] Oetzel | A systematic methodology for privacy impact assessments: a design science approach[END_REF] and tools [START_REF]GS1: GS1 EPC/RFID Privacy Impact Assessment Tool[END_REF][START_REF]Introduction to the SPIA Program[END_REF] have been discussed (a good overview and evaluation of tools can be found in a paper by Wadhwa et al [START_REF] Wadhwa | Evaluating privacy impact assessments[END_REF]). Three PIA tools are discussed here focusing on their methodology for scoring privacy risk.

GS1 PIA Tool

To 'rapidly perform a comprehensive assessment of privacy risks of any new EPC/RFID implementation' [START_REF]GS1: GS1 EPC/RFID Privacy Impact Assessment Tool[END_REF], the not-for-profit organization GS1 developed an easy to use MS Excel based PIA tool focusing on RFID implementation. For privacy risk, the tool has predefined levels of likelihood and impact and allows variable scoring for the control effectiveness. Even though scores for likelihood and impact can be changed, the main emphasis is on the control effectiveness score (level of maturity of implemented control to tackle privacy risk). Table 1 shows the scoring logic and each variable is scored on a scale of 1-5. Based on the level of PIA required, there are 5 risk areas with a total of 5 questions each for controls. While likelihood and impact are scored for a risk area, control effectiveness is scored individually for each control (C1, C2, C3, C4, and C5). Risk score follows a semi-quantitative approach and is measured based on the following formula 1:

𝑅𝑖𝑠𝑘 = 𝐼𝑚𝑝𝑎𝑐𝑡 × 𝐿𝑖𝑘𝑒𝑙𝑖ℎ𝑜𝑜𝑑 -(𝐶1 + 𝐶2 + 𝐶3 + 𝐶4 + 𝐶5) (1)
The methodology aims well at a numerical score to measure and monitor the privacy risks level. Also, scoring considers perspectives of both the data subject (usually the customer) and the organization (company). However, the criteria for scoring is broad and generalized i.e. not specific for privacy risks. For example, consider the following risk area -'The data subject is unaware of the collection of personal data'. Criteria can be refined and narrowed down based on sensitivity, financial value of personal data for instance, to score the impact and likelihood for privacy risk score.

Score

iPIA Tool

This tool has been developed at Institute for Management Information Systems, Vienna University [START_REF] Oetzel | A systematic methodology for privacy impact assessments: a design science approach[END_REF].

It is an open source application written in PHP and JavaScript using jQuery UI. Similar to the GS1 tool, this tool also focuses on RFID applications. The process of assessment consists of 8 main parts and unlike other PIA tools, risk is not measured using impact and likelihood. Here, the degree of protection for each target is evaluated based on three demand categories: low, scored at 1; medium scored at 2; and high, scored 3. For this degree of protection there are two main dimensions split further into sub-categories. Based on this privacy target score, threats are then ranked in the subsequent steps. Table 2 shows the categories for the degree of protection for privacy target.

Instead of measuring the level of risk, this tool measures the level of protection required. The scoring is discrete and there is no overall score which makes it difficult to compare two different versions of a PIA report.

Category

SPIA Tool

Focused on both security and privacy, this tool has been developed by University of Pennsylvania [START_REF]Introduction to the SPIA Program[END_REF]. Similar to GS1 tool this tool is also based on MS Excel spreadsheet.

The tool has two risk scores for the pre-defined threat scenarios -1) current state and 2) future state. For both these states, level of probability and consequence are entered and risk score is calculated as the product of probability and consequence. Table 3 shows the categories for probability and consequence.

Score

Probability Score Consequence 0 Threat does not apply to this application / database 0 Threat is not applicable to this application 1

The event would only occur under exceptional circumstances 1 Negligible impact on ability to plan and conduct business activities with minimal reduction in customer service, operational efficiency and staff morale. Very limited, or no financial/political impact 2

The event could occur at some time, but probably will not 2

Minor impact on ability to plan and conduct business activities with minimal reduction in customer service, operational efficiency and staff morale. Minimal financial or political impact.

3

The event should occur at some time 3

Medium impact on ability to plan and conduct business activities with a moderate reduction in customer service, operational efficiency and staff morale. Some financial or political impact is experienced.

The event will probably occur at some time 4

Major impact on ability to plan and conduct business activities with significant reduction in customer service, operational efficiency and staff morale. Considerable financial or political impact 5

The event is expected to occur in most circumstances 5

Comprehensive impact on ability to plan and conduct business activities with total disruption in customer service, operational efficiency and staff morale.

Devastating financial or political impact

Table 3: Scoring technique in SPIA tool

This tool has a larger scale as compared to other tools but scores are still ambiguous as it is difficult to objectify difference between the different levels. For instance, the probability as "(3) should occur at some time" and "(4) probably occur at some time" are quite similar. Also, scoring for consequences is highly influenced by security risk assessment making it difficult to gauge the privacy risk.

Summary

It can be concluded, based on these tools (summarized in table 4), that scoring of privacy risks has not been well focused. The concept for scoring privacy risk has been adapted from IT security management literature [START_REF] Vose | Risk Analysis: A Quantitative Guide[END_REF]. This makes it difficult to score and increasing the ambiguity in the scoring. In other words, as the scoring criteria are generalized and not specific for privacy risk, it becomes difficult to assign a particular score for a privacy risk scenario. For example, likelihood is only based on the probability levels and lacks any criteria which changes the probability of a privacy breach like financial value, sensitivity of data, level of security of data etc.

Tool Pros Cons

GS1 Tool

Uses a semi-quantitative approach, considers control effectiveness to monitor the progress

A Proposed Methodology for Measuring Privacy Risk

The process of the proposed privacy risk scoring methodology involves three steps -1) Risk Identification, 2) Risk Modeling (qualitative part) and 3) Risk Evaluation (quantitative part). First, in risk identification, scenarios for which risk is to be evaluated are considered. Second, in risk modeling step, qualitative modeling of the risk scenario is done so as to establish a relation between assets, vulnerabilities and threats. Third, in the risk evaluation step, a relative numerical score for the risk scenario is evaluated.

Risk Identification

This step involves identifying risk scenarios for the considered IT application. In this paper, risk scenarios are identified based on the EU data protection directive 95/46/EC [20] but can also be extended depending on the complexity of the application. These legal regulations also reflect company's perspective as following these regulations is one of the major considerations before deploying a new application. Risk scenarios are thus, the opposite cases of legal regulations as risk involved is doing something against the law. For instance, if the law states that the data should be used only for specified purpose, risk scenario would be -data is used for unspecified purpose i.e., worst-case scenario against a particular regulation (opposite of the regulation).

Risk Modeling

To analyze and score privacy risk, it is important to have a clear picture of the risk scenario involved. Therefore, this step deals with modeling risk scenarios qualitatively, which are identified in the previous step. It helps in understanding the complex risk scenario through abstraction. Hence, for scenario abstraction and for simplifying the scenario, CORAS diagrams are used for modeling. CORAS approach is a general approach for risk analysis and fits well with privacy risk scenarios. Qualitatively, the risk is defined as the potential for loss, damage or destruction of an asset as a result of a threat exploiting vulnerability.. Figure 1 shows a generalized CORAS risk diagram. It starts with who all can expose the system to risk (which includes system design as well).

Usually, the negligence of employees to handle the data properly or poor system design can lead to a privacy breach. Then, vulnerability, which is basically a weakness, is identified. This vulnerability can be exploited by a threat to depreciate the value of an asset. Then the threat corresponding to the vulnerability is determined which is simply the cause for unwanted incident. Similarly, unwanted incident is then classified which is the scenario when the vulnerability is exploited by the threat. Lastly, asset loss i.e. asset which is affected by the unwanted scenario is depicted in Figure 1.

Who can initiate it?

Vulnerability? Threat scenario Unwanted scenario Asset loss . If privacy concerns are undermined then there is less chance of fair and lawful processing. Negligence of employees, mischief of a hacker as well as poor system design can initiate the threat. Vulnerability here is, thus, ignoring / not considering the regulations. As a result, the threat is usage of personal data against the law leading to an unwanted incident as either lawsuit(s) against the company or bad publicity in the media.

Negligence of employees

Risk Evaluation

After defining the risk qualitatively, this section attempts at quantification of risk score for the modeled scenario. Similar to the IT security risk management approach [START_REF] Vose | Risk Analysis: A Quantitative Guide[END_REF], privacy risk is defined as the product of impact and likelihood explained in the subsequent sub-sections.

Impact.

For assessing the impact Solove's taxonomy is used [START_REF] Solove | A taxonomy of privacy[END_REF]. The taxonomy focuses on specific activities that may pose privacy problems rather than just the definitions of different aspects of privacy. Also it aims at activities that create privacy problems and that can upset the balance of social or institutional power in undesirable ways. This makes it easier to match and relate it to the risk diagrams. The taxonomy is split into four categories: 1) Information collectionrelated to collection of data, 2) Information processinginvolves the way information is stored, manipulated and used, 3) Information disseminationis about circulating and sharing the information, 4) Invasion -involves interference into people's private affairs. These four categories are subsequently split into further categories. Each risk scenario is considered and matched with different dimensions of impact. Then a simple sum of the categories applicable for the directive is calculated. This sum becomes the impact score for the risk scenario. For example, according to EU directive's article 6, collected data should be accurate. For this article, risk scenario would be the worst-case possibility i.e. very low data quality. Poor accuracy can lead to 'exclusion' as wrong information might devoid an individual from some offer [21, p. 521]. Similarly, it can also lead to 'breach of confidentiality' [21, p. 524]as an individual trusted the company and had high confidence while sharing personal data. It can also lead to 'distortion' [21, p. 546] as the personal information about the individual has low accuracy and wrong information would lead to distortion if used in some application. Therefore, three dimensions are valid for low data accuracy or low data quality. For scoring, simplistic harm benefit analysis is considered. All the different dimensions here are considered as harms and there are no benefits. So, the impact score is the net harm, which is the number of the affected dimensions, 3 in this example.

Likelihood.

For measuring likelihood, Lipton's work on 'Mapping online privacy' is used [START_REF] Lipton | MAPPING ONLINE PRIVACY[END_REF]. This work focuses on privacy issues related to digital data. Unlike Solove's work, giving the methodology a broader view by incorporating online privacy of customers. It identifies 6 different dimensions of privacy -1) Actors and relationships includes all those involved in a privacy incursion, 2) Conduct is about privacy threatening activities, 3) Motivations is simply about the motives for privacy threatening activities, 4) Harms and remedies includes all the harms and ways to redress those harms, 5) Nature of information is about the content of the information and 6) Format of information, which is about the format used to gather information online and disseminate it later. To estimate likelihood four of the six dimensions (i.e., all except 'conduct' and 'harms & remedies' which are similar to privacy risk and its consequences respectively) are used to measure likelihood. The dimensions of likelihood are broadly classified in two categories -1) Actors involved and 2) Data Characteristics. The data characteristics category incorporate the different dimensions of motivation, nature and format of information. Figure 3 shows the different dimensions of likelihood. Actors involved can be divided into 3 categories -First, the company, which involves both the employees and system design (also a strong passive actor in relation to the personal data). Second, 3 rd parties which are involved in handling the personal data and third, other actors like competitors and hackers who also have interest in the collected personal data of the customers. Similarly, data characteristics is also divided into 3 categories -1) Amount of data, 2) Sensitivity of data, 3) Value of data involved. Amount of data is about the total rows and columns of the data. If more data is collected then the likelihood of privacy risk in general increases. Also, the value of data is about the monetary benefits of a privacy breach. If cost of an activity leading to privacy risk is low than the likelihood will be higher as vulnerability can be exploited easily without any substantial cost. Similar is the case with benefits obtained with that malicious activity, i.e., the higher the financial value of data, the higher is the likelihood of occurrence of similar activity. Additionally, a category regarding sensitivity of data is considered for measuring likelihood because financial value is not always higher for more sensitive data as it depends more on the context. For example, CEN standards define a higher asset value to an email address as compared to racial origin, which is actually a very sensitive data type. But, as maybe current scope of commercial exploitation is not that high for racial origin (as compared to email address), there is a higher commercial value for email addresses. Nevertheless, sensitive data is usually intimate for the customers and this gives a high motivation to the actors who have intentions of damaging the reputation of the firm collecting and disseminating the personal sensitive data.

A case study -Application to the law

In this section a case study is presented to illustrate the proposed methodology. A fictitious restaurant with an online ordering and home delivery system is considered for the example. Customers can open restaurant's webpage, order food, pay it online and can get it delivered to their desired address.

According to article 6 of EU data protection directive -'personal data of data-subjects must be adequate, relevant and not excessive in relation to the purposes for which they are collected and/or further processed' [20]. The risk scenario would therefore be collection of personal data inadequate, irrelevant and excessive for the purpose. 4 shows the modeled risk diagram for the scenario. Due to either negligence of employees, their lack of awareness or the poor design of the system can lead to scenarios where data collected is excessive of the purpose. Underlying vulnerability here is that before deploying a system or during its design the purpose of collected personal data fields is not checked or actively updated with the changes in the design. This vulnerability is leads to a threat, which is simply the excessive data collection (opposite scenario of the legal regulation). Then, unwanted scenario for this threat would be higher risk in securing and handling more data fields as compared to the case when limited data would have been collected. Also, according to article 10 of EU data protection directive [20], data subjects should be given the information regarding the purpose of data collection which would be difficult to provide as data collected is excessive to the purpose. Hence, it will lead to loss of reputation and trust of customers (datasubjects) for the company.

Let us assume that the restaurant collects the personal details as shown in table 6. The purpose is to process an online order and deliver the food at the given address which requires last name to identify a person, address to deliver it and telephone number to notify when the delivery staff is at the given address. 6. If excessive data is collected then it can lead to increased surveillance with the help of excessive data fields that are collected. In the example, browsing history is a case of surveillance on customer's browsing habits. Similarly, it also leads to aggregation as a more comprehensive profile of the customers would be collected, which can also lead to identification. In general, customer would be roughly identified for the delivery using last name and address but the data collected would lead to exact identification. Also, more data leads to more insecurity and might tempt the restaurant for other secondary uses like sending marketing emails based on customer profile. Personal data of a customer can be also misused by an employee or a hacker to use his/her identity for a malicious activity leading to appropriation. Company would have increased accessibility about the customer and would be in fact intruding in customer's personal life by collecting personal information, which is not required for the application. Therefore the impact score is quite high as 9/13.

The likelihood score would be subjective and more context dependent. For this scenario, the main actors are easily identifiablesystem design and employees at the restaurant. Data characteristics score would depend on the quantity, financial value, and sensitivity of the collected data. Considering the fact that only the basic demographics like name, age, address and phone numbers are collected, the score would be 2/3. For sensitivity it would be 0. For amount of data the score can be set to 1 (out of 3) as not much data is collected. Value of data would be around 2 out of 3 as address, telephone numbers, browsing history etc. have high marketing value. In total, the score for likelihood would be 5/10 as shown in table 8. Hence, the risk score would be 8.75 out of 25 as shown in the table 9. The scale has been adjusted such that the maximum risk score would be 25. The risk is then represented on a an impact-likelihood (probability) graph [START_REF] Vose | Risk Analysis: A Quantitative Guide[END_REF]. It can be observed from the graph in figure 5 that risk score lies in the escape/transfer region. Hence, it is required to escape the scenario by modifying the design of the system, which can be either done by an audit to confirm the use of all the data collected or by reducing the personal data which is being collected. Subsequently, in the later stages, likelihood can be decreased by improving the system design or securing the collected data (to increase the efforts required for unreasonable access). Similarly, impact would be reduced when limited data is collected for a predefined purpose as dimensions of intrusion, surveillance etc. would then not be valid. Following an IT security risk management approach, this paper proposes a structured privacy risk metric. The risk score enables measuring the progress made in minimizing privacy risk between the incremental development cycles in system development. Risk scenarios based on EU data protection directive 95/46/EC have been taken as an example to illustrate the process. These scenarios are modeled using CORAS diagrams for better understanding and abstraction. For quantification, risk is then broken down into impact and likelihood. The dimensions for likelihood focus on company's perspective by considering actors, financial value of data etc. and dimensions for impact based on Solove's taxonomy help in measuring the impact from the customer's point of view. In the end, a privacy risk score is obtained as the product of impact and likelihood.

Dimensions

Score

The focus in previous sections has been to develop a structured metric for privacy risk score and scales for measuring impact and likelihood are not discussed in detail. 0 and 1 have been used for scoring the impact dimensions and all of them have the same weightage. However, impact dimensions can have different weightages based on the scenario. For example, consider a scenario where CCTV cameras are used in a store for surveillance. If cameras are around the changing rooms then it can lead to 'Exposure' of customers i.e. might reveal their nude body. In this scenario, weightage for 'Exposure' should be higher than 'Aggregation' of their purchase history. Hence, the future work would involve selecting suitable functions to aggregate impact dimensions along with assigning appropriate weightages to them. Additionally, the scoring metric would then be integrated in a PIA tool to benchmark it in a real-life scenario. It would be crucial to tackle the tradeoff between customizability and complexity. A rigorous and fully customizable risk scoring algorithm might lead a complex PIA process whereas, standardizing all the parameters might reduce the usefulness of the score. Hence, for a simple yet meaningful PIA, it is important that scoring process does not add a lot of complexity to the process.

Figure 1 :Figure 2

 12 Figure 1: Schematic of risk modeling using CORAS approach Figure 2 shows an example of CORAS diagram for EU directive 95/46/EC article 6 about personal data being processed fairly and lawfully [20]. If privacy concerns are undermined then there is less chance of fair and lawful processing. Negligence of employees, mischief of a hacker as well as poor system design can initiate the threat. Vulnerability here is, thus, ignoring / not considering the regulations. As a result, the threat is usage of personal data against the law leading to an unwanted incident as either lawsuit(s) against the company or bad publicity in the media.

Figure 2 :

 2 Figure 2: Example of risk modeling using CORAS approach

Figure 3 :

 3 Figure 3: Dimensions for measuring likelihood

Figure 4 :

 4 Figure 4: CORAS diagram for the risk scenario

Figure

  Figure4shows the modeled risk diagram for the scenario. Due to either negligence of employees, their lack of awareness or the poor design of the system can lead to scenarios where data collected is excessive of the purpose. Underlying vulnerability here is that before deploying a system or during its design the purpose of collected personal data fields is not checked or actively updated with the changes in the design. This vulnerability is leads to a threat, which is simply the excessive data collection (opposite scenario of the legal regulation). Then, unwanted scenario for this threat would be higher risk in securing and handling more data fields as compared to the case when

Figure 5 :

 5 Figure 5: Risk score on impact likelihood graph

Likelihood Score Impact Score Control effec- tiveness

		occur in the		will be detri-		place -proven
		organiza-		mental and cause		effective in the
		tion		residual effects		past 6 months
				to the organiza-
				tion.
	3	This risk may occur in the or-ganization	3	The impact to the data subject will be minor and cause some residual effects to the organiza-tion.	3	Risk mitigation strategy or con-trol process in place -proven largely effec-tive
						Risk mitigation
				There could be		strategy or con-
		It is un-		minor impact to		trol process re-
	2	likely that this risk	2	the data subject with some resid-	2	cently imple-mented -effec-
		will occur		ual effects to the		tiveness is
				organization.		questionable or
						unknown
	1	It is very unlikely that this risk will occur	1	There would be no impact to the data subject with no residual ef-fects to the or-ganization.	1	Risk mitigation strategy or con-trol process is not in place or is under devel-opment
	5	It is very likely that this risk will occur in the or-ganization	5	The impact to the data subject will be highly detrimental and cause residual ef-fects to the or-ganization.	5	Risk mitigation strategy or con-trol process in place -proven highly effective in the previous 12 months
	4	It is likely that this risk will	4	The impact to the data subject	4	Risk mitigation strategy or con-trol process in

Table 1 :

 1 Scoring technique used in GS1 PIA Tool

Table 2 :

 2 Scoring technique used in iPIA Tool

		Subcategory	Score
	Operator perspective	Impact on reputation and brand value Financial loss	Low,
	Consumer perspective	Social standing Financial well being Personal freedom	Med, High
	Overall category

Table 4 :

 4 Pros and cons of the tools

	Criteria for scoring is too generic

Table 5

 5

	shows the different dimensions based on

Table 5 :

 5 Dimensions for impact based on Solove's taxonomy

Table 6 :

 6 Categories of personal data collected by the restaurantThe next step is quantifying the impact and likelihood score. Using Solove's (2006) taxonomy, the impact dimensions are measured as shown in table

	Category of per-sonal data	Collected	Required for the pur-pose?
	First name	Y	N
	Last name	Y	Y
	Address	Y	Y
	Telephone	Y	Y
	Email	Y	N
	Gender	Y	N
	Birthday	Y	N
	Order history	Y	N
	Browsing his-	Y	N
	tory

Table 7 :

 7 Impact score for the example

	for impact	S U M	Surveillance	Aggregation	Identification	Insecurity	Secondary Use	Exclusion	Breach of confi-dentiality	Disclosure	Exposure	Appropriation	Distortion	Increased Acces-sibility	Intrusion
	Excessive collection	9	Y	Y	Y	Y	Y	N	N	Y N Y N	Y	Y
					Dimensions		Score Max
					Actors involved	2		3
					Amount of data	1		3
					Sensitivity of data	0		1
					Value of data		2		3
					Total			5		10

Table 8 :

 8 Estimating the likelihood

Table 9 :

 9 Calculating the risk score

			Score out of 5
	Impact	9/13	3.5
	Likeli-	5/10	2.5
	hood
	Risk score	8.75 / 25


Alaa Alaqra

Simone Fischer-Hübner

Thomas Gross

Thomas Lorünser

Daniel Slamanig

Thomas Groß

Signatures for Privacy, Trust and Accountability in the Cloud: Applications and Requirements

Keywords: Privacy, Cloud Computing, Functional Signatures, Malleable Signatures, Graph Signatures, Anonymous Credentials, User Requirements

scientifiques 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

Cloud computing is a very promising direction within ICT, but the practical adoption of cloud computing technologies may be greatly hindered by the lack of adequate technical controls to enforce the privacy of data and users in this outsourcing scenario. Solving this issues is especially challenging due to some fundamental properties of cloud computing such as being an open platform, its anytime and anywhere accessibility, as well as the intrinsic multi-tenancy, which introduce new security and privacy threats. In general, cloud computing is typically an outsourcing model and if the associated threats are not addressed adequately it leads to a tremendous risk for cloud users and their data. Thus, it is widely accepted that outsourcing of data and computations to third party cloud infrastructure requires various challenging security and privacy issues to be solved in order to gain users' trust. Besides the evident privacy and confidentiality issues associated with outsourced personal data and other type of confidential data (e.g., business secrets), which are a quite well understood albeit unsolved problem, this new computing paradigm introduces additional problems related to authenticity, verifiability and accountability. Basically, the question is how we can ensure that the cloud works as it is intended or claimed to do and how can the cloud be held accountable if deviations occur. Thereby, one may not only be concerned with the data itself, but also with processes (tasks/workflows) running in the cloud and processing the data. Moreover, such concerns may also be related to the used infrastructure itself.

Enforcing authenticity, verifiability and accountability for cloud based data processing by means of cryptography is one core topic within the recently started EU Horizon 2020 project Prismacloud5 on Privacy and Security Maintaining Services in the Cloud [START_REF] Lorünser | Towards a New Paradigm for Privacy and Security in Cloud Services[END_REF]. Its general goal is the research and development of tools and methodologies to strengthen the security, privacy and accountability for cloud based services, i.e., to make them more trustworthy. The main results will be showcased in different use-cases from the three application domains e-Health, e-Government and Smart Cities, which typically deal with sensitive data of citizens. To maximize the impact of the project results another focus of Prismacloud is on the usability of developed solutions. Therefore, we are studying how users perceive such technologies if used within cloud based services, and elicit end user and human-computer interaction (HCI) requirements and guidelines for usable cryptography and protocols for the cloud. The aim is to design services which provide adequate security features but at the same time respect the users' needs in order to guarantee for the best acceptance of security technologies. The users should be able to understand and perceive the increased security and privacy they have when interacting with an augmented system while not being confronted with obstacles complicating their real tasks.

At the IFIP Summer School 2015 (Edinburgh, August 2015), the Prismacloud project has organised a workshop comprising a series of parallel focus group sessions on the first day and a second-day "Deep Dive on Cryptography" workshop session. The motivation behind organizing this workshop related to the Prismacloud project was as follows. Firstly, it was our intention to benefit from the knowledge of experts (from different domains) participating at the summer school in order to gather feedback, criticism and input on very early descriptions of the use-cases within Prismacloud and to elicit end user and HCI requirements. Secondly, it was our aim to bring the attention of the audience to the cryptographic tools that are used and further developed within Prismacloud. In particular, to attract interest from other researchers to also conduct research in this important field as well as interest from other security and privacy related research projects and researchers to cooperate with Prismacloud. This paper summarises the content and discussion results of this workshop.

Outline. The remainder of this paper is structured as follows: In the next section, the cryptographic tools for the use-cases within Prismacloud will be introduced. Section 3 briefly presents preliminary use-case scenarios in the areas of e-Health, e-Government and Smart Cities that are currently elaborated in Prismacloud and helped explaining the ideas in the workshop and served as a basis for our focus group discussions. Section 4 presents the discussion results including the elicited end user and HCI requirements of five parallel focus groups that were part of the workshop. Section 5 will then summarise the results of the discussion on the second day on graph signatures and topology certification (as they have not been covered in the presented use-cases). Section 6 is finally rounding up this paper with overall conclusions.

Cryptographic Tools

Securing data over its life cycle in the cloud by means of cryptography is extremely challenging yet appealing to prevent many of provider related threats. This is due to the fact, that today widely used cryptography is designed to protect the confidentiality and authenticity of data in a very stringent way, i.e., without allowing for any modification. However, in the cloud setting it is important to support controlled altering and sharing of data in an agile way in order not to lose the benefits of cloud computing for cryptographically protected data. A very descriptive example is cloud storage. If we simply encrypt the data before uploading to the cloud we are protected from all major threats but completely lose the possibility to share or process the data, hence, we have to resign from almost all additional benefits of cloud computing for the sake of security. The same is true for authenticity protected data by means of signatures, every alteration of the data would immediately render the signature invalid, no matter how small it may be.

In Prismacloud we focus on the research and development of efficient cryptographic methods tailored to fit the needs of cloud computing and allow for controlled modification and sharing of data without giving up on the end-to-end security paradigm. We carefully selected technologies which have the potential to better protect the security of data during their stay in the cloud in a more agile way than currently possible. Subsequently, we briefly introduce some cryptographic tools that (a) are used within the use-cases presented and discussed in the workshop and (b) that have been presented throughout the second technical part of the workshop. Some of them do not appear in the use-cases that have been selected for the workshop and focus groups at the first workshop day. In particular, we will briefly present the concept of distributed cloud storage, different variants of signature schemes with special properties and the concept of (attribute-based) anonymous credentials.

Distributed cloud storage. Protecting the privacy, integrity and availability of stored data in the public cloud setting while at the same time allowing them to be shared in dynamic groups is a challenging problem. Currently, most cloud storage services store the data either unencrypted or apply encryption in a way that the keys remain under complete control of the cloud service provider. Hence, the data is susceptible to insider attacks and curious providers. In Prismacloud we follow a distributed systems approach and apply the cloud-of-clouds paradigm to increase availability and robustness. Here, the information is split into a number of shares [START_REF] Shamir | How to share a secret[END_REF], of which any subset of a fixed number allows the reconstruction of the original data. This approach is keyless and removes many obstacles in the area of usability and group key management [START_REF] Lorüenser | ARCHISTAR: Towards Secure and Robust Cloud Based Data Sharing[END_REF]. Additionally it is capable to provide long-term security and everlasting privacy, which is very interesting for archiving of sensitive data. The confidentiality of data is guaranteed independently of the adversarial power and future developments, i.e., the rise of quantum computers. However, this assumption only holds as long as the majority of nodes in the cryptographic storage network have not been compromised. This assumption is different from conventional approaches and was a matter of discussion in the workshop.

Malleable and functional signatures. Malleable signatures are digital signatures that have some well-defined malleability property. This means, that signed data can be changed in a controlled way without invalidating the corresponding signature. In the following we will only very loosely discuss the two classes of malleable signatures that are of interest for the use-cases presented during the workshop. Firstly, malleable signatures that treat the signed message as structured data and allow to modify (e.g., black-out) well-defined parts of such a signed message. Such schemes, depending on their properties, i.e., who is allowed to perform the modifications, are modifications visible, etc., are denoted redactable [START_REF] Johnson | Homomorphic Signature Schemes[END_REF][START_REF] Steinfeld | Content Extraction Signatures[END_REF] or sanitizable [START_REF] Ateniese | Sanitizable Signatures[END_REF] signature schemes. The prime application of such a scheme is publishing a redacted version of a previously signed document where all sensitive information have been removed from the document without invalidating the original signature and thus the evidence for the authenticity of the document (cf. Figure 1). Another class of schemes that usually treats messages as numeric data and targets on computing on signed data are called homomorphic signature schemes [START_REF] Catalano | Homomorphic Signatures and Message Authentication Codes[END_REF]. Basically, this means that there exists a public operation on signatures that carries over to the signed messages, e.g., one can compute the sum of single signed messages and derive a valid signature from the corresponding messages without requiring the secret signing key (cf. Figure 2). These schemes (and their practical efficiency) thereby greatly differ in the supported class of computations, e.g., linear functions, polynomial functions of some higher but fixed degree or arbitrary computations (fully homomorphic signature schemes). Functional signatures [START_REF] Boyle | Functional Signatures and Pseudorandom Functions[END_REF] allow to delegate signature generation for message meeting certain conditions to other parties, who can then compute signatures for a certain functionality on behalf of the original signer. Prime examples are proxy-signatures [START_REF] Boldyreva | Secure Proxy Signature Schemes for Delegation of Signing Rights[END_REF] for delegating signing capabilities and their application to certify computations on data (verifiable computations). Within Prismacloud we want to study the application of aforementioned types of signature schemes to add verifiability features to data processing in the cloud in terms of end-toend authenticity as well as verifiability of computations.

Graph signatures. Graph signatures [START_REF] Groß | Signatures and efficient proofs on committed graphs and NP-statements[END_REF] are a new primitive we investigate within Prismacloud, which makes it possible that two parties engage in an interactive protocol to issue a signature on a graph. The resulting signature enables a prover to convince a verifier that the signed graph fulfils certain security properties (e.g., isolation or connectedness) without disclosing the blueprint of the graph itself. The foundational scheme for graph signatures [START_REF] Groß | Signatures and efficient proofs on committed graphs and NP-statements[END_REF] works on arbitrary undirected graphs. It encodes the graph data structure into a Camenisch-Lysyanskaya signature, making it accessible to zero-knowledge proofs of knowledge. The method for this is a form of Gödel numbering, that is, of representing data uniquely as products of prime numbers. This technique makes it possible that subsequent cryptographic proofs can argue over vertices, edges and labels. Within Prismacloud we develop and optimize the use of graph signatures for practical use in virtualized infrastructures. Their application allows an auditor to analyse the configuration of a cloud, and to issue a signature on its topology (or a sequence of signatures on dynamically changing topologies). [START_REF] Groß | Efficient certification and zero-knowledge proofs of knowledge on infrastructure topology graphs[END_REF]. The signature encodes the topology as a graph in a special way, such that the cloud provider can prove high-level security properties such as isolation of tenants to verifiers. Furthermore, we will bridge between cloud security assurance and verification methodology and certification. We do this by establishing a framework that issues signatures and proves security properties based on standard graph models of cloud topologies and security goals stated in formal language, such that the virtualization assurance language VALID [START_REF] Bleikertz | A Virtualization Assurance Language for Isolation and Deployment[END_REF].

Anonymous credentials. Anonymous credentials (often denoted Privacy ABCs or simply ABCs) [START_REF] Camenisch | Concepts around privacy-preserving attribute-based credentialsmaking authentication with anonymous credentials practical[END_REF] are an important privacy-enhancing cryptographic tool that can be used to realize a privacy-friendly authentication mechanisms. In particular, it allows users to obtain credentials (that may contain various attributes of users) from some organization such that can later use them for authentication without the organization being able to track them. Moreover, if a user presents the credential more than once, these presentations cannot be linked together (unless special care is taken to allow such a mechanism). Finally, they allow data minimization. This means that the user does not need to reveal all the attributes encoded into a credential, but can selectively decide which attributes to show. Typically ABCs also allow a user to only prove that certain attributes satisfy some relation without revealing anything beyond, i.e., to demonstrate that the credential holder is older than some required threshold without revealing the birth date. In cloud based applications and services, the user's privacy is enormously endangered, since tracking user's data and behaviour is easily possible. Consequently, within Prismacloud we focus on bringing ABCs into practical application and also on improving their applicability.

Use-Case Scenarios

In the introductory workshop presentation, the following four use-case scenarios were presented to illustrate the use of the cryptographic tools of the project. The E-Health scenarios (a) and (b) use malleable signatures, the E-Government scenario is based on distributed cloud storage and the Smart Cities scenario involves anonymous credentials (a) E-Health: blood test. Consider a case where a patient goes to the doctor for a routine check-up and takes an extensive blood test. The blood test is taken by the doctor's nurse and the results are uploaded to a cloud portal and are digitally signed by the nurse. The doctor has access to the complete blood test results. Later, the patient visits a dietitian, who requires few specific fields of the blood test. The patient doesn't want to reveal all fields from the extensive blood test. So the patient selects the mandatory fields from the extensive blood test for the dietitian to see and redacts ("blacks-out") the other fields.

Alternative case: Consider a case where the patient goes to the doctor for a routine check-up and takes an extensive blood test. The blood test results and diagnosis report are uploaded to a cloud portal and are digitally signed by the doctor. The doctor has access to the complete blood test results. However, the patient wants a second opinion from another doctor regarding her results. The patient doesn't want to reveal the diagnosis fields from the report. So the patient selects the blood test results for the second doctor while redacting ("blackingout") the diagnosis field.

(b) E-Health: smart phone monitor application. Consider a case, where a patient has a smart phone training application that uses the sensors on the phone/wearable device to monitor and collect personal data of the patient. The patient would like to share only a statistical summary of activity progress information of the data collected by the application with her personal trainer without revealing sensitive medical data values.

(c) E-Government: disaster files recovery. For disaster recovery and backup purposes, IT providers of governmental institutions split their databases into multiple parts (shares) that are stored at independent cloud providers. Consider a case where a disaster occurs, and there is a risk of a potential data loss. To reconstruct data, only a predefined subset of shares stored at different cloud providers would be required, e.g., 4 shares out of 7.

(d) Smart Cities: handicap parking. Consider a case where handicapped citizens are required to use either their regular phones or smart phones to validate themselves in order for them to park at the handicap parking spot. Parking reservations are then stored centrally in the cloud for constantly monitoring the load of parking reservations. When using a regular phone, a control station by the parking will be used to authorize the parking using an SMS. When using a smart phone, the parking app would use the NFC badge (digital identification) and GPS location for authorization. With a privacy-enhanced solution based on a mobile phone based on an anonymous credentials-equipped mobile phone, the users could secretly authorise themselves for being eligible for this service without leaking any other information.

Day 1-Focus Groups Discussions

In the following subsections, we present a description of the workshop process. We give first an overview of the focus groups and then further details of the discussions and results per group in terms of the elicited requirements.

Workshop Format

A workshop in the form of expert focus group discussions was conducted on the first day with summer school participants who can be considered as experts in the field of privacy and security. The use-case scenarios in the areas of e-Health, e-Government, and Smart Cities developed in Prismacloud and briefly presented above in Section 3, were used in the workshop in order to give a context for the use of the project's cryptographic tools. The aim of the focus group discussions was to discuss use-case scenarios, to explore end user and HCI challenges of the scenarios and further elicit requirements in regards to usability, trust, and privacy.

The workshop consisted of informative and interactive parts. In total 25 participants with different research levels and backgrounds formed 5 interdisciplinary focus groups, coming mainly from Europe and Asia. The informative part consisted of a brief introduction to Prismacloud, the three use-case scenarios, and a technical overview of signatures schemes covering malleable and functional signatures and other Prismacloud crypto tools in preparations of the focus group tasks and discussions. Each group had a moderator (the authors of this paper) who guided the group through tasks, brainstorming activities, discussions, and feedback throughout the interactive sessions.

The interactive session consisted of three parts: (a) An introduction to the workshops agenda, materials, group forming, and group members' introductions. (b) Selection of use-case scenarios to be discussed by that focus group and discussion of related cryptographic tools, and further the implications and features of those functions in regards to usability, privacy, and trust. (c) Requirements elicitation of cryptographic tools from part (b) to enhance usability, privacy, and trust in the cloud. For the brainstorming discussions, participants wrote short notes on opportunities and concerns that they see in regard to the selected case scenarios on post-it notes that were stuck on poster.

Results from the focus group sessions were documented as summaries by the moderator of each group. The summaries below followed the basic structure of: A. Group participants B. Use-case scenario C. Key points of the discussion D. Elicited requirements

Focus groups

The participants varied in formation of the 5 focus groups. For instance, one group consisted of only security and privacy PhD students group (FG1), others included a mix of security and privacy researchers with of participants with backgrounds in cryptography (FG2, FG3, FG4), cognitive science (FG2) and legal practice (FG5). For the use-case selection, the e-Health use-case scenario was chosen by FG1, FG3, and FG5, Smart Cities use-case was chosen by FG2, and FG4 discussed all. It was noted that the 5 focus groups have focused on different aspects of the scenario (which was expected), and the resulting requirements have reflected on these diverse focuses. All groups discussed the scenarios cryptographic aspects, however the focus was on control, privacy, and trust (FG1), functions, applications, and usability (FG2), rules and policies (FG3), cryptographic tools (FG4), as well as data types and legal rights (FG5), which is to be seen in the following subsections.

Focus Group No. 1:

(A) Group participants: The group consisted of 4 Computer Science PhD students doing research in IT Security & Privacy. A Computer Security professor and Prismacloud project member acted as the workshop leader.

(B) Use-case scenario: As a scenario, the presented e-Health scenario on the redaction of blood test parameters in medical files stored in the cloud via malleable signatures was chosen and not further modified.

(C) Key points of the discussion: It was discussed that malleable signatures can in this case enhance privacy, as they give the data subject/redactor more control over what information to disclose to the verifier and what data she would like to redact. Hence, it allows the data subjects to enforce data minimization. At the same time, the barrier for patients to exercise control may be lower if they can do it electronically and thus directly, instead of having to request signed redacted data offline (e.g. via mail). Patients may also put more trust into the health care provider, if they get options to control their data. Also, trust by the verifier can be enhanced, as the malleable signature guarantees that also the redacted document remains authentic.

However, increased patient control may also put extra burden and responsibility on the users. Moreover, it can also be debated whether patients should really have full electronic access to their medical dossiers, as they may not always be able to interpret all details and consequences correctly. From the patients perspective, they may not feel competent enough to do redactions themselves. For example, if they redact too much information, it may endanger their safety. They may therefore want to delegate this task to a trusted third party. However, accountability for the redaction may in this case be at stake.

As for redaction, doctors or nurses must be trusted to make competent decisions in regard to the amount of information that can be redacted by different patients considering both the patient's privacy and safety. If the redactor cannot be authenticated (i.e., in technical terms: the redaction operation is "unkeyed"), the verifier may lack trust in the redaction, e.g. may not be sure that really only information that was not needed in a certain context was redacted by authorized persons. Moreover, the patient may repudiate. If it is possible that the doctor can do the redaction and later claim that the patient did so, this may create privacy and trust issues.

If the signer who is in charge of sampling the blood test creates a malleable signature on the blood test that authorizing the patient concerned to do redactions on his blood test, then the identity of the patient may leak to the signer. However, for privacy reasons it is the practice that blood tests should be submitted anonymously.

It may affect trust if the verifiers cannot distinguish the cases when data has been redacted from documents or not. Also, privacy may be affected if the fact that information has been redacted (i.e. that the patient chose to hide certain medical values) cannot be hidden.

(D) Elicited requirements: The following list includes a number of requirements for enhancing privacy, trust and usability that were jointly suggested by the workshop participants:

-R1A It must be possible for the patient to delegate redactions to a specialist that he trusts; In this case, the delegate must be accountable for his actions. -R1B The redactor should be accountable (i.e., the redaction operation should be a "keyed" operation). -R1C Even if the redactor can be made accountable, there should be a possibility that the redactor can be anonymous or pseudonymous to the signer (so that the anonymity of blood tests can be guaranteed). ible" to the verifiers, i.e. in some cases the very fact that data was redacted should be hidden. -R1E Usable guidelines and support are needed for informing users about how much information is advisable to redact taking both privacy and patient safety criteria into consideration. -R1F The user interface should be based on suitable metaphors and HCI concepts and complementing tutorials for illustrating how the system works for promoting user trust in the claimed functionality of malleable signatures. -R1G The definition of fields that can be redacted should follow the data minimisation principle while considering the patient's safety. Doctor and nurses need guidelines and support on how to define redactable fields while following these principles.

Focus Group No. 2:

(A) Group participants: The 5 participants of this group were 3 from computer privacy and security and 2 from cognitive science background. One issue regarding the mixture of the participants was related to their different levels of experience, which have hindered some discussion flows and interactivity, i.e. the two more senior researchers and practitioners in computer privacy and security were more dominant in the discussion due to their knowledge and expertise. An HCI Computer Security PhD. candidate and Prismacloud project member acted as the workshop leader.

(B) Use-case scenario: When choosing the use-case, participants questioned the reason behind choosing a specific scenario and applicability of any chosen scenario. There was a discussion on how plausible the scenario is, and whether the scope is too narrow. Eventually, smart city and handicap parking was chosen as a preliminary case scenario.

(C) Key points of the discussion: The group started the discussion with the scenarios' functions. A main concern was raised on whether there is a need to use the cloud at all for this use-case scenario and when verifying credentials in the cloud which hardware and software to be considered from the users' side, in this case the discussion focused on the smart mobile phone. A debate arouse regarding whether the cryptographic tools are useful, it concluded with a suggestion to use attribute-based signatures to sign GPS coordinates as a claim of a handicapped person on a specific parking spot. Inspection measures versus linkability problem was brought up as there was a discussion on what is required to be considered and done in regards to this tradeoff, i.e., there is a need for inspection means, however linkability can't be avoided. Some concern came up whether the application might give a false sense of privacy, where users might not be aware of the extent of data they are exposing. On the other hand, sabotaging users launching denial of service (DoS) and distributed denial of service attacks by anonymously reserving all parking places were discussed. Fraud and fault issues were addressed, and the discussion on how users can still lend out the handicap privileges despite the applications' main functions.

Finally, participants discussed usability issues with the app in comparison to the handicap card. The latter requires no effort on the behalf of the user, whereas the first is more demanding, i.e., credentials: there is a need for certain devices, and a level of understanding by the handicap users to get the application to work and show that the parking is authorized.

(D) Elicited requirements:

-R2A Trust requirements for the users: need of evaluators and transparency.

-R2B Each user must possess a credential that is securely stored on a mobile device, and a provably correct anonymous credentials protocol and implementation (validation + verification). -R2C Important to protect the verifiers' availability and integrity (no corruption or coercion ). -R2D Payment requirement, even a little in order to mitigate DoS. -R2E Revocation should be possible; temporary impaired/handicapped people (doctors/physicians can issue revocation). -R2F Fraud inspection means are needed.

-R2G Usability: Less credentials to handle for easy decision making and less interferences with driving. -R2H Suitable user interfaces and tutorials so that users can be aware of the systems functions and limitations. -R2I Mobile application needs to be generic, for usability and appeal.

Focus Group No. 3:

(A) Group participants: The 5 group members consisted of a senior researcher in applied cryptography, a researcher and 2 PhD students in privacy and security related work within computing science, and a research engineer on privacy policies specification and their enforcement within a cloud computing environment.A technical Computer Security senior researcher and Prismacloud project member acted as the workshop leader.

(B) Use-case scenario: In this group, the e-Health scenario was chosen, and the discussion focused on the application of malleable signature schemes.

(C) Key points of the discussion: In particular, the discussion was about "blacking out fields" from medical data. In the beginning, there were some issues that needed clarification by the moderator (as there were questions from the participants which were only answered in the second part of the workshop). Afterwords, the discussion identified positive aspects of applying such schemes, e.g., more efficient processes (less interaction steps are required) and no longer requiring the signer if we want to give away authentic data to another party (offline feature). Nevertheless, the focus was more on the related problems and thus focused on what one would need to do in order to make such schemes applicable in practice.

It was identified that it is very important to specify redaction rules of how signed messages/documents are allowed to be redacted/modified. Thereby, it could be problematic if redacted versions of a document would be used in various different areas (e.g., e-Health and outside e-Health) -as this makes it hard to specify in which context which redaction is allowed. This could then lead to a redacted document that could be misused in the respective other area. Technically, one could counter this problem by using redaction policies (i.e., using a formal specification language to exactly specify what is allowed) and it should clearly (formally) define what is allowed to do in which context (it seems, however, that this is a highly non-trivial task). Policies could also support users (signers as well as redactors) to eliminate human errors and make such redaction tools easier to handle. Another problem that was identified in context of users is that users (signers) may not be able to comprehend what data to "mark" as being redactable. Consequently, it seems that for practical applications there is an inevitable need for policy and software support tool.

(D) Elicited requirements:

-R3A Important to specify redaction rules of how signed messages/documents are allowed to be redacted/modified. -R3B Need for redaction policies (i.e., using a formal specification language to specify what is allowed) and it should clearly define what is allowed in which context. -R3C Practical applications' strong need for policies and software support tools.

Focus Group No. 4:

(A) Group participants: The group consisted of (1) an associate professor of privacy enhancing protocols and privacy by design, (2) a principal research scientist in the Security and Cloud Research Lab with a focus on privacy enhancing technologies, accountability and the cloud, (3) a research engineer involved in developing a monitoring framework for cloud assurance and accountability, and (4) a PhD student working on data pseudonymization and anonymization. A technical Computer Security senior researcher and Prismacloud project member acted as the workshop leader.

(B) Use-case scenario: In general, the group attempted to analyze all scenarios, but discussion got caught up on signatures. It started with detailed explanation of redactable signatures and the health use-case. The use of malleable signatures and verifiable computation in the blood test use-case was then discussed.

(C) Key points of the discussion: The discussion was focused on the tools. First the redactable signatures were introduced and explained by the moderator, the group understood the features and also the need for redaction in some situations, e.g. anonymous data sharing in health care applications, although they doubted the feature of anonymity, because inferences can be made by learning metadata. There are maybe better or additional means necessary like anonymization/pseudonymization to provide protection against re-identification. It was also a questions to which extent this features could be limited to third parties and selectively delegated. Another concern regarding the redactability was, if it was really deleted. This comment was also referring to the problem of re-identification. One participant questioned the use of malleable signatures, and claimed that the concept is very close to ABC which even provide unlinkability and most of the features of redactable signatures cloud be implemented by the use of ABCs. He was interested in the advantage of redactable signatures compared to ABCs.

In the discussion of malleable signatures and verifiable computation, confidentiality was pointed out to be a more critical issue than authenticity. There was doubt about the use-case and participants thought the introduction of a trusted third party is dangerous. A concern regarding the danger of the third party adding not the right values to influence the result to their own favor,and that this scenario only makes sense if the final signature can also be used to verify that the right values have been included in the computation.

Reasons why ABC is necessary and what can be done with it were discussed. There was a concern regarding the smart city use-case with the electronic version of the disable batch. The fear was that it is still possible to link GPS or other metadata to anonymous credentials, e.g., license plate.

In the case of distributed storage, participants saw an opportunity to further compute data in such a setting which would be another advantage of such a system. However, they would like to see good technical arguments to make sure that they don't collaborate, because otherwise they would not fully trust this assumption to be true in many situations.

(D) Elicited requirements -R4A Different scenarios for redactor roles are needed; if redactor=user, then use ABCs. -R4B Need for proactive measures for introducing redactable fields.

-R4C Address the need for third parties, and improve means for trusting them (confidentiality). -R4D Need for additional means to protect against re-identification and aid anonymization and pseudo anonymization. -R4E Need for good technical arguments for trusting distributed storage systems. -R4F Need to address scalability, what if many fields should be redactable.

Focus Group No. 5:

(A) Group participants: Five participants from computer security (2), privacy (1) and legal (2) background. The different backgrounds made for an interesting and inspiring discussion with multiple angles covered. The discussion was fruitful, albeit straying from the initial agenda. A technical Computer Security senior researcher and Prismacloud project member acted as the workshop leader.

(B) Use-case scenario: The discussion gravitated around finding scenarios for case studies, yet touched upon general principles. The scenario became the catalyst of the discussion, which yielded further considerations in multiple topics. As scenario, the group proposed e-Health as general area and specifically a fitness app that stores the data in the cloud. The question was raised what data is shared or stored locally on the user's device.

(C) Key points of the discussion: A core topic discussed by the group is the data types that need consideration in such a scenario, where the group named the following types:

-Medical data, -Personal identifiable data, -Location data, -Time data (history over time), and -Metadata (data about data).

The group raised the question about derivative data, i.e., data derived from the user's primary data, e.g., information learned and stored in Machine Learning Models. The question of ownership arises for the ownership and the user's rights with respect to that data. How could cryptography offer a chain of custody for such derivative data?

The group considered the overall risk of the scenario. Here, the opinion was voiced that having data stored in the cloud is equivalent to a risk. Further, it was raised whether the data should be stored in the cloud at all, and whether the benefits thereof make up for the risk. Further the group questioned the aggregation of data over time. What can parties learn from the user's cloudstored data over the user's lifetime? Poignantly put, the question was asked "Will I get problems in 10 years time?" With respect to the data types mentioned before, the question was asked whether generally, there is too much data shared.

The primary question asked how cryptography can increase the trust in the system. To gain efficient solutions, the group advocated a "trust-but-verify" approach, which entails that one trusts parties optimistically, yet verifies that they are well behaved. This trust required that data processing goes beyond informed consent.

The group voiced the opinion that the legal system has an important role to play to ensure the privacy of the overall solution. Poignantly, this was put as "Court counters Curiosity". Furthermore, the question was raised whether it should be a human right to have access to cryptography. This discussion is in the context of privacy being supported by human rights and constitutions. Cryptography is a means to ensure privacy protection.

(D) Elicited requirements: The group discussed requirements on the system vis--vis of requirements on cryptographic primitives.

-R5A Simplicity and enhanced user experience.

-R5B Restrictions on retention of the primary data as well as on the retention of derived data.

-R5C Use of sticky policies (privacy policies attached, sticking, to the data) that enable a cross-system tracking of privacy policies, obligations and purposebinding made. The sticky policies should be enforced by cryptography. -R5D Strong purpose-binding throughout, that is, it is specified and enforced what purpose data can be used for. Purpose-binding could be enforced by encryption, e.g., attribute-based encryption with purpose credentials as attributes. -R5E Need for misuse detection.

As cryptography requirements, the group advocated -R5F Encryption of data at rest as minimal requirement, with the key stored on a user's device. -R5G Malleable signatures should be used to allow the discovery of misbehaviour. -R5H The cryptographic primitives employed should yield evidence.

Day 2-Deep Dive on Cryptography: Graph Signatures and Topology Certification

This section summarises the content and discussion for the second day "Deep Dive on Cryptography" workshop on graph signatures and topology certification, as this concept was not covered by the use-cases presented in the workshop. The objective of this second day workshop was in contrast to the first day focus groups not primarily the elicitation of requirements, but rather in addition to giving a short tutorial, the discussion of further possible application scenarios. The workshop contribution set the state illustrating that graphs are indeed a common data structure in computer science, naming examples of -Social network graphs for a Blackhat organisation, -Causality graphs (structured occurrence nets) for criminal investigations, and -Topology graphs of virtualised infrastructures.

It was observed that often in these cases the integrity data substrate and the derived graph is not guaranteed and that the graphs contain confidential or sensitive information. Hence, there is a tension between integrity and confidentiality requirements.

Concretely, these conflicting requirements were illustrated for multi-tenant virtualised infrastructures, in which tenants seek to gain security assurance on the infrastructure while infrastructure providers (and other tenants) want to keep the blueprint of their infrastructure confidential. This problem is aggravated as a tenant's sub-system can be impacted by configuration changes elsewhere in the infrastructure. For instance, a misconfigured VLAN identifier elsewhere could lead to other tenants getting access to a tenant's private network, causing an isolation breach.

Naturally, tenants have little reason to trust the provider's assertions of the secure configuration of the entire infrastructure. They would require evidence for the security assurance based on an independent trust root. Hence, we introduce an auditor as third party, who inspects the low-level configuration of the infrastructure, derives a graph representation, and signs this representation. The signature is done in such a way that the provider can subsequently prove to the tenants that security properties they require are fulfilled. For instance, a tenant A could require that no other tenant has access to A's resources.

A more elaborate version of this scenario was presented in [START_REF] Groß | Efficient certification and zero-knowledge proofs of knowledge on infrastructure topology graphs[END_REF]. Figure 3 depicts the system model for the topology certification. The auditor continuously inspects the low-level configuration and issues multiple signatures for defined time instances. The provider receives all these signatures together with diff-logs on the graph representation. Henceforth, the provider is enables to prove that security properties on the topology are fulfilled for times asked about by the tenants. It was pointed out that the graph signature primitive is generic, as it makes it possible to establish a signature on a graph independent of the question subsequently asked about the graph. The scheme is also expressive, as it can encode statements from arbitrary NP-languages.

Graph Representation of Virtualized Infrastructure

The audience made observations that the graph signature scheme could be used for a variety of scenarios. One proposal made was that graph signatures could be used to prove that the surveillance and investigation of a secret agency has only infiltrated people with k degrees of distance in the social network graph of a designated target, based on a selector. Legal oversight requires such organisations to limit their investigations to a low number of hops from the designated selector. Previously, it was impossible to verify claims that the secret service agency has been compliant with the regulations. However, an independent auditor could derive a social network graph representation on surveillance requests and issue a graph signature, which would in turn enable the secret service agency to prove in zero-knowledge that it was compliant.

The workshop took advantage of diverse discussions that happened in the focus groups and workshop sessions for eliciting requirements for Prismacloud. Experts, coming from different areas and working backgrounds, have discussed opportunities and challenges in regards to enhancing privacy and trust in the cloud throughout the selected use-case scenarios discussions. It was concluded that the main notions to ensure trust are accountability, transparency, verification and authentication. There is a clear need for means, such as crypto tools, for enhancing users' privacy and control especially when dealing in different data types, such as (explicitly and implicitly) disclosed and derived data, in the cloud. Specific considerations are needed for Prismacloud, such as for redaction rules and policies which need to be clearly stated, e.g., in regard to the competence of the redactor and to the awareness of responsibilities associated with redaction, and delegation policies; i.e., delegations of redactions to a third party/specialist needs to fulfil trust requirements set by guidelines, policies, and laws. Privacy enhancing means by cryptography need usable guidelines and suitable interfaces and metaphors to communicate privacy incentives and risks to the users and ensure that a certain level of awareness is reached when using these means. Support from the legal perspective is necessary, e.g. by enforcing the encryption of users' data in the cloud as a requirement for privacy or, as one focus group discussed, even by establishing a human right to access cryptography.

Fig. 1 .

 1 Fig. 1. Malleable signatures for document redaction.

Fig. 2 .

 2 Fig. 2. Malleable signatures for numeric computations.

Fig. 3 .

 3 Fig. 3. System model of the topology certification proposal (from [7]).

https://prismacloud.eu

Acknowledgements: The authors have received funding from the the European Union's Horizon 2020 research and innovation programme under grant agreement No 644962 (Prismacloud project). A special thanks to the workshop participants for their input.