Enforcing Access Control in Web-based Social Networks

Transcription

1 Enforcing Access Control in Web-based Social Networks BARBARA CARMINATI, ELENA FERRARI, and ANDREA PEREGO DICOM, Università degli Studi dell Insubria, Varese, Italy In this paper, we propose an access control mechanism for Web-based Social Networks, which adopts a rule-based approach for specifying access policies on the resources owned by network participants, and where authorized users are denoted in terms of the type, depth, and trust level of the relationships existing between nodes in the network. Differently from traditional access control systems, our mechanism makes use of a semi-decentralized architecture, where access control enforcement is carried out client-side. Access to a resource is granted when the requestor is able to demonstrate of being authorized to do that, by providing a proof. In the paper, besides illustrating the main notions on which our access control model relies, we present all the protocols underlying our system and a performance study of the implemented prototype. Categories and Subject Descriptors: H.3.5 [Information Storage and Retrieval]: Online Information Services Data Sharing; Web-based Services; K.6.5 [Management of Computing and Information Systems]: Security and Protection General Terms: Design, Theory Additional Key Words and Phrases: Access Control, Semantic Web, Social Networks 1. INTRODUCTION Web-based Social Networks (WBSNs) are online communities that allow users to publish resources and to record and/or establish relationships with other users, possibly of different type ( friend, colleague, etc.), for purposes that may concern business, entertainment, religion, dating, etc. Recently, the usage and diffusion of WBSNs have been increasing, with about 300 Web sites collecting the information of more than 400 millions registered users. 1 The net model is today more and more used also by companies and organizations to communicate, share information, making decisions, and doing their business. Regardless of the purpose of a WBSN, one of the main reasons for participating is to share and exchange information with other users. Recently, the adoption of Semantic Web technologies, such as FOAF (Friend of a Friend) [Brickley and 1 See: Authors addresses: B. Carminati, E. Ferrari, and A. Perego, Dipartimento di Informatica e Comunicazione, Università degli Studi dell Insubria, Via Mazzini 5, Varese, Italy; {barbara.carminati, elena.ferrari, andrea.perego}@uninsubria.it. Permission to make digital/hard copy of all or part of this material without fee for personal or classroom use provided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/server notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or a fee. c 20YY ACM /20YY/ $5.00 ACM Journal Name, Vol. V, No. N, Month 20YY, Pages 1 40.

2 2 Barbara Carminati et al. Miller 2007; Ding et al. 2005], has simplified information access and dissemination over multiple WBSNs. If this has been quite a relevant improvement towards an easier sharing of information, it is now necessary that information owners have more control over its diffusion. So far, this issue has been addressed by most of the available Social Network Management Systems (SNMSs) by allowing a user to specify whether a given piece of information (e.g., personal data and resources) must be public, private, or accessible only by the users with whom he/she has a direct relationship, or by providing simple variants to this basic setting. Such simple access control paradigm has the advantage of being straightforward and easy to be implemented, but it suffers from several drawbacks. On one hand, it may either grant access to non-authorized users or limit too much information sharing, and, on the other hand, it is not flexible enough to express the heterogeneous access control requirements that different WBSN users may have. For instance, such access control paradigm does not take into account the type of the relationships existing among users. Consequently, it is not possible to state access control policies such as only my friends or my colleagues can access a given piece of information. We think that more sophisticated access control mechanisms should be designed for current WBSNs. Besides relationships, some other information can be used for access control purposes. In fact, also the depth of a relationship i.e., the length of the shortest path(s) between two nodes in the graph representation of a WBSN may be a useful parameter to customize access control policies, in that it allows one to control the propagation of access rights in the network. Moreover, in some WBSNs, users can specify how much they trust other users, by assigning them a trust level. Such information is currently exploited for purposes that encompass the primary objectives of a WBSN, e.g., as a basis for recommender systems [Adomavicius and Tuzhilin 2005], but we believe it can be used as well to denote the users authorized to access a resource in terms of their trustworthiness. In this paper, we propose a discretionary access control model and a related enforcement mechanism for controlled sharing of information in WBSNs. The model allows the specification of access rules for online resources, where authorized users are denoted in terms of the relationship type, depth, and trust level existing between nodes in the network. In devising the related enforcement mechanism, we adopt a semi-decentralized strategy, where, differently from traditional information management systems, each participant is in charge of specifying and enforcing access control policies. As clarified in Section 4, this solution is semi-decentralized in that we assume the presence of a repository managing certificates concerning the existing relationships. Indeed, due the increasing concerns about privacy in WBSNs, we believe this solution is a good trade-off between efficiency and scalability, and the emergent wish of users to have more control over their data. In the paper, besides describing the access control model and the related access control mechanism, we illustrate the prototype implementation we have developed and the performance evaluation we have carried on. Moreover, we present the security analysis of the proposed protocols. This paper extends the work reported in [Carminati et al. 2006], where the access control model has been proposed. [Carminati et al. 2006] focuses only on the access control model, but no details are provided on access control enforcement. Here, we

3 Enforcing Access Control in Web-based Social Networks 3 extend such work with the definition of two protocols for certifying relationships and enforcing access control, and with a performance evaluation of the implemented system. Moreover, we perform a security analysis of our protocols that shows that they are robust to the main security threats. The remainder of this paper is organized as follows. Section 2 discusses related work and provides an overview of existing WBSNs. Section 3 introduces the WBSN model we use throughout the paper and discusses WBSNs access control requirements. Section 4 presents the proposed access control model. The enforcement mechanism is illustrated in Section 5. Sections 6 and 7 describe, respectively, the protocols for relationship certificate management and access control enforcement. Security issues concerning our protocols are discussed in Section 8. Section 9 illustrates the prototype implementation, whereas Section 10 deals with performance evaluation. Finally, Section 11 concludes the paper and outlines future research directions. The notation used throughout the paper is reported in Appendix A, whereas Appendices B and C illustrate, respectively, the usage of Notation 3 Logic (N3) [Berners-Lee et al. 2008] for representing relationships and access rules, and the performance of the reasoner used in our system to generate a proof. 2. RELATED WORK In this section, we first overview the characteristics of current WBSNs, and then we discuss related work in the area of WBSN security and trust. 2.1 An Overview of Existing WBSNs Usually, a social network is defined as a small world network[watts 2003], consisting of a set of individuals (persons, groups, organizations) connected by personal, work, or trust relationships. Social networking is then quite a broad and generic notion which, in the Web context, might be applied to any kind of virtual community. When a user registers to a WBSN, the system gives him/her an account (also called profile), where he/she will be able to insert personal information, specify relationships with other users, and, in some WBSNs, manage personal resources (such as blogs, photos, video and audio files). Usually, a WBSN member can also decide which personal information, relationships, and/or resources are accessible by other members. The basic protection options are to mark a given item as public, private, or accessible by direct contacts. In order to give more flexibility, some WBSNs enforce variants of this setting. For instance, besides the basic setting, Bebo ( Facebook ( and Multiply ( multiply.com) support the option selected friends (selected contacts); Last.fm ( supports the option profile neighbors (i.e., the set of WBSN members, computed by the SNMS, having musical preferences and tastes similar to mine); Facebook, Friendster ( and Orkut ( orkut.com) support the option friends of friends (2nd degree contacts); Xing ( supports the options contacts of my contacts (2nd degree contacts), and 3rd and 4th degree contacts ; LinkedIn ( com) and Multiply support the option my network (nth degree contacts i.e., all the WBSN members whom I am either directly or indirectly connected to, independently from how distant they are). It is important to note that all these approaches have the advantage of being easy to be implemented, but they lack

4 4 Barbara Carminati et al. flexibility. In fact, the available protection settings do not allow users to easily specify their access control requirements, in that they are either too restrictive or too loose (e.g., the options 1st degree contacts and my network in LinkedIn). Which types of personal/work relationships are supported depends on the purposes of a WBSN, and on how relationships are used. For instance, WBSNs aimed at connecting and finding friends, such as Friendster, Facebook, and Bebo, and those with entertainment purposes, such as Last.fm, support just the friend relationship type. Some WBSNs with business purposes, like Xing, support a single, generic, relationship type, denoting the fact that I know a given person. In contrast, some other WBSNs provide a wider range of choices among personal and/or work relationships. Typical examples are LinkedIn, which gives its members the possibility of choosing among colleague, classmate, business partner, friend, groups and associations, other, and even I don t know X, and Multiply, which supports more than 30 relationship types, grouped into the following categories: friend, online buddy, family, and professional contact. Some WBSNs give their members also the ability of specifying how much they trust other members, thus establishing trust relationships. This can be done either by expressing a recommendation, or by rating other users according to a numeric scale. An example of WBSN supporting recommendations is LinkedIn, where a free text label can be associated with a user, explaining why he/she is recommended by another user. In contrast, in Orkut and RepCheck ( users trust can be expressed according to a numeric scale. The semantics of trust varies depending on the specific purposes of a WBSN: for instance, Orkut allows its members to rate personal trust, whereas RepCheck supports both personal and business trust. As far as relationship specification is concerned, it is currently a common practice to require the consent of both members before recording a new relationship. Usually, if a member A asks to create a relationship with another member B, the system sends B an asking for a confirmation. This procedure is adopted for both personal and work relationships in all the WBSNs we have reviewed, and it is also the approach we adopt in our system. In contrast, a trust relationship does not need the consent of the trustee to be established, but he/she is however notified of being rated, and he/she will be able to verify who has posted the rating and the rating value itself. Table I summarizes the characteristics of the WBSNs we have reviewed. 2.2 WBSN Security So far, research on WBSN security has mainly focused on privacy-preserving techniques to allow statistical analysis on social network data without compromising WBSN members privacy (see Carminati and Ferrari [2008] for a survey on this topic). In contrast, access control in WBSNs is a new research area. As far as we are aware, the only other proposals are the ones by Hart et al. [2007], Ali et al. [2007], and the D-FOAF system [Kruk et al. 2006]. In their position paper, Hart et al. [2007] discuss the access control requirements of WBSNs, and they argue that existing WBSN relationships can be used to denote authorized members. However, only direct relationships are considered, and the

5 Enforcing Access Control in Web-based Social Networks 5 Table I. WBSNs characteristics. ith degree contacts denotes WBSN members whose distance in the network graph is equal to i; nth degree contacts denotes WBSN members connected by paths of undefined length; online contacts denotes people known online, but who are not real world contacts. WBSN Purpose Relationships Trust Protection Options Bebo general friend none Facebook general friend none Friendster general friend none MySpace general friend none Multiply general various none Orkut general friend personal Flickr photos friend/family none Last.fm music friend none Xing business generic none LinkedIn business various business RepCheck reputation generic personal, business public, private, 1st degree contacts, selected contacts public, private, 1st-2nd degree contacts, selected contacts members from selected continents, private, 1st-2nd degree contacts public, members > 18 years old, private, 1st degree contacts public, private, 1st and nth degree contacts, 1st degree but not online contacts, selected contacts public, private, 1st-2nd degree contacts public, private, 1st degree contacts (friends or family) public, private, 1st degree contacts (and profile neighbors) public, private, 1st-4th degree contacts public, private, 1st and nth degree contacts none notion of trust level is not not taken into account as one of the possible parameters to be used in access authorizations. Differently from our proposal, Ali et al. [2007] adopt a multi-level security approach, where trust is the only parameter used to determine the security level of both users and resources. More precisely, to each user u a reputation value r(u) is assigned, computed as the average of the trust ratings specified for him/her by other users in the system. After having logged in, user u chooses an operating trust level τ, such that 0 τ r(u). A resource o created by user u will then be assigned a confidence level equal to τ, whereas user u can read only resources with confidence levels equal to or less than τ. Access control is enforced according to a challenge-response based protocol. For each resource o, the resource owner generates a secret key K, which is then processed by the (k,n) threshold algorithm proposed by Shamir [1979]. The basic principle of such algorithm is that a key K can be split into n portions and then reconstructed based only on k portions of it, where k < n. In [Ali et al. 2007], the n portions of K are distributed to n trustworthy nodes. If a requestor wishes to access resource o, the resource owner sends him/her the challenge encrypted with K. Then, the requestor retrieves the k portions of K from the set of n nodes holding them. Such portions are released only if the requestor satisfies the trust requirements specified by the resource owner. Once the requestor has reconstructed K, he/she responds to the challenge, and gains access to the resource. The main difference between the approach described above and our proposal is that Ali et al. [2007] consider only direct trust relationships, whereas we consider (a) both direct and indirect relationships, and (b) both personal and trust relationships. This has the advantage of giving resource owners the ability to specify more flexible policies, making them able to better denote the constraints to be satisfied by users in order to access a resource. Another relevant difference is that we adopt a discretionary access control paradigm, whereas Ali et al. [2007] a mandatory one.

6 6 Barbara Carminati et al. Finally, the D-FOAF system, described by Kruk et al. [2006], is primarily a FOAF-based distributed identity management system for social networks, where access rights and trust delegation management are provided as additional services. In D-FOAF, relationships are associated with a trust level, which denotes the level of friendship existing between the users participating in a given relationship. Although Kruk et al. [2006] discuss only generic relationships, corresponding to the ones modeled by the foaf:knows RDF property defined in the FOAF vocabulary [Brickley and Miller 2007], another D-FOAF-related paper [Choi et al. 2006] considers also the case of multiple relationship types. As far as access rights are concerned, they denote authorized users in terms of the minimum trust level and maximum length of the paths connecting the requestor to the resource owner. Such an approach shares some similarities with ours, in that we also associate trust levels with relationships, and we express access control policies in terms of the minimum trust level and maximum distance of the paths existing between two WBSN members. However, there also exist several relevant differences. As we argue later in this paper (see Section 4), in a relationship-based access control system, it is necessary to enforce a mechanism able to prevent forging of fake relationships. We address this issue by requiring that relationships are established only with the mutual consent of the involved WBSN members. Moreover, relationships are encoded into relationship certificates, hosted by a trusted third party, referred to as certificate server. In contrast, D-FOAF does not consider at all these issues. Another difference concerns access control policies. In D-FOAF, the relationships required to access a given resource always concern the requestor and the resource owner, whereas in our model we do not have such constraint. Moreover, in our model, policies are expressed not only in terms of the trust level and length of paths connecting two members, but also in terms of the type of relationship they denote. As mentioned previously, Choi et al.[2006] consider also the case of multiple relationship types, but they do not illustrate how this affects the access control model described by Kruk et al. [2006]. Finally, Kruk et al. [2006] do not discuss the case of multiple policies associated with the same resource, whereas our model supports the possibility of combining policies by using the AND and OR Boolean operators (see Section 5). The last main difference concerns access control enforcement. In D-FOAF, both path discovery and access control are enforced by the D-FOAF SNMS hosting the resource owner account. In contrast, in our system, we separate these tasks. Path discovery is performed by the certificate server, whereas, access control is enforced based on a rule-based approach, according to which is the requestor who must provide to the resource owner a proof of being authorized to access the requested resource (see Section 4). As we argue later in this paper (see Section 3.2.2), we think that such an approach is more suitable to WBSNs than the centralized one adopted by D-FOAF. 2.3 Trust An analysis of the related literature shows that there does not exist a unique definition of trust, since it may vary depending on the context and for which purposes it is used. This affects also how trust is computed and expressed, whether it is a local or global measure of the trustworthiness of a given entity, and whether trust rela-

7 Enforcing Access Control in Web-based Social Networks 7 tionships are explicitly or implicitly established. In this section, we first overview the different solutions adopted so far for trust representation and computation, then we discuss the specific requirements of trust modeling in our access control system Trust Representation and Computation. Although the notion of trust is often associated with the one of reputation, there exists a relevant difference between the two concepts. As pointed out by Jøsang et al. [2007], trust denotes whether, and, possibly, how much, a given entity A considers trustworthy another entity B. As such, it expresses a personal opinion of A about B, and thus trust can be considered as a subjective (or local) measure of trustworthiness. In contrast, reputation denotes the trustworthiness of a given entity for all the entities in a network. As such, it expresses the collective opinion of a community on one of its members, and thus it is an objective (or global) measure of trustworthiness. Note that here subjective does not mean arbitrary. Rather, it denotes an opinion based on the observations made by a given entity A on another entity B. Similarly, objective is used to denote an opinion based on the observations made by all the entities in a network about B. The definitions above have two main implications. First, whether trust or reputation are used in a system depends on whether personal opinions or tastes are relevant or not. For instance, in a WBSN supporting collaborative rating of books or movies, reputation can be a measure of the expertise of a given user on a given topic. However, independently from a user s reputation, I can consider him/her as untrustworthy, because his/her tastes are different from mine, and thus he/she will give a bad rating where I would give a good one. In contrast, reputation is useful when there exist precise requirements to be satisfied in order to be considered as trustworthy. A typical example is the one of P2P (Peer-to-Peer) systems, where the trustworthiness of a given peer depends on its reliability in providing a given service. The second implication is that the notions of trust and reputation are not disjoint, since reputation is derived from the trust relationships existing between entities in a network. This means that, in general, reputation can be computed after having evaluated trust relationships. As an example, both the EigenTrust [Kamvar et al. 2003] and PeerTrust [Xiong and Liu 2004] algorithms, designed for P2P environments, consist of two main steps: first they compute the trust existing between peers, and then they use this to compute the reputation of each peer in the network. A similar approach is adopted also by the RepCheck social network (see Section 2.1). The access control framework we present falls under the class of trust systems. In our approach, each WBSN member uses trust as one of the parameters for denoting the members authorized to access his/her resources. Therefore, in such a scenario, we believe that WBSN members trustworthiness cannot be assessed by a collective measure. For these reasons, in this section we focus on how trust is represented and computed, whereas we do not discuss the corresponding issues related to reputation. A trust relationship is usually modeled as a directed edge, connecting two entities A and B, labeled with information stating whether, and, possibly, how much, A considers B trustworthy. The directed edge models a specific property of trust, i.e., its asymmetric nature. In fact, if A trusts B, it does not necessary follow that B trusts A. Different approaches have been proposed so far to represent

8 8 Barbara Carminati et al. trust. The most accurate is probably the one making use of belief calculus, and, in particular, subjective logic (see, e.g., [Jøsang 1999] and [Jøsang et al. 2006]), where trust relationships are modeled based on three parameters, namely, belief, disbelief, and uncertainty. Despite the accuracy of such an approach, the most diffused trust measures are based on a single trust value, which may be either scalar or binary. Scalar trust relationships make use of a range of either continuous or discrete values, denoting how much A considers B as trustworthy. This includes also ordered set of trust levels, as in the PGP (Pretty Good Privacy) web of trust [Garfinkel 1996]. In contrast, binary trust relationships make use of a binary value t {0,1}, which denotes whether B is considered trustworthy (t = 1) or not (t = 0) by A. As such, binary trust can be considered a particular case of scalar trust, and it is usually adopted in environments with restrictive trust requirements, such as PKIs (Public Key Infrastructures). Some P2P systems and WBSNs adopt binary trust relationships, but for different reasons. In WBSNs, this is just a way to make as simple as possible the task of trust specification (see, e.g., [Golbeck and Hendler 2006]), whereas, in some P2P file-sharing services, a peer providing even only one fake or corrupted file, is unreliable, and thus it is considered as totally untrustworthy (see, e.g., [Xiong and Liu 2004]). In contrast, scalar trust relationships can be used to rank entities based on their trustworthiness, making other entities able to decide which is the threshold that makes an entity trustworthy or not. Examples of this approach are provided by both P2P systems (see, e.g., [Kamvar et al. 2003]) and WBSNs (see, e.g., [Avesani et al. 2005; Golbeck 2005; Kruk et al. 2006; Choi et al. 2006]). So far, we have discussed only direct trust relationships. However, the above considerations can be extended to relationships corresponding to paths of lengths > 1. This implies considering trust relationships as transitive. However, even if it is true that trust is not necessary transitive i.e., if A trusts B and B trusts C, it does not necessary follow that A trusts C trust paths may be useful to predict the trustworthiness existing between entities not directly connected. More precisely, the notion of transitive trust relies on the assumption that, if trust relationships exist between entities A and B, and B and C, but not between A and C, then it is possible to use the trust path ABC to determine whether and/or how much A considers C trustworthy. Computation of transitive trust has been investigated in different fields, comprising federated PKIs, P2P systems, and social networks. The main issue concerns which trust paths must be considered in order to obtain an accurate trust value, since multiple paths may exist connecting two entities. Several solutions have been proposed so far, and, usually, they enforce some constraints in order to select just some of the existing paths. For instance, Beth et al. [1994] discard trust paths with either maximum or minimum trust values, whereas Reiter and Stubblebine [1997] do not consider trust paths having a length greater than a given bound b. Constraints on the maximum path length are also used by the MoleTrust [Avesani et al. 2005] and TidalTrust [Golbeck 2005] algorithms, where, in addition, the exploration of the network graph terminates as soon as all the shortest trust paths have been discovered. MoleTrust and TidalTrust introduce also the notion of trust threshold, which is used to select the trust relationships to be considered. The constraint on

9 Enforcing Access Control in Web-based Social Networks 9 the maximum length of trust paths is motivated by claiming that the reliability of propagated trust decreases as the length of the considered trust path increases. Golbeck [2005] provides also experimental results supporting this claim. Finally, the D-FOAF system [Kruk et al. 2006; Choi et al. 2006] adopts a simpler approach according to which the trust level of a relationship existing between two WBSN members is determined by the path having the highest trust level among those of a given maximum length. The paths trust levels correspond to the product of the trust levels associated with their edges Trust in WBSNs. Golbeck [2005] discusses how trust is and could be used in WBSNs. In particular, she motivates the adoption of either binary or scalar trust relationships, instead of more sophisticated approaches (such as the one based on subjective logic), by claiming that the semantics of trust must be clear to average Web users, as WBSN members are, and that the task of trust specification must be as simple as possible. Although Golbeck [2005] focuses on WBSNs for collaborative rating, we believe that such considerations apply also to our access control scenario. As it will be illustrated in the following sections, in our approach trust is one of the factors that determines whether a given WBSN node is authorized to access a given resource. Clearly, in our scenario trust has a different meaning from the one used in collaborative rating WBSNs. Trust should mainly convey information about how much confidence a user has that another user does not disclose sensitive information to unauthorized users, and thus its purpose has some similarities with the notion of security level used in mandatory access control models (see [Ferrari and Thuraisingham 2000] for a survey on this topic). For these reasons, in our model we use a new type of trust levels, called security trust levels, which are represented by the range of rational numbers between 0 and 1. Note that such definition of trust differs from the one adopted in D-FOAF [Kruk et al. 2006], where trust levels model friendship degrees and are used both for access control purposes and collaborative filtering, thus merging two notions of trust However, similarly to D-FOAF, we do not consider trust relationships as independent from personal relationships, which is the approach usually adopted. In fact, when sharing resources, a user usually has in mind a specific audience, which, in a WBSN, is determined on the basis of personal direct or indirect relationships. For instance, some resources are meant for friends and should not be accessed by colleagues (or vice versa). From this follows also that there may exist different trust relationships with the same user. As an example, suppose that I have both a relationship of type friendof and colleagueof with a given user: the confidence I have with him/her as a friend rather than as a colleague may be different, since it depends on the context (free time vs. work activities) and on the set of resources to be disclosed (recreative vs. business documents). Consequently, we model trust as a property of personal relationships. Therefore, trust transitivity is related to the transitivity of personal relationships. In other words, there exists a trust path between two WBSN nodes A and B, only if such path consists of edges denoting the same type of relationship. Finally, considering the purpose for which trust relationships are used in our context, it is preferable to let resource owners explicitly specify how much they trust possible requestors, instead of implicitly deriving

10 10 Barbara Carminati et al. their trustworthiness from other information (which, however, can be used by the resource owner to help him/her in the computation of the trust value). As far as the computation of transitive trust is concerned, our purpose is to avoid bounding our system to a specific algorithm, with the only constraint that, following Avesani et al. [2005] and Golbeck [2005], only the shortest trust paths are considered. Therefore, to be as general as possible, currently, our system separates path discovery from trust computation. As it will be illustrated in Section 7.2, our algorithm consists of two steps. First, it discovers all the shortest paths, independently from their trust values, and then it computes transitive trust. This approach differs from the one adopted by some trust computation algorithms, such as MoleTrust and the one adopted in D-FOAF, where trust is used as a search parameter. This choice makes us also able to test the performance of our system (cfr. Section 10) by considering the worst case (i.e., the absence of threshold). However, as it will be clearer in the remainder of the paper, other approaches for trust computation can be easily adopted as well without too much impacting our system. In the current version of our system, we adopt the variant of the TidalTrust algorithm granting the best accuracy in trust computation [Golbeck 2005]. First, all the shortest paths are discovered. Then, they are processed in order to set a trust threshold maxt, which is used to discard trust paths consisting of edges with a trust value less than maxt. More precisely, given two nodes v and s, connected by one or more trust paths of length 2, the predicted trust existing between v and s, denoted t v,s, is computed as follows: t v,s = u N t v,u maxt t v,ut u,s u N t v,u maxt t v,u (1) where t v,u (t u,s ) denotes the trust value of the relationships existing between nodes v andu(uands), whereasn denotesthesetofnodeswithanincomingedgeexiting from v. If the distance between v and s is greater than 2, the formula above is applied recursively, until the predicted trust existing between v and s is computed. The trust threshold maxt is computed as follows. For each of the discovered paths, all its edges, except the one entering in s, are evaluated to compute the path s strength, that is, the minimum trust value associated with such edges. Then, the trust threshold maxt is set to the strength of the strongest path. For instance, considerthefollowingtrustpathsabcs andades, suchthatt A,B = 0.2, t B,C = 0.8, t A,D = 0.4, and t D,E = 0.6. In such a case, the strength of ABCS is equal to 0.2, whereas the strength of ADES is 0.4. Consequently, the trust threshold is set to 0.4. Trust is then computed by considering only the paths with a strength equal to or greater than the trust threshold (i.e., only ADES will be considered). 3. BACKGROUND & REQUIREMENTS In this section, we first introduce the formal model of WBSN used throughout the paper, then we discuss access control requirements for WBSNs.

11 Enforcing Access Control in Web-based Social Networks 11 C (friendof, 0.7) (friendof, 1) F (friendof, 0.6) (friendof, 0.6) (friendof, 0.8) A (friendof, 0.2) (colleagueof, 0.4) D (friendof, 1) (colleagueof, 1) G (friendof, 0.8) (colleagueof, 0.1) (colleagueof, 0.9) (colleagueof, 0.8) B (colleagueof, 0.3) E Fig. 1. A subgraph of a WBSN. Labels associated with edges denote the type and trust level of the corresponding relationship. 3.1 Preliminary Notions Similarly to other networks, a WBSN can be represented as a graph, where each node denotes a user in the network, whereas edges represent the existing relationships between users, and their trust levels. Edge direction denotes which node specified the relationship and the node for which the relationship has been specified, whereas the label associated with each edge denotes the type of the relationship. Moreover, we associate a trust level t with each edge. The number and type of supported relationships depends on the specific WBSN and its purposes; our only assumption is that there exists at least one relationship type. We also assume that, if RT denotes the set of supported relationship types, given two nodes A,B SN, there may exist at most RT edges from A to B (from B to A, respectively), all labeled with distinct relationship types. We can now formally define a WBSN as follows. Definition 3.1 WBSN. A WBSN SN is a tuple (V SN,E SN,RT SN,φ SN ), where RT SN isthesetofsupportedrelationshiptypes, V SN ande SN V SN V SN RT SN are,respectively,thenodesandedgesofadirectedlabeledgraph(v SN,E SN,RT SN ), whereas φ SN : E SN [0,1] is a function assigning to each edge e E SN a trust level t, which is a rational number in the range [0,1]. An edge e = vv E SN expresses that node v has established a relationship of a given type rt e RT SN with node v. We say that such relationship, denoted rt(v,v ), is direct, since v and v are directly connected by edge e. As an example, consider the WBSN depicted in Figure 1, where Alice (A) has a direct relationship of type friendof and trust level 0.6 with Carl (C). Note that, in a given WBSN SN, multiple paths may exist between two nodes, denoting the same type of relationship. For instance, in the WBSN depicted in Figure 1, four paths exist from Alice to David (D) denoting a relationship of type friendof namely, ABD, ACD, ACFD, and ACFGD. As discussed in Section 2.3, trust computation is more accurate when only the shortest paths are taken into account. As such, we adopt this approach throughout the paper. Therefore, we extend the notion of relationship by saying that a relationship rt(v,v ) is the set of all the shortest paths from v to v consisting of edges labeled with relationship type rt.

12 12 Barbara Carminati et al. Besides type and trust level, relationships have a further property, i.e., their depth. The depth d rt(v,v ) N of a relationship rt(v,v ) corresponds to the length of any of the paths in rt(v,v ). In contrast, the trust level of rt(v,v ), denoted t rt(v,v ), is computed by using formula 1 in Section Requirements for Access Control in WBSNs As discussed in Section 2.1, currently, most WBSNs enforce very simple mechanisms for controlling access to resources. Such simple access control mechanisms have the advantage of being straightforward to be implemented, but they are not flexible enough in denoting authorized users. Therefore, in this section we first discuss requirements that an access control model for WBSNs should satisfy. We then point out some relevant issues related to access control enforcement Access Control Model Requirements. In what follows, we consider the WBSN depicted in Figure 1 by analyzing different scenarios with varying access control requirements. Suppose, for instance, that Alice is the owner of a set of resources R A, and that she wishes to share them with some of her friends. In this simple scenario, standard access control policies provided by Database Management Systems (DBMSs) fit very well. Indeed, since an access control policy basically states who can access what and under which modes, and since Alice knows a priori her friends, she is able to set up a set of authorizations to properly grant the access only to (a subset of) her friends. However, if we consider a more general scenario, the traditional way of specifying policies is not enough. For instance, let us suppose that Alice decides to make available her resources not only to her friends, but also to their friends, the friends of their friends, and so on. The problem is that Alice may not know a priori all her possible indirect friends, and thus she may not be able to specify a set of access control policies applying to them. Additionally, even if she knew all of them, she should specify a huge number of policies. Moreover, if we consider that relationships among users of a WBSN could change dynamically over time, this solution implies a complex policy management. An access control model for WBSNs should therefore take into account that usually a node in the network wishes to share its data with other nodes on the basis of both direct and indirect relationships existing among them. Therefore, a first requirement that we need to address is supporting access control based on users relationships and their types. Let us consider again the WBSN depicted in Figure 1, and assume once again that Alice wishes to share her data with some of her direct and indirect friends. In particular, she wants to grant access to Bob (B) and Carl, since they are direct friends of hers. She wants to allow also David and Fred (F) to access her data, even if Alice does not know them directly, because they are direct friends of Bob and Carl. In contrast, Alice may not want to give Greg (G) access to her resources, since she does not know how Fred chooses his friends. In conclusion, when considering a WBSN, the length of the path connecting two nodes (i.e., the depth of a relationship) is a relevant information for access control purposes. Thus, an access control model for WBSNs should make a user able to state in a policy not only the type but also the maximum depth of a relationship. Although the notions of depth and trust may be related, they are not equivalent.

13 Enforcing Access Control in Web-based Social Networks 13 For instance, let us suppose that Alice does not trust Bob very much, and that, in contrast, she considers Carl highly trustworthy. In this case, the depth of the relationship is the same for both Bob and Carl, but the trust level is different. Therefore, access control policies should support also constraints on the minimum trust level of a relationship Access Control Enforcement Requirements. Usually, access control is enforced by a software module, called reference monitor, that intercepts each access request submitted to the system and, on the basis of the specified access control policies, determines whether the access can be partially or totally authorized, or it must be denied. Therefore, the robustness of access control relies on the trustworthiness of the entity implementing the reference monitor, which should correctly enforce all and only the specified access control policies. As a consequence, when designing an access control enforcement mechanism for WBSNs, one has to decide where the reference monitor has to be placed, that is, which is the trusted entity of the WBSN architecture in charge of evaluating access control policies. A first possibility is to delegate to the SNMS the role of reference monitor. According to this choice, users have to completely delegate the control of their data to the SNMS, by simply stating how data must be released to other network nodes. In this scenario, to which we refer to as centralized access control enforcement, the SNMS stores the access control policies of each user in the network, it processes each access request and evaluates over it WBSN members access control policies. Even if this kind of solution is largely accepted in other Web-based applications, it is important to understand whether centralized access control is appropriate in WBSN scenarios. The main reason of this concern is that, adopting centralized access control enforcement, implies to totally delegate to the SNMS the administration of user data. Since access control is enforced by the SNMS, users actually do not know whether access control is correctly enforced. They do not have any assurance about the behavior of SNMSs with respect to their data (for instance, they could maliciously release them to unauthorized users). They have to totally trust SNMSs. Therefore, it is important to carefully evaluate whether this could be easily accepted by WBSN members. It is true that, in current WBSNs, users are already providing SNMS a huge amount of personal data. But, it is also true that some recent events have made users aware that the SNMS s behavior is not always honest and transparent. Let us consider, for instance, some privacy concerns related to Facebook [EPIC 2008a]. In 2006, Facebook received the complaints of some privacy activists against the use of the News Feed feature [Chen 2006], introduced to inform users with the latest personal information related to their online friends. These complaints resulted in an online petition signed by over 700,000 users demanding the company to stop this service. Facebook replied by allowing users to set some privacy preferences. More recently, November 2007, Facebook received other complaints related to the use of Beacon [Berteau 2007]. Beacon is part of the Facebook advertising system, introduced to track users activities on more than 40 Web sites of Facebook partners. Such information is collected even when a user is off from the social-networking site, and are reported to the user s friends without the consent of the user him/herself. Even in this case, the network community promptly reacted with another online petition that gained more than

14 14 Barbara Carminati et al. 50,000 signatures in less than 10 days. These are only few examples of privacy concerns related to SNMSs. All these events have animated several online discussions about WBSN privacy, and government organizations started to seriously consider this issue [EPIC 2008b; Hogben 2007; Canadian Privacy Commission 2007; Federal Trade Commission 2007]. These increasing privacy concerns about how SNMSs manage personal information lead us to believe that a centralized access control solution is not the most appropriate in the WBSN scenario. As mentioned before, one could argue that this paradigm is already well-accepted and adopted in several Web-based applications (for instance, home banking or services just to mention two of them). However, the main difference with respect to WBSNs is that in all these scenarios users have no choice: if they want to exploit the service, they have to accept that their data are managed according to the policies specified and enforced by the entity providing the service. In contrast, in WBSNs the real services are provided by users. Indeed, relationships are created by them, data are published by them. SNMSs only provide the framework, but, without users and their contents, the framework is completely useless. For all these reasons, we believe that in the near future WBSN participants would like to have more and more control over their data. In view of this, we believe it is necessary to investigate alternative ways of enforcing access control, which make users not totally dependent on SNMSs. A possible solution is to make the network participants themselves able to evaluate their access control policies. In this scenario, to which we refer to as decentralized access control enforcement, each participant is in charge of specifying and enforcing his/her access control policies. Each time a user receives an access request, the reference monitor, which is locally hosted by each network node, evaluates it against the specified policies, and decides whether access to the resource can be granted or not. The main drawback of this solution is that implementing a decentralized access control mechanism implies software and hardware resources more powerful than those typically available to WBSN participants. For instance, since access to a resource in a WBNS is usually granted on the basis of the direct/indirect relationships the requestor node has with other nodes in the network, answering an access request may require to verify the existence of specific paths within a WBSN. This task may be very difficult and time consuming in a fully decentralized solution. Therefore, a further essential requirement of access control enforcement in WBSNs is to devise efficient and scalable implementation strategies. In the following section we propose a semi-decentralized solution, as a way to trade-off between all the discussed requirements. 4. OVERVIEW OF THE PROPOSED MECHANISM In order to cope with the requirements outlined in the previous section, we propose a rule-based access control model for WBSNs, which allows the specification of access rules for online resources, where authorized users are denoted in terms of the type, maximum depth, and minimum trust level of the relationships existing between nodes in the network. The proposed access control model, described in

15 Enforcing Access Control in Web-based Social Networks 15 Section 5, totally satisfies the requirements discussed in Section As far as access control enforcement is concerned, we have decided to take the view outlined by Weitzner et al. [2006], who propose to enforce access control in the Semantic Web according to a strategy which is analogous to the one adopted by trust management systems such as PolicyMaker [Blaze et al. 1998], SPKI/SDSI [Ellison et al. 1999], and KeyNote [Blaze et al. 1999]. Differently from traditional access control mechanisms, in such an approach the task of verifying whether an access is authorized is in charge of the requesting user, who must prove to the resource s owner that he/she satisfies the requirements expressed by the owner s access control policies. Adopting this solution in the context of WBSNs implies the following steps. When a user, hereafter called the resource owner, receives from another user, hereafter the requestor, an access request for one of his/her resources, he/she replies by sending the set of access rules regulating the release of the resource. In order to gain access to the resource, the requestor has to provide the resource owner with a proof showing the existence of the required relationships, and that these relationships have the required depth and trust level. Therefore, each node is equipped with a reasoner for rule evaluation and proof generation. By means of the reasoner, the resource owner is then able to locally verify the proof, if he/she does not trust the requesting user. Implementing this client-side access control mechanism implies to address relevant issues related to the trustworthiness of the proofs sent by the requestor. Indeed, the resource owner should be able to verify that the proof received by the requestor has not been forged. To cope with this issue, we propose a solution based on the notion of relationship certificates (see Section 6 for more details), according to which, whenever a user, say Alice, establishes a new relationship with another user, say Bob, they both create and sign a certificate stating that between them there exists a direct relationship of a certain type and with a certain trust level. A proof regarding the existence of an in/direct relationship of a given type between users A and B can therefore be generated and verified through a set of certificates confirming the existence of a path of that type between them (hereafter we refer to this set of certificates as certificate path). Thus, providing the resource owner with certificate paths makes him/her able to verify the correctness of a proof certifying the existence of a given in/direct relationship as well as its depth, in that the number of certificates in the path represents the length of the path itself. In contrast, verifying the relationship s trust level needs a more complex strategy. Indeed, since the trust level between two nodes is computed taking into account all the shortest paths connecting them, in order to verify the validity of the trust level contained into a proof the requestor must provide the resource owner with all the corresponding certificate paths. However, how can the owner be sure that the requestor has actually provided all the shortest certificate paths? If there exist more than one path, the requestor may maliciously omit one or more of them, providing only the paths with the highest level of trust. Example 4.1. Consider the WBSN depicted in Figure 1, and suppose that David requests access to a resource rsc, owned by Alice, for which it is required to be a friend of hers, with maximum depth equal to 4, and with a minimum trust level equal to 0.8. The relationship of type friendof existing between Alice and David

16 16 Barbara Carminati et al. consists of four paths, ABD, ACD, ACFD, and ACFGD. The shortest paths, namely, ABD and ACD, must all be taken into account when computing the trust level, because they are required to compute the trust threshold used to select the paths to be considered when computing the trust level of the relationship. Now, the strengths of ABD and ACD are equal to 0.2 and 0.6, respectively. Consequently, only path ACD will be used for trust computation. According to formula 1 in Section 2.3.2, the trust level between Alice and David is equal to 0.7, and thus David cannot access rsc. Yet, if we consider the two shortest paths separately, we have t ABD = = 0.8 and t ACD = = 0.7. Thus, if David provides to Alice only the certificate path corresponding to ABD, he will gain access to rsc since t ABD = 0.8, even if he is not actually authorized. To avoid this problem, we assume the presence of a trusted Certificate Server (CS). This server acts like a certificate repository in charge of storing into a central certificate directory CCD all the relationship certificates specified by WBSN nodes, and enhanced with the functionality of discovering certificate paths (see Section 7.3 for more details). Thus, whenever the requestor needs to prove to the resource owner the existence of a given relationship, as well as its depth and trust, he/she requests the CS to discover the set of certificate paths corresponding to all the shortest paths referring to the required relationship. Such certificate paths, signed by CS, are then used by the requestor to generate the proof. The proof and the certificate paths are sent to the resource owner, which can locally verify the validity of the proof, if needed. This solution has several benefits in term of efficiency and scalability with respect to the fully decentralized one. Indeed, introducing the certificate server makes the overall framework more efficient, in that the burden of certificate management is on the CS, which obviously performs this task more efficiently than any other single node in the network. Moreover, the framework gains in scalability, in that a WBSN could exploit several (external) certificate servers, on the basis of the number of its participants. Moreover, this solution might be extensible to interactions among different WBSNs. Indeed, users of a given WBSN could interact with participants of another WBSN, under the assumption that there exists a mutual agreement between the corresponding certificate servers. However, besides the benefits, introducing the certificate server makes the solution no more fully decentralized. Indeed, in the proposed solution users locally take access control decisions but on the basis of certificate paths discovered by certificate servers. In some way, they still rely on external and potentially untrusted entities for their access control decision. For this reason, we define the proposed solution as semi-decentralized, in that the access control decision is taken by resource owner itself but exploiting information discovered by certificate servers. Even if this solution is not fully decentralized, there is a relevant difference between the proposed strategy and the centralized one. Indeed, in a centralized solution users have to trust the entity enforcing access control (i.e., the SNMS). They have no chances to verify the correctness of access request evaluation. In contrast, according to our semi-decentralized solution, users rely on external entities only for certificate management and certificate path discovery. Moreover, they are still able to verify whether the certificate paths discovered by a CS are correct or not. For instance,

17 Enforcing Access Control in Web-based Social Networks 17 users could inquiry other certificate servers to cross-check the received certificate paths, or they could directly contact other participants to verify certificates correctness. This, in addition to the benefits in terms of efficiency, leads us to consider the proposed semi-centralized solution a good trade-off between efficiency and security requirements. 5. AN ACCESS CONTROL MODEL FOR WBSNS In our model, access control requirements applying to a resource are expressed by specifying one or more access conditions, by which the resource owner O determines the type of relationships that a requesting node R must have with a given node (which may correspond to O or to any other node in the network), possibly along with their maximum depth and minimum trust level. Access conditions are formally defined as follows. Definition 5.1 Access Condition. An access condition ac is a tuple (inode, rt, d max, t min ), where inode V SN { } is the node with which the requesting node must have a relationship, rt RT SN { } is a relationship type, whereas d max N { } and t min [0,1] { } are, respectively, the maximum depth and minimum trust level that the relationship must have. If inode = and/or rt =, inode corresponds to any node in V SN and/or rt corresponds to any relationship in RT SN, whereas, if d max = and/or t min =, there is no constraint concerning the depth and/or trust level, respectively. Here and in what follows, given a tuple t we denote with comp(t) the value of the component comp of tuple t. Therefore, we denote with inode(ac), rt(ac), d max (ac), and t min (ac) the different components of a given access condition ac. Moreover, ifoneormorecomponentsofanaccessconditionacissettothewildcard ( ), we say that it is a -condition (denoted, ac). Given a resource rsc, the access control requirements of rsc are expressed through a set of access rules specified by its owner O. The notion of access rule is formally defined as follows. Definition 5.2 Access Rule. An access rule ar is a pair (rid,ac), where rid is the identifier of resource rsc, whereas AC = is a set of access conditions (also referred to as condition set), expressing the requirements a node must satisfy in order to be allowed to access resource rsc. The conditions in AC do not denote a set of alternative requirements, but all the requirements to be satisfied. In other words, the semantics of a condition set {ac 1,...,ac n } can be expressed as ac 1 ac n. It may be also the case that more than one access rule is specified for a given resource, when alternative access control requirements must be met. Example 5.3. Consider the WBSN depicted in Figure 1, and suppose that Alice owns a resource rsc, which she wishes to make available only to her direct and indirect friends, with the constraint that their relationships have a maximum depth equal to 3, and a minimum trust level equal to 0.8. Such policy can be expressed through the following access rule: ar 1 = (rid,{(a,friendof,3,0.8)}), where rid is the ID of resource rsc. In contrast, suppose that resource rsc should be accessed

18 18 Barbara Carminati et al. by users that are either friends of Alice (with the constraints on depth and trust level stated by ar 1 ) or direct colleagues of Carl, independently from their trust level. This can be achieved by specifying two distinct access rules, namely, ar 1 above, and ar 2 = (rid,{(c,colleagueof,1, )}). Finally, suppose that resource rsc should be accessed by users that are both friends of Alice and colleagues of Carl, with the same constraints on depth and trust level stated by ar 1 and ar 2. In such a case, Alice can specify the following rule: ar 3 = (rid,{(a,friendof,3,0.8), (C,colleagueOf,1, )}). 6. CERTIFYING RELATIONSHIPS As stated in Section 4, to support client-side access control, we need a way to ensure relationships authenticity. For this purpose, we assume that a relationship is expressed by means of a relationship certificate. More precisely, whenever a node inode V SN wishes to establish a relationship of type rt with another node tnode V SN, it generates a certificate where it declares the existence of a relationship of type rt and given trust level with tnode. The certificate is signed by both inode and tnode. In the following, we denote with PK v and SK v the public and private keys of a node v V SN, respectively. The notion of relationship certificate is formally defined as follows. Definition 6.1 Relationship Certificate. Let inode V SN be a node wishing to establish a relationship of type rt with another node tnode V SN. Let t be the trust level inode wishes to assign to the relationship, and ts a timestamp denoting the time instant when the relationship has been established. The certificate rc of such relationship is given by the concatenation of the tuple relspec = (inode,tnode,rt,t,ts)withitsdoublesignaturedsig,i.e.,apair(sig SKinode (relspec), Sig SKtnode (relspec)), where Sig is a signing function. 2 Example 6.2. The following are examples of certificates corresponding to the relationships existing between Alice and Bob in the WBSN depicted in Figure 1: (A,B,friendOf,0.2,ts) (Sig SKA (A,B,friendOf,0.2,ts),Sig SKB (A,B,friendOf, 0.2,ts)) (A,B,colleagueOf,0.8,ts ) (Sig SKA (A,B,colleagueOf,0.8,ts ),Sig SKB (A,B, colleagueof,0.8,ts )). After being generated and signed, certificates are uploaded to the certificate directory CCD of the certificate server, which acquires them after having checked the validity of their signatures. Copies of such certificates are also held by the nodes that generated them into their local certificate directories. Moreover, the certificate server is equipped with a Certificate Revocation List to manage certificate revocation. 2 Sig k (d) denotes the signature of d with key k. For simplicity, we use here the same pairs of private and public keys for both encrypting and signing messages. It is however possible to have two different pairs of private/public keys, one to be used for encrypting and the other for signing.

19 Enforcing Access Control in Web-based Social Networks ACCESS CONTROL ENFORCEMENT As pointed out in Section 4, in order to access a given resource rsc, the requestor must provide the resource owner with a proof demonstrating to be authorized to do that. Therefore, before illustrating the steps involved in access control enforcement, we clarify the notion of proof. 7.1 Proofs A proof certifies that a requestor R satisfies at least one of the access rules associated with the requested resource. Suppose that a resource rsc is protected by the set of access rules AR rsc. To generate a proof, the requestor must attest that there exists at least one access rule ar AR rsc such that he/she satisfies all the conditions stated by the condition set AC(ar). This is obtained by first computing for each condition ac AC(ar) an assertion stating that between node R and node inode(ac) there exists a relationship of type rt(ac), with a certain depth and trust level. The assertion is computed by R on the basis of the corresponding certificate paths discovered by CS (see Section 7.4 for more details). The result is a set of assertions RA = {ra 1,...,ra n }, one for each ac AC(ar), of the form ra = (inode,r,rt,d,t), which are then matched with the set of access conditions AC(ar) in order to obtain a proof. More precisely, a proof is obtained if, for each access condition ac AC(ar), there exists an assertion ra RA such that: (1) inode(ra) = inode(ac), (2) rt(ra) = rt(ac), (3) d(ra) d max (ac), and (4) t(ra) t min (ac). Example 7.1. Consider the WBSN depicted in Figure 1 and the access rules in Example 5.3, and suppose that David requests to access a resource owned by Alice, protected by access rule ar 1 = (rid,{(a,friendof,3,0.8)}). As already seen in Example 4.1, the shortest paths of type friendof between Alice and David are ABD and ACD. The resulting assertion generated by David, namely, (A,D,friendOf,2,0.7), states that between Alice and David there exists a relationship of type friendof, depth 2 and trust level 0.7. Since this assertion does not satisfy the condition on the minimum trust level required by ar 1, a proof is not obtained, and consequently David will be not authorized to access the resource. We use the Cwm reasoner [Cwm 2006] in order to compute the proof. For this purpose, before running Cwm, we transform both assertions and access rules into equivalent logical formulas, expressed by using N3 (see Appendix B for more details on N3). As a result, we obtain an N3-encoded proof, denoted as π, containing, besides the assertions and the rule, also the steps followed by the reasoner to carry out the demonstration. 7.2 Access Control Protocol In order to implement in a secure way the access control procedure sketched in Section 4, we need to devise a protocol ensuring both the requestor and the resource owner that access rules and proofs are valid and authentic. For these purposes, we have devised an access control protocol (depicted in Figure 2) consisting of the steps described in Figure 3. 3 Note that all the exchanged messages are encrypted 3 In the figure and in the remainder of the paper, E k (d) denotes the encryption of d with key k.

20 20 Barbara Carminati et al. CS 3. E PKCS (E SKR (AC(ar), n)) 4. E PKR (E SKCS (CP, n)) 5. E PKO (E SKR (rid, π, E SKCS (CP, n))) R 6. E PKR (E SKO (rsc)) 2. E PKR (E SKO ({(ar 1, n 1),..., (ar n, n n)}) 1. E PKO (E SKR (rid)) O Fig. 2. Access control protocol. R is the node requesting a resource with identifier rid, O is the node owning such resource, whereas CS is the certificate server. (1) R submits to O an access request for resource rsc, with identifier rid. (2) If the resource is public, access is granted. Otherwise, O returns to R the set of access rules AR = {ar 1,...,ar n} regulating the access to rsc. With each access rule ar i AR, i [1,n], a distinct nonce value n i is associated as a session identifier. (3) R chooses from AR an access rule ar and sends CS the nonce value n associated with ar and the corresponding condition set AC(ar). More precisely, since the certificate server CS has only to discover the shortest certificate paths referring to the relationships denoted by AC(ar), whereas the requestor is in charge of trust computation, for each ac AC(ar), R sends CS a modified version of the corresponding set AC(ar) of access conditions (denoted AC(ar)), where the t min component of each ac AC(ar) is set to null. (4) CS returns R the set CP of shortest certificate paths, if any, related to the relationship constraints expressed by the access conditions in AC(ar), along with the nonce n associated with ar; otherwise, CS returns a failure message. In the latter case, R goes back to step 3 and chooses another access rule, until CS returns the set CP, if any, or all the access rules have been processed (the algorithm for certificate path discovery is described in Section 7.3). (5) Based on the certificate paths in CP, R computes the corresponding set of assertions RA, and then he/she invokes the reasoner in order to match them against access rule ar (see Section 7.4 for more details). If a proof is not obtained, R goes back to step 3 and chooses another access rule; otherwise, he/she sends O a message, which contains the resource identifier, the proof π, and the certificate paths obtained from CS. CP and n are kept encrypted with the private key of CS, in order to grant their authenticity. (6) O sends R the requested resource in case the proof π is valid and the nonce value n corresponds to the correct session identifier. Before granting access to the resource, O can locally check whether the set of assertions used in the proof are actually derived from the received certificate paths in CP, by performing the same steps done by the requestor for proof generation (see Section 7.5). Fig. 3. Description of the access control protocol depicted in Figure 2 with the private key of the sender and with the public key of the receiver, in order to ensure their authenticity, integrity, and confidentiality. Example 7.2. Consider the WBSN depicted in Figure 1, and suppose that David requests to access a resource rsc owned by Alice, protected by two access rules,

21 Enforcing Access Control in Web-based Social Networks 21 namely,ar 1 = (rid,{(a,friendof,3,0.8)})andar 2 = (rid,{(c,colleagueof,1, )}). According to the access control protocol described in Figure 3, evaluating this access request requires the following steps: (1) David sends Alice an access request E PKA (E SKD (rid)), where rid is the identifier of resource rsc. (2) AlicesendsbacktoDavidamessageE PKD (E SKA ({(ar 1,n 1 ),(ar 2,n 2 )})), containing the access rules ar 1 and ar 2 applying to rsc, associated with two distinct nonces n 1 and n 2. (3) David selects the first rule ar 1, extracts the corresponding set of conditions AC(ar 1 ) = {(A,friendOf,3,0.8)} and modifies the condition by setting the trust component to null, so that AC(ar 1 ) = {(A,friendOf,3,null)}. Then, he sends CS the message E PKCS (E SKD (AC(ar 1 ),n 1 )). (4) CS verifies whether one or more certificate paths exist satisfying AC(ar 1 ). As already seen in Example 4.1, the shortest paths of type friendof existing between Alice and David are ABD and ACD. CS then builds the corresponding certificate paths, namely (rc 1,rc 2 ) and (rc 3,rc 4 ), where: rc 1 = (A,B,friendOf,0.2,ts 1 ) DSig 1,rc 2 = (B,D,friendOf,0.8,ts 2 ) DSig 2,rc 3 = (A,C,friendOf,0.6,ts 3 ) DSig 3, rc 4 = (C,D,friendOf,0.7,ts 4 ) DSig 4. It then sends David the message E PKD (E SKCS ({(rc 1,rc 2 ),(rc 3,rc 4 )},n 1 )). (5) David must verify whether the relationship denoted by {(rc 1,rc 2 ),(rc 3,rc 4 )} satisfies ar 1. For this purpose, he computes the corresponding assertion (A,D, friendof, 2, 0.7). Since this assertion does not satisfy the constraint on the minimum trust level, David cannot obtain a proof. Consequently, he sends CS the modified set of conditions AC(ar 2 ) = {(C,colleagueOf,1,null)} corresponding to rule ar 2. (6) CS verifiesthatapathoftypecolleagueof andlength1existsbetweencarland David, and therefore it sends David the message E PKD (E SKCS ({(rc 5 )},n 2 )), where rc 5 = (C,D,colleagueOf,0.4,ts 3 ) DSig 5, and n 2 is the nonce value associated with ar 2. (7) From the received certificate path (rc 5 ), David obtains the assertion (C,D, colleagueof, 0.4), which satisfies ar 2. Thus, David computes the proof π and sends it to Alice in the message E PKA (E SKD (rid,π,e SKCS ({(rc 5 )},n 2 ))). (8) Alice verifies that the nonce value n 2 is valid and that the proof π is correct. Then, she can decide whether to grant access to the resource without any further check or to verify the correctness of the assertion derived from rc Certificate Path Discovery In step 4 of the protocol (see Figure 3), CS discovers the shortest certificate paths referring to the set of access conditions AC(ar) (AC, for short) received by the requestor node. This can be achieved by exploring the network graph, a task which may have high computational cost, depending on the degree and the order of the graph itself. More precisely, exploring the network graph requires either O(V SN + E SN ) or Θ(V SN + E SN ) time complexity, depending on whether we use a breadth-first search (BFS) or a depth-first search (DFS), respectively. However, given the constraints on the relationship type and depth specified in an access

22 22 Barbara Carminati et al. condition, we can reduce the size of the graph to be explored, and therefore the computational cost. In fact, the search can be terminated as soon as either the specified maximum depth is reached or the shortest path(s) between two nodes is (are) found. Moreover, we are not actually interested in discovering all the paths existing between two nodes, but only in those consisting of edges all labeled with one of the relationship types RT = {rt 1,...,rt n } specified in the input condition set AC = {ac 1,...,ac n }. Therefore, we explore only the set of subgraphs SN rt1,...,sn rtn SN, where SN rti denotes a subgraph of SN consisting of all and only the edges labeled with relationship type rt i and the nodes connected by them. Unless RT SN = 1, we have to explore graphs of a size which is usually far lower than the one of SN. Finally, since we have to find only the shortest path(s), the search is performed by using a BFS-algorithm. This means that exploring each subgraph SN rti SN requires O(V SNrti + E SNrti ) time complexity. Another factor that affects the system performance is the use of the wildcard for one or more of the components of an access condition. Since the certificate server CS performs the search based on a modified version of AC, where the constraints on the minimum trust level are omitted, we do not consider the case in which the access condition contains a wildcard in its trust component. We can then say that, in the general case, the time complexity required to evaluate an access condition is O( rt RT(ac) (V SN rt + E SNrt )), where RT(ac) is the set of relationship types specified in the access condition ac. More precisely, RT(ac) = RT SN, if the rt component of ac is set to ; RT(ac) = 1, otherwise. Thus, since an access rule consists of one or more access conditions, evaluating an access rule ar requires O( ac AC(ar) rt RT(ac) (V SN rt +E SNrt )) time complexity. Let us now introduce how the certificate path discovery is carried out in our system. This task is performed by Algorithm 1, which receives as input the identifier of the requesting node R and a set of modified conditions AC(ar) (AC, for short), referring to an access rule ar, and returns a data structure CP. CP is a bi-dimensional array where each element is in turn an array containing the set of shortest certificate paths denoting relationships of R that satisfy a condition in AC. More precisely, CP[i], 1 i CP, is an array where each element CP[i][j], 1 j CP[i], contains the set of shortest certificate paths having the same initial and terminal node and consisting of edges all labeled with the same relationship type, which correspond to a given relationship satisfying the ith condition in AC. Finally, each certificate path in CP[i][j] is a tuple of length n, where n is the depth of the relationship denoted by CP[i][j]. The reason why we model CP as a bidimensional array is to make it easier the computation of relationship assertions for -conditions, as it will be explained in Section 7.4. The algorithm starts by setting CP to be empty and initializing the variables used in the subsequent steps, namely, the set RT of relationship types specified in AC and the set termrt of relationship types associated with edges entering in R (lines 2-4). Then, it applies a preliminary check to determine whether the input access conditions cannot be satisfied by the requesting node. If the check is not satisfied, each access condition ac AC is iteratively considered (lines 9-54). This implies to first initialize array CP[i] and a temporary variable, i.e., Paths (line 12). The latter will contain the discovered certificate paths, if any, satisfying the current

23 Enforcing Access Control in Web-based Social Networks 23 Algorithm 1 Certificate Path Discovery 1: function DiscoverShortestPaths(R, AC) 2: Array CP is initialized to be empty 3: Let RT RT SN be the set of relationship types specified in AC 4: Let termrt be the relationship types associated with edges entering in R 5: if RT termrt then 6: return failure 7: else 8: i 0 9: for all ac AC do 10: i i : j 0 12: Array CP[i] and variable Paths are initialized to be empty 13: switch 14: case inode(ac) = rt(ac) = 15: for rt termrt do 16: Paths BFS(R,,Adj rt,d max(ac)) 17: while Paths > 0 do 18: j j : Let path be a path in Paths 20: CP[i][j] ExtractSimilarPaths(path, Paths) 21: Remove from Paths the paths in the elements of CP[i][j] 22: end while 23: end for 24: end case 25: case inode(ac) = rt(ac) = 26: if rt(ac) termrt then 27: Paths BFS(R,,Adj rt(ac),d max(ac)) 28: while Paths > 0 do 29: j j : Let path be a path in Paths 31: CP[i][j] ExtractSimilarPaths(path, Paths) 32: Remove from Paths the paths in the elements of CP[i][j] 33: end while 34: end if 35: end case 36: case inode(ac) = rt(ac) = 37: Let initrt be the relationship types associated with edges exiting from inode(ac) 38: for rt termrt initrt do 39: j j : CP[i][j] BFS(R,inode(ac),Adj rt,d max(ac)) 41: end for 42: end case 43: default case 44: Let initrt be the relationship types associated with edges exiting from inode(ac) 45: if rt(ac) termrt initrt then 46: j j : CP[i][j] BFS(R,inode(ac),Adj rt(ac),d max(ac)) 48: end if 49: end default case 50: end switch 51: if CP[i] = 0 then 52: return failure 53: end if 54: end for 55: return CP 56: end if 57: end function access condition, and having the same initial and terminal nodes, and consisting of edges all labeled with the same relationship type. Such certificate paths will then be permanently stored by each element of array CP[i]. The algorithm then selects the more efficient search procedure for each access condition ac AC (lines 13-50). In particular, if inode(ac) = and rt(ac) =, the search is enforced by lines 14-24, whereas, if inode(ac) = and rt(ac) =,

24 24 Barbara Carminati et al. the search is implemented by lines In contrast, lines address the case when inode(ac) = but rt(ac) =. Finally, when inode(ac) = and rt(ac) =, the procedure is enforced by lines In all these cases, certificate path discovery is performed by the BFS() function, which receives as input the pair of nodes R, inode(ac), the maximum depth specified in the access condition, and the adjacency list Adj rt (denoted Adj rt(ac), in case rt(ac) = ), whichassociateswitheachnodev V SN thesetofcertificatesdenoting relationships of type rt (rt(ac)), where v participates as terminal node. This function implements a standard BFS-algorithm, modified in order to end the search as soon as the maximum depth is reached or all the shortest paths have been found. In case the inode(ac) parameter is set to, the BFS() function searches for all the shortest paths connecting R with any other node in the network. In contrast, in case d max =, there is no limit in the depth of the search. Let us now see in detail each different case. When inode(ac) = and rt(ac) = (lines 14-24), the BFS() function is iterated for all the relationship types in termrt. In contrast, in case inode(ac) = and rt(ac) =, the BFS() function is executed only on the relationship type rt(ac) (lines 25-35). It is important to note that, in both these cases, the BFS() function returns certificate paths denoting relationships of R with different nodes in the network (since inode(ac) = ). For example, in case inode(ac) = and rt(ac) =, the BFS() function returns all the shortest certificate paths connecting R with any other node in the network, and having edges all labeled with relationship type rt(ac). In these cases, in order to compute the trust level of such relationships, it is necessary to consider separately the corresponding sets of discovered certificate paths. For this reason, the paths returned by the BFS() function are processed by function ExtractSimilarPaths() (lines 20, 31), which selects those of them connecting the same pair of nodes, that is, those denoting the same relationship. Such paths are then stored into a distinct element of array CP[i]. When inode(ac) =, we have two different cases. If rt(ac) =, the BFS() function is executed only on the relationship types for which there could exist a relationship between R and inode(ac). These types are given by the intersection of initrt and termrt (lines 36-42), where initrt denotes the set of relationship types associated with edges exiting from inode(ac). In case rt(ac) =, the BFS() function is executed only for relationship type rt(ac) (lines 43-49). Note that, if no certificate paths are found, the current access condition is not satisfied. In this case, since all the access conditions in AC must be satisfied, the algorithm ends, and returns a failure (line 52). Otherwise, the process is iterated on the next access condition. Example 7.3. Consider the access control protocol illustrated in Example 7.2, according to which, in step 3, the certificate server CS receives from David a message E PKCS (E SKD (AC(ar 1 ),n 1 )), where AC(ar 1 ) = {(A,friendOf,3,null)}. To reply to this request, CS has then to explore the WBSN in Figure 1 in order to find the shortest paths, if any, between Alice and David, of type friendof and maximum length equal to 3. Once verified that there exists an edge entering in node D and an edge exiting from node A, both labeled with relationship type friendof, CS calls the BFS() function, and starts the search by considering David s neighbors with

25 Enforcing Access Control in Web-based Social Networks 25 respect to the relationship type friendof i.e., Bob, Carl, Fred, and Greg. Since Alice is not one of David s neighbors, the BFS() function now considers, in turn, the neighbors of Bob, Carl, Fred, and Greg. The BFS() function discovers that Alice is a friend of Bob, and thus that there exists a path of length 2 between Alice and David. Sinceapathhasbeenfoundoflengthlessthan3, thebfs()functionverifies only whether other paths of length 2 exist that is, whether other shortest paths exist. Then, the BFS() function considers the next David s neighbor, i.e., Carl, and it discovers that Alice is friend of Carl too. In contrast, Fred has just one neighbor, Carl, whereas Greg s only neighbor is Fred. Consequently, the only paths satisfying AC(ar 1 ) are ABD and ACD, corresponding to the certificate paths (rc 1,rc 2 ) and (rc 3,rc 4 ) (see Example 7.2). Then, CP = [[{(rc 1,rc 2 ),(rc 3,rc 4 )}]]. 7.4 Proof Computation Once received from CS all the requested certificate paths, R has to generate the corresponding assertions and then compute the proof π (step 5 of the protocol in Figure 3). The former task is performed by Algorithm 2, which receives as input the bi-dimensional array CP returned by Algorithm 1, and returns a set of assertions RA, corresponding to the relationships denoted by the paths stored into the elements of CP. For each element CP[i] of CP, with 1 i CP, the algorithm iteratively considers each set CP[i][j] of certificate paths, with 1 j CP[i]. In particular, if the current set CP[i][j] contains a single path path, which in turn consists of a single certificate rc, the algorithm sets the trust level of the relationship to the trust level in rc (lines 7-13). Otherwise, the algorithm computes the relationship trust level by using formula 1 in Section (lines 15-42). This implies first to compute the trust threshold maxt, and to remove from the current set of paths CP[i][j] those having a strength less than max t (lines 16-22). Then (line 23), the certificates are grouped based on their position in all the paths in CP[i][j] (i.e., RC k denotes the set of certificates at the kth position in the paths in CP[i][j]). Moreover, the initial node inode and the terminal node tnode of the path currently considered by the algorithm are determined (lines 24-26). Finally, the algorithm (lines 27-38) computes the trust value of the relationship between nodes inode and tnode by applying recursively formula 1 in Section on the sets RC 1,...,RC n of certificates computed before. The last part of the algorithm (lines 39-42) is in charge of verifying whether the current set CP[i][j] of certificate paths is to be used or not to generate a relationship assertion. Such check is carried out in order to obtain a single relationship assertion for each element CP[i] of CP. We remind that each element CP[i] stores the certificate paths satisfying a given modified access condition ac, grouped based on the relationship they denote. When none of the components of a modified access condition ac are set to, all the certificate paths returned by Algorithm 1 have the same initial and terminal nodes, and they consist of edges all labeled with the same relationship type, satisfying ac. Consequently, CP[i] will have just a single element, and a single assertion will be generated based on it. However, in case inode(ac) =, the returned paths denote relationships of the same type existing between the requestor and any other node in the network, all satisfying ac. Moreover, if rt(ac) =, the returned paths denote relationships between the same pair

26 26 Barbara Carminati et al. Algorithm 2 Assertion Generation 1: function GenerateAssertions(CP) 2: RA The set of assertions is initialized to be empty 3: for i = 1, CP do 4: trust 0 5: for j = 1, CP[i] do 6: flag 0 7: if CP[i][j] =1 then 8: Let path be the only path in CP[i][j] 9: if path consists of a single certificate rc then 10: ra (inode(rc), tnode(rc), rt(rc), 1, t(rc)) 11: flag 1 12: end if 13: end if 14: if flag = 0 then 15: Let path be a certificate path in CP[i][j] 16: depth path The relationship depth 17: PathsStrength 18: for all cp CP[i][j] do 19: Compute the strength of certificate path cp and add it to PathsStrength 20: end for 21: Let max t max(pathsstrength) be the trust threshold 22: Remove from CP[i][j] the paths with a strength less than maxt 23: Let RC k be the set of certificates at the kth position in the paths in CP[i][j] 24: Let firstcert and lastcert be, respectively, the first and last certificates in path 25: inode inode(firstcert) The initial node of the relationship 26: tnode tnode(lastcert) The terminal node of the relationship 27: k 1 28: while k < depth do 29: V {v V SN rc RC k such that v = inode(rc)} 30: for all v V do 31: Let N be the set of neighbors of v, based on the certificates in RC k 32: Let S be the set of neighbors of the nodes in N, based on RC k+1 33: for all s S do 34: t inode,s u N t inode,u tu,s u N t inode,u 35: end for 36: end for 37: k k : end while 39: trust max(trust,t inode,tnode ) 40: if trust = t inode,tnode then 41: ra (inode, tnode, rt(firstcert), depth, trust) 42: end if 43: end if 44: end for 45: Add ra to RA 46: end for 47: return RA 48: end function of nodes, but of different type, all satisfying ac. Finally, if inode(ac) = and rt(ac) =, the returned paths denote relationships of any type existing between the requestor and any other node in the network, all satisfying ac. This means that, in case of -conditions, the number of elements of CP[i] and the generated relationship assertions, will be equal to V SN RT SN, in the worst case. Since all such relationship assertions satisfy ac, it would be quite inefficient to process them all. Indeed, we need only one of them. In order to address this issue, we discard all the returned sets of certificate paths, except one of those having the highest trust level, and then we computed the relationship assertion only based on it (lines 40-42).

27 Enforcing Access Control in Web-based Social Networks 27 (1) The resource owner O verifies whether the received nonce is valid. O maintains an access request list ARL where, for each access request, a set of tuples is stored, one for each access rule protecting the requested resource. Each tuple has the form (R,ar,n), where R is the requesting node, ar is one of the access rules applying to the requested resource, whereas n is the nonce value associated with access rule ar by O (see step 2 of the protocol in Figure 3). When O receives from R the message E PKO (E SKR (rid,π,e SKCS (CP,n))) at step 5 of the protocol, he/she first decrypts the pair (CP,n) with the public key PK CS of CS, and then he/she compares the nonce value n with the one currently stored into ARL. If (CP,n) cannot be decrypted and/or a tuple (R,ar,n) is not present in ARL, O denies the access to the resource; otherwise, (2) O checks whether the proof sent by R is correct; if the proof is not correct, O removes the tuple (R,ar,n) from ARL and denies the access to the resource; otherwise, (3) O can choose between two options: (a) going directly to step 4, or (b) deriving from the certificate paths in CP the corresponding set of assertions, by using the same procedure described in Section 7.4. In the latter case, if the assertions computed by O are different from those used in the proof delivered by R, O removes the tuple (R,ar,n) from ARL and denies the access to the resource*; otherwise, (4) O removes the tuple (R,ar,n) from ARL and grants the access to the resource. * Note that O might also verify the validity of the certificates discovered by CS by contacting other certificate servers or other nodes in the network. 7.5 Proof Verification Fig. 4. Proof verification steps In the last step of the access control protocol (i.e., step 6 in Figure 3), the resource owner O verifies the validity of the proof returned by the requestor and then decides whether to grant or deny access to the resource. The four steps carrying out proof verification are illustrated in Figure 4. Example 7.4. Consider the access control request illustrated in Example 7.2. In step 7 of the protocol, Alice receives from David the message: E PKA (E SKD (rid,π,e SKCS ({(rc 5 )},n 2 ))) According to the protocol described in Figure 4, Alice first tries to decrypt E SKCS ({(rc 5 )},n 2 ). Then, she verifies whether there exists in her access request list ARL a tuple (D,ar 2,n 2 ). Since Alice is able to decrypt E SKCS ({(rc 5 )},n 2 ) and the required tuple is found in ARL, she then verifies the correctness of proof π by running the Cwm reasoner. Once having verified that proof π is correct, Alice removes the tuple (R,ar 2,n 2 ) from ARL and she may directly send David the requested resource or, alternatively, she can perform a further check on the certificate paths delivered by David. Thus, from {(rc 5 )}, Alice computes the corresponding assertion and compares it to the one used in the proof. Since the two assertions match, Alice removes (D,ar 2,n 2 ) from ARL and grants access to the resource. 8. SECURITY ANALYSIS The potential attacks, which our system may be subject to, concern both the certificate server CS and resource owners, and can be grouped into two classes, depending on their purpose, namely, attacks aiming at gaining unauthorized access

28 28 Barbara Carminati et al. to resources, and denial of service attacks. Access to a resource can be gained only if a requestor is able to provide the resource owner with a set of information (namely, a proof, a set of certificate paths, and a nonce value) demonstrating that he/she satisfies a given access rule. The simplest attack consists in forging such information. Consider, for instance, a node R requestingaresourcersc toanodeo. Rreceivesthesetofaccessrulesar 1,...,ar n applying to rsc along with the corresponding nonce values n 1,...,n n. R can choose one of these access rules (say ar 1 ), forge an appropriate proof for it and a corresponding data structure CP, and then send such information along with the nonce value n 1 to O. This attack is prevented by our access control protocol (see steps 4 and 5 in Figure 3) by keeping the pair (CP,n 1 ) encrypted with the private key SK CS of the certificate server. An alternative attack implies to upload to CS fake certificates, generated in such a way to have a (set of) certificate path(s) satisfying a given access rule. However, this attack is prevented by our system, since a certificate is double signed by the two nodes establishing the relationship, and thus it is not possible to certify fake relationships (see Section 6). A similar attack can be performed by forging only the proof. Suppose that R must prove to have a relationship with node v. Suppose now that R obtains from CS a set of certificate paths demonstrating that he/she actually participates with v in a relationship of the required type and depth. Yet, when computing the proof, R realizes that he/she does not satisfy the constraint on the minimum trust level. In such a case, R may decide to forge and send the proof to the resource owner O, along with the encrypted pair (CP,n) sent by CS. In such a case, the nonce is valid and the proof seems to be correct. However, O can realize that R is not authorized to access the requested resource by checking the proof against CP (such operation is enforced as an option by the protocol in Figure 4). The idea underlying this strategy is making the owner able to customize the required security guarantees by taking into account the profile of the requestor. For instance, the choice of whether or not checking the proof against the set of received certificate paths can be based on the results of previous requests submitted by the same node. A different type of attack can be performed by impersonating an authorized node in the network. For example, suppose that R knows that a given node A is authorizedtoaccessaresourcersc ownedbyo. Insuchacase,RmaycontactO and CS, claiming to be A, and thus retrieving the appropriate information to gain access to rsc. The same attack can be performed by eavesdropping the messages exchanged between A and O related to an access request to resource rsc. R can intercept the message with the proof and send it to O, claiming to be A. However, our access control protocol prevents both identity theft and man-in-the-middle attacks by requiring that all the messages are encrypted with the private key of the sender and the public key of the receiver. Finally,timingandreplayattacksmayalsobeperformedinordertogainaccessto a resource. As an example, suppose that, at a given instant ts, R requests to access resource rsc, and that he/she is authorized according to the corresponding rules. Suppose now that, at a given instant ts > ts, one or more certificates concerning R have been revoked, and that, as a consequence, R is no more authorized to access resource rsc. In such a case, R could still send O the previous proof and the

29 Enforcing Access Control in Web-based Social Networks 29 corresponding certificate paths received from CS at instant ts, thus gaining access to rsc. In order to prevent this attack, in our access control protocol nonce values are associated with the access rules sent by O, which are also returned by CS along with the corresponding set of certificate paths (see steps 3-5 of the access control protocol in Figure 3). Each nonce value identifies a given access rule with respect to a given session, and it cannot be modified by R, since it is encrypted with the private key of CS (step 5). Thanks to this, it is possible to discard proofs when the received nonce value differs from that of the corresponding access rule. Denial of service attacks concern mainly the certificate server, but also resource owners may be subject to them. The vulnerable service of the certificate server is the one in charge of discovering certificate paths. A node may maliciously submit a high number of requests requiring high computational costs to be managed. Typically, this means, for example, requests of certificate paths concerning two nodes not connected by any relationship. This forces CS to explore the whole network graph. To address this issue, we can adopt standard strategies used by online systems in order to reduce the risk of denial of service attacks. As an example, we can set an upper bound to the number of requests to be accepted and fix a maximum timeout for their evaluation, which may vary depending on the system workload. A similar approach can be adopted in order to avoid denial of service attacks on the side of resource owners, which can be overloaded by access requests or invalid proofs. Such attacks may also be prevented by allowing resource owners to track these kinds of behavior and to maintain a list of malicious nodes, to be used in order to refuse a priori their requests. 9. SYSTEM IMPLEMENTATION Figure 5 depicts the four main components of the system implementing our access control model: the certificate server CS, the SNMS, a peripheral node, corresponding to a node in the network, and the system interface. The certificate server, the SNMS, and the peripheral nodes are implemented as Web services, whereas the system interface is provided as an extension to the Mozilla Firefox browser, which can be downloaded and installed by users after being registered into the network. All these applications communicate by using the HTTPS protocol. Finally, the system makes use of OpenID ( as authentication framework, which has the advantage of simplifying the registration and authentication procedures by allowing users to log in into different WBSNs by using a single user ID and password. To store relationship certificates and the users data needed for authentication, the certificate server and the SNMS make use of the PostgreSQL relational DBMS. In contrast, peripheral nodes store the data concerning relationships, access rules, and resources by using RDF files. Our prototype supports in total 33 relationship types, corresponding to those defined in the RELATIONSHIP vocabulary [Davis and Vitiello Jr 2005] plus the FOAF knows property [Brickley and Miller 2007]. The prototype system has been implemented in a WBSN, called ACSoNet. System services can be accessed through the system interface, a client application, that is typically run by end users machines. Through the system interface it is possible to generate, update, and revoke certificates and access rules, as well

30 30 Barbara Carminati et al. Fig. 5. System architecture as submitting access requests to the nodes in the network, and receiving and delivering rules and proofs. When activated, the system interface displays a window consisting of a toolbar and a set of tabs, allowing users to manage their personal profile, their contacts, and their resources, and to browse the resources shared in the network and the list of registered users. Figure 6 depicts a screenshot of the system interface, namely the My resources tab, which displays information about the resources owned by the user, along with the associated access rules and corresponding conditions. The user has also the possibility to decide whether the existence of a given resource should be publicly available to network participants. This is achieved by properly setting the Visible property of a given resource. In addition, access to a resource can be temporarily blocked by using the Locked option. 10. SYSTEM PERFORMANCE In this section, we discuss the performance of the implemented prototype in terms of time required to evaluate an access request. The main tasks affecting the performance of access control enforcement are: (1) certificate path discovery, performed by CS; (2) assertions generation, performed by R and O; (3) proof generation, performed by R and O. In what follows, we evaluate the performance of each single task Certificate Path Discovery The complexity of this task is the time required by Algorithm 1. The algorithm exploits the BFS() function (see Algorithm 1) to explore the social network graph and discover the certificate paths satisfying a given access condition. The BFS() functionisiteratedforeachaccessconditionintheruleonthesetrt ofrelationship types to be taken into account. We consider the algorithm s performance in the worst case, i.e., when each access condition in AC(ar) has the inode, rt, and d max components set to. Moreover, we assume that RT = RT SN which implies that

31 Enforcing Access Control in Web-based Social Networks 31 Fig. 6. The My resources section of the system interface foreachdifferentrelationshiptypeinrt SN thealgorithmsearchesforadifferentset of certificate paths and that it is necessary to explore, in the worst case, the whole subgraph to verify whether a relationship exists or not between two nodes. Since in our prototype we support the 33 relationship types defined in the RELATIONSHIP vocabulary, plus the FOAF knows property, in the worst case the search is iterated at most 34 times for each access condition. To have an estimation of the time complexity in real world scenarios, we have thus performed several experiments over the BFS() function, by varying the order of the subgraph SN rt, as well as the indegree of the nodes in SN rt. The experiments were conducted on a 3.60GHz Dual-Core Intel Xeon GNU/LINUX machine, with 4GB RAM. As reported in Figure 7, we have considered subgraphs consisting of a number of nodes ranging from 100 to 6,000. According to the obtained results, exploring a graph of order 100 requires at most sec, one of order 600 at most 0.01 sec, one of order 2, sec, and one of 6,000 nodes 1 sec. We recall that the size is not referred to the order of the whole social network graph; rather, given a relationship type, it represents the number of nodes having at least a relationship of such type. The number of nodes participating in a relationship of a given type depends both on the size and the purposes of the network graph and on the type itself of the relationship. Thus, it is important to outline which kinds of WBSNs represent the target for our access control mechanism. We do not believe that the scenario that can benefit from our system is the one of a general purpose WBSN, that is, a WBSN set up with the aim of creating a place where a possibly huge amount of people can meet. Indeed, in this kind of WBSNs, the main users requirements are not related to security. In contrast, a reference scenario for our system is a WBSN set up for creating a place where users with common goals and interests should be able to share some information mainly for business or research purposes. An example of such a WBSN could be, for instance, the one set up into an organization, where users are employees, and relationship types corresponds to