Gergely Alpár
email: gergely@cs.ru.nl

Jaap-Henk Hoepman

Avoiding Man-in-the-Middle Attacks When Verifying Public Terminals ⋆

An individual who intends to engage in sensitive transactions using a public terminal such as an ATM needs to trust that (a) all communications are indeed carried out with the intended terminal, (b) such communications are confidential, and (c) the terminal's integrity is guaranteed. Satisfying such requirements prevents man-in-the-middle attacks and eavesdropping. We have analysed several existing transaction schemes and concluded that they tend not to meet all requirements during the entire transaction. We propose a new, generic protocol that provides (a) optional terminal identification, (b) key establishment, and (c) customisable integrity assurance.

Introduction

Individuals often have to use public terminals for sensitive communication in which trust is taken for granted; however, establishing trust is not easy in a public environment 1 . Several schemes in the literature have been proposed for the users to verify such terminals and to receive a reliability report before performing the main transaction. This approach is not sufficient as an adversary can place an intermediary platform that relays all messages between the trustworthy terminal and the user during verification. After verification this hostile platform will be trusted by the user, who may communicate sensitive data during the main transaction.

To protect against such a man-in-the-middle (MitM) attack, the main transaction has to be linked strongly to the verification. There are two ways to establish this link: key exchange and identification. A key exchange is used to establish a secure channel that is bound to the verification and to the verified honest device, while an identification process of a terminal demonstrates locality, that is, a proof of direct contact between the user and the public terminal. Considering these two methods independently, we can analyse and design protocols more consciously.

The purpose of the present study is twofold. First, we examine whether existing schemes can exclude man-in-the-middle attacks. Second, we design a flexible generic protocol that optionally incorporates these linking methods.

The paper is organised as follows. Section 2 presents preliminary notions in relation to cryptography and trusted computing. The problem statement in Section 3 is divided into three parts.

First, the model and the main assumptions are described. Second, key exchange and identification are discussed in detail. Third, we discuss the relevant state of the art in this area. Applying our approach and model, Section 4 provides an analysis of two existing protocols and Section 5 reports and analyses our new protocol. Finally, Section 6 discusses conclusions and open questions.

Preliminaries

Cryptographic Tools

Since throughout this paper we use cryptographic concepts, this section aims to describe some relevant notions without their mathematical background. For a more complete description see e.g. [START_REF] Smart | Cryptography, An Introduction[END_REF].

Randomness plays a crucial role in cryptography and, instead of true randomness, computing devices generate pseudorandom values in practice. A cryptographic hash function creates a fixed length bit string, often called a hash value, from an arbitrary length bit string. Even if the function is deterministic, a hash value is seemingly random and reveals nothing about the input value. A nonce is a (pseudo)random number generated for using it only once in an instance of a cryptographic protocol. The bit length of a nonce usually depends on the system's security parameter.

Symmetric-and public-key encryptions and digital signatures are essential topics in cryptography,. While in case of symmetric-key encryption both the sender and the receiver of the message have the same key and therefore encryption and decryption can be performed by both of them, in case of public-key encryption only the receiver can decrypt by means of a secret key and the corresponding encryption key can be put publicly available. Since computing a secret key from the corresponding public key is intractable anyone can encrypt, but only the receiver can decrypt. A digital signature on a message is an appendix to the message that can only be produced by the signer but can be verified by anyone. The signer needs her private key, and the verifier needs the corresponding public key. As any small modification in the message essentially changes the signature, a digital signature provides authenticity (it is originated from the signer) and integrity (it has not been changed) for the message. A signature of participant A on a message m is denoted by sig{m} A .

In order to establish a secure channel, both participants have to hold a symmetric key that enables them to encrypt and decrypt messages. Key establishment can be achieved by either a secure key exchange, or some key distribution mechanism. In this study we make use of the Diffie-Hellman key exchange [START_REF] Diffie | New directions in cryptography[END_REF] that enables two participants to create a shared secret key after sending certain messages over an insecure channel. Although applying the pure Diffie-Hellman key exchange is vulnerable to the MitM attacks, it can be protected by authenticating the messages during the key exchange.

In the context of public-key cryptography an important issue is how participants receive keys belonging to other participants. To verify a signature or to send a secret message, the public key is often certified by a trusted third party, the certificate authority, or CA. By signing other CAs' certificates, CAs can establish a hierarchy of public signature keys which is called a public-key infrastructure, or PKI.

TPM

A trusted platform module, or TPM [START_REF] Pearson | Trusted computing platforms: TCPA technology in context[END_REF] is the hardware root of trust within a computing device. Besides the TPM, a trusted subsystem of a host computer contains two software components:

A core root of trust for measurement (CRTM) and a trusted software stack (TSS). The CRTM, usually located within the TPM, is the first piece of software to run during the boot process, and the TSS communicates with the rest of the host platform and with other computers. A trusted subsystem can create attestation identification keys (AIKs) certified by a unique endorsement key, to sign its output. A trusted third party, the privacy certificate authority (Privacy CA) may attest in a certificate that an AIK was actually signed by a valid TPM's endorsement key. According to the specification, the TPM's actual identity (the public part of the endorsement key) is not revealed during an attestation. This enables the design of privacy-preserving protocols.

An integrity report, created by the trusted subsystem and the host platform, is a statement about the current state of a computer. When an integrity report is requested during a so-called remote attestation, the TPM by means of its AIK creates and signs a secure summary about the host computer's current hardware and software configuration.

In the course of the verification of an integrity report, a verifier follows several steps. It checks that the signature is valid and that the signing key (AIK) is certified by a Privacy CA. Moreover, it verifies that the current state of the platform occurs in a previously stored database of "good" states. In certain scenarios the verification requires big resources including large storage space (storing all "good" states of all computers in a system), many computations (verifying large measurement logs), and additional interaction with the Privacy CA.

Problem Statement

Verification of a computer is a process resulting in a report about the integrity of that device. It determines the state of the device and is able to detect whether the device contains malicious software, such as viruses or trojans. A special case of verification in which the computer is in the direct vicinity of an individual, is called local verification. Local verifications are often recommended to precede security or privacy critical actions. Examples of such actions are withdrawing money from an ATM, paying at a POS terminal in a supermarket, or using a public kiosk computer for internet access.

Model and Assumptions

A user U, having a trusted personal device M, such as a mobile phone, intends to verify whether a public terminal T is trustworthy enough to be used for a security or privacy sensitive task.

The user trusts his mobile device to perform all computations correctly, and to display the results honestly. Moreover, U relies on M's security, i.e., that it does not leak any information to a third party.

The terminal T is potentially untrusted. However, as in most proposed schemes, T is assumed to have a hardware TPM as the root of trust, which is able to perform integrity checks and to provide an integrity report about the current hardware and software configuration (see Section 2.2). Being a hardware module, T's TPM is able to reveal any software modification. T is presumed to be tamper-resistant and hence no adversary can make hardware alterations.

Although in some scenarios mobile phones can be suitable to verify integrity reports, we incorporate a trusted verification server S which is able to carry out this demanding task requiring much storage, computation, and communication. To convey the resulting signed statement, called an attestation about the state of the terminal in question, an authentic channel has to be established from the server to the user's trusted mobile phone via the untrusted terminal. (This authentic channel is established by a digital signature of the verification server, which is assumed to be efficiently verifiable, unforgeable, and it is assumed to provide message integrity.) Note that we do not assume a direct channel between M and S; however, we do presume that M stores S's public signature key or uses a matching PKI.

In our model the adversary is reasonably powerful as it controls all digital input and output channels between M and T and between T and S, see Figure 1; all messages transmitted through these channels can be eavesdropped on or modified by the attacker.

Approach: Key Exchange or Identification

The primary objective of a verification process is to assure the user U that a terminal T is not in a compromised state. However, the positive result of a verification does not necessarily guarantee that it does not originate from another terminal. Some previous protocols, such as [START_REF] Bangerter | A demonstrative ad hoc attestation system[END_REF] and [START_REF] Toegl | An approach to introducing locality in remote attestation using near field communications[END_REF], suffer from a potential man-in-the-middle attack. In this type of attack, an adversary places a hostile computer T' between the honest computer and the user. While the verification is done on the honest computer, the result is displayed on the hostile terminal. Consequently, the user is convinced that the hostile computer is honest.

We would like to draw attention to two methods to eliminate man-in-the-middle attacks by binding the communication to the honest terminal. A key exchange during the verification produces a secure key between the user's personal device and the honest terminal. This key is used to build a secure logical channel between these participants, so even if a man in the middle is present, it will not be able to extract or insert messages. The channel is tied to the verification result and hence to the honest terminal; therefore, it provides security for the main transaction. Identification, on the other hand, is a means to provide locality by determining that the device included in the verification is in fact the same as the one the user is physically interacting with.

Combining these two independent optional methods generates four different types of verification schemes to study (see Figure 2). 1. Schemes of type 1 do not establish a secure channel and provide no strong identification.

Since the lack of these features results in the lack of a link between the verification and the main protocol, schemes of type 1 are vulnerable to man-in-the-middle attacks. 2. Schemes of type 2 provide assurance that the public terminal a user is standing at is indeed the honest computer and not a platform in the middle that relays all the messages between the honest host and the user. Although the main transaction does not require the use of a personal device, robust identifications may require to involve it for the verification. This would be a meaningful method for verifying ATMs before using them: (1) identification is obviously required because of the human interaction, and (2) the use of a secure channel is not possible since a user is required to communicate directly with the public terminal when typing the 4-digit PIN. 3. Schemes of type 3 allow computing devices to establish a secure channel (e.g., SSL) during verification. This requires the user to apply a trusted personal device for the whole (secure) communication with the public terminal. As a positive verification result is bound to the honest terminal, the key of the secure channel is also bound to it. Therefore, even if there is a device T' in the middle controlled by an adversary, it is impossible for it to eavesdrop. Consequently, schemes of type 3 provide security without identification. As an example, an enhanced cash withdrawing protocol would enable the user to enter the PIN into her mobile phone (instead of directly into the ATM) that would send it over the secure channel to the honest ATM. 4. Schemes of type 4 establish a key between the user's mobile phone and the public terminal for the whole transaction and, simultaneously, they provide a technique for the identification of the public terminal in the vicinity. By linking the identity of the terminal and the key of the secure channel, these methods guarantee that the user and his personal device are communicating with the same public terminal.

Distinguishing these types helps to understand the requirements of different scenarios and the essential differences among proposed schemes in the literature.

Requirements

Consider the system model in Section 3.1. A verification scheme must provide an authentic and verifiable integrity report about the current state of the public terminal with the following properties:

-Completeness: An honest terminal should be able to convince a verification server and eventually the user about its good state. -Soundness: A cheating terminal should not be able to convince either a verification server, or a user that it is honest.

Furthermore, the scheme must bind the verification to the transaction by one of the methods described in Section 3.2, i.e., it has to be of type 2, 3, or 4.

Related Work

Several schemes have been proposed in the literature for integrity reporting and locality verification. We can classify proposals using the four types described in the previous section.

Recently, Toegl and Hutter [START_REF] Toegl | An approach to introducing locality in remote attestation using near field communications[END_REF] and Bangerter et al. [START_REF] Bangerter | A demonstrative ad hoc attestation system[END_REF] propose verification schemes that output the state of a public terminal using its TPM. Even though these protocols claim to provide identification of a public terminal, they do not as both schemes are vulnerable to manin-the-middle attacks (see Section 4). Consequently, these schemes are of type 1 instead of type 2.

McCune et al. propose Seeing-is-Believing (SiB ) [START_REF] Mccune | Seeing-is-believing: using camera phones for human-verifiable authentication[END_REF] techniques for demonstrative identification of previously unknown devices by applying bar codes and cameras. SiB protocols, which can securely associate a trustworthy device identifier with the present communication, are able to assure the user that a man-in-the-middle attack does not take place. McCune et al. discuss TPM related protocols, in which identification is based on the TPM identifier which is welded securely on the cover of the host platform. This identifier and the one that provides authenticity in the integrity report are compared and expected to be the same by the user's mobile device. This results in a verification protocol, which is also included as a sub-protocol in our proposal (see Section 5), of type 2.

Locality can also be achieved by distance bounding, which was devised by Brands and Chaum [START_REF] Brands | Distance-bounding protocols[END_REF] and is still an important topic of research [START_REF] Chong | The swiss-knife rfid distance bounding protocol[END_REF]. Distance bounding guarantees an upper bound on the physical distance between the user and the public terminal.

Stumpf et al. [START_REF] Stumpf | A robust integrity reporting protocol for remote attestation[END_REF] show that several remote attestation protocols are vulnerable to man-inthe-middle attacks. To protect against this, they propose a new scheme that they call enhanced integrity reporting. This method is based on a simple yet essential observation: The actual goal of a remote attestation (and verifications, in general) is not the valid integrity report for its own sake, but a secure communication that is bound to the computer that provides it. Therefore, in the protocol of enhanced integrity reporting, remote attestation is complemented by a session key establishment between the verifier server and the terminal. This key is then used to secure the channel for the whole communication. Although Stumpf et al. study the problem of remote attestation and therefore their scheme does not tackle identification of a local computer resulting in a scheme of type 3, it can easily be incorporated into the verification of public terminals as we show in our proposal (see Section 5).

Garris et al. [START_REF] Garriss | Trustworthy and personalized computing on public kiosks[END_REF] describe a specific scenario of type 4 in which a user can interact with a public kiosk computer using a trusted mobile phone for encrypting all personal information. The scheme, which uses the SiB concept for identification and TPM technology for verification, enables the user to verify a public computer before using it. This protocol is closely related to our proposal; however, it is not practical in some scenarios (e.g., ATM, POS terminal) as it requires the public computer to reboot during an execution of the protocol and to run a virtual machine. Oprea et al. [START_REF] Oprea | Securing a remote terminal application with a mobile trusted device[END_REF] also design an application of type 4, that is, it guarantees both a secure channel and identification. Their scheme is not just an initial verification for some main interaction, but a complex protocol. It applies two SSL channels for scenarios in which users access a trusted remote computer, such as their home computer, from an untrusted terminal.

In sum, though specific protocols of different types were designed that bind a computer with the secure communication, no general description exists to prevent an adversary from performing man-in-the-middle attacks. In particular, there does not exist a scheme of type 2, 3, or 4 that can provide secure verification in the context of public terminals.

Analysis of Existing Schemes

A secure verification scheme does not only provide a trustworthy report about the public terminal in question, but also guarantees that the transaction is properly bound to the verified device. To analyse the design of a verification scheme, we perform the following steps with respect to its security and its binding procedure:

-Determine the type of verification the scheme claims to perform • If it is of type 1 (i.e., no identification, no key exchange), then it is vulnerable to a man-in-the-middle attack. • If it is of type 2, 3, or 4, then its security has to be studied further.

-Verify security of the messages: proper freshness (to prevent replay attack), inclusion of the identifier of the terminal (to prevent the use of another terminal's report), authentic evaluation result (to prevent a rogue evaluation). -Verify security of the channels (depending on the type): identification (channel between the user and the terminal) and/or key exchange (channel between the personal device and the terminal) are properly bound to the transaction.

After studying several schemes, we found that proposed verifications of public terminals often fail to provide robust solutions. Below we describe the analysis of two schemes briefly. The objective of Toegl and Hutter's elegant scheme (Sections 4 and 5 in [START_REF] Toegl | An approach to introducing locality in remote attestation using near field communications[END_REF]) was to build a verification protocol of type 2, that is, it should incorporate identification. In their work, locality is provided by using a direct near-field communication (NFC) channel from the TPM to the user's mobile device -according to Parno's [START_REF] Parno | Bootstrapping trust in a "trusted" platform[END_REF] suggestion in his theoretical work. They proposed a design modification in the TPM specification by extending it with an NFC interface. Nevertheless, another recent study by Francis et al. [START_REF] Francis | Practical nfc peerto-peer relay attack using mobile phones[END_REF] shows that NFC is vulnerable to manin-the-middle attacks, so its use for proving locality is not secure enough. The scheme can be enhanced for each verification type in the following manners:

-Type 2: Apply mitigations against NFC man-in-the-middle relay attacks by location-based information, distance-bounding, or multi-channel communication [START_REF] Francis | Practical nfc peerto-peer relay attack using mobile phones[END_REF]; however, those are not always possible. -Type 3: For communicating S's verification result, a secure channel is established between M and T's TPM in the scheme. Either the protocol should be extended and the honest host terminal should learn this key, or the TPM should be involved during the whole secure communication.

-Type 4: By combining the security and locality extensions above, the scheme can be reinforced to be of type 4.

Bangerter et al. [START_REF] Bangerter | A demonstrative ad hoc attestation system[END_REF] proposed a scheme that applied the proprietary AXS system2 , which uses special flickering images, for secure communication from S to M, while T is used only for conveying encrypted messages. Their protocol aims to produce a type 2 verification, but it also turns out to be vulnerable against man-in-the-middle attacks in our model. Our attack works as follows. As the adversary has control over all input and output channels of the terminal, messages from the server can be captured and displayed on the monitor of a dishonest terminal. Even if the flickering image cannot be relayed, as Bangerter et al. assume, the data is seized on a lower level. Because the terminal's identifier is not included in the protocol, there is no way for the user to detect this man-in-the-middle attack. If the protocol is extended by an adequate identification procedure of the terminal, it does become a verification of type 2.

General Proposal

In this section, we propose a resilient verification protocol for public terminals that can provide key exchange (type 3) and optionally identification (type 4) together with the terminal verification process. First, we present a set of requirements that the protocol has to meet, then we show our scheme, and finally, we give a brief security analysis.

Verification Scheme

Our proposal, shown in Figure 3, is based on two previous proposals. Firstly, the scheme incorporates key exchange that provides a secure channel for further communication according to Stumpf et al.'s robust integrity reporting [START_REF] Stumpf | A robust integrity reporting protocol for remote attestation[END_REF]. Secondly, the scheme applies the SiB principle (see 3.4 and [START_REF] Mccune | Seeing-is-believing: using camera phones for human-verifiable authentication[END_REF]) that enables the identification of the public terminal. A brief description of the scheme is as follows:

1-4 A fresh integrity report is generated with an additional Diffie-Hellman key exchange (in a standard cryptographic setup) as in [START_REF] Stumpf | A robust integrity reporting protocol for remote attestation[END_REF]. (Besides the nonce n and the DH key share g b , the integrity report rep contains a quote that describes the measurement of the current state, the public key of the terminal, and a certificate about the AIK that is used to sign the whole report.) 5-8 Having received the integrity report, the server evaluates it ("good" state, signature, key, etc.) and creates a signed message containing the state and the identity of T as well as the nonce. 9-10 (a) Depending on whether direct U-T interaction is necessary in the main transaction or not, the scheme does or does not include identification. In the first case the user, by means of his mobile device, employs SiB techniques to scan and compare the terminal's identifier ID T from the signature and that on the outside of the terminal (ID T ). In the latter case, in which no direct U-T interaction is necessary in the main transaction, the user does not initiate identity verification. (b) To verify freshness, the mobile device confirms that the nonce in the attestation and the original nonce from step 8 are equal. Furthermore, the mobile device also checks equality of the terminal's public channel key g b from step 3 and 10. 11 Finally, after validating freshness, channel security, identification, and T's verified state report, M displays the result to U whether T is in a trustworthy state.

As a result of this verification protocol, the user knows the state of the public terminal; moreover, M and T have a session key K = g ab that establishes a secure and authentic channel between the mobile device and the honest terminal. If identification supplements the verification (in steps 9-10), the user is also convinced that the honest terminal is the one directly in front of him.

Security Analysis

Although a comprehensive security analysis has not been carried out in this research, we argue that the protocol above is of type 3 or type 4, depending on the exclusion or inclusion of identification, and it meets the security requirements described in Session 3.3. Basically, there are two cases according to the state of the platform.

If terminal3 T with its TPM cannot produce a valid integrity report, i.e., either the TPM's signature is not valid, or the state is not in the set of "good" states, then the verification server will output "bad" as the terminal's state in step 6. Since the state -together with the nonce and the terminal's identifier -is sent signed by S, it is impossible to change the values without knowing S's private signature key. Eventually, M will display to the user that T should not be used for processing sensitive data. As a result, we get that the scheme is sound, that is, no malicious terminal T' can convince U that it is honest.

If T can produce a valid integrity report, there are further evaluations. If the scheme includes the identification steps in 9 and 10, the ID T in S's signed message and the identifier ID T on the casing of the public terminal have to match. Moreover, the nonces generated by M in step 1 and signed by S in step 7 should be the same as it is verified in step 10. As a result we get that an honest terminal can convince U that it is honest; therefore, the scheme is complete.

We show that the scheme without the identification method in steps 9 and 10 is of type 3. First, we show that the channel established in steps 1-4 is secure between M and the honest terminal T. We need to prevent an attacker to break the channel key, replay previous communications, and being able to mischievously have M establish a key with T' instead of T. Since a and b are only known by M and T, respectively, according to the Diffie-Hellman assumption4 , the key of the secure channel K = g ab can only be computed by these participants. Furthermore, the nonce freshly generated by M (see step 1) prevents replay attacks. Finally, T's share g b is included in the integrity report (see steps 2 and 8), therefore it is bound to T. The key verification in step 4 guarantees that the two participants share the same key. Second, we show that it does not provide identification. It is easy to see that a terminal T' is able to impersonate T by relaying all messages between M and T (although T' can only see encrypted messages). Therefore, the scheme is of type 3.

By incorporating the identification in steps 9 and 10, the scheme is of type 4 since it provides not only secure communication between M and T as above, but also between U and T. Since ID T as well as T's key share g b are included in the integrity report, M and U communicate with the same honest terminal.

We have considered the security problem of verification of a public terminal prior to sensitive communication between an individual and the terminal. The findings suggest that two independent security methods, identification and key exchange, can prevent man-in-the-middle attacks.

While the strongest schemes provide both methods, one of them is often sufficient. When direct user interaction is required with the public terminal, key exchange, which is computationally intractable for humans, is not possible. Therefore, in this case terminal identification is preferred. On the other hand, when a private mobile device can be employed for conveying all sensitive information, prior key exchange without actual identification is often adequate.

In order to put the problem of verification of public terminals in a broader context, we construct an overview table (see Table 1) of scenarios that illustrates eight different alternatives depending on which of the three channels are present for sensitive communication in the main transaction between a user U, a personal device M, and a public terminal T. They characterise distinct scenarios, security and channel requirements, and user experience. We have described a way to analyse verification schemes and, in order to demonstrate the analysis, we have studied existing schemes and found that some of them failed to provide either of these methods. We made recommendations to rectify those.

U-M U-T M-T Description

We have designed a generic user-friendly and privacy-friendly protocol that provides both methods to accompany the verification. The protocol design is modular in the sense that, according to the requirements, besides establishing a secure channel identification can be added or removed.

Further Research

Although this research can be enhanced in several directions including the verification of not only public terminals but also other (mobile) devices or the whole environment a mobile device is placed, we focus on two interesting questions.

As the personal device is often a mobile phone in practice, the presumption that there is no independent channel between M and S may be eliminated. In this case new protocols can be designed in which the server can communicate the evaluation result easier as the untrusted public terminal is excluded.

As mobile phones are ever more disposed to malicious software, the trust assumption about M can be questionable. Using the model in which T and M are both untrusted but independent (i.e., assuming that they are not attacked by the same adversary), new protocols can be designed to verify whether T is in a valid state.

Fig. 1 .

 1 Fig. 1. Attacker model: The adversary has control over all digital channels.

Fig. 2 .

 2 Fig. 2. Binding the verification to the main protocol: key exchange and/or identification.

Fig. 3 .

 3 Fig. 3. Protocol for verifying a public terminal.

Table 1 .

 1 All possible scenarios for single-channel communication between a user U, a mobile device M, and a public terminal T.

	Requirment	Example

The AXS system contains hardware and software elements. Each user has a small electronic device, the AXS token, that has two input channels (an optical sensor and a fingerprint reader) and an output channel (display). The software element is at the server's side and its main output is an unforgeable flickering pattern that can be sent and displayed on the client side. AXS tokens can read and interpret these patterns as numbers.

Throughout this section, we refer to the honest terminal as T, while to an adversarial terminal as T'.

Informally, the Diffie-Hellman problem is to compute g ab from g, g a , and g b without knowing a or b. The Diffie-Hellman assumption states that in certain groups this problem is hard.

Acknowledgements

The authors are grateful to Rieks Joosten for stimulating discussions, advices on writing, and insightful comments, and to Maarten Everts for his helpful remarks.

⋆ This research is supported in part by the research programme Sentinels as project 'Mobile IDM' (10522). Sentinels is being financed by Technology Foundation STW, the Netherlands Organisation for Scientific Research (NWO), and the Dutch Ministry of Economic Affairs. The work described in this paper has been supported in part by the European Commission through the ICT programme under contract ICT-2007-216676 ECRYPT II.


Martin Beck
email: martin.beck1@tu-dresden.de

Michael Marhöfer
email: michael.marhoefer@nsn.com

Do-Not-Track techniques for browsers and their implications for consumers

Recent efforts to increase online privacy by offering the user a more general choice to opt out of online tracking were mainly pushed by the FTC in late 2010. As the FTC explicitly omitted technical details, browser developers started to implement what they thought might be appropriate to either limit user tracking directly, or let the advertiser know about the user's wish to not be tracked. This paper gives a short overview on the positions and arguments of stakeholders and evaluates the technical proposals and implementations aiming to support the consumer in keeping control over his personal data.

Introduction

Since the Internet Architecture Board (IAB) held its "Internet Privacy Workshop" in December 2010 [START_REF]Internet privacy workshop -how can technology help to improve privacy on the internet?[END_REF] and the Federal Trade Commission (FTC) released its preliminary staff report "Protecting Consumer Privacy in an Era of Rapid Change" also in December 2010 [START_REF] Ftc | Protecting consumer privacy in an era of rapid change[END_REF], many discussions and comments from all parties involved led to a huge media interest about online privacy, resulting in the "Online Privacy: Towards Informational Self-Determination on the Internet" workshop at Dagstuhl [START_REF]Perspectives workshop: Online privacy: Towards informational selfdetermination on the internet[END_REF], in a workshop at the world wide web consortium (W3C) [START_REF]W3c workshop on web tracking and user privacy[END_REF], drafts for standardization of tracking protection features [START_REF] Mayer | Do not track: A universal third-party web tracking opt out[END_REF][START_REF] Zeigler | Web tracking protection[END_REF] and even proposed bills [START_REF] Kerry | Commercial privacy bill of rights act of 2011[END_REF][START_REF] Markey | Do not track kids act of 2011[END_REF][START_REF] Rockefeller | Do-not-track online act of 2011[END_REF].

Earlier on in November 25th, 2009 the European Parliament passed a directive to regulate storage of and access to information on the equipment of a user [START_REF]The European Parliament and the Council of the EU[END_REF]. Commonly used HTTP-Cookies are only one example of such a storage mechanism. The consumer needs to be provided with "comprehensive" information about any activity that results in the described behaviour and the offer to refuse from engaging in this activity [START_REF]The European Parliament and the Council of the EU[END_REF]. So a user must first give his consent [6], or the corresponding data processing would be unlawful. The time for transforming this Directive into national law was set to one and a half year, so on May 25th, 2011 all members of the European Union should have finished a corresponding local law. The only country that adopted the european directive in time is the UK [START_REF]The privacy and electronic communications[END_REF], giving organisations and businesses one year to comply with the new law [START_REF]Ico gives website owners one year to comply with cookies law[END_REF].

Throughout all these discussions the common synonym "Do Not Track" (DNT) is used with very different meanings. Development of unique definitions for "tracking" and "privacy" is ongoing and undertaken, for instance, at the beforementioned W3C workshop. The expected results of "Do Not Track" and proper technical solutions are also to be discussed and defined. This paper gives a short overview on the positions and arguments of stakeholders and evaluates the technical proposals and implementations aiming to support the consumer in keeping control over his personal data.

Tracking is used in this document as identifying a consumer by a specific ID or some sort of fingerprinting and by getting to know his current action. If tracking is done by a third party not being the domain or party the user intentionally wanted to communicate with, this is called third-party tracking, as opposed to first-party tracking from the intentionally visited domain.

The paper will be structured as follows. In section 2 groups composed by similar interests will be observed regarding their preferences and arguments within the overall DNT debate. Section 3 covers proposed solutions by browser developers and finally Section 4 will conclude this paper.

Stakeholders

Restricting and regulating online tracking affects a wide range of parties, represented by stakeholders from the advertising industry, privacy advocates, publishers, browser developers and researchers. As a result, contrary goals need to be integrated to arrive at a commonly acceptable solution.

An often named application for online tracking is behavioral targeted advertising, which uses aggregated data collected through online tracking to show adverts for the extrapolated interests of a certain user. According to [START_REF] Beales | The value of behavioral targeting[END_REF], behavioral targeted ads in 2009 had a 2.68 times higher average price compared to standard "Run of Network" ads, while in the same year the average conversion rate increased from 2.8% to 6.8% by a factor of 2.43. The total ad revenue for the participants of the study in 2009 was approximated to $3.3 billion, with 17.9% attributable to behavioral targeting.

Opposing the "Commercial Privacy Bill of Rights Act of 2011" [START_REF] Kerry | Commercial privacy bill of rights act of 2011[END_REF], Google, Facebook, Yahoo, AOL and other companies sent a letter to Senator Alan Lowenthal [START_REF] Google | [END_REF], to vote against regulating privacy as proposed by the mentioned bill. Main arguments include that the regulation would be unnecessary, as current browsers already offer tracking protection and self-regulation programs "already addressing all areas of consumer privacy [. . . ]" [START_REF] Google | [END_REF]. Internet economy and innovation would be harmed due to conflicting standards, "creating significant confusion and uncertainty for investors" [START_REF] Google | [END_REF].

From the consumer's perspective, represented by privacy advocates, pure technical solutions which are not backed up by legal rules are unlikely to reach their full potential, as advertising networks are not committed to respect the user's desired privacy policy. Companies could just ignore the implications of the deployed technical solutions without facing legal consequences. Also, without regulation and clear definitions of used terms and expected results, it remains unclear to the consumer what the implications of using this privacy preserving technology are due to the lack of transparency. Making an educated choice would incorporate many-in the regulatory case unnecessary-constraints, such as reading lengthy privacy policies to extract the definitions of otherwise common terms like "tracking" or "privacy" on a per domain basis.

The third party next to advertisers and privacy advocates, which is directly involved, is composed of publishers, service providers and general content providers, who used targeted advertising to increase their revenue. According to the argumentation of the advertising industry, publishers highly depend on behavioral targeting to be able to keep their services running as we know them today [START_REF] Zaneis | do not track' rules would put a stop to the internet as we know it[END_REF]. Often this inferes that behavioral targeting is equivalent to or at least necessary for digital advertising. However, behavioural targeting only counts for one part of all available user targeted advertising methods. Targeted adverts using contextual, search, placement or social network data are not engaging in any user tracking and are thus not subject to this regulation. As behavioral advertising only had a share of about 4% of overal internet advertising revenue [START_REF] Waxman | Memorandum. Technical report[END_REF] advertising will, with high probability, continue with only a small impact, caused by the Do-Not-Track regulation [START_REF] Mayer | Do not track is no threat to ad-supported businesses[END_REF].

Contrary to the position of advertisers and privacy advocates, browser developers did not define a common language for communicating consumer privacy whishes in the first place. Instead most large browsers got equipped with various privacy enhancing technoloies. Implications from that will follow in section 3.

Within the W3C, a tracking protection working group was formed 3 , which tries to define methods for expression of user preferences and thus to improve user control and privacy. The final recommendation compiled by this working group should be available in June, 2012. The current Draft [START_REF] Fielding | Tracking preference expression (dnt)[END_REF] already proposes many technical details regarding the DNT protocol and answers questions and issues regarding the underlying model.

Proposed Technical Solutions

When looking at the technical aspects of the -advertising-industry-preferredself-regulation, which has been evolved over the past years, the same technology that mainly started tracking is used to limit it-HTTP Cookies. These are now called Opt-Out Cookies [START_REF] Dixon | THE NETWORK ADVERTISING INITIATIVE: Failing at Consumer Protection and at Self-Regulation[END_REF]. Consumers may go to specific web sites 4 , which offer a list of supported advertising companies allowing to opt-out of behavioral advertising for these.

Several problems arise with such a system. So, in its current design, self-regulation does not offer an appropriate privacy solution to customers. One of the downside aspects, namely Opt-Out Cookies being deleted together with all other Cookies, can be prevented by using a browser plugin for making such Cookies permanent. Google released such an extension called "Keep my Opt-Outs"(KMOO) [START_REF] Harvey | Keep your opt-outs, January 2011[END_REF] for "Google Chrome", which takes a copy of the NAI5 consumer opt out registry6 to reinstall all Cookies described within that list each time they got deleted. The user cannot choose to allow specific companies, add Cookies or update the registry. Instead updates to the KMOO extension are required to reflect changes made to the original NAI registry, or the consumer would have to manually edit this file, respectively replace it by a more current version. A similar plugin for Mozilla Firefox is "Taco Beef", which also makes Opt-Out Cookies permanent.

Another proposed solution-DNT-Header -comes from Mozilla and describes an extension to the sent HTTP header, which will carry a new entry called "DNT" [START_REF] Mayer | Do not track: A universal third-party web tracking opt out[END_REF]. Upon reception of this flag, carrying the value 1, the receiving server gets to know that the user does not want to be tracked. What this means is still to be defined. Next to the Mozilla Firefox browser7 , the Microsoft Internet Explorer also added support for this header since version 9. Apple's Safari browser will be equipped with a compatible header in an upcoming version [START_REF] Foresman | Safari to join "do not track" crowd, leaving google behind[END_REF]. Again we shall look at the arguments surrounding this technology.

Pros

-Generic broadcast solution that can be set once within the browser and forbids tracking on all supported networks -Good usability, as the consumer does not need to maintain a list or keep track of updates -Tracking preference is conveyed to advertising company

Cons

-Updated browser needed to enable header support -Adoption by companies just started, having nearly no practical usage right now -Again, most tracking information is still sent to the advertiser, also handing over control for this data

Once the used terms are commonly defined, DNT support is included within the major browsers and web servers, and advertising companies respect the setting, this technical solution could provide a very convenient way to disable online tracking. As far as browser support is concerned, as Apple Safari also ships with DNT support, 84% of the browser market is ready to protect the user's privacy through this technology [START_REF] Foresman | Safari to join "do not track" crowd, leaving google behind[END_REF]. Also support from some companies was announced [START_REF] Fowler | Advertisers and publishers adopt and implement do not track[END_REF], giving initial usage to the DNT-Header approach. As a third proposed way to protect the privacy of customers, Microsoft implemented black and white lists within the latest version of its "Internet Explorer" browser [START_REF] Zeigler | Web tracking protection[END_REF]. The scope for checking URLs against the lists is always on third party domains, implying that the originally visited domain (first party) and all its sub-domains cannot be subject to tracking protection. These lists, called "Tracking Protection Lists" (TPL), are implemented by three complementing mechanisms, which are:

-A personalized, semi-automatic list -External lists by third party providers -A tracking protection exception list

The personalized list gets filled automatically based on a user-defined threshold, specifying how often a single third party element must at least be present across different domains to get included onto the list. Once an element made it onto the personalized list, the user can choose to manually select if this item should be black or white listed with allowance being the default, or automatically blacklist all entries. The only possibility a user has to influence what gets included is through the beforementioned threshold. The list cannot be edited easily to add or remove elements.

External lists are provided by third parties to allow users to benefit from already approved list entries without the need to build up lists on their own. Microsoft officially linked8 to four such list providers upon the release of their Internet Explorer v9. Two of these lists are the EasyPrivacy list, known from the AdBlock Plus project, that also compiles the EasyList for blocking adverts, and TRUSTe tracking protection list. While "tracking protection" would imply that the user is to be protected against tracking and thus actually less to no tracking would take place after such a list would be installed, the TRUSTe list actually whitelists companies marked as trustworthy to TRUSTe.

Another problem can also be described based on the mentioned white list: Allow rules always have higher priority than Block rules. These rules are applied to each requested element that is referenced within the visited website and resides in a third party domain. So once a blocking rule is selected, the request is dropped and no data is transferred to the third party host. Those are the main arguments in favor and against blocking lists and TPL especially: Pros -All data and thus control over personal data remains at the user side -Established and known lists exist which can be used immediately (EasyPrivacy from AdBlock Plus) -As long as a user relies on external lists, no manual maintenance is needed Cons -Blocking lists are not tailored to tracking, but may block everything, including adverts or functionality -May break functionality if wrong scripts are blocked -Advertiser does not know that a user wants to opt out of tracking

External lists may include a number for specifying a time-to-live interval, after which the list should be updated automatically, which is typically in the range of three to five days. During this period, updates by the list providers are not pushed to the consumers.

The proposed standard [START_REF] Zeigler | Web tracking protection[END_REF] submitted by Microsoft also includes the DNT-Header introduced by Mozilla together with a new DOM element "doNotTrack" under "document.navigator". This element can be accessed by Javascript to offer scripts the possibility to detect the user's privacy preferences for the current site. Checking this element should return 1 in case tracking protection is set for this domain.

However, since the given priority calculation in the W3C proposal [START_REF] Zeigler | Web tracking protection[END_REF] differs from the implementation of the "Internet Explorer 9.0", which again differs from the "Internet Explorer 9.0 Release Candidate 1" implementation, complex blocklists may produce unexpected results.

Conclusion

As very different technical solutions are developed, many different kinds of advantages and drawbacks were recognized. Overall, the solutions can be categorized into either letting the advertiser know that tracking is not desired, or blocking requests and thereby limiting information flow to the advertisers.

A combination of both techniques enhances the privacy protection even further, as non-trustworthy companies which are not responding to DNT requests could be blocked, while other networks which respect the privacy setting can be allowed at the same time. Another aspect of online tracking is largely ignored: passive fingerprinting for (re-)identification. The EFF9 hosts a web site which tries to measure the amount of information a user's browser gives away 10 . In order to at least disturb the companies who use unique combinations of transmitted information by the browser to build profiles on top of these fingerprint IDs, they could be confronted with a less unique appearance. More generic values within the HTTP header, sorted font lists and alike can help to increase the anonymization set. Such measures can be implemented by using a specific Firefox profile like "JonDoFox"11 or equivalent.

As far as current usability for web-based opt-out solution, built in browser DNT options, blocking lists or browser plug-ins goes [START_REF] Leon | Why johnny can't opt out: A usability evaluation of tools to limit online behavioral advertising[END_REF], non-technical consumers face a rather long list of issues. The selection of companies within opt-out lists is not based on a meaningful per-company decision by the user, but rather by excluding a few common company names or just disabling traffic to all available companies. Default options are always set to explizitly opt-out of tracking, even after downloading and installing tracking protection plugins like TACO and Ghostery, which implies that a user most probably wants to stop companies tracking his online behaviour. The same is true for the IE9, where a user is not supported in adding third party lists after enabling tracking protection.

The implemented interfaces for configuring the opt-out are either too simplistic, so the user is not well informed (IE9 slider), or contain too many technical terms to be understood (Ghostery). As such, these tools are ineffective at communicating their purpose and guiding users [START_REF] Leon | Why johnny can't opt out: A usability evaluation of tools to limit online behavioral advertising[END_REF]. Interfaces are further confusing to the user, as it wasn't clear if tracking protection, for those companies intended, was already enabled, or even that third party TPL lists could be added to the IE9 protection feature. This is partly influenced by a lack of feedback for the tested tools, which leaves the user in the unknown state, whether tracking protection works or not [START_REF] Leon | Why johnny can't opt out: A usability evaluation of tools to limit online behavioral advertising[END_REF].

The average user at the end will most probably not notice any difference at all. The block list feature of the Microsoft Internet Explorer would have the highest impact, which could block third party adverts all together. The notification mechanisms of DNT-Header, DOM elements or Opt-Out Cookies will still let advertisers deliver ads, but hopefully not tailored to that user.

As long as targeted advertising is of main interest, several solutions for performing privacy-preserving targeting are proposed and developed [START_REF] Toubiana | Adnostic: Privacy preserving targeted advertising[END_REF][START_REF] Guha | Privad: practical privacy in online advertising[END_REF][START_REF] Fredrikson | RePriv: Re-Imagining Content Personalization and In-Browser Privacy[END_REF], focusing around stopping the unwanted flow of personal information to companies within the online advertising ecosystem. These solutions have local information extraction in common, which allows data mining against much of the local available information to generate highly probable interests for the consumer. Some of these systems even allow privacy-preserving gathering of correct adverts. Another point for discussion within such systems is whether the user would allow advertisers to get relevant personal information in case the consumer is able to give and actually gave informed consent.

Fig. 1 .

 1 Fig. 1. DNT adoption on desktop and mobile devices

Figure 1

 1 Figure 1 shows the adoption of the DNT option in Mozilla Firefox on desktop and mobile devices throughout September and October in 2011.

http://www.w3.org/2011/tracking-protection/

Like: http://www.aboutads.info/choices/, http://www.networkadvertising.org/managing/opt out.asp

Network Advertising Initiative, http://www.networkadvertising.org/

located at: http://networkadvertising.org/optoutprotector/registry.json

since Mozilla Firefox version 4.0

http://ie.microsoft.com/testdrive/Browser/TrackingProtectionLists/Default.html

Electronic Frontier Foundation, https://www.eff.org/

https://panopticlick.eff.org/

http://anonymous-proxy-servers.net/en/jondofox.html


Sebastian Labitzke
email: sebastian.labitzke@kit.edu

Who got all of my personal data? Enabling users to monitor the proliferation of shared personally identifiable information

The risk involved when users publish information, which becomes available to an unintentional broad audience via online social networks is evident. It is especially difficult for users of social networks to determine who will get the information before it is shared. Moreover, it is impossible to monitor data flows or to control the access to personal data after sharing the information. In contrast to enterprise identity management systems, in which provider-engineered processes control the access to and flow of data, the users of social networks themselves are responsible for information management. Consequently, privacy requirements have become important so that users can control the flow of their personal data across social networks and beyond. In particular, this kind of userbased information management should provide the capability to control data flows in a proactive manner, as well as reactive components to monitor the proliferation of data. In this conceptual paper, we motivate the necessity of a dedicated user-based information management on the basis of studies that we conducted on information that users share publicly in online social networks. Moreover, we outline the building blocks of user-based information management on the basis of existing approaches, which support users in managing data flows and an investigation that we did on the linkability of social network profiles. Furthermore, we contrast user-based information management with our experiences in developing and operating federated identity management services at the Karlsruhe Institute of Technology (KIT). 1

Motivation

Today's users of online social networks (OSNs) are often unduly generous in sharing personally identifiable information (PII) via their OSN profiles. This fact is confirmed by the results of recent studies that we carried out [START_REF] Labitzke | What your friends tell others about you: Low cost linkability of social network profiles[END_REF], [START_REF] Labitzke | How I and others can link my various social network profiles as a basis to reveal my virtual appearance[END_REF], as well as by many other previous investigations (e.g., [START_REF] Gross | Information revelation and privacy in online social networks[END_REF], [START_REF] Lampe | A familiar face(book): profile elements as signals in an online social network[END_REF], [START_REF] Krishnamurthy | On the leakage of personally identifiable information via online social networks[END_REF]).

In [START_REF] Labitzke | What your friends tell others about you: Low cost linkability of social network profiles[END_REF], we report, inter alia, which specific pieces of information OSN users share publicly. We analyzed 180,000 profiles of four popular OSNs for this (see Section 2 for more details), however, results showed two things. The first was that a great deal of information is publicly available despite the fact that privacy settings can be adjusted; secondly, the availability of specific pieces of information differs according to the OSN. We showed, for instance, that people tend to share information dedicated to business contacts via a business-driven social network and more private information through a network in which private contacts are gathered. The assumption could be made that users are aware of the target group of the shared information because of the type of network they are using.

However, it already seems to be difficult for users to determine who will be able to access a given piece of information before sharing it. To emphasize this, "Dunbar's number" says that the maximum number of people that humans are cognitively able to keep in touch with in terms of stable social relationships is 150 [START_REF] Dunbar | Coevolution of neocortex size, group size and language in humans[END_REF]. Keeping this figure in mind, Facebook states that an average user has 130 friends. 2 However, we found out that the standard deviation of the number of friends is very high (at about 216 regarding Facebook). In addition, in every network analyzed, we found some users with many more than 5,000 friends. At least, all of these friends have access to shared information, therefore information that was shared without giving much thought to it may be accidentally accessible to users who were not originally intended to get the information. Thus, OSNs should provide users with easy and comprehensible (proactive) features for choosing the group of receivers of a shared piece of information in a fine-grained manner.

Furthermore, it is essential to provide users with the ability to monitor who has access to which personal information over time, which information can be accessed by third parties, and which pieces of information can be linked to one another and in the end to the user as a physical person. On the one hand, this monitoring facility enables users to maintain an overview of their publicly available PII, i.e., an overview of the availability of their personal data after sharing the information. On the other hand, this monitoring capability has the potential to alert users to privacy risks and could be a motivation to use privacy settings more adequately. However, reactive components are not yet provided and users are not able to monitor the flow of their personal data.

We refer to a facility that combines the aforementioned proactive features with reactive capabilities to monitor and control data flows as an Information Management Assistance System (IMAS). We are aware of the fact that the idea of supporting users in preserving their privacy is not new, particularly in light of the ideas and prototypes grown in the EU research projects PRIME 3 and PrimeLife 4 and in terms of privacy and transparency enhancing technologies. However, the concept presented in this paper covers a novel perspective of the requirements of such support features. The difference between this concept and existing approaches is discussed in Section 2 and the following parts of the paper.

In this paper, we start by contrasting user-based information management in terms of the aforementioned IMAS and "conventional" enterprise identity management. The aim of this comparison is to figure out the parallels of both management perspectives. Moreover, we formulate the requirements for an IMAS transferred from the experiences that we gained by developing and operating enterprise identity management systems at KIT. In addition, we relate these requirements to existing features, which support users in the management of their PII as well as identify existing gaps. This paper is more of a conceptual than technical paper that, inter alia, motivates and introduces a novel perspective on the requirements for privacy preserving features. In particular, we point out that the aforementioned reactive part of an IMAS is not yet in place. However, we demonstrate a building block of a reactive component that could serve as a basis to enable users to reactively monitor the proliferation of shared PII. In summary, the contributions of this paper are:

-Comparison of enterprise identity management processes with "user-based" information management with respect to monitoring and control of data flows -Requirement analysis regarding proactive and reactive information management assistance -Comparison of identified requirements with the status quo of provided features that allow the management of personal data flows -Identification of the building blocks for reactive monitoring capabilities, which are not available today

The paper is structured as follows. Section 2 provides more insights into our previous investigation of publicly available information of OSN users. Furthermore, this section highlights related work, as well as recent statements of researchers working in the field of OSN analysis. Section 3 starts by introducing identity management concepts implemented at the Karlsruhe Institute of Technology (KIT). Subsequently, these concepts and related experiences are contrasted with the current opportunities available to OSN users for monitoring and controlling the proliferation of personally identifiable information in OSNs. Section 4 introduces the concept of an information management assistance system (IMAS), which could tackle the requirements that have been identified to support users in managing the proliferation of their data. Section 4.1 differentiates the capabilities of an IMAS from existing user-centric mechanisms, whereas Section 4.2 outlines the building blocks of such a system, which does not yet exist. Section 5 concludes the paper.

Related work

Many studies have been published that deal with user behavior and self-disclosure with regard to personal data in OSNs (see [START_REF] Labitzke | How I and others can link my various social network profiles as a basis to reveal my virtual appearance[END_REF] and [START_REF] Labitzke | What your friends tell others about you: Low cost linkability of social network profiles[END_REF] for a detailed discussion on related work). In particular, the availability of specific pieces of information in the OSN profiles were investigated. Recently, we showed that the date of birth is available in between 0% and 64% of user profiles depending on the OSN. The current residence is available in up to 48% of all analyzed user profiles. Up to 51% of users reveal the name of their university and up to 18% of users share their political and/or sexual orientation publicly. See Figure 1 and [START_REF] Labitzke | What your friends tell others about you: Low cost linkability of social network profiles[END_REF] for further results of this investigation. However, we also discovered that friends lists are available in a huge amount of OSN profiles (between 48% and 67% depending on the OSN) and we showed that such friends lists can be (ab-)used to gather and link various pieces of information about a single user shared in different OSN profiles. With privacy settings, OSNs enabled users to restrict access to shared information. In comparison with the results of earlier studies( [START_REF] Gross | Information revelation and privacy in online social networks[END_REF], [START_REF] Lampe | A familiar face(book): profile elements as signals in an online social network[END_REF], [START_REF] Krishnamurthy | Characterizing privacy in online social networks[END_REF], [START_REF] Schrammel | How much do you tell? information disclosure behaviour indifferent types of online communities[END_REF]), the results of [START_REF] Labitzke | What your friends tell others about you: Low cost linkability of social network profiles[END_REF] showed that an increasing number of OSN members are making use of privacy settings. However, we showed that only 7% to 22% of the users of the four OSNs analyzed have hidden their profile completely from strangers. Thus, we revealed that many users still do not make adequate use of the privacy settings provided or do not use them at all. As early as 2004, Acquisti stated that the provided technology is not effective if the risk awareness of users is not yet in place [START_REF] Acquisti | Privacy in electronic commerce and the economics of immediate gratification[END_REF]. Recently, Krishnamurthy said, "from an awareness point of view, the situation is pretty bad" [START_REF] Krishnamurthy | I know what you will do next summer[END_REF]. These statements provide the motivation for developing an IMAS, a system which has the potential to establish an appropriate awareness on the user side.

The aim of the European research project digital.me is to implement capabilities that are similar to those that we defined as the requirements for the proactive part of an IMAS [START_REF] Scerri | digital.me -towards an integrated personal information sphere[END_REF]. With digital.me, users will be empowered to keep an overview of the pieces of information they provided to integrated services, such as OSNs. Within other projects, like the EU projects PRIME and PrimeLife, researchers have also investigated features that support users in keeping track of third parties to which they provided specific pieces of information. As early as 2005, in the context of the PRIME project, the authors of [START_REF] Bergmann | Exploring the feasibility of a spatial user interface paradigm for privacy-enhancing technology[END_REF] assessed the idea of a system that supports users in preserving their privacy. Inter alia, in [START_REF] Berg | Privacy in social software[END_REF], the privacy-enhanced social network site Clique is introduced. This site provides users with the capability of segregating the audience of PII that is to be shared. It also provides options to define the accessibility of shared PII in a fine-grained manner. The authors of [START_REF] Fischer-Huebner | Trust and assurance HCI[END_REF] investigated a user interface called Data Track to support people in maintaining an overview of their provided PII. In 2009, XML co-developer Eve Maler,5 presented a similar mock-up (called CopMonkey) at the European Identity Conference (EIC). CopMonkey represents a system that serves as a tool for assessing the given privacy status of a user. In particular, the design and investigation of such mock-ups, as well as related implementations, such as the Clique tool, are essential for assessing the usability of such features and providing support in maintaining an overview of the services and audiences with whom a user has shared PII. However, all of these approaches only cover the proactive part of the requirements identified for an IMAS. An exception to this is the PrimeLife Data Track that provides also capabilities to get online access to PII stored by a service provider. This capability goes beyond proactive control and could constitute a building block for reactive user support. Apart from that, the mentioned approaches only comprise granting control who will have access to the PII in an intended sharing procedure, as well as the capability to maintain an overview of which service or what audience a user has provided specific pieces of PII to.

In this paper, we would like to go one step further than the aforementioned approaches. We assess the requirement of being able to keep track of the proliferation of provided data in a reactive manner, i.e., a concept that aims at providing a feature to show users the PII that they have made available and their resulting current virtual appearance in OSNs, or rather the Internet. Of course, the idea of such a monitoring system is not completely new. In 2009, in the scope of the EU research project PICOS6 , the "control over usage and proliferation of PII" was identified as a major concern regarding the implementation of privacy-preserving social networks [START_REF] Weiss | Privacy threat model for data portability in social network applications[END_REF]. As well as in projects mentioned above, the proactive perspective of this concern is also discussed in several publications of the project PICOS (e.g., [START_REF] Kahl | How to enhance privacy and identity management for mobile communities: Approach and user driven concepts of the picos project[END_REF], [START_REF] Tschersich | Towards privacy-enhanced mobile communities -architecture, concepts and user trials[END_REF]). On the contrary, the authors of [START_REF] Hedbom | Transparency tools[END_REF] described an approach to preserve privacy in a reactive manner. They proposed a system that would allow users to view the log files of a specific provider. This would allow users to get information about third parties that received their PII from this provider. In contrast to this, the concept of an information management assistance system is different in that a provider is not required to allow access to internal information regarding forwarded PII. With the IMAS concept, information about the virtual appearance of a user is also not based solely on data gathered during the communication processes between a user and services, but rather it is based on analysis of data that is publicly available on the Internet and linkable to a specific user. In fact, the information about a user's virtual appearance consists of an aggregation of any accessible PII that is linkable to a user. Hence, the information is not limited to what happens with specific pieces of PII revealed to a specific provider. In point of fact, an IMAS provides a similar perspective on a user's own PII, which is proliferated through Internet services, such as a third party that is able to gather it and link it to a physical person. In Section 4.2, we discuss existing knowledge that could serve as a basis for such a reactive capability to monitor flows of PII.

Contrasting provider-and user-based information management

The following section distinguishes between data flows controlled by identity management (IDM) systems, developed for and operated in an enterprise environment, and the proliferation of PII in the area of OSNs. First, we outline the concepts of identity management systems implemented at the Karlsruhe Institute of Technology (KIT), as well as related experiences to provide examples of provider engineered identity management processes. Subsequently, we try to identify parallels and differences between IDM systems and OSNs with respect to flows of data, as well as capabilities for monitoring and controlling such flows. Finally, we determine how we can learn from the experiences in implementing IDM in an enterprise environment to implement effective technical solutions to help users maintain privacy in OSNs.

Identity management and related experiences at KIT

At KIT, we started to establish identity management systems and services within a project called Karlsruhe Integrated Information Management (KIM). 7 Today, we operate a federated data provisioning that provides user attributes to IT services of the KIT [START_REF] Schell | Federated identity management as a basis for integrated information management[END_REF]. Federated provisioning constitutes a comprehensible, manageable and scalable identity management infrastructure. The distribution of PII and other attribute values is designed in a hierarchical fashion in order to maintain the independence and flexibility of the organizational units of the KIT. Figure 2 visualizes this federated provisioning approach. Authoritative resources provide user attributes to a central IDM system and this system prepares the data for sub-IDM systems and central services. Afterwards, the central IDM system distributes the data to the IDM systems of several organizational units, as well as to cross-organizational services. This system also makes the intended attributes available to SAML-based authentication and attribute delivery services in the form of a Shibboleth identity provider (IdP). This IdP is, inter alia, part of the largest German Authentication and Authorization Infrastructure (AAI) for academia, which is operated by the German National Research and Education Network. 8 Additionally, we provide an inner organizational service federation at KIT and we have recently become involved in a new identity management project of the state of Baden-Württemberg, Germany (bwIDM). This bwIDM project aims at expanding web-based authentication and authorization federations, such as Shibboleth AAIs to support federated access to non-web-based services, such as SSH consoles. In this context, SSH consoles are needed to access high performance, grid, and cloud computing resources.

Based on experiences related to the development of introduced components, we learned how to implement identity management systems and services so that data flows can be controlled and managed in an appropriate manner to maintain privacy and compliance. Furthermore, drawing from our experiences, we found that technical issues are often less challenging than issues regarding the coordination and control of implementing IDM-related business processes. In this regard, communication and interaction between federation participants within provider-based federations play an important role. Furthermore, data protection regulations (that are absolutely necessary) often lead to enormous overhead during process designs. In short, the implementation of provider-based federations takes time due to the overhead with regard to the extensive coordination required and the design of compliant processes. Moreover, due to the absence of standardized coordination structures to implement provider-based federations, some amount of overhead is unavoidable today.

Thus, from a technical point of view, today's developers know how to implement compliant IDM solutions. Furthermore, they are able to implement systems that guarantee user privacy inside organizational borders. Issues having to do with IDM in an enterprise environment are more or less concealed in the area of organization, the development of policies, and the collaboration of service providers and providers of IDM systems and services. In a broader sense, the real issues are shifting away from provider-based IDM to the federated management of services and, consequently, to a less technical area.

User-based federations

In turn, underlying difficulties and delays in implementing IDM services have inspired the popularity of services, in which the providers only offer the service itself, i.e., services that are provided without pre-configured data flows, such as in an enterprise IDM. Therefore, the configuration of data flows is not accompanied by the identified overhead of the provider-engineered IDM. In the following, we use the term user-based federation to include services and underlying processes that are not engineered solely by a provider, i.e., users are involved in the "implementation" of data flows and, therefore, in the proliferation of PII. For instance, Facebook provides the OSN as a service, users are responsible for the connections between entities. Therewith, they are "configuring" the underlying data flows. Moreover, user-based federations can be provided instantaneously because the users involved often do not have to communicate with each other to participate and interact. The operability of user-based federations does not depend on the functionality of the whole federation, i.e., the interconnectivity of every participant and the coordination of all participants at once. This might also be the reason why such user-based federations have recently become more popular.

The following example illustrates the user-based character of these services: It is possible to link the contacts stored on a smartphone with Facebook friends. If the friends update their email address, telephone number or other contact information via Facebook, this information is updated on every linked smartphone. This kind of feature forms a user-based federation because the implementation of the associated update functionality (a typical identity management service) largely takes place without the involvement of a provider. The corresponding processes, or rather the data flows, are not pre-engineered by a provider. Users initiate such processes, therefore, they may be involuntarily allowing such data flows. federation on the left side the picture. In contrast, the right side outlines userbased and incomprehensible data flows outside the borders of any organization or organizational federations, respectively. However, users are part of both sides, therefore the distinction between inside and outside becomes blurred. Thereby, the attractiveness of the outside is the simplicity of connecting to and exchanging information with other participants, which is completely the users' responsibility. The overhead regarding compliance and organizational efforts, as well as the communication between participating entities is reduced from the perspective of an OSN provider, as well as from the user's point of view. Otherwise, consolidated data flows inside organizational federations would be indispensable, particularly in light of the requirement to comply with data protection laws.

Contrasting inside and outside perspectives

The main similarity between provider-engineered and user-based federations is obvious as well: The implementation of both kinds of federations results in data flows that have to be monitored and controlled. However, if users are responsible for the configuration of data flows outside of organizational borders, to some extent, they are also responsible for ensuring privacy. On the other hand, if users establish federations in the above described manner, they have to be provided with features similar to those that developers and administrators are provided with. This implies that before a user-based federation is provided, the participants should be able to have an overview of the consequences of their participation. This feature would be similar to the overview that a developer has of the design and implementation of identity management processes. Compared to the monitoring and management capabilities available to administrators of provider-based federations, users also have to be provided with reactive features for the control of data flows after the implementation of a user-based federation. We stress the point that an Information Management Assistance System (IMAS) with proactive and reactive components has to be available to users to support them in the implementation of comprehensible data flows in terms of user-based federations and the ability to monitor the data flows afterwards.

Information Management Assistance System

As mentioned before, the requirements for an Information Management Assistance System are very similar to requirements in the field of enterprise identity management systems, apart from the fact that the roles of developer and administrator are not separate. In particular, the support required by users is similar to the technical support for people involved in the development and operation of enterprise IT.

Figure 4 shows the concept of an IMAS. The user is able to restrict the audience receiving the shared pieces of information. In the example given, a user shares information with a subset of his social network contacts, however, the information will not be spread via websites, blogs, etc. Moreover, the user is able to monitor the proliferation of shared information by use of the reactive components of an IMAS (also shown in Figure 4).

Since an IMAS has not yet been implemented, the question is whether there are disadvantages with such a system. A system that is able to reveal the proliferation of personal data could probably be used to link shared pieces of information to one another and to the user as a physical person. This function may constitute a threat for users if third parties are able to use an IMAS on the shared information of an arbitrary user. An IMAS would run in an environment that is far more open to the public than an enterprise IDM that is implemented inside a closed and secured network segment. Hence, the security requirements of an IMAS are different from the requirements of an enterprise IDM. The aim is to ensure that only the users themselves be able to gather their own proliferated PII and to link such pieces of information to one another.

Whether an IMAS could be implemented on a compliant basis is also questionable. In order to detect proliferating personal data, the shared information of several users would have to be analyzed to decide a specific piece of information is part of the data that a specific user has shared. The processing required of information shared by other users, who have not given their consent, would not be compliant with data protection laws, like the German Data Protection Act.

However, besides the aforementioned potential disadvantages, an IMAS includes a facility that could help users keep track of data proliferation and motivate them to apply their privacy settings more carefully. In the following, we discuss the differences between the required proactive features of an IMAS with user-centric approaches to identify the status quo of the capability of users to allow or deny access to PII before the data has been forwarded to a third party. Afterwards, we target the reactive facility of an IMAS and focus on what can be learned from our previous studies. In particular, we outline the building blocks for reactive components based on the results of the investigation presented.

Contrasting an IMAS with user-centricity and transparency enhancing technologies

As described above, an IMAS should have proactive and reactive components. Currently, the proactive part is more or less known in terms of the efforts regarding user-centricity [START_REF] Bhargav-Spantzel | User centricity: A taxonomy and open issues[END_REF]. Authentication and authorization frameworks of projects, such as the Kantara Initiative UMA, 9 OAuth, 10 and OpenID, 11 to name just a few, often include a proactive information management component, which can be adjusted to deny or allow third parties access to the PII requested. Due to the multitude of proactive components that come up with the aforementioned approaches, adjusting the provided settings adequately can be a challenge to users. User-controlled Automated Identity Delegation (UCAID) is an extension of user-centric federated identity management systems. With UCAID, users no longer have to approve each dissemination of information manually. UCAID ensures user control by means of user-defined dissemination policies [START_REF] Höllrigl | User-controlled automated identity delegation[END_REF].

These tools and standards enable users to allow or to deny third party providers to get the specific information requested. However, the implications of granting permission to access personal data are often not clear to users because today's tools only show that data is to be shared. The intended purpose of shared data is not displayed and if it is, is only implicitly comprehensible. Moreover, third party providers often request most of potentially available information and users merely be able to accept these request in their entirety.

It is not possible to pick and choose which information will be shared with a third party. Furthermore, without sharing all of the information requested, most services cannot be used. This is why the previously mentioned EU research projects determined that there is a need for transparency enhancing technologies (TETs). TETs provide more sophisticated possibilities for monitoring and adjusting access rights to PII compared to the current user-centric authentication and authorization frameworks. As discussed in Section 2, these projects developed several approaches to support users in maintaining an overview of the audiences and service providers that were given specific pieces of PII and who are potentially able to access this shared information. However, such capabilities cannot guarantee, or rather monitor, whether the PII is forwarded and re-posted by third parties, such as users or service providers who have access to the information. Due to the fact that shared PII proliferates through social networks and does not usually stay within the context of the intended audience or service, we see the need to monitor the proliferation of PII in a broader manner compared to previous approaches of TETs. In the following, we outline knowledge that could serve as a basis for a more sophisticated monitoring capability.

A building block for reactive IMAS components

In contrast to approaches of proactive capabilities to control data flows, reactive components are not implemented today. Currently, users are not able to maintain an overview of the providers and users who received their personal data and therefore cannot know who has access to it, respectively.

In [START_REF] Labitzke | What your friends tell others about you: Low cost linkability of social network profiles[END_REF], we investigated an approach to demonstrate to users that their OSN profiles can be linked. We showed that several OSN profiles of a single physical person can be linked by third parties on the basis of comparisons between user friends lists. We argue that profile linking could be used to show users their own virtual appearance. Hence, users will be able to get bold and simple insights to information that could be linked to themselves. Therefore, this feature shows that gathering comprehensive information about users also presents opportunities for third parties.

Today's OSN users are not aware of how much information they reveal to third parties, especially considering the aforementioned linkability. The efforts to federate the social web by conducting several OSNs could facilitate the linkability of OSN profiles and consequently the linkability of the PII of OSN users. As a result, users will be even less able to keep an overview of the information proliferating through OSNs. Thus, there will be an ongoing need to monitor the proliferation of shared information. In this context, the linkability study could form a building block for a reactive IMAS component.

Conclusions

In this conceptual paper, we pointed out that people are unduly generous in sharing personally identifiable information via online social networks and that adequate risk awareness regarding privacy does not yet exist. Consequently, we stated the necessity of a personal Information Management Assistance System (IMAS). An IMAS should enable online social network users to control who will receive their shared data before they share information and monitor the flows afterwards. In comparison to federated enterprise identity management systems, such an IMAS would have monitoring capabilities that are analogous to the administrator's view of data flows. Furthermore, an IMAS should include capabilities that are similar to those of developers to implement controlled federated processes. We related the approaches of user-centricity and transparency enhancing technologies even further with the vision of an IMAS. We discussed the disadvantages of approaches for proactive IMAS components and showed that the approaches of reactive components do not go far enough in supporting a user sufficiently according to the requirements discussed. To this end, we presented parts of the insights that we gained from a study on the linkability of online social network profiles [START_REF] Labitzke | What your friends tell others about you: Low cost linkability of social network profiles[END_REF]. On the basis of this information, linkability to a feature could be implemented, which helps users to maintain an overview of third parties that are authorized to access shared information. However, the current building blocks of an IMAS (proactive and reactive components) are more or less isolated applications that do not fulfill all of the requirements identified. The biggest challenge is to combine, as well as improve the applications, projects and efforts mentioned in an integrative manner.

Acknowledgement

We would like to thank the anonymous reviewers for their invaluable comments.

Fig. 2 .

 2 Fig. 2. Identity Management at Karlsruhe Insitute of Technology (KIT)

Figure 3 Fig. 3 .

 33 Figure 3 visualizes the organized, consolidated, and provider-engineered data flows managed and controlled inside organizational borders or within a distinct

Fig. 4 .

 4 Fig. 4. Structure of an Information Management Assistance System

We published a similar, but less comprehensive position paper on the workshop on the Federated Social Web (FSW), June

2011, Berlin, Germany.

https://www.facebook.com/press/info.php?statistics.

https://www.prime-project.eu/.

http://www.primelife.eu/.

http://www.xmlgrrl.com.

http://www.picos-project.eu/.

http://kim.cio.kit.edu/.

Das Deutsche Forschungsnetz (DFN).

http://kantarainitiative.org/confluence/display/uma.

http://oauth.net/.

http://openid.net/.