Key Allocation Schemes for Private Social Networks Keith B. Frikken
Preethi Srinivas
Department of Computer Science and Software Engineerings Miami University Oxford, OH
Department of Computer Science and Software Engineerings Miami University Oxford, OH
[email protected]
[email protected]
ABSTRACT
Keywords
In this paper we introduce a novel scheme for key management in social networks that is a first step towards the creation of a private social network. A social network graph (i.e., the graph of friendship relationships) is private and social networks are often used to share content, which may be private, amongst its users. In the status quo, the social networking server has access to both this graph and to all of the content, effectively requiring that it is a trusted third party. The goal of this paper is to produce a mechanism through which users can control how their content is shared with other users, without relying on a trusted third party to manage the social network graph and the users’ data. The specific access control model considered here is that users will specify access policies based on distance in the social network; for example some content is visible to friends only, while other content is visible to friends of friends, etc. This access control is enforced via key management. That is for each user, there is a key that only friends should be able to derive, there is a key that both friends of the user and friends of friends can derive, etc. The proposed scheme enjoys the following properties: i) the scheme is asynchronous in that it does not require users to be online at the same time, ii) the scheme provides key indistinguishability (that is if a user is not allowed to derive a key according to the access policy, then that key is indistinguishable from a random value), iii) the scheme is efficient in terms of server storage and key derivation time, and iv) the scheme is collusion resistant.
Privacy, Key Management, Access Control, Social Networks
1.
INTRODUCTION
Social networking has become ubiquitous. The availability of such information raises significant privacy concerns. One way to mitigate some of these concerns is to allow users to control access to their resources. However, many current social networking sites provide limited access control to users over their content. There has been a significant amount of work in access control in social networks [5, 6, 4, 9, 13]. Some of these solutions assume that a server will enforce the access control, but this does not protect the privacy of the users against the server. Other solutions are synchronous in that they require the users to enforce their own access control, and thus multiple users must be online simultaneously for each content access. The goal of this paper is to provide a decentralized (i.e., no trusted third party) and asynchronous access control enforcement mechanism. More specifically, it should allow access to a user’s content even when that user is not online, but the access should only be allowed when the access control policy is satisfied. In this paper we consider performing social network access control via key management. More specifically, each user will have a set of keys, and other users will be able to derive some of these keys. The access control model1 that we consider is as follows: the trust level between two users depends on the distance between the users in the social network. For example, a friend of Alice will be able to access more content than a friend of a friend of Alice. The advantage of using key management is that a user can simply post content encrypted with the key corresponding to the access control policy for that content. If the key management is done properly, then only users that do not satisfy the policy will not have the key and thus the encrypted content will be meaningless. One drawback of this approach is that malicious users could publish other users’ keys, and then unauthorized users would be able to access content. We leave the resolution of this problem as future work. Our system achieves the following properties; we are not aware of any other scheme that satisfies these properties:
Categories and Subject Descriptors H.3.3 [Information Search and Retrieval]: Retrieval Models
General Terms Security, Algorithms
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WPES’09, November 9, 2009, Chicago, Illinois, USA. Copyright 2009 ACM 978-1-60558-783-7/09/11 ...$10.00.
1. Users that are d hops or less from a specific user, Alice, will be able to derive Alice’s depth d key. 2. Users that are not within d hops of Alice will not be 1
A more complex access control model is considered as an extension in section 6.
11
n Experiment Exprec Π,Av (1 ) (1n , pub, sec) ← SOGEN (1n , G, L) corr ← Corruptv,d (sec) k ← Av (1n , pub, corr, G) if k = kv,d then return 1 else return 0
able to derive the key. Furthermore these users will not be able to distinguish the key from a randomly chosen key. This is true even in the presence of collusion. 3. The server does not know user keys, and the actual social network is protected.
Figure 1: A key recovery experiment in which a static adversary participates.
4. The scheme is efficient in that the public storage at the server is proportional to the size of the social network.
1.1
n Experiment Expind−0 Π,Av (1 ) (1n , pub, sec) ← SOGEN (1n , G, L) corr ← Corruptv,d (sec) k ← {0, 1}n b ← Av (1n , pub, corr, G, k) return b
Problem Definition
We begin by defining some notation. There is a directed social network graph, G = (V, E), where V has a vertex for every user and an edge (u, v) ∈ E implies that u trusts v. In what follows we will refer to the vertex of a user and the user interchangeably. We define depthG (u, v) to be the shortest path in G from u to v, and define depthG (u, v) = ∞ if no such path exists. We define Fu,d,G = {v ∈ V : depthG (u, v) = d}; that is, Fu,d,G is all nodes in V that ? are d hops away from u in G. We also define Fu,d,G = d ? F ; that is, F consists of all nodes that are u,d,G u,d,G i=0 d or less hops from node from u. We assume that while G exists, it is private and should not be reconstructed publicly. Specifically, it is assumed that each user knows all of their outgoing and incoming edges for their vertex in the graph, but the user does not know other users’ edges. Let L be the maximum allowable depth for which a user wants to share information, typically L will be very small. The key management scheme should assign L keys to every user; the keys for user u are denoted by ku1 , . . . , kuL . The ? scheme should allow all users in Fu,d,G to obtain kud , but ? no user in V − Fu,d,G should be able to obtain this key. The naive solution where users are simply given all of their keys fails for several reasons: i) it assumes that the entire social network is known to somebody which is one of the things we are trying to avoid and ii) it requires users to store a prohibitively large number of keys. More formally, a key management scheme for social networks consists of a tuple of probabilistic polynomial time algorithms (SOGEN, SODER) such that:
n Expind−1 Π,Av (1 ) (1n , pub, sec) ← SOGEN (1n , G, L) corr ← Corruptv,d (sec)
b ← Av (1n , pub, corr, G, kvd ) return b
Figure 2: A pair of key indistinguishability experiments in which a static adversary participates. the actual key from a random key. This latter notion is preferred in cryptographic applications, because it states that the adversary has no significant information about the key. Thus such a scheme can be composed with other cryptographic tools more readily than a scheme that provides only security against key recovery. While our definitions are for static adversaries, it was shown in [2], that this implied security for adaptive adversaries.
S
• Key Recovery: Security against key recovery implies that an adversary that doesn’t control any nodes that i for any are d hops from node A, cannot obtain kA i ∈ [1, L]. We represent the key recovery requirement n as experiment Exprec Π,Av (1 ) in Figure 1. In this experiment, Corruptv,d (sec) returns the secret information for all nodes that are more than d hops away from n n rec v. We define Advrec Π,Av (1 ) = P r[ExpΠ,Av (1 ) = 1]. We say that a key management scheme provides security against key recovery for static adversaries if n Advrec Π,Av (1 ) is negligible in n. • Key Indistinguishability: Security against key indistinguishability implies that an adversary that does not control any nodes that are d hops from vertex v, cannot distinguish kvd from a randomly chosen key. We define two experiments, in Figure 2, and we define n Advind Π,Av (1 ) as
• SOGEN is an information generation algorithm that takes as input security parameter 1n , social network graph G = (V, E), and max derivation depth L. It produces public information pub, a piece of secret information secu for each u ∈ V , and L keys, ku1 , . . . , kuL , for each user u ∈ V . The idea is that each user, u, will receive secu and pub will be made public. We will denote as sec the set of all user secret information.
n ind−1 n |P r[Expind−0 Π,Av (1 ) = 1] − P r[ExpΠ,Av (1 ) = 1]|
We say that a key management scheme provides key inn distinguishability against a static adversary if Advind Π,Av (1 ) is negligible in n.
• SODER is the key derivation algorithm that takes as input security parameter 1n , public information pub, source node u, destination node v, key depth d, and source node secret information secu . As output this produces kvd if and only if depth(u, v) ≤ d.
1.2
Our Contributions
1. We introduce a scheme for key management in social networks assuming that a server is present to distribute the keys. This is an initial strawman solution, because it assumes the server knows the entire social network.
We require that if pub and secu were generated using ? SOGEN (1n , G, L), and ∀v ∈ V, ∀u ∈ Fu,d,G (where d ≤ L), n then SODER(1 , pub, u, v, d, secu ) = kvd We consider two types of security requirements [1], security against key recovery and security against key indistinguishability. Essentially key recovery states that an adversary cannot recover the exact key from the public information, while key indistinguishability states that an adversary cannot distinguish
2. We remove the need for the server by decentralizing the algorithms. This second scheme reveals the entire social network however. 3. We extend the previous scheme to eliminate the revelation of the social network.
12
4. We extend the scheme to: i) support dynamic changes to the social network, ii) support multiple types of relationships, and iii) to support different relationship strengths.
1.3
requester is authorized to access the resource based on depth of the requester from the resource owner. Drawbacks of this approach is that relationship strengths are revealed to intermediate users, and the scheme required multiple users to engage in a protocol for each new access. Another scheme was introduced in [13], that also protected the relationship strengths. All of the above work either relied on a third party (who when corrupted could access all data) or require the participants to actively engage in a protocol. That is if Alice wants to access a resource of Bob, then both she and Bob must be online at the same time. Furthermore, if the path from Alice to Bob contains other users, then all of these other users must also be online. In this paper we consider protocols that are asynchronous, that is we do not require all parties to be online simultaneously. This is how many social networks currently operate. However, the price of an asynchronous scheme is: i) we do not support the full range of access policies of the previous work, and ii) we do not protect the relationships to the same extent as the previous work. In [16] a scheme was proposed for hiding content from the social networking site, however this did not achieve the same type of access control as the current paper. Key management for access hierarchies (such as an RBAC) has been well studied. It is addressed in [1] (which gives a survey of prior work in this area). It introduced a scheme based on pseudorandom functions and CCA-secure encryption that supported key management in an access hierarchy. Any updates are handled locally and are not propagated to the descendant or ancestor nodes. A trusted central authority is used to generate and distribute the keys. Recently a variation of this work achieved similar results while also protecting the access graph [7]. While this is the same access control enforcement that is considered in this paper, it is not sufficient to simply apply this scheme to the social network graph. If this were done, then any node that had any path to Alice’s vertex could generate her key. This key management framework has been applied to other access control models, including temporal key management [2].
Organization of Manuscript
The rest of this manuscript is organized as follows. In section 2 related work is discussed. In section 3 details of previous key management schemes are described. Section 4 provides a strawman protocol that has a trusted server. This scheme is improved by removing the server in section 5, however this scheme still reveals the social network. Several extensions are discusses in section 6, including a scheme that protects the social network is given in section 6.1. Finally, the manuscript is summarized and future work is given in section 7.
2.
RELATED WORK
There has been a substantial amount of recent work has attempted to address the problem of privacy in social networks. One area of research is how to publish social network data while preserving user privacy. One potential approach is to remove identifying information from the published networks, but this is not sufficient. For example, it was shown in [3, 18] that an adversary who corrupts a small number of users, could introduce patterns into the graph which will allow the adversary to de-anonymize several honest users. However, there have been other schemes [12, 15, 17] that introduce changes in the graph to mitigate these concerns. For a detailed survey of this work see [8]. However, the goal of the above-mentioned work is very different from the goal of this manuscript. Specifically, this work assumed that a single authority who knows the entire social network would like to publish a social network so that the data can be analyzed. However, the model in this paper aims to avoid any individual from knowing the entire social network, and to provide users with the ability to share resources with each other without relying on a trusted third party. Another area of research has been to compute functions on social networks where the knowledge of the data is distributed amongst multiple parties. In [11] a set of privacypreserving protocols was given for reconstructing a social network based on individual’s local information. In [10] protocols were given to determine if two users were friends of friends. Finally, in [14] protocols were given for computing various metrics for a social network. Again the goal of this manuscript is very different from the goal of this previous work; that is the above-mentioned work does not attempt to protect privacy of resources. The most closely related work in social network privacy is the area of access control for social networks [5, 6, 4, 9, 13]. In [5] an access control model was given that allowed users to specify access rules for their content. It provides a ˇ rule-based access control for selective distribution of usersS resources in social networks. This scheme used a trusted third party to enforce the access policies. This requirement was removed in [6, 4], but these schemes required that the users of the social network must be online to perform a protocol. In [9] a scheme based on public-key protocol achieved the same features, while eliminating the need for a central node. This prevents the threat of entire system being compromised when the central node is compromised. According to this protocol, the resource owner can identify whether the
3.
BUILDING BLOCK: KEY MANAGEMENT
The scheme for social networks used in this paper uses the key management scheme for access hierarchies from [1] as a starting point. In [1], a key derivation scheme was described for an access graph. In this scheme if there exists a path from node A to node B in the access graph, then A can derive B’s key. However, if there is not a path, then B’s key should be indistinguishable from a randomly generated value. This scheme was secure in the presence of an adaptive adversary that could corrupt multiple nodes assuming pseudorandom functions and CCA-secure encryption. The public information is proportional to the size of the graph, and key derivation requires work proportional to the length of the path from the source to the destination nodes. Furthermore, this scheme does not require expensive cryptographic operations. At a high level, the scheme in [1] used two algorithms Setup(1n , G0 ) and Der(1n , pub, u, v, secu ). The Setup algorithm takes as input the access graph and produces public information pub and a secret for each node in the graph. The Der algorithm takes the public information pub, a source node u, a destination node v, and the source node’s secret secu , and if there is a path from u to v in the access graph derives the key for node v. As the scheme for social net-
13
Notation G = (V, E) depthG (u, v) kud Fu,d,G ? Fu,d,G L G0 Vu Vud
works uses this scheme as a starting point, we now briefly describe how the scheme works in more detail. Each node in the graph will be assigned a public label and a secret; we denote this label and the secret for A respectively by `A and secA . Using these values the scheme derives a tag and a key for each node in the graph, denoted respectively by tA and kA . Furthermore, each edge, (A, B) in the graph will be assigned a public label, yA,B . The relationships between these values are as follows: • tA = FsecA (0||`A ) where F is a Pseudorandom function.
`v tv kv yu,v su
• kA = FsecA (1||`A ). • yA,B = EncrA,B (tB ||kB ) where rA,B = FtA (`B ) and Enc is a CCA-secure encryption scheme. The key derivation properties of the above scheme are as follows: i) given secA and the public information one can derive tA and kA and ii) given tA , kA , and yA,B one can derive kB and tB . Also, by changing labels, it is possible to make changes to the graph without having to rekey individuals. That is, it is possible to change the key of a node, to add edges, to remove edges, and to add nodes without ever having to rekey any users. We refer the reader to [1] for more details as well as the proof of security (for key recovery and key indistinguishability) for the scheme. We introduce two other algorithms used by our protocol in addition to Setup and Der: i) CREAT E(`B , kB , tB , kA , tA ) that simply returns the edge information as if an edge was created in a graph from a node with tag-key pair (tA , kA ) to a node with label `B and tag-key pair (tB , kB ), and ii) F OLLOW (kA , tA , yA,B , `B ), which returns the tag-key pair for a node with label `B , if the edge information is yA,B and the source node’s tag-key pair is (tA , kA ).
Table 1: Notation in paper G0 has L + 2 vertices. One vertex, Vv , is referred to as the master vertex, and the other vertices Vv0 , . . . , VvL are referred to as the content vertices. The Setup algorithm from a key allocation scheme with key indistinguishability (such as [1]) is applied to G0 to produce public information pub and secret information sec. User u is given the secret corresponding to vertex Vu . Furthermore, u’s content key for users within d hops from u in the social network is the key associated with content vertex Vud . For each edge (v, u) in the social network (e.g., u should be able to derive v’s keys), an edge is added from Vui to Vvi+1 (this facilitates friends that are i hops from u can obtain the i + 1 hop key for v). A crucial property of the construction of G0 is that there will be a path from Vu to Vvd if and only if there is a path from v to u in G with length ≤ d. It is important to note that the direction of the edges in the access graph is the opposite of the edge direction in the social network graph. This is because, in the social network graph an edge from u to v implies that u trusts v, but in the access graph an edge from u to v implies that u can derive v’s key (i.e., v trusts u). The full details of the SOGEN algorithm are described in Algorithm 3. To derive keys in the social network, the SODER algorithm simply invokes Der on G0 with appropriate vertex choices. For example, if user u wants to derive user v’s depth d key, Der is used to derive the key for Vvd using the secret of Vu . The full details are described in Algorithm 4.
Algorithm 1 CREAT E(`B , kB , tB , kA , tA ) 1: rA,B = FtA (`B ) 2: yA,B = EncrA,B (tB |||kB ) 3: return yA,B
Algorithm 2 F OLLOW (kA , tA , yA,B , `B ) 1: rA,B = FtA (`B ) 2: tB ||kB = DecrA,B (yA,B ) 3: return tB ||kB
4.
Meaning Social network graph Distance from u to v in graph Depth d key for user u Vertices exactly d hops form u Vertices ≤ d hops from u The maximum derivation depth An access graph created for G A master vertex created for user u A content vertex created for user u that corresponds to depth d A label associated with vertex v A tag associated with vertex v A key associated with vertex v A label associated with edge (u, v) Secret for user u
4.1
Example
STRAWMAN SOLUTION
Before describing the construction we show the notation used throughout this paper in Table 1. We initially describe a solution which assumes a centralized keying authority establishes the user keys based on the social network graph. This scheme is not secure against a malicious or compromised key server and it assumes that a single server knows the entire social network. These weaknesses are mitigated by our later schemes that remove the centralized key authority, however this strawman solution introduces important ideas used by the improved schemes. The key authority converts the social network graph G = (V, E) into a new access graph G0 . For each vertex v ∈ V ,
Figure 3: Example Social Network We now clarify SOGEN and SODER using an example. Consider the social network in Figure 3. The graph that results from SOGEN (G, L, 1n ) is depicted in Figure 4. Notice that there is a path from VB to VA1 but there is not a path from VC to VA1 . Thus B will be able to obtain the depth 1
14
Algorithm 3 SOGEN (G, L, 1n ) 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23:
path u, u1 , . . . , u` , v in G where ` ≤ d−1. Thus the following is a path from Vu to Vvd in G0 :
0
V = {} E 0 = {} for all v ∈ V do V 0 = V 0 ∪ {Vv } for i = 0 to L do V 0 = V 0 ∪ {Vvi } E 0 = E 0 ∪ {(Vv , Vvi )} if i 6= 0 then E 0 = E 0 ∪ {(Vvi−1 , Vvi )} end if end for end for for all (v, u) ∈ E do for i = 0 to L − 1 do E 0 = E 0 ∪ {(Vui , Vvi+1 )} end for end for (pub, sec) ← Setup(1n , G0 ) {G0 is the graph (V 0 , E 0 )} pub0 := pub for all v ∈ V do sec0v := secVv end for return (pub0 , sec0 )
Vu , Vu0 , Vu11 , Vu22 , . . . , Vu`` , Vv`+1 , Vv`+2 , . . . , Vvd+1 Note that the edge (Vu , Vu0 ) exists because of Step 7, ) exist because of Step 15, the edge the edges (Vuii , Vui+1 i+1 (Vu`` , Vv`+1 ) exists because of Step 15, and the edges (Vvi , Vvi+1 ) exist because of Step 9. To show the other direction, suppose there is a path in G0 between Vu and Vvd . Since master vertices have no incoming edges, this path contains only one such node (namely, Vu ). Denote this path by: Vu , Vui0 , Vui11 , Vui22 , . . . , Vuinn , Vvd All edges from nodes created in Steps 9 and 15, increase the index by one; that is if there is an edge from Vxi to Vyj , then j = i + 1. Thus i1 = i0 + 1, i2 = i0 + 2, . . . , in = d − 1. Since there is a path from Vu0 to Vui for all i, WOLOG we assume the i0 = 0. Thus, WOLOG assume that the path is: Vu , Vu0 , Vu11 , Vu22 , . . . , Vud−1 , Vvd d−1 If ui 6= ui+1 , then there must be an edge from ui to ui+1 in G, as this is the only case where such edges are added. If we let u01 , . . . , u0n , denote the vertices on the above path with duplicates removed, then u, u01 , . . . , u0n , v is a path in G, and furthermore, n0 < d. Therefore this is a path in G with length ≤ d from u to v. 2
Algorithm 4 SODER(1n , pub, u, v, d, secu ) 1: kvd := Der(1n , pub, Vu , Vvd , secu ) 2: return kvd
Theorem 2. If the underlying key allocation system is secure against key indistinguishability (key recovery), then (SOGEN, SODER) provide key indistinguishability (key recovery) for social networks.
key for A, but C cannot. However, C can obtain the depth 2 key for A, since there is a path from VC to VA2 in G0 .
4.2
Analysis
For each vertex of G, there are O(L) vertices in G0 , thus |V 0 | = O(L|V |). In Steps 7 and 9 of SOGEN , O(L) edges are created for each vertex, and in Step 15 O(L) edges are created for each edge in E. Thus |E 0 | = O(L|V | + L|E|). Assuming that (Setup, Der) is the scheme in [1], then to derive a depth d content key, SODER must find a path to the appropriate content key and then must perform O(1) cryptographic operations for each edge on this path. Thus the total number of cryptographic operations required by key derivation is O(d). Finding the path will require O(|V 0 | + |E 0 |) = O(L|V | + L|E|) operations, assuming that a breadth first search is used to find the path.
4.3
Proof Sketch: The security of this scheme follows from Lemma 1 and the security of the key allocation scheme (Setup, Der). That is, suppose an adversary who has not corrupted any nodes within d hops of A can distinguish the d from a randomly chosen value. This means that the key kA adversary can distinguish the key for vertex VAd from a random key. By Lemma 1, the adversary has not corrupted any nodes that have a path to VAd , and thus the adversary must have broken the original key allocation scheme. 2
5.
Proof of Security
DECENTRALIZING THE SCHEME
In this section we remove the key authority. This scheme suffers from the drawback that the social network graph is reconstructed and posted publicly, but this is mitigated later. The main difference is that the actions performed by SOGEN will now be distributed amongst the users. The same access graph is created, but it will be built by individual users and pairs of users in various steps. These steps include:
As will be shown in Lemma 1, the access graph created in SOGEN will have a path from Vv to Vud if and only if the distance from u to v in the social network is ≤ d. In the key allocation mechanism when Setup is applied to a graph G, vertex s can derive vertex e’s key if and only if there is a path from s to e in G. Combining the above implies that when given secVv (i.e., the secret information for user v) and pub it is possible to derive the key for Vud if and only if there is a path in the social network from u to v of length ≤ d.
• Vertex Creation: Each individual user will create their own piece of the graph, that is they will create a master node, their content nodes, and the edges between these nodes. Figure 5 shows the subgraph for user A. Since the user has now created his own keys, only the user himself will have these keys at this point. The public information created for this subgraph is posted.
Lemma 1. Let G0 be the access graph created by SOGEN (G, L, 1n ) for a social network graph G. There is a path from Vu and Vvd if and only if depthG (v, u) ≤ d. Proof: Suppose depthG (v, u) ≤ d, then there exists a
15
Figure 4: Example Access Graph • Edge Creation: This is done in two steps. First the edge source sends information to the destination. Basically, the source sends its key information to the destination vertex; that is it sends enough information so that the user corresponding to the destination vertex can compute the edge label. The destination vertex then creates edge information in the access graph which is then posted.
the server’s graph. This is acceptable because this is only done during user setup. 3. ADDEDGE(username, pwd, src, dest, edgeLabel) This adds an edge with a specific label between two vertices in pub. The server enforces access control over this operation; that is a user can only add edges to vertices that this user created. 4. GET P U B(): This returns the public information. Note that this operation is anonymous and does not require the user to authenticate to the server. One downside to this is that it requires downloading the entire social network. A possibile mitigation to this problem is that the user can request a particular subgraph. 5. SEN D(send, rec, mess): This sends a message from send to rec. We assume that this is done via a private and authenticated channel. We assume that the server is unaware of who is sending/receiving the messages as well as to the content of the messages. This could be achieved by using a communication channel outside of the system, but in order to authenticate the communication channel a PKI appears to be necessary.
Figure 5: Subgraph for user Notice that this scheme still requires a server, however this server is different from the server in the previous section. Mainly it doesn’t know the users’ content keys. This server simply stores pub and allows users to access this information. However, to prevent users from adding edges to other user’s sub-graphs, this server authenticates users before allowing them to modify pub. Specifically, it will allow users to modify only their own subgraphs. In the protocols below we achieve this authentication with a password, but it is trivial to modify the protocol to use other authentication mechanisms.
5.1
5.2 5.2.1
Scheme User setup
The user creates an account on the server, and then he creates an access subgraph for himself. This corresponds to the master vertex and the content vertices. The user then applies Setup to his subgraph to establish a key allocation scheme for this graph. The user posts this access subgraph on the server. The details of the algorithm for creating the access graph is described in Algorithm 5.
Server Setup
We assume that the following services are available:
5.2.2
1. CREAT E(name, pwd): This creates a user account with a specific username. The password, pwd, is used to authenticate the user at a later point in time. If a user’s account cannot be created this method will return f alse otherwise it will return true. 2. M ERGEP U B(username, pwd, userP ub) This takes the public information for a user’s subgraph and merges it into the server’s graph. This assumes that the new subgraph is isolated (i.e., has no common vertices) from
16
Offer Edge
When A wants to offer an edge to user B, A simply sends the tag and key of content node VA1 to B. That is, B will have to create edges to A’s vertices, and so B needs the necessary information to compute the public edge labels. We assume that the algorithm Der is the same as Der (from [1]) except that it will return both the tag and the key for a specific vertex–rather than just the key. This is a trivial modification of Der, since Der already computes the tag.
d
6.
Algorithm 5 SERSET U P (1n , A, pwd, L) 1: bool := CREAT E(A, pwd) 2: if bool = f alse then 3: F AIL 4: end if 5: {Create access subgraph G0 } 6: V 0 := {} 7: E 0 := {} 8: V 0 := V 0 ∪ {VA } 9: for i = 0 to L do 10: V 0 := V 0 ∪ {VAi } 11: E 0 := E 0 ∪ {(VA , VAi )} 12: if i 6= 0 then 13: E 0 := E 0 ∪ {(VAi−1 , VAi )} 14: end if 15: end for 16: {Compute graph keys and post} 17: (pubA, secA) ← Setup(1n , G0 ) 18: M ERGEP U B(username, pwd, pubA) 19: sA := secVA
6.1
6.2
Accept Edge
When B accepts the edge from A, he adds edges from his subgraph to A’s subgraph. The details are in Algorithm 7. 1 , sB , pwd) Algorithm 7 ACCEP T (A, B, 1n , t1A ||kA 1: pub := READP U B() 0 ← Der(1n , pub, VB , VB0 , secB ) 2: t0B ||kB 1 0 1 , t1A ) , t0B , kA := CREAT E(`V 1 , kB 3: yA,B A 1 ) 4: ADDEDGE(B, pwd, VB0 , VA1 , yA,B 5: for i = 2 to L do i−1 i−1 i ← F OLLOW (kA , tA , yV i−1 ,V i , `V i ) 6: tiA ||kA
d
d
A
A
1. When a content vertex is rekeyed, all incoming edges need to be updated. However, the owner of the content vertex does not necessarily know the key of of the source vertex. Referring back to Figure 4, if A wants to change the key for VA1 , then it would need to update the edge from VB0 , but A does not have the necessary information to update this value.
A
i−1 ← Der(1n , pub, VB , VBi−1 , secB ) ti−1 B ||kB i−1 i−1 i i := CREAT E(`V i−1 , kB , tB , kA , tiA ) yA,B B
i ) 9: ADDEDGE(B, pwd, VBi−1 , VAi , yA,B 10: end for
5.3
Dynamic Changes
The key allocation scheme for access hierarchies from [1] supported dynamic changes to the graph. Assuming that at most one user was assigned to every node (which is the case in this manuscript) it is possible to: i) add vertices, ii) remove vertices, iii) change keys, iv) add edges, and v) remove edges. All of these things could be done without rekeying any individual user, and required only changes to the public information. At first glance this would appear to solve the problem of dynamic changes for social network access control. In fact, for the strawman protocol (section 4) this is the case, because there is a server to manage the public information. Furthermore, adding vertices and edges is straightforward in all of the schemes. However the decentralized scheme presents several difficulties, including:
d
7: 8:
Hiding the Social Network
The previous scheme does not protect the social network. That is, pub will contain the entire access graph from which the social network can be recovered. To mitigate this we use the technique from [7]. The idea is as follows: we hide the destination of the edges as well as the public edge information with encryption. That is if there is an edge from VAi and VBj then the system encrypts the destination (i.e., VBj ) and the edge information yV i ,V j with the key for VBj . By doing A B this the only users who can obtain the edge information are those that could already access VBj . Thus a specific user will only be able to see his or her neighborhood in the graph. A downside to this strategy is that key derivation will be slower as it will require multiple decryptions to perform the derivation. Another downside is that the every time a user accesses the social network, he will have to download the entire social network. And so the scheme is not scalable; we leave the mitigation of this problem as future work.
Algorithm 6 OF F ER(A, B, 1n , sA ) 1: pub := READP U B() 1 := Der(1n , pub, VA , VA1 , sA ) 2: t1A ||kA 1 ) 3: SEN D(A, B, t1A ||kA
5.2.3
EXTENSIONS
2. When removing a vertex then all vertices that are reachable from this vertex need to change keys. Referring back to Figure 4, suppose user B wants to be removed. Then A should update her keys, in order to prevent C and D from accessing her content (as they no longer have a path to A in the social network).
Proof of Security (sketch) and Analysis
Security follows because the public information in this scheme is identically distributed to that created in the centralized scheme from the previous section. It is straightforward to see that the graph created by the distributed algorithms has the same vertices and edges as the graph created in Algorithm 3. Furthermore, if the (Setup, Der) are the algorithms from [1] then edge and vertex information is generated in the same manner. Thus if the previous scheme is secure, then this new scheme is also secure. Since the graph is the same as before, the analysis does not change from the previous section. However, it is worth noting that the user must now perform O(L) work to do user setup and to accept a relationship.
3. When removing an edge (e.g., if A no longer trusts B), then A will need to rekey her content vertices. However, this will require changing all incoming edges to these vertices. Furthermore, all users that trust A (either directly or indirectly) need to update their keys. For example, suppose B wants to remove his trust relationship with C in Figure 4. B would have to change the keys associated with VB1 and VB2 . The edges coming from D’s nodes would have to be update (and B does not have the information to do this). Also A should rekey her vertices in order to prevent C from access-
17
6.3
ing her content, and again B does not have enough information to make all of these changes.
Relationship Types
In all of the previous schemes we have considered only a single relationship type. A more flexible approach for a web-based social network would be to allow users to indicate various types of relationships (e.g., friend, family, etc). Having this extra information would allow more flexibility than the single-relationship type system. For example, a policy could be made that allows family to access some content, and friends to access other content. An even more flexible model would allow users to specify a hierarchy of relationships, such as there could be relationships family, friend, and both. People with the both relationship would be able to see everything that family and friends could access. Supporting multiple relationships is straightforward. Each user will create L + 1 vertices for every relationship type. When establishing a relationship with another user, the user simply sends the keys for the appropriate relationship to that user. To support a hierarchy of relationships, the content vertices are connected to allow derivation. Figure 7 shows a subgraph for a user A, with three types of relationships friend, family, and both. For example, if Bob was Alice’s friend, then she would give him access to VA1 and VA2 . However if Bob was friend and family, then she would give him access to VA100 and VA200 . From these keys he could derive the keys for VA1 , VA2 , VA10 , and VA20 .
Clearly, the above system is unusable for dynamic key management in the social network. However, by making two small changes to the system, this situation is significantly improved. These changes are: i) to add a level of indirection to make key changes possible, and ii) to rekey all users periodically. In the remainder of this section, these two ideas are explored in more detail. In this new system, when a user, A, wants to offer a relationship to another user, B, then the following steps occur: 1 L 1. A creates L new vertices VAB , . . . , VAB , creates edges i from VA to VAB for all i ∈ [1, L], creates edges between i+1 i VAB and VAB (for i ∈ [1, L − 1]), and creates edges i from VAB and VAi (for i ∈ [1, L]). A also creates tags, keys, and labels for these new vertices and assigns labels to the edges (as in the key allocation scheme). A posts these new vertices to the public information. 1 2. A sends the tag key pair t1AB ||kAB to B. i for i ∈ [1, L] 3. B creates edges between VBi−1 and VAB
See Figure 6 for an example of a graph between two users after the above process has been completed. With this d , then A change if A wants to change the content key kA can assign a new key to VAd (and later keys) and simply update all of the edges to this vertex; note that A can make i for all this change since it knows the keys for vertices VAM trusted nodes M and i ∈ [1, L]. This does increase the size of the graph from O(L|V |) to O(δLV ) where δ is the maximum number of relationships for any vertex in the graph.
Figure 7: Example access graph with different relationship types
6.4
Relationship Strengths
So far the scheme has considered all relationships to be the same, which is not necessarily true. In this section we extend the scheme to support a more flexible model. The model that we consider is an adaptation of the model considered in [5, 6, 4, 9, 13]. Each relationship is assigned an integer from 0 to M that indicates the level of trust, where M is a high level of trust and 0 means that no trust exists. Trust is transferred in the multiplicative manner. That is, if A trusts B with level i and B trusts C at level j, then A trusts C ij c. We take the approach from [13], and assume at level b M the trust between two users is the maximum trust level that can be found on any path between the two users. By making minor modifications to the previous schemes it is possible to support this new trust model. However, it is important to note that this new scheme does not hide the relationship trust levels as previous synchronous schemes such as [13] have. Instead of having a content vertex for every node, a user will have M content nodes (one for each trust level); denote these by VAM , . . . , VA1 . If user A wants to
Figure 6: Graph for A and B The second problem, i.e., of updating the keys of users that trust A when A removes an edge, is not as easily solved. A naive solution would be to update all of users that trust A whenever A removes any relationships. However, this would require notifying all users that have a trust chain to A of size L or less. As this could be a large number of users (many of which A may not know), this is clearly not a workable solution. However, a better way to mitigate this problem is to have users rekey their keys periodically. In the extreme case this is done for every login. Now a user would be ensured that when content is posted, it would be for the access graph at the time of the last login.
18
establish a relationship with user B at level i, then A sends the tag and key for VAi to B. B then adds an edge from VBj
[5] B. Carminati, E. Ferrari, and A. Perego. Rule-based access control for social networks. In Proc. of the OTM Workshops number, pages 1734–1744, 2006. [6] B. Carminati, E. Ferrari, and A. Perego. Private relationships in social networks. in ICDE Workshops, pages 163–171, 2007. [7] S. De Capitani di Vimercati, S. Foresti, S. Jajodia, S. Paraboschi, G. Pelosi, and P. Samarati. Preserving confidentiality of security policies in data outsourcing. In WPES ’08: Proceedings of the 7th ACM workshop on Privacy in the electronic society, pages 75–84, New York, NY, USA, 2008. ACM. [8] L. Ding, L. Zhou, T. Finin, and A. Joshi. How the semantic web is being used: An analysis of foaf documents. In Proc. of the, 113(3), 2005. [9] J. Domingo-Ferrer. A public-key protocol for social networks with private relationships. in Lecture Notes in Computer Science, pages 373–379, August 2007. [10] M. Freedman and A. Nicolosi. Efficient private techniques for verifying social proximity. In International Workshop on Peer-to-Peer Systems (IPTPS), 2007. [11] K. Frikken and P. Golle. Private social network analysis: how to assemble pieces of a graph privately. In ACM Workshop On Privacy In The Electronic Society (WPES’06), pages 89–98, 2006. [12] M. Hay, G. Miklau, D. Jensen, D. Towsley, and P. Weis. Resisting structural re-identification in anonymized social networks. Proceedings of the VLDB Endowment, 1(1):102–114, 2008. [13] Viejo Alexandre J. Domingo-Ferrer, Sebe Francesc, and Gonzalez-Nicolas Ursula. Privacy homomorphisms for social networks with private relationships. Elsevier, Computer Networks, 2008. [14] F. Kerschbaum and A. Schaad. Privacy-preserving social network analysis for criminal investigations. In ACM Workshop on Privacy in the Electronic Society, pages 9–14, 2008. [15] L. Liu, J. Wang, J. Liu, and J. Zhang. Privacy preserving in social networks against sensitive edge disclosure. Technical Report CMIDA-HiPSCCS 006-08, Department of Computer Science, University of Kentucky, 2008. [16] M. Lucas and N. Borisov. Flybynight: mitigating the privacy risks of social networking. In ACM Workshop On Privacy In The Electronic Society (WPES’08), pages 1–8, 2008. [17] E. Zheleva and L.Getoor. Preserving the privacy of sensitive relationships in graph data. In First ACM SIGKDD Workshop on Privacy, Security, and Trust in KDD (PinKDD 2007), 2007. [18] B. Zhou and J. Pei. Preserving privacy in social networks against neighborhood attacks. In International Conference on Data Engineering (ICDE’08), pages 506–515, 2008.
b ij c
to VA M for all j ∈ [1, M ]. As an example consider Figure 8, where M = 4, and A trusts B at level 2.
Figure 8: Graph for A and B when M = 2 and relationship strength is 2 While this modification supports a more flexible access control model, it does reveal the strength of each relationship for every edge on the path, which is undesirable in some circumstances.
7.
SUMMARY/FUTURE WORK
In this paper we have made a first step to the creation of a key management mechanism that enforces access control for a social network. With this mechanism it is possible to create a social networking service that protects user’s content from the server and other untrusted users. As future work we plan to implement the system to analyze its effectiveness. Other issues to be considered in future work include: i) edge removal leaves much to be desired in the current scheme, ii) to access other user’s data one has to download the information for the entire social network (which is clearly not scalable), and iii) nothing prevents malicious users from sharing other user’s keys with unauthorized users in the system.
Acknowledgements The authors would like to thank the anonymous reviewers for their comments and useful suggestions.
8.
REFERENCES
[1] M. Atallah, M. Blanton, N. Fazio, and K. Frikken. Dynamic and efficient key management for access hierarchies. ACM Trans. Inf. Syst. Secur., 12(3):1–43, 2009. [2] G. Ateniese, A. De Santis, A. Ferrara, and B. Masucci. Provably-secure time-bound hierarchical key assignment schemes. In ACM Conference on Computer and Communications Security (CCS’06), 2006. [3] L. Backstrom, C. Dwork, and J. Kleinberg. Wherefore art thou r3579x?: anonymized social networks, hidden patterns, and structural steganography. In International Conference on World Wide Web (WWW’08), pages 181–190, 2007. [4] B. Carminati and E.: Ferrari. Privacy-aware collaborative access control in web-based social networks. In V, editor, Atluri, pages 81–96. Springer, V., ed.: DBSec. Volume 5094 of Lecture Notes in Com-puter Science., : DBSec. Volume 5094 of Lecture Notes in Com-puter Science., Springer, 2008.
19
