Fatbardh Veseli

Tsvetoslava Vateva-Gurova

Ioannis Krontiris

Kai Rannenberg

Neeraj Suri

Towards a Framework for Benchmarking Privacy-ABC Technologies

Technologies based on attribute-based credentials (Privacy-ABC) enable identity management systems that require minimal disclosure of personal information and provide unlinkability of user's transactions. However, underlying characteristics of and differences between Privacy-ABC technologies are currently not well understood. In this paper, we present our efforts in defining a framework for benchmarking Privacy-ABC technologies, and identifying an extensive set of benchmarking criteria and factors impacting such benchmarks. In addition, we identify important challenges in the adoption of Privacy-ABC technologies, indicating directions for future research.

Introduction

In the digital world, users are often required to authenticate towards service providers in order to use their services. In many interactions with different service providers, users must disclose personally identifying information in order to use these services, resulting in the loss of control over such information, and a direct impact on their privacy. Privacy-enhancing attribute-based credentials (Privacy-ABCs) enable an identity management system that takes into consideration both the privacy interests of the User, and the security requirements of the Service Providers. They eliminate the need for an active participation of the identity service provider during the authentication of the user, and enable minimal disclosure of personal information for authentication purposes. However, despite existence of implementations of such technologies, such as Microsoft's U-Prove [START_REF] Paquin | U-prove Cryptographic Specification v1.1[END_REF] or IBM's Idemix [START_REF] Bichsel | Cryptographic Protocols of the Identity Mixer Library[END_REF], there are additional challenges towards their wider adoption in practice, one of which is the lack of understanding of their differences.

Privacy-ABC technologies are mainly investigated as part of anonymous credential systems. As the underlying technology relies heavily on cryptographic primitives [START_REF] Camenisch | A Signature Scheme with Efficient Protocols[END_REF][START_REF] Brands | Rethinking Public Key Infrastructures and Digital Certificates: Building in Privacy[END_REF], much of the work has been focused on individual aspects, such as efficiency [START_REF] Camenisch | A Signature Scheme with Efficient Protocols[END_REF][START_REF] Vullers | Efficient Selective Disclosure on Smart Cards Using Idemix[END_REF][START_REF] Mostowski | Efficient U-Prove Implementation for Anonymous Credentials on Smart Cards[END_REF][START_REF] Schnorr | Efficient signature generation by smart cards[END_REF][START_REF] Lapon | Performance Analysis of Accumulator-Based Revocation Mechanisms[END_REF][START_REF] Camenisch | Dynamic Accumulators and Application to Efficient Revocation of Anonymous Credentials[END_REF], or support for additional features [START_REF] Belenkiy | P-signatures and Noninteractive Anonymous Credentials[END_REF][START_REF] Li | Universal accumulators with efficient nonmembership proofs[END_REF]. In addition, there are a number of proposed mechanisms for revocation of anonymous credentials, which also need to be benchmarked. An analysis on revocation schemes for PKI is presented in [START_REF] Aarnes | Selecting Revocation Solutions for PKI[END_REF], but it does not take into account the specific aspects of Privacy-ABCs (e.g. privacy features). In this regard, tradeoffs between revocation schemes for anonymous credentials have been analysed in [START_REF] Lapon | Analysis of Revocation Strategies for Anonymous Idemix Credentials[END_REF][START_REF] Lapon | Performance Analysis of Accumulator-Based Revocation Mechanisms[END_REF][START_REF] Camenisch | Dynamic Accumulators and Application to Efficient Revocation of Anonymous Credentials[END_REF]. From a methodological perspective, elicitation of benchmarking criteria in general is studied also in other areas, e.g. on benchmarking security [START_REF] Luna | Benchmarking Cloud Security Level Agreements Using Quantitative Policy Trees[END_REF][START_REF] Luna | Quantitative Assessment of Cloud Security Level Agreements: A Case Study[END_REF][START_REF] Parrend | Security benchmarks of OSGi platforms: toward Hardened OSGi[END_REF], although not particularly focusing on Privacy-ABC technologies. However, there is no comprehensive work on benchmarking Privacy-ABC technologies with a broader perspective covering a wider range of aspects.

In this paper, we provide results of an ongoing work towards a framework for benchmarking Privacy-ABC technologies, identifying an extensive set of criteria covering main aspects of Privacy-ABC technologies. We organise these criteria into four main dimensions and identify relevant factors that could influence the benchmarks. We base our work on the unified architecture, concepts and features of Privacy-ABCs [START_REF] Camenisch | Concepts and Languages for Privacy-Preserving Attribute-Based Authentication[END_REF][START_REF] Camenisch | D2.1 Architecture for Attribute-based Credential Technologies -Version 1. ABC4TRUST -Deliverable to the European Commision[END_REF], and build on both the relevant literature on these technologies, as well as experiences during the deployment of these technologies in real-world pilots [START_REF]ABC4Trust: Abc4trust pilots[END_REF]. Besides for benchmarking Privacy-ABC technologies, this work can also be used as an indicator to the specific challenges and important considerations in their deployment in real life applications. This paper is organized as follows. First we briefly introduce Privacy-ABC technologies. Then we present the proposed framework for benchmarking these technologies, describing also typical factors that may influence benchmarks. Finally, we conclude the paper with a summary of our results, and a discussion on the potential utility of this work, and give future research directions.

Privacy-ABCs -Overview of Features and Concepts

This section gives a very brief introduction on the Privacy-ABC technologies. The interested reader is referred to [START_REF] Camenisch | D2.1 Architecture for Attribute-based Credential Technologies -Version 1. ABC4TRUST -Deliverable to the European Commision[END_REF][START_REF] Camenisch | Concepts and Languages for Privacy-Preserving Attribute-Based Authentication[END_REF], where a comprehensive description of these technologies is provided. Privacy-ABC technologies address the privacy implications of existing identity management schemes, by supporting selective disclosure of identity information, and enabling unlinkability of user's transactions. Through Privacy-ABCs users can be authenticated without being identified due to the anonymous zero-knowledge proofs support.

The architecture of Privacy-ABCs [START_REF] Camenisch | D2.1 Architecture for Attribute-based Credential Technologies -Version 1. ABC4TRUST -Deliverable to the European Commision[END_REF] recognizes the entities: User, Issuer, Verifier, Revocation Authority and Inspector. The User is a central entity mainly interacting with the Issuer to get Privacy-ABC in an issuance protocol, and with the Verifier when accessing services. A Verifier accepts verifiable proofs by the User in forms of presentation tokens, and trusts the proofs generated by the credentials of the User, which are issued by the Issuer. Following the Privacy-ABCs architecture [START_REF] Camenisch | D2.1 Architecture for Attribute-based Credential Technologies -Version 1. ABC4TRUST -Deliverable to the European Commision[END_REF] and the interactions between the entities [START_REF] Camenisch | Concepts and Languages for Privacy-Preserving Attribute-Based Authentication[END_REF], we consider the following stages in the lifecycle of Privacy-ABCs, namely issuance, presentation, inspection, and revocation.

Issuance. During this initial stage of the lifecycle, an Issuer issues a credential to the User. Privacy-ABC technologies support different forms of issuance, also more "advanced" ones e.g., reflecting the relation of a new credential to an existing one. Examples are "carrying-over attributes" or "key binding".

Presentation. In a presentation protocol the User can prove the possession of credentials and disclose certain information to the Verifier using Privacy-ABC. The Verifier sends a presentation policy to the User, specifying the type of proof the User must present. This may include proof of possession of a certain type of credential, disclosure of a subset of attributes, proof of not being revoked, etc., which the User presents in the form of a presentation token to the Verifier. Finally, the Verifier can verify the validity of the presented proof.

Inspection. In scenarios where an identity management system aims at conditionally "anonymous" transactions with conditional accountability, Privacy-ABCs support the optional feature of inspection, which enables revocation of anonymity in exceptional cases, and is performed by a trusted entity, the Inspector. The fact that a particular presentation token may potentially be subject to inspection in the future should be clearly explained to the User in the presentation policy, along with a strict description of the potential reasons that require inspection to take place.

Revocation. Revocation is the last stage in the lifecycle of Privacy-ABCs, invalidating the credential(s). It is a crucial component of an identitiy management system. The reasons for revocation might be scenario-specific, but revocation is considered normally in cases of misuse, lost or compromised credentials or their storage medium, etc. Responsible for revocation is the Revocation Authority, which maintains the list of (in)valid credentials, and disseminates the latest information on this list to the other entities.

Benchmarking Criteria and Impact Factors

We have organised the extensive set of identified benchmarking criteria into four main subsets: Functionality, Efficiency, Security Assurance, and Practical Viability. Each of these subsets represent a separate benchmarking dimension and contains a list of criteria, organised following the lifecycle of Privacy-ABCs, as presented in Figure 1. Furthermore, we identify typical impact factors for the benchmarks related to given criteria, following a user-centered approach.

Functionality

The functionality criteria are mostly qualitative and they aim at benchmarking different Privacy-ABC technologies based on their native support for different features, as well as on the additional factors that could be valuable in practice. Table 1 summarizes the list of criteria which could be used for functionality benchmarking, organised following the Privacy-ABC lifecycle approach. Support for the advanced privacy features of the issuance phase, such as "key binding", or carry-over" (blindly, from another credential), or presentation features, such as pseudonymity, (types of) predicates, inspection, or non-revocation proof, provide basic criteria for benchmarking functionality aspects of different Privacy-ABC technologies. For inspection it is important to recognize whether the technology provides certain features that would minimise the potential for authority abuse by an Inspector, such as four-eyes principle or requiring k out of n inspectors to be present for inspection. Finally, as revocation is usually a challenging aspect of Privacy-ABCs, the support for immediate revocation is a key benchmarking criterion, whereas additional advantage is gained if a revocation scheme enables revocation of the secret key instead of a credential attribute (for instance, to revoke all credentials based on a given key at once).

Efficiency

Privacy-ABC technologies can be built using different cryptographic building blocks, such as signature schemes, encryption, zero-knowledge proofs, commitments, and revocation schemes. Efficiency has been identified as an important factor for Privacy-ABCs already in previous research [START_REF] Camenisch | A Signature Scheme with Efficient Protocols[END_REF][START_REF] Vullers | Efficient Selective Disclosure on Smart Cards Using Idemix[END_REF][START_REF] Mostowski | Efficient U-Prove Implementation for Anonymous Credentials on Smart Cards[END_REF][START_REF] Schnorr | Efficient signature generation by smart cards[END_REF][START_REF] Lapon | Performance Analysis of Accumulator-Based Revocation Mechanisms[END_REF][START_REF] Camenisch | Dynamic Accumulators and Application to Efficient Revocation of Anonymous Credentials[END_REF][START_REF] Li | Universal accumulators with efficient nonmembership proofs[END_REF], as it directly affects the performance of the applications using these technologies, which is a crucial factor for their wider acceptance. In our work, we identify a set of criteria for benchmarking the efficiency, which are mostly quantitative, and organise them in three main aspects, namely into computational, communication and storage efficiency criteria.

Computational efficiency is expressed in time units (in seconds) required to perform a given operation, whereas communication efficiency deals with the data sizes exchanged during different operations. Both efficiency metrics depend on the underlying cryptographic operation that are performed. Table 2 presents the main criteria for benchmarking different Privacy-ABCs on these two metrics, and the most important factors, which influence both of these efficiency aspects along the lifecycle of Privacy-ABCs. The use of advanced features during the issuance and presentation, such as key binding or (type of) predicates, should impact both efficiency figures, as they incurr additional crypto operations. However, the actual impact on on different Privacy-ABC technologies may vary. On top of that, a significant overhead on the presentation efficiency can be the use of inspection, which may also vary depending on the number of inspectable attributes. Finally, revocation has a similar overhead on presentation, which may depend on the type of revocation scheme used. Finally, the security level, which corresponds to the cryptographic key length used, has a direct impact on the efficiency of presentation.

Storage efficiency is important, as storage requirements can have impact on the choice of storage medium for the user. Besides the Privacy-ABCs, a number of other information might need to be stored in practice, such as revocation-related information to credentials, pseudonyms, and other static information about other entities (public key of the issuer, revocation authority, inspector). Hence, it is important to benchmark the different storage requirements of different Privacy-ABC technologies, and the factors impacting it.

Security Assurance

To be able to assess the security assurance provided by a specific Privacy-ABC technology, we propose the usage of security assurance criteria for the different stages of the lifecycle of Privacy-ABCs. The aim of these criteria is to assess the effectiveness of the technology-specific security assurance mechanisms in order to evaluate how the security requirements are met by the respective Privacy-ABC technology. Table 3 presents the security assurance benchmarking criteria we are proposing. As can be seen from the table, security assumptions and security proofs are involved in all the stages of the lifecycle and have to be taken into account. It has to be considered whether the security proofs and assumptions of the issuance protocol and the presentation token, as well as the security proofs and assumptions of the inspection-related and revocation-related mechanisms are information theoretic, computational or without security reduction. In case they are computational, the hardness assumptions have to be described. In each of the lifecycle's stages the underlying security proofs and assumptions have to be listed. In addition, means to assess the security of the conventional mechanisms, which are specifically applied and customized to enhance the security assurance of Privacy-ABCs (e.g. access control mechanisms for the Revocation Information), are necessary; therefore security assurance benchmarks for these mechanisms are to be considered. With regard to Inspection, the security assurance for preventing authority misuse by the person in charge of inspection has to be investigated. It has to be assessed whether the technology supports measures for preventing this, e.g. by applying key sharing mechanisms, where k out of n keys must be combined in order to be able to conduct inspection. Additional security assurance criteria are needed also for the Revocation. The guarantees the the Privacy-ABC technology provides for the protection of integrity and authenticity of the Revocation Information have to be studied and the applied protection mechanisms need to be specified. Moreover, the access restrictions to the Revocation Handles that are posed through the technology have to be analyzed. The different possibilites, e.g. public vs. private access and whether the Revocation Handles are learnt only by the Verfier or also by the Revocation Authority have to be studied.

Practical Viability

Practical viability benchmarking deals with a group of criteria that may inhibit or enable adoption of Privacy-ABC technologies in the ever-more mobile world. These criteria are listed in Table 4 and relate to the workarounds in overcoming potential lack of support for certain Privacy-ABC features, limiting restrictions on the deployment platforms, or challenges in maintaining privacy in potentially unforeseen application requirements. Reissuance of linkable credentials. Certain Privacy-ABC technologies do not provide multiple presentations unlinkability. In case this feature is required, a workaround could be to use Privacy-ABCs only one time, requiring re-issuance of such credentials (before every presentation). In order to overcome potential privacy implications, it is possible to automate the process of issuance by issuing a batch of such credentials at once. However, this approach has not only storage implications for the User, but also the usability impact for the fact that the User needs to engage in additional issuance instances with the Issuer (which also may require the User needs to be online).

Feasibility of smart card deployment. Many scenarios where Privacy-ABCs could be deployed, such as new e-IDs or e-tickets, could benefit from the use of smart cards. Except for storing Privacy-ABCs, it may be useful to be able to perform presentation proofs in the card, which can be challenging, considering the computing power of current smart cards. In addition to that, as smart cards are offline devices, Privacy-ABC technologies must enable offline presentations. This factor is important for the wider acceptance and usability of the Privacy-ABC technologies in such scenarios, as also recognized in the the efforts to efficiently implement them on smart cards [START_REF] Vullers | Efficient Selective Disclosure on Smart Cards Using Idemix[END_REF][START_REF] Mostowski | Efficient U-Prove Implementation for Anonymous Credentials on Smart Cards[END_REF][START_REF] Schnorr | Efficient signature generation by smart cards[END_REF][START_REF] Lapon | Analysis of Revocation Strategies for Anonymous Idemix Credentials[END_REF].

Offline non-revocation proof. Proving non-revocation comes challenging for Privacy-ABCs, as this needs to be done without losing privacy. Schemes that support immediate revocation rely on accumulators [START_REF] Li | Universal accumulators with efficient nonmembership proofs[END_REF][START_REF] Camenisch | Dynamic Accumulators and Application to Efficient Revocation of Anonymous Credentials[END_REF], and this typically involves some overhead on the presentation, who needs to provide an additional proof of not being revoked. This makes the presentation less efficient (longer), but also requires periodical connectivity of the User with the Revocation Authority during the presentation in order to refresh the "evidence" that her credentials are not revoked, limiting the deployability of these technologies on devices with network capabilitiy (making them infeasible such as smart cards). A number of studies in this area show the different overhead distribution of revocation (non-revocation proof) on the presentation [START_REF] Lapon | Analysis of Revocation Strategies for Anonymous Idemix Credentials[END_REF][START_REF] Lapon | Performance Analysis of Accumulator-Based Revocation Mechanisms[END_REF], whereas the importance of non-interactive schemes is obviously acknowledged [START_REF] Camenisch | Dynamic Accumulators and Application to Efficient Revocation of Anonymous Credentials[END_REF].

Conclusion

Privacy-ABC technologies enable user-centric, privacy-preserving identity management. This paper summarizes ongoing work in providing a framework for benchmarking Privacy-ABC technologies, enabling a transparent identification of their differences in terms of functionality, efficiency, security assurance, and practical viability. It identifies a number of challenges in the adoption of these technologies in practice, which can also be used to identify open research directions. Next steps in completing the proposed framework include identifying additional factors that could influence the benchmarks and performing actual benchmarks to evaluate the actual impact of these factors on different Privacy-ABC technologies.

Fig. 1 .

 1 Fig. 1. The organisational structure of the benchmarking criteria

Table 1 .

 1 Functionality benchmarking criteria

	Stage	Functionality Criteria
	Issuance	-Supported advanced issuance features
	Presentation	-Unlinkability of multiple presentations
		-Supported advanced presentation features
	Inspection	-Support for multi-party inspection
	Revocation	-Support for immediate revocation
		-Key-vs. attribute revocation

Table 2 .

 2 Efficiency benchmarking criteria

	Stage	Criteria	Impact Factors
	Issuance	-CCE of issuance	-Number of attributes
			-Use of "advanced" issuance features
	Presentation -CCE of presentation	-Number of credentials proven
			-Use of advanced presentation features
	Inspection -Overhead on presentation -Number of inspectable attributes
	Revocation -Overhead on presentation -Number of revocable credentials
	All stages		-Security level (key size)

Table 3 .

 3 Security assurance benchmarking criteria

	Stage	Criteria
	Inspection	-Preventive measures against authority misuse
	Revocation	-Mechanisms to guaraantee the authenticity and integrity of RI
		-Access to the Revocation Handles
	All stages	-Security proofs and assumptions

Table 4 .

 4 Benchmarking criteria for practical viability

	Stage	Practical Viability Criteria
	Issuance	-Reissuance of linkable credentials
	Presentation	-Feasibility of smart card deployment
	Revocation	-Offline non-revocation proof

The research leading to these results has received funding from the European Communitys Seventh Framework Programme (FP7/2007-2013) under Grant Agreement no. 257782 for the project Attribute-based Credentials for Trust (ABC4Trust).


Dominik Herrmann

Max Maaß

Hannes Federrath

Evaluating the Security of a DNS Query Obfuscation Scheme for Private Web Surfing

The Domain Name System (DNS) does not provide query privacy. Query obfuscation schemes have been proposed to overcome this limitation, but, so far, they have not been evaluated in a realistic setting. In this paper we evaluate the security of a random set range query scheme in a real-world web surfing scenario. We demonstrate that the scheme does not sufficiently obfuscate characteristic query patterns, which can be used by an adversary to determine the visited websites. We also illustrate how to thwart the attack and discuss practical challenges. Our results suggest that previously published evaluations of range queries may give a false sense of the attainable security, because they do not account for any interdependencies between queries.

Introduction

DNS is an integral part of the Internet infrastructure. Unfortunately, it does not offer privacy, i. e., the so-called resolvers (recursive nameservers) can see all queries sent to them in the clear. Resolvers can learn about users' habits and interests, which may infringe their privacy if the resolver is not run by a trusted party, but by a third party such as Google, whose resolver 8.8.8.8 serves more than 130 billion queries per day on average [11]. The discussions about limiting tracking via cookies spurred by the "Do not track" initiative may result in DNS queries becoming the next target for tracking and profiling purposes [START_REF] Conrad | Towards Improving DNS Security, Stability, and Resiliency[END_REF]. According to [START_REF] Herrmann | Behavior-based Tracking: Exploiting Characteristic Patterns in DNS Traffic[END_REF] behavior-based tracking based on DNS queries may be feasible.

Integrating mechanisms for confidentiality into DNS is difficult because of the need for compatibility with existing infrastructure. Fundamental changes to the protocol are implemented very slowly, as previous attempts have shown: Although the initial DNSSEC security extensions have been proposed in 1999 [START_REF] Eastlake | Domain Name System Security Extensions[END_REF], the majority of users still can not profit from their benefits today. Unfortunately, DNSSEC does not address privacy issues due to an explicit design decision [START_REF] Arends | DNS Security Introduction and Requirements[END_REF].

Currently, there is no indication that facilities for privacy-preserving resolution will be integrated into the DNS architecture in the short term. Previous research efforts have focused on interim solutions, i. e., add-ons and tools that enable users who care for privacy to protect themselves against profiling and tracking efforts. The objective consists in designing and evaluating suitable privacy enhancing techniques in such a way that users do not have to rely on or trust the existing DNS infrastructure. The "range query" scheme by Zhao et al. [START_REF] Zhao | Analysis of Privacy Disclosure in DNS Query[END_REF] is one of those efforts. The basic idea consists in query obfuscation, i. e., sending a set of dummy queries (hence the term "range") with random hostnames along with the actual DNS query to the resolver.

So far the security of range query schemes has only been analyzed within a simplistic theoretical model that considers the obtainable security for singular queries. In this paper we study the security offered by range queries for a more complex real-world application, namely web surfing, which is one of the use cases Zhao et al. envision in [START_REF] Zhao | Analysis of Privacy Disclosure in DNS Query[END_REF]. In contrast to singular queries, downloading websites typically entails a number of inter-related DNS queries. Our results indicate that the range query scheme offers less protection than expected in this scenario, because dependencies between consecutive queries are neglected.

The main contribution of this paper is to demonstrate that random set range queries offer considerably less protection than expected in the web surfing use case. We demonstrate that a curious resolver (the adversary) can launch a semantic intersection attack to disclose the actually retrieved website with high probability. We also show how the effectiveness of the attack can be reduced, and we identify a number of challenges that have to be addressed before range query schemes are suitable for practice.

The paper is structured as follows. In Sects. 2 and 3 we review existing work and fundamentals. Having described our dataset in Sect. 4, we continue with theoretical and empirical analyses in Sects. 5 and 6. We study countermeasures in Sect. 7 and discuss our results in Sect. 8. We conclude in Sect. 9.

Related Work

The basic DNS range query scheme was introduced by Zhao et al. in [START_REF] Zhao | Analysis of Privacy Disclosure in DNS Query[END_REF]; there is also an improved version [START_REF] Zhao | Two-Servers PIR Based DNS Query Scheme with Privacy-Preserving[END_REF] inspired by private information retrieval [START_REF] Chor | Private Information Retrieval[END_REF]. Although the authors suggest their schemes especially for web surfing applications, they fail to demonstrate their practicability using empirical results.

Castillo-Perez and Garcia-Alfaro propose a variation of the original range query scheme [START_REF] Zhao | Analysis of Privacy Disclosure in DNS Query[END_REF] using multiple DNS resolvers in parallel [START_REF] Castillo-Perez | Anonymous Resolution of DNS Queries[END_REF][START_REF] Castillo-Perez | Evaluation of Two Privacy-Preserving Protocols for the DNS[END_REF]. They evaluate its performance for ENUM and ONS, two protocols that store data within the DNS infrastructure. Finally, Lu and Tsudik propose PPDNS [START_REF] Lu | Towards Plugging Privacy Leaks in the Domain Name System[END_REF], a privacypreserving resolution service that relies on CoDoNs [START_REF] Ramasubramanian | The Design and Implementation of a Next Generation Name Service for the Internet[END_REF], a next-generation DNS system based on distributed hashtables and a peer-to-peer infrastructure, which has not been widely adopted so far.

The aforementioned publications study the security of range queries for singular queries issued independently from each other. In contrast, [START_REF] Federrath | Privacy-Preserving DNS: Analysis of Broadcast, Range Queries and Mix-Based Protection Methods[END_REF] observes that consecutively issued queries that are dependent on each other have implications for security. They describe a timing attack that allows an adversary to determine the actually desired website and show that consecutive queries have to be serialized in order to prevent the attack.

Fundamentals

Random Set DNS Range Query Scheme

In this paper we focus on the basic "random set" DNS range query scheme as introduced in [START_REF] Zhao | Analysis of Privacy Disclosure in DNS Query[END_REF]. Zhao et al. stipulate that each client is equipped with a large database of valid domain names (dummy database). Each time the client wants to issue a DNS query to a resolver, it randomly draws (without replacement) N -1 dummy names from the database, and sends N queries to the resolver in total. When all replies have been received from the resolver, the replies for the dummy queries are discarded and the desired reply is presented to the application that issued the query.

Zhao et al. claim that this strategy leaves the adversary with a chance of 1 N to guess the desired domain name. The value of N is a security parameter, which is supposed to be chosen according to the user's privacy expectations and performance needs.

Query Patterns

The semantic intersection attack exploits the fact that typical websites embed content from multiple servers, causing clients to issue a burst of queries for various domain names in a deterministic fashion, whenever they visit the site. For example, visiting google.com will also trigger a DNS request for ssl.gstatic.com, as the site includes some resources from that domain. We call the set of domain names that can be observed upon visiting a site its query pattern p, i. e., p(google.com) = {google.com, ssl.gstatic.com}. In Sect. 4, we will show that many popular websites do have query patterns that can be used for this attack. Using range queries, each individual query from a pattern p is hidden in a set of N -1 randomly chosen queries, leading to |p| sets, each containing N queries, being sent to the resolver in order to retrieve all the domain names required to visit the corresponding website. We refer to N as the block size of the range query scheme and to each individual range query as a block.

Note that the client uses standard DNS queries to deliver the range query, because it uses a conventional DNS resolver, i. e., a single range query with a block size of N causes N individual DNS queries.

The Semantic Intersection Attack

An adversary, who is in possession of a database that contains the query patterns for a set of websites he is interested in (pattern database), can check whether one of these patterns can be matched to consecutive query blocks received by the client. As all the dummy names are drawn independently from each other from the dummy database, it is quite unlikely that the client will draw the pattern of a different website by chance. Therefore, the adversary can be optimistic that he will only find a single pattern in the set of consecutive range queries he receives from the client, i. e., the pattern of the actually desired website. From the viewpoint of the adversary there are two different scenarios, depending on how well the adversary can distinguish consecutive blocks (cf. Fig. 1). The adversary may either be able to identify all the queries that belong to the first block, but be unable to determine which of the remaining queries belongs to which of the remaining blocks (1BD, 1st block distinguishable), or be able to distinguish all individual blocks, i. e., be able to determine for all queries to which block they belong (ABD, all blocks distinguishable). The difference between the 1BD and the ABD scenario becomes evident by considering the following example. When a user visits the site http:// www.rapecrisis.org.uk , her browser will issue a query for www.rapecrisis.org.uk. Moreover, it will issue two additional queries, for twitter.com and www.rapecrisislondon.org, once the HTML page has been parsed. For illustrative purposes we assume that range queries with N = 3 are used. In the ABD scenario the adversary might, for instance, observe a first block of queries for (cnn.com, www.rapecrisis.org.uk, img.feedpress.it), then a second block for (github.com, twitter.com, s.ebay.de), and finally a third block for (www.rapecrisislondon.org, ytimg.com, conn.skype.com). In contrast, in the 1BD scenario the adversary might observe a first block with (cnn.com, www.rapecrisis.org.uk, img.feedpress.it) and a second block with (github.com, twitter.com, www.rapecrisislondon.org, s.ebay.de, ytimg.com, conn.skype.com).

The first block is distinguishable in both scenarios, because the web browser has to resolve the primary domain name in order to learn the IP address of the main web server. This IP address is received within the replies that belong to the first block of queries. After the browser has downloaded the HTML file from the main web server, it will issue queries for the secondary domain names in order to retrieve all embedded content hosted on other web servers.

Given a pattern database DB that contains primary and secondary domain names of websites, the adversary proceeds as follows in order to carry out the intersection attack in the ABD scenario:

1. From DB the adversary selects all patterns, whose primary domain name is contained in the first block, obtaining the set of candidates C. 2. The adversary selects all patterns with length |p|, which is the number of observed blocks, from C to obtain C |p| . 3. For each pattern q in C |p| the adversary performs a block-wise set intersection: q is a matching pattern, if all of its domain names are dispersed among the blocks in a plausible fashion, i. e., iff (a) each block contains at least 1 element from q, and (b) each element of q is contained in at least 1 block, and (c) q can be completely assembled by drawing one element from each block.

In the 1BD scenario the adversary has to use a different approach, because there are only two blocks observable:

1. From the pattern database the adversary selects all patterns, whose primary domain name is contained in the first block, thus obtaining the set of candidate patterns C. 2. For each pattern q in C the adversary performs a block-wise set intersection:

q is a matching pattern, if all of its secondary domain names are contained within the second block.

Note that due to caching, the adversary cannot reliably determine |p| in the 1BD scenario. Due to variations in the lookup time of different domain names, the stub resolver on the client may already receive replies (and cache the results) for some domain names before all range queries have been submitted to the resolver. However, if the range query client happens to draw one of the cached domain names as a dummy, the stub resolver will not send another query, but answer it immediately from its cache. As a result, some queries will not reach the adversary and the effective size of consecutive blocks will vary. Therefore, the adversary cannot easily determine |p| in the 1BD scenario in order to filter the set C. For now, we neglect the fact that caching may also affect the desired queries (cf. Sect. 8 for a discussion of this issue).

In the remainder of the paper we focus on the 1BD scenario, which we deem to be more realistic than the ABD scenario. Contemporary web browsers issue the queries for the secondary queries in parallel. Thus, when the range query client constructs range queries for each of the desired domain names, the individual queries of all the blocks will be interleaved, causing uncertainty about the composition of the individual blocks. On the other hand, the ABD scenario is relevant for range query schemes that submit all queries contained in a block in a single message. We will consider the effect of this approach in Sect. 6.4.

Dataset

In order to evaluate the feasibility of the semantic intersection attack, we performed probabilistic analyses and implemented a simulator that applies the attack to the patterns of actual websites. For this purpose we obtained the query patterns of the top 100,000 websites of the "Alexa Toplist" (http: //www.alexa.com) with the headless Webkit-based browser PhantomJS (http: //phantomjs.org). 1 As PhantomJS was not able to reach and retrieve all of the websites contained in the Toplist at the time of the data collection (May 2013) The average pattern length (mean value) is 13.02 with a standard deviation of 14.28. The distribution of pattern lengths as displayed in Fig. 2 shows that, while patterns of the length 1 are frequent, patterns of higher lengths make up the majority of the dataset. The longest pattern consists of 315 queries.

Probabilistic Analysis

Before we carry out any practical evaluation using our simulator, we want to get an expectation of the likelihood of ambiguous results, which occur if the client happens to draw all the domain names of another website from the dummy database while the range queries needed for the desired website are assembled. If the client draws all domain names of a different pattern by chance and distributes the individual names among the blocks in a plausible fashion, the adversary will observe two patterns: the pattern of the actually desired website as well as the random pattern.

Modeling the Probability of Ambiguous Results

In the 1BD scenario an ambiguous result occurs if the primary domain name of a random pattern (the domain name of the corresponding website) is selected as a dummy in the first block, and all remaining elements of the pattern are contained in the union of the remaining blocks. 2 The probability for an ambiguous result can be modeled as a series of hypergeometric distributions. A hypergeometric distribution h(k|N ; M ; n) describes the probability of drawing k elements with a specific property when drawing n elements out of a group of N elements, of which M have the desired property:

h(k|N ; M ; n) := M k N -M n-k N n (1)
First, we need to obtain the probability to draw the first element of a pattern of the correct length n into the first block of queries. As the variables of the hypergeometric distribution overlap with those we use to describe the properties of a range query, we substitute them for their equivalents in our range query notation. N is equal to |Q|, the number of names in the dummy database. M equals to the number of patterns of the correct length, which we will write as |P n |. In our case, the parameter n of the hypergeometric distribution corresponds to N -1, as we will draw N -1 dummy names into the first block. By substituting these values into Eq. 1, we obtain the probability p(n, k) of drawing exactly k beginnings of patterns of the length n:

p(n, k) := |Pn| k |Q|-|Pn| (N -1)-k |Q| N -1 (2)
In addition to that, we need to determine the probability of drawing the remaining k * (n -1) queries into the second block, which contains the remaining (n-1) * (N -1) randomly drawn dummy names in the 1BD scenario. To complete our k patterns, we need to draw k * (n-1) specific dummy names. The probability of success is described by the function q(n, k), which is given in Eq. 3.

q(n, k) := n-1 n-1 k |Q|-(n-1) * k (n-1) * (N -1)-(n-1) |Q| (n-1) * (N -1) = |Q|-(n-1) * k (n-1) * (N -1)-(n-1) * k |Q| (n-1) * (N -1) (3)
The two probabilities p(n, k) and q(n, k) can now be combined to receive the probability of drawing k complete patterns of the correct length n:

P (n, k) := p(n, * q(n, k) (4)
In this context, the expected value of P (n, k) for different values of n is of interest, as it describes the average number of patterns we expect to see. The expected value, in general, is defined as:

E(X) := i∈I (x i p i ) (5)
In our case, x 1 is k, as it describes the number of patterns, and p i equals P (n, k) as the probability of drawing k patterns, i. e., the expected value is

E(n) := 1 + N -1 k=1 (P (n, k) * k) (6)
We are adding 1 to the result, as the original pattern will always be present. Equation 6 will only calculate the expected value for patterns of a specific length. However, as the adversary does not know the length of the pattern with certainty in the 1BD scenario, we have to consider patterns of any length. For that, we have to use a modified variant of Eq. 3:

q(n, k, M ) := |Q|-(n-1) * k (M -1) * (N -1)-(n-1) * k |Q| (M -1) * (N -1) (7)
In Eq. 7, n is the length of the random pattern, while M is the length of the original pattern. Accordingly, we modify Eq. 4 and Eq. 6:

P (n, k, M ) := p(n, k) * q(n, k, M ) (8)
E(M ) := 1 + M n=1 N -1 k=1 (P (n, k, M ) * k) (9)
Finally, to determine the expected mean value of the number of detected patterns given a specific block size N , we calculate

F (N ) = 1 |P | * L M =1 (E(M ) * |P M |) (10)
where L is the length of the longest pattern, and |P M | the number of patterns having length M .

Analytical Result

The results (cf. Table 1) indicate that an adversary will, on average, detect only very few random patterns. As expected, the privacy expectation for singular queries ( 1 N ) does not apply to the web surfing scenario. Note that for reasons of conciseness we have provided a slightly simplified model, which disregards overlaps between patterns. Actually, the adversary must expect to find a slightly higher number of patterns, because a domain name that is contained within multiple patterns has to be drawn only once to be detected as part of all patterns. Nevertheless, the analysis is instructive and provides us with a baseline for the empirical evaluations that we will describe in the following.

Evaluation

In order to evaluate the effectiveness of the semantic intersection attack in a realistic scenario, we developed a simulator that enables us to efficiently test different attack strategies and various assumptions about the knowledge of the adversary. In the following we present results for the 1BD scenario.

Methodology Given a dataset the simulator will generate range queries for all the patterns from the dataset and perform the semantic intersection attack. We are interested in the influence of two factors on the effectiveness of the attack, namely the block size N , and the size of the dummy database |Q| that contains the dummy names. If the range query scheme was to be used in practice, these two factors could be easily influenced by the user. Thus, it is worthwhile to analyze their effect on the attainable privacy.

In the following, we will use the metric of k-identifiability, which is derived from the well-known metric k-anonymity [START_REF] Sweeney | k-Anonymity: A Model for Protecting Privacy[END_REF]: A set of consecutively observed range queries is said to be k-identifiable, if the adversary finds exactly k matching patterns of websites in his pattern database. For conciseness we will show the cumulative distribution of the fraction of k-identifiable patterns, i. e., the fraction of patterns that are k-identifiable or less than k-identifiable.

Results of Experiment 1: Variation of Block Size

For the purpose of this analysis, we consider three different block sizes: N = 10, N = 50, and N = 100. [START_REF] Federrath | Privacy-Preserving DNS: Analysis of Broadcast, Range Queries and Mix-Based Protection Methods[END_REF] has shown that the median latency exceeds 1200 ms for a block size of N = 100, rendering higher values impractical for practical use.

Based on the result of Sect. 5, we expect to receive some, but not many ambiguous results, i. e., instances where the whole pattern of a different website appears in a set of consecutively observed range queries by chance. Intuitively, the larger the block size, the more random patterns will occur. Accordingly, we expect the effectiveness of the attack to degrade with increasing block sizes.

As can be seen in Table 2 and Fig. 3, the smallest block size provides little privacy, with 62 % of patterns being 1-identifiable. Consequently, the median of the observed k-identifiability values is 1. 99 % of patterns are 5-identifiable or better. No pattern is more than 6-identifiable. For a larger block size of N = 50, only 8 % of patterns are 1-identifiable, but the cumulative distribution quickly approaches 100 %. All patterns are 14-identifiable or less, and the median of all observed k-identifiability values is 3, i. e., for 50 % of the websites the adversary can narrow down the actually desired site to a set of 3 or less sites, which is far smaller than the baseline probability of 1 50 for finding the desired domain name in the first block. As expected, N = 100 is most effective: 0.8 % of patterns are 1-identifiable, but still 43 % of patterns are at most 5-identifiable.

Generally, we can observe diminishing returns when the block size is increased. While the increase from N = 10 to 50 leads to 54 % less 1-identifiable patterns, adding another 50 queries per block only decreases the fraction by 7.2 percentage points. The same is true for the maximum k-identifiability, which increases by eight and four, respectively. On overall, the results indicate that range queries provide far less privacy than suggested by Zhao et al. in the web surfing scenario.

1BD-improved We also considered an improved attack algorithm that guesses the length of the desired patterns based on the total number of observed queries in the second block, resulting in a range of possible pattern lengths. This allows the adversary to reject all patterns that do not fall into this range. As a result 80 % (N = 100) and 94 % (N = 10) of all patterns are 1-identifiable. Due to space constraints, we are unable to adequately cover the calculations to estimate the length in this paper, but we have released an implementation including the relevant documentation in the source code repository (see Footnote 1).

Results of Experiment 2: Variation of Dummy Database

Generating and maintaining a dummy database is a non-trivial task for the client, which gets harder the larger the database is supposed to be. Accordingly, the importance of the size of the dummy database is of interest. We assume that the client's dummy database is always a subset of the pattern database of the adversary, because, in general, the adversary will have access to more resources than the client, and collecting patterns scales very well.

We compare the effectiveness of three different database sizes (S = 2000, 20,000 and 200,000). The domain names are chosen by drawing patterns from the full pattern database (without replacement) and adding all domain names of each pattern to the dummy database. This process continues until exactly S unique domain names have been found. We select full patterns to increase the chance that the client randomly chooses a full pattern when drawing dummies. We used a fixed block size of N = 50 for this experiment. Fig. 4 shows that the differences are quite small on overall. Thus, the biggest effect of varying the database is the change in the percentage of 1-identifiable patterns: The percentage of 1-identifiable patterns drops by three percentage points when the dummy database size is increased from S = 2000 to S = 20,000, and by another 7 points on the second increase to S = 200,000. The observed changes have a much smaller effect than the variation of the block size; however, regardless of these results, a larger database is always desirable to prevent other attacks, such as the enumeration of the client's database.

Effect of Pattern Length on Site Identifiability

Now that we know the effect of varying the block size, the composition of the different k-identifiabilities is of interest. With this information, we can determine whether websites with longer or shorter patterns are more at risk to be identified. Intuitively, shorter patterns should generally have lower k-identifiabilities, as comparatively few dummies are drawn to obfuscate them, decreasing the chance of drawing a whole pattern. Conversely, longer patterns should generally achieve higher k-identifiabilities, as they use a higher number of dummy domain names. We will now test this hypothesis by analyzing the composition of the different k-identifiabilities, using the results of our simulation with a block size of N = 50 and the full dummy database (S = 216,925). As can be seen in Table 4, the mean pattern length rises almost linearly with increasing k-identifiability, which supports our hypothesis. The standard deviation exhibits a similar behavior, albeit with a slightly lower and less uniform growth rate. We could reproduce this result for other block and database sizes. The correlation is more distinct for larger block sizes. Smaller block sizes do not show this behavior as clearly, as the range of k-identifiabilities is too small to show any distinct trend.

Results of Experiment 3: ABD Scenario

So far, we concentrated on the 1BD scenario (cf. Sect. 3.3). We will now consider the ABD scenario by repeating the experiment from Sect. 6.1, simulating an adversary that can distinguish individual blocks: In the ABD scenario the adversary is able to 1-identify between 87 % (N = 100) and 97 % (N = 10) of all domain names, vastly improving on the results of 1BD (1 % and 62 %, respectively).

The increased accuracy is due to two effects: Firstly, in the ABD scenario the adversary can derive |p|, the length of the obfuscated pattern, and filter the set of candidate patterns accordingly (cf. Sect. 3.3). Secondly, the probability that another matching pattern is drawn from the dummy database by chance is much smaller when it has to meet the three ABD conditions.

The contribution of these two effects to the overall effectiveness obtained for ABD can be analyzed by reviewing the results obtained for the baseline (1BD) in comparison to 1BD-improved (cf. Sect.6.1) and ABD: The results for 1BD-improved, which filters candidate patterns using a vague estimation of |p|, already show a significant increase: For N = 50 the fraction of 1-identifiable sites is 83 % for 1BD-improved, while it is only 8 % for 1BD. On the other hand, the fraction of 1-identifiable websites obtained for ABD, where matching patterns have to meet the additional conditions and the exact value of |p| is known, rises only by another 6 percentage points (reaching 89 %) compared to 1BD-improved.

While this sort of analysis can not conclusively prove that the effect of filtering by length is larger than the effect of filtering via the ABD conditions, we note that the additional benefit of these conditions is comparatively small when the adversary can estimate the length of the obfuscated pattern.

This result indicates that range query schemes that are supposed to provide privacy in a web surfing scenario have to be devised and implemented in a way that the adversary cannot infer the length of the obfuscated query pattern.

Countermeasures

Having shown the weaknesses of the range query scheme against a pattern-based attack strategy, we will now discuss possible countermeasures. First, we will discuss and evaluate a pattern-based dummy selection strategy. Afterwards, we will consider other strategies that could be used to hinder the adversary.

Pattern-Based Dummy Selection Strategy

In the original dummy selection strategy, the client sampled the dummies independently and randomly from his dummy database. In contrast, the client will now draw whole patterns from his database. When querying the resolver for a desired pattern, the client will draw N -1 random patterns of the same length and use them as dummies. If not enough patterns of the correct length are available, the client will combine two shorter patterns to obtain a concatenated pattern with the correct length. Intuitively, this approach ensures that the adversary will always detect N patterns. The results of our evaluation, shown in Table 5, confirm this conjecture. All patterns are exactly N -identifiable. However, in real-world usage scenarios, the length of the pattern the client is about to query cannot be known in advance. As the dummies for the first element of the pattern have to be chosen before the query can be sent, the client has no way to be sure of the pattern length of the desired website, as these values may change over time when a website changes. This leads to uncertainty about the correct length of the dummy patterns. A wrong choice of pattern length may be used by the adversary to identify the original pattern. Future research could study more sophisticated dummy selection strategies, drawing from experience gained in the field of obfuscated web search [START_REF] Balsa | OB-PWS: Obfuscation-Based Private Web Search[END_REF].

Other Countermeasures

As described in the previous section the pattern-based dummy selection strategy is subject to practical limitations. We will briefly cover other countermeasures that may be used to improve the privacy of clients. This list is not exhaustive.

The first option is to use a variable value for N that changes on each block. This will raise the difficulty of determining the length of the original pattern, as long as the adversary cannot distinguish individual blocks. This change would render 1BD-improved useless, as it depends on a fixed number of chosen dummies per block (although similar optimizations could be found that would still improve on the performance of the trivial algorithm). However, this would not impact the performance of the ABD algorithm, as it does not rely on uniform block sizes.

Another improvement that may make the pattern-based strategy more feasible would be to round up the length of the target pattern to the next multiple of a number x > 1. The additional queries ("padding") could be chosen randomly, or by choosing patterns of the correct length.

Finally, other privacy-enhancing techniques, such as mixes and onion routing [START_REF] Chaum | Untraceable electronic mail, return addresses, and digital pseudonyms[END_REF][START_REF] Dingledine | Tor: The Second-Generation Onion Router[END_REF], can be employed to counter monitoring and tracking efforts. However, these general-purpose solutions are not specifically designed for privacy-preserving DNS resolution and may introduce significant delays into the resolution process.

Discussion

We designed our experimental setup to stick as closely as possible to reality. However, for reasons of conciseness and clarity we have neglected some effects. In the following we will discuss whether they affect the validity of our conclusions.

Firstly, the results are implicitly biased due to a closed-world assumption, i. e., our results have been obtained on a dataset of limited size. However, as the Toplist of Alexa contains a large variety of websites we are confident that the results are valid for a large fraction of sites in general. Moreover, we have only evaluated the effectiveness of the attack for the home pages; the evaluation of the attack on individual sub-pages is left for future work.

Secondly, while we considered the effects of caching of dummy queries in the 1BD scenario, we disregarded caching of the desired queries: The client may still have (parts of) a pattern in his local cache, resulting in incomplete patterns being sent to the resolver. However, the adversary may adapt to caching by remembering the TTL of all responses he sent to a client and matching the patterns against the union of the received domain names and the cached entries.

Moreover, an adversary who wants to determine all websites a user visits needs the patterns of all websites on the Internet. Such a database would be non-trivial to generate and maintain. However, a reactive adversary may visit any domain name he receives a query for and store the pattern for that domain name in its pattern database, making a slightly delayed identification possible.

Finally, we disregarded changing patterns as well as DNS prefetching techniques, which cause longer and more volatile patterns. However, a determined adversary will have no problems in addressing these issues.

Conclusion

We demonstrated that random set range queries offer considerably less protection than expected in the use case of web surfing. Our attack exploits characteristic query patterns, which lead to greatly reduced query privacy compared to the estimations made by Zhao et al. in their original work. Moreover, we proposed and evaluated an improved range query scheme using query patterns to disguise the original pattern. We encourage researchers to consider the effects of semantic interdependencies between queries when designing new schemes for query privacy, as the rising pervasiveness of social networking buttons, advertising and analytics makes singular queries less and less common for web surfing.

5 Fig. 1 .

 51 Fig. 1. Distinguishability of blocks for the resolver

Fig. 2 .

 2 Fig. 2. Histogram and cumulative distribution of pattern lengths

Fig. 3 .

 3 Fig. 3. Distribution of k-identifiability for varying block sizes N (whole database)

Fig. 4 .

 4 Fig. 4. Distribution of k-identifiability for varying dummy database sizes S; N = 50

Table 1 .

 1 Expected avg. number of detected patterns F (N ) for varying block sizes N

	N	10	50	100
	F (N )	1.35	2.93	4.83

Table 2 .

 2 Results for varying block sizes N given the whole dummy database

	N	S	1-identifiable	≤ 5-identifiable	median(k)	max(k)
	10	216,925		62 %		99 %	1	6
	50	216,925		8 %		88 %	3	14
	100	216,925		1 %		43 %	6	18
			1
		Cumulative fraction of patterns	0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9	1	10	N10 N50 N100	100
					k

Table 3 .

 3 Results for varying dummy database sizes S given the block size N = 50

	N	S	1-identifiable	≤ 5-identifiable	median(k)	max(k)
	50	2,000	19 %	92 %	3	14
	50	20,000	16 %	95 %	3	11
	50	200,000	9 %	88 %	3	13

Table 4 .

 4 Number of patterns n k , mean length |p| and standard deviation SD aggregated by resulting k-identifiability (N = 50, S = 216,925)

	k	1	2	3	4	5	6	7	8	9 ≥ 10
	n k 7,693 18,790 23,184 19,784 12,497 6,532 2,875 1,077	336	121
	|p| 10.59	11.43	12.52	13.54	14.43 15.45 16.22 17.65 17.09 19.47
	SD 12.16	13.24	13.65	14.55	15.02 16.14 16.65 17.71 15.35 19.68

Table 5 .

 5 Statistics for varying block sizes N using the pattern-based dummy construction strategy

	N	S	1-identifiable	≤ 5-identifiable	median(k)	max(k)
	10	216,925	0 %	0 %	10	10
	50	216,925	0 %	0 %	50	50
	100	216,925	0 %	0 %	100	100

This paper is based on the BSc thesis[START_REF] Maaß | Schnittmengenangriffe auf DNS Range Queries[END_REF] of the second author.

The source code of our crawler and simulator as well as all experimental data is available at https://github.com/Semantic-IA

In the 1BD scenario the query distribution between the remaining blocks is irrelevant, as long as all needed queries occur at least once in the union of the blocks.


Gabriela Varona Cervantes

Stefan Fenz
email: stefan.fenz@tuwien.ac.at

How to assess confidentiality requirements of corporate assets?

Confidentiality is an important property that organizations relying on information technology have to preserve. The purpose of this work is to provide a structured approach for identifying confidentiality requirements. A key step in the information security risk management process is the determination of the impact level arisen from a loss of confidentiality, integrity or availability. We deal here with impact level determination regarding confidentiality by proposing a method to calculate impact levels based on the different kind of consequences typically arisen from threats. The proposed approach assesses the impact arisen from confidentiality losses on different areas separately and uses a parameterized model that allows organizations to adjust it according to their specific needs. A validation of the developed approach has been conducted in a small software development company.

Introduction

Nowadays Information Technology (IT) plays a crucial role in society. Organizations depend on it to successfully carry out their business missions and functions. In our interconnected and digitized world, confidentiality becomes an important asset to preserve for companies and individuals. The National Institute of Standards and Technology (NIST) defines confidentiality as "preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information."

Companies typically have information that should kept secret in order to maintain their business' competitive advantage. Confidentiality requirements must be incorporated in the business processes of a company, along with the implementation of the corresponding security measurements. The 2013 edition of the biennial information security breaches survey carried out by Infosecurity Europe in UK (Department for business innovation and skills, United Kingdom, 2013), has confirmed the upward trend in the number of security breaches affecting UK businesses. Affected companies experienced on average roughly 50% more breaches than a year ago. The number of organizations critically depending on externally hosted services has slightly increased since the last survey. Increasing numbers of companies are now storing confi-dential or highly confidential data on the cloud, which makes confidentiality compliance more complex. 10% of respondent companies had their worst security incident related with the theft or unauthorized disclosure of confidential information, the majority of which had a serious impact for the organization.

In information security risk management (ISRM), IT managers have to identify and evaluate possible risks before deciding what security measures to implement. In this process, a balance has to be found between the impact of potential breaches and the operational and economic costs of protective measures. Regarding confidentiality, it is important to accurately define confidentiality requirements on data, resources and business processes. While no restrictions can cause confidential information leaks, setting everything as confidential will complicate the processes and result in higher economic costs for the company. Therefore, the research question of this paper is: How can confidentiality requirements be determined for corporate assets?

Our work approaches confidentiality determination by proposing a structured method for companies to determine their resources' confidentiality. In this paper we present our developed approach on confidentiality determination and validate it in the context of a small software development company.

Related work

Related work includes business process-based approaches (cf. (Accorsi et al., 2011a), (Accorsi et al., 2011b), [START_REF] Accorsi | Automatic information flow analysis of business process models[END_REF], [START_REF] Fenz | Business process-based resource importance determination[END_REF], (Lehmann et al., 2012), [START_REF] Lehmann | Modeling wizard for confidential business processes[END_REF], and [START_REF] Lohmann | Petri net transformations for business processes-a survey[END_REF]) and confidentiality determination methods implemented as part of different risk assessment methods (e.g., NIST (Barker et al., 2008a)

Potential impacts

Definitions

Low

The potential impact is low if-The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals (e.g., minor damage to organizational assets). Moderate The potential impact is moderate if-The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals (e.g., significant financial loss).

High

The potential impact is high if-The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals (e.g., severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries).

Table 1. Potential impact levels by FIPS 199

In Magerit's (Spanish Ministry for Public Administrations, 2006) terminology, confidentiality, availability and integrity, together with authenticity are dimensions of an asset that together determine its value. Furthermore, the "valuation of an asset in a certain dimension is the measurement of the prejudice the organization may suffer if the asset is damaged in that dimension", i.e. the impact level. For valuation of assets a scale of 10 values is used. Criteria to value the assets consider adverse consequences in the following aspects: the security of persons, personal information, obligations arising from the law, capacity for following up offences, commercial and financial interests, interruption of the service, public order, corporate policy, and other intangible values. As a result from the valuation process, assets are assigned one of four confidentiality labels: secret, confidential, restricted or unclassified. Magerit's risk analysis process takes into account dependencies between assets when calculating the security impact.

Mehari (CLUSIF, 2010) uses a four-value scale to measure the impact level should a security breach occur: Level 4 -Vital: existence and survival of the entity is in danger. Level 3 -Very Serious: The impact is considered very serious at the level of the entity, although its future would not be at risk. Level 2 -Serious: Malfunctions at this level would have a clear impact on the entity's operations, results or image, but are globally manageable. Level 1 -Not significant: At this level, any resulting damage would have no significant impact on the results or image of the entity.

Confidentiality impact level determination

Confidentiality determination refers to how restricted access to a certain resource must be in order to preserve its confidentiality. It can be expressed as a meaningful label or category. How to combine this categorization with other risk information and translate it to security measures is subject of another part of the risk management process. As mentioned earlier, the confidentiality label that must be assigned to an asset depends directly on the impact if the asset's confidentiality is compromised. This impact should be assessed independently of the implemented security measures and not with respect to any particular threat. Instead, the overall impact for the organization in case the asset is publicly available should be considered. Consider for instance a company that keeps a file containing the details of a planned advertising campaign of which only the marketing team and the managers are aware. The file disclosure by other staff members would probably have a negligible impact for the company, while its disclosure by competitors could reduce the effectiveness of the campaign and negatively affect the company. The confidentiality of such a file should be then determined by the higher potential impact resulting from any possible situation.

In general, adverse impact is related to a degradation of the following:

 Laws and regulations compliance  Commercial and financial interests  Company's reputation  Privacy and security of individuals Note that they are not independent from each other and are interrelated in a causeeffect manner. Thus, a compromise to the privacy of individuals may affect the company's reputation and directly lead to a noncompliance with the law, which in turn may cause the company to be fined and affect financial interests. Nevertheless this relation may sometimes be difficult to determine and so the approach we propose evaluates each factor independently.

Furthermore, organizations may find damage to some of the above mentioned factors to have a greater impact than others. For instance, a company acting as a trusted third party managing the electronic transactions between absent participants will find a minimum damage to its reputation to have a stronger impact on it than, for instance, the noncompliance to a minor regulation.

Impact level determination

To determine the overall impact level derived from the loss of confidentiality of a certain resource x, we propose the following formula:

where each of the represent the level of damage to one of the mentioned areas (in this order): laws and regulations, commercial and financial interests, company's reputation and privacy and security of individuals. The coefficients allow adjusting the relevance each factor has with respect to the others.

Each of the consequences should be assessed in a scale from 0 to 4, being 0 -No damage to the organization 1 -Minimum damage with no significant impact on the organization 2 -Damage with clear impact on the organization 3 -Serious damage to the organization (future of the organization is not at risk) 4 -Maximum damage to the organization (bankruptcy, etc.)

Coefficients should range from 0 to 1, all of them summing up to 1. Aspects having stronger impact on the company's mission and business activity will be accompanied by higher coefficients. Note that organizations are free to add to the formula additional terms representing factors they might find missed. It is not advisable to neglect any of the factors, i.e. assigning a value very close to 0 to any of the accompanying coefficients, as that would cause to ignore potential impacts affecting the particular factor. Coefficients should be used to tune the final result by adding information of the specific company context to the model. According to our estimations, it is not recommended to have any coefficient being more than twice the value of any other one. We recommend equally distributing the coefficients (i.e., 0.25 at each coefficient) and only adjust if there is clear evidence to do so.

Notice that the coefficients (α, β, γ, δ) are part of the general model built by the company to evaluate potential impact, while the damage on each factor ( ) should be determined for each resource for which the potential damage wants to be calculated.

Here are some questions that can help in the determination of each of the Ai factors regarding the disclosure of a specific asset x. Notice that in case a certain fact affects more than one aspect, damage to each of them should be estimated independently.

Laws and regulations compliance

Is the disclosure likely to lead to an important/serious breach of legal or regulatory obligations? Consider not only external laws affecting the organization's activity but also internal regulations the company or the group to which it belongs can be subject to.

Commercial and financial interests

Does it facilitate significant improper gain or advantage for individuals or other organizations? Is of high/medium interest to a competitor? Would the disclosure result in significant monetary or productivity losses?

Company's reputation

Is it likely to adversely affect relations with other organizations, the public, or other countries? To what extent? Is it likely to result in widespread adverse publicity? Could it lead to loss of public confidence in the organization? Could it lead to loss of current or potential employees trust? Could it lead to a serious breach of contractual undertakings to maintain the security of information provided by third parties?

Privacy and security of individuals Does x contain sensitive information such as financial account number or medical records that can be linked to individuals? Is it likely to lead to the life of an individual or group of individuals being threatened?

Recall that this whole process should be carried out in the specific context of the organization in question. The same financial loss (in terms of absolute monetary units) won't have the same impact in a big and in a small company. Also, some aspects will be more critical to some kinds of companies. For instance, the impact a hospital would face if its customers' (i.e. patients) records are disclosed are higher than the impact faced by a dancing company giving up its customers' data. For this reason it is important that impact determination process is guided by managers and staff involved in the company's activity and with some experience in the sector. It may be the case that the consequences of a confidentiality breach are rated differently by different stakeholders within the company. Therefore the proposed method requires a consolidation phase for the impact ratings (0-4). In this phase the organization has to identify the reasons for the deviations and has to harmonize the impact ratings. Furthermore, confidentiality categories might vary as part of the regular lifecycle of a process. For instance, the disclosure of an advertising campaign could have a considerable impact while is still being planned, but once it has been implemented the impact will be minimal, if not zero.

Validation -field test

To validate the approach, we conducted a field test in a 4-year-old software development company in Austria. The company develops information security software and has therefore a high interest in protecting the confidentiality of the products' source code. Because of its business activities, the company relies on its reputation and trustworthiness and because it is a young company, it is critical for them to maintain a quality service and gain its customers loyalty. For validation purposes, the members of the management team were informed about the developed confidentiality determination method and asked to determine the required parameters. The management team discussed the weighting of the impact categories and decided to focus on the financial interest and reputation category (i.e. these categories were weighted higher than the remaining ones). The following weights were applied: Laws and regulations: 0.2

  The National Institute of Standards and Technology (NIST) defines security categorization as the first step in the risk management process. Security categories used by NIST SP 800-60 are defined in the Federal Information Processing Standard Publication 199 (FIPS 199) (NIST, 2004):

	, Magerit (Spanish Ministry for Public Administrations,
	2006), and Mehari (CLUSIF, 2010)). When dealing with confidentiality requirements
	in business processes one of the first decisions to make is the level to which each
	asset should be protected. This is part of the risk assessment phase of the ISRM pro-
	cess, which aims at identifying and evaluating risks affecting confidentiality, integrity
	and availability. Standards, methods and tools supporting security categorization and
	ISRM in general have been developed (e.g. (NIST, 2012; ISO/IEC, 2013; Spanish
	Ministry for Public Administrations, 2006; CLUSIF, 2010).

Commercial and financial interests: 0.3 Reputation: 0.3 Privacy and security for individuals: 0.2 Therefore, the general formula used by the company to assess the impact level derived from the loss of confidentiality is:

After the category weighting we asked the management board to estimate the damage derived from the disclosure of the source code (0: no damage, …, 4: maxiumum damage to the organization):

Laws and regulations ( ): 3 Commercial and financial interests ( ): 4 Reputation ( ): 4 Privacy and security for individuals ( ): 1 Thus, the overall impact level derived from the disclosure of the source code is 3.2. Based on their experience, the calculated impact level has been approved by the man-agement board. Within this field test we conducted 14 calculations regarding different assets to check if the calculation results comply with managements' opinion. 9 calculations provided obvious results (like the source code confidentiality calculation shown above). 5 calculations provided results which were not obvious to the management team (e.g., disclosure of personal data on invoices or e-mails). In these cases the method helped to think in a structured way about the confidentiality impact and plan appropriate countermeasures.

Conclusions and further work

Impact level determination is a complex and context-dependent process and a crucial step in security risk management processes. When approaching confidentiality, impact level estimations are more complex as the kinds of possible damage involved are of different nature and thus affect in different ways.

Approaching our original research question: "How can confidentiality requirements be determined for corporate assets?" we proposed here a method of impact level determination regarding confidentiality. The peculiarity of the method is that it estimates negative impact on different areas separately. That is, damage to laws and regulations, finance, or reputation are assessed independently and then combined to calculate the overall impact to the organization. The model also allows organization to give more relevance to some aspects than to others thus making the process more flexible and customizable.

Although this method leads to more accurate results in the context of each organization, it requires a lot of effort from qualified and experienced personnel. In further research we aim at automating the proposed method (e.g., by analyzing business processes and their interaction with the corporate assets).