Key Allocation Schemes for Private Social Networks

Keith B. FrikkenDepartment of Computer Science and Software

EngineeringsMiami University

Oxford, OHfrikkekb@muohio.edu

Preethi SrinivasDepartment of Computer Science and Software

EngineeringsMiami University

Oxford, OHsrinivp@muohio.edu

ABSTRACTIn this paper we introduce a novel scheme for key man-agement in social networks that is a first step towards thecreation of a private social network. A social network graph(i.e., the graph of friendship relationships) is private andsocial networks are often used to share content, which maybe private, amongst its users. In the status quo, the socialnetworking server has access to both this graph and to allof the content, effectively requiring that it is a trusted thirdparty. The goal of this paper is to produce a mechanismthrough which users can control how their content is sharedwith other users, without relying on a trusted third party tomanage the social network graph and the users’ data. Thespecific access control model considered here is that userswill specify access policies based on distance in the socialnetwork; for example some content is visible to friends only,while other content is visible to friends of friends, etc. Thisaccess control is enforced via key management. That is foreach user, there is a key that only friends should be able toderive, there is a key that both friends of the user and friendsof friends can derive, etc. The proposed scheme enjoys thefollowing properties: i) the scheme is asynchronous in thatit does not require users to be online at the same time, ii)the scheme provides key indistinguishability (that is if a useris 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 keyderivation time, and iv) the scheme is collusion resistant.

Categories and Subject DescriptorsH.3.3 [Information Search and Retrieval]: RetrievalModels

General TermsSecurity, Algorithms

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.WPES’09, November 9, 2009, Chicago, Illinois, USA.Copyright 2009 ACM 978-1-60558-783-7/09/11 ...$10.00.

KeywordsPrivacy, Key Management, Access Control, Social Networks

1. INTRODUCTIONSocial networking has become ubiquitous. The availability

of such information raises significant privacy concerns. Oneway to mitigate some of these concerns is to allow usersto control access to their resources. However, many currentsocial networking sites provide limited access control to usersover their content. There has been a significant amount ofwork in access control in social networks [5, 6, 4, 9, 13]. Someof these solutions assume that a server will enforce the accesscontrol, but this does not protect the privacy of the usersagainst the server. Other solutions are synchronous in thatthey require the users to enforce their own access control,and thus multiple users must be online simultaneously foreach content access. The goal of this paper is to provide adecentralized (i.e., no trusted third party) and asynchronousaccess control enforcement mechanism. More specifically, itshould allow access to a user’s content even when that useris not online, but the access should only be allowed whenthe access control policy is satisfied.

In this paper we consider performing social network ac-cess control via key management. More specifically, eachuser will have a set of keys, and other users will be able toderive some of these keys. The access control model1 thatwe consider is as follows: the trust level between two usersdepends on the distance between the users in the social net-work. For example, a friend of Alice will be able to accessmore content than a friend of a friend of Alice. The ad-vantage of using key management is that a user can simplypost content encrypted with the key corresponding to theaccess control policy for that content. If the key manage-ment is done properly, then only users that do not satisfythe policy will not have the key and thus the encrypted con-tent will be meaningless. One drawback of this approachis that malicious users could publish other users’ keys, andthen 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 notaware of any other scheme that satisfies these properties:

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

1A more complex access control model is considered as anextension in section 6.

11

able to derive the key. Furthermore these users will notbe able to distinguish the key from a randomly chosenkey. This is true even in the presence of collusion.

3. The server does not know user keys, and the actualsocial network is protected.

4. The scheme is efficient in that the public storage at theserver is proportional to the size of the social network.

1.1 Problem DefinitionWe begin by defining some notation. There is a directed

social network graph, G = (V, E), where V has a vertexfor every user and an edge (u, v) ∈ E implies that u trustsv. In what follows we will refer to the vertex of a user andthe user interchangeably. We define depthG(u, v) to be theshortest 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 thatare d hops away from u in G. We also define F ?

u,d,G =Sdi=0 Fu,d,G; that is, F ?

u,d,G consists of all nodes that ared or less hops from node from u. We assume that while Gexists, it is private and should not be reconstructed publicly.Specifically, it is assumed that each user knows all of theiroutgoing 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 userwants to share information, typically L will be very small.The key management scheme should assign L keys to everyuser; the keys for user u are denoted by k1

u, . . . , kLu . The

scheme should allow all users in F ?u,d,G to obtain kd

u, butno user in V − F ?

u,d,G should be able to obtain this key.The naive solution where users are simply given all of theirkeys fails for several reasons: i) it assumes that the en-tire social network is known to somebody which is one ofthe things we are trying to avoid and ii) it requires usersto store a prohibitively large number of keys. More for-mally, a key management scheme for social networks con-sists of a tuple of probabilistic polynomial time algorithms(SOGEN, SODER) such that:

• SOGEN is an information generation algorithm thattakes as input security parameter 1n, social networkgraph G = (V, E), and max derivation depth L. Itproduces public information pub, a piece of secret in-formation secu for each u ∈ V , and L keys, k1

u, . . . , kLu ,

for each user u ∈ V . The idea is that each user, u,will receive secu and pub will be made public. We willdenote as sec the set of all user secret information.

• SODER is the key derivation algorithm that takes asinput security parameter 1n, public information pub,source node u, destination node v, key depth d, andsource node secret information secu. As output thisproduces kd

v if and only if depth(u, v) ≤ d.

We require that if pub and secu were generated usingSOGEN(1n, G, L), and ∀v ∈ V, ∀u ∈ F ?

u,d,G (where d ≤ L),

then SODER(1n, pub, u, v, d, secu) = kdv We consider two

types of security requirements [1], security against key re-covery and security against key indistinguishability. Essen-tially key recovery states that an adversary cannot recoverthe exact key from the public information, while key indis-tinguishability states that an adversary cannot distinguish

Experiment ExprecΠ,Av

(1n)(1n, pub, sec)← SOGEN(1n, G, L)corr ← Corruptv,d(sec)k ← Av(1n, pub, corr, G)if k = kv,d then return 1else return 0

Figure 1: A key recovery experiment in which astatic adversary participates.

Experiment Expind−0Π,Av

(1n) Expind−1Π,Av

(1n)

(1n, pub, sec)← SOGEN(1n, G, L) (1n, pub, sec)← SOGEN(1n, G, L)corr ← Corruptv,d(sec) corr ← Corruptv,d(sec)k ← {0, 1}n

b← Av(1n, pub, corr, G, k) b← Av(1n, pub, corr, G, kdv)

return b return b

Figure 2: A pair of key indistinguishability experi-ments in which a static adversary participates.

the actual key from a random key. This latter notion is pre-ferred in cryptographic applications, because it states thatthe adversary has no significant information about the key.Thus such a scheme can be composed with other crypto-graphic tools more readily than a scheme that provides onlysecurity against key recovery. While our definitions are forstatic adversaries, it was shown in [2], that this implied se-curity for adaptive adversaries.

• Key Recovery: Security against key recovery impliesthat an adversary that doesn’t control any nodes thatare d hops from node A, cannot obtain ki

A for anyi ∈ [1, L]. We represent the key recovery requirementas experiment Exprec

Π,Av(1n) in Figure 1. In this exper-

iment, Corruptv,d(sec) returns the secret informationfor all nodes that are more than d hops away fromv. We define Advrec

Π,Av(1n) = Pr[Exprec

Π,Av(1n) =

1]. We say that a key management scheme providessecurity against key recovery for static adversaries ifAdvrec

Π,Av(1n) is negligible in n.

• Key Indistinguishability: Security against key indistin-guishability implies that an adversary that does notcontrol any nodes that are d hops from vertex v, can-not distinguish kd

v from a randomly chosen key. Wedefine two experiments, in Figure 2, and we defineAdvind

Π,Av(1n) as

|Pr[Expind−0Π,Av

(1n) = 1]− Pr[Expind−1Π,Av

(1n) = 1]|

We say that a key management scheme provides key in-distinguishability against a static adversary if Advind

Π,Av(1n)

is negligible in n.

1.2 Our Contributions

1. We introduce a scheme for key management in socialnetworks assuming that a server is present to distributethe keys. This is an initial strawman solution, becauseit assumes the server knows the entire social network.

2. We remove the need for the server by decentralizingthe algorithms. This second scheme reveals the entiresocial network however.

3. We extend the previous scheme to eliminate the reve-lation of the social network.

12

4. We extend the scheme to: i) support dynamic changesto the social network, ii) support multiple types of re-lationships, and iii) to support different relationshipstrengths.

1.3 Organization of ManuscriptThe rest of this manuscript is organized as follows. In

section 2 related work is discussed. In section 3 details ofprevious key management schemes are described. Section4 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. Severalextensions are discusses in section 6, including a scheme thatprotects the social network is given in section 6.1. Finally,the manuscript is summarized and future work is given insection 7.

2. RELATED WORKThere has been a substantial amount of recent work has

attempted to address the problem of privacy in social net-works. One area of research is how to publish social networkdata while preserving user privacy. One potential approachis to remove identifying information from the published net-works, but this is not sufficient. For example, it was shownin [3, 18] that an adversary who corrupts a small numberof users, could introduce patterns into the graph which willallow the adversary to de-anonymize several honest users.However, there have been other schemes [12, 15, 17] thatintroduce changes in the graph to mitigate these concerns.For a detailed survey of this work see [8]. However, the goalof the above-mentioned work is very different from the goalof this manuscript. Specifically, this work assumed that asingle authority who knows the entire social network wouldlike to publish a social network so that the data can be an-alyzed. However, the model in this paper aims to avoid anyindividual from knowing the entire social network, and toprovide users with the ability to share resources with eachother without relying on a trusted third party.

Another area of research has been to compute functionson social networks where the knowledge of the data is dis-tributed amongst multiple parties. In [11] a set of privacy-preserving protocols was given for reconstructing a socialnetwork based on individual’s local information. In [10] pro-tocols were given to determine if two users were friends offriends. Finally, in [14] protocols were given for computingvarious metrics for a social network. Again the goal of thismanuscript is very different from the goal of this previouswork; that is the above-mentioned work does not attemptto protect privacy of resources.

The most closely related work in social network privacyis the area of access control for social networks [5, 6, 4, 9,13]. In [5] an access control model was given that allowedusers to specify access rules for their content. It provides arule-based access control for selective distribution of usersSresources in social networks. This scheme used a trustedthird party to enforce the access policies. This requirementwas removed in [6, 4], but these schemes required that theusers of the social network must be online to perform a pro-tocol. In [9] a scheme based on public-key protocol achievedthe same features, while eliminating the need for a centralnode. This prevents the threat of entire system being com-promised when the central node is compromised. Accordingto this protocol, the resource owner can identify whether the

requester is authorized to access the resource based on depthof the requester from the resource owner. Drawbacks of thisapproach is that relationship strengths are revealed to in-termediate users, and the scheme required multiple users toengage in a protocol for each new access. Another schemewas introduced in [13], that also protected the relationshipstrengths. All of the above work either relied on a thirdparty (who when corrupted could access all data) or requirethe participants to actively engage in a protocol. That is ifAlice wants to access a resource of Bob, then both she andBob must be online at the same time. Furthermore, if thepath from Alice to Bob contains other users, then all of theseother users must also be online. In this paper we considerprotocols that are asynchronous, that is we do not requireall parties to be online simultaneously. This is how manysocial networks currently operate. However, the price of anasynchronous scheme is: i) we do not support the full rangeof access policies of the previous work, and ii) we do notprotect the relationships to the same extent as the previouswork. In [16] a scheme was proposed for hiding content fromthe social networking site, however this did not achieve thesame 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 asurvey of prior work in this area). It introduced a schemebased on pseudorandom functions and CCA-secure encryp-tion that supported key management in an access hierarchy.Any updates are handled locally and are not propagated tothe descendant or ancestor nodes. A trusted central author-ity is used to generate and distribute the keys. Recently avariation of this work achieved similar results while also pro-tecting the access graph [7]. While this is the same accesscontrol enforcement that is considered in this paper, it is notsufficient to simply apply this scheme to the social networkgraph. If this were done, then any node that had any path toAlice’s vertex could generate her key. This key managementframework has been applied to other access control models,including temporal key management [2].

3. BUILDING BLOCK: KEY MANAGEMENTThe 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 wasdescribed for an access graph. In this scheme if there ex-ists 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 randomlygenerated value. This scheme was secure in the presenceof an adaptive adversary that could corrupt multiple nodesassuming pseudorandom functions and CCA-secure encryp-tion. The public information is proportional to the size ofthe graph, and key derivation requires work proportional tothe length of the path from the source to the destinationnodes. Furthermore, this scheme does not require expensivecryptographic operations.

At a high level, the scheme in [1] used two algorithmsSetup(1n, G′) and Der(1n, pub, u, v, secu). The Setup algo-rithm takes as input the access graph and produces publicinformation pub and a secret for each node in the graph. TheDer algorithm takes the public information pub, a sourcenode u, a destination node v, and the source node’s secretsecu, and if there is a path from u to v in the access graphderives the key for node v. As the scheme for social net-

13

works uses this scheme as a starting point, we now brieflydescribe how the scheme works in more detail. Each nodein 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 anda key for each node in the graph, denoted respectively by tA

and kA. Furthermore, each edge, (A, B) in the graph willbe assigned a public label, yA,B . The relationships betweenthese values are as follows:

• tA = FsecA(0||`A) where F is a Pseudorandom func-tion.

• kA = FsecA(1||`A).

• yA,B = EncrA,B (tB ||kB) where rA,B = FtA(`B) andEnc is a CCA-secure encryption scheme.

The key derivation properties of the above scheme are asfollows: i) given secA and the public information one can de-rive tA and kA and ii) given tA, kA, and yA,B one can derivekB and tB . Also, by changing labels, it is possible to makechanges to the graph without having to rekey individuals.That is, it is possible to change the key of a node, to addedges, to remove edges, and to add nodes without ever hav-ing to rekey any users. We refer the reader to [1] for moredetails as well as the proof of security (for key recovery andkey indistinguishability) for the scheme.

We introduce two other algorithms used by our protocol inaddition to Setup and Der: i) CREATE(`B , kB , tB , kA, tA)that simply returns the edge information as if an edge wascreated 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)FOLLOW (kA, tA, yA,B , `B), which returns the tag-key pairfor a node with label `B , if the edge information is yA,B andthe source node’s tag-key pair is (tA, kA).

Algorithm 1 CREATE(`B , kB , tB , kA, tA)

1: rA,B = FtA(`B)2: yA,B = EncrA,B (tB |||kB)3: return yA,B

Algorithm 2 FOLLOW (kA, tA, yA,B , `B)

1: rA,B = FtA(`B)2: tB ||kB = DecrA,B (yA,B)3: return tB ||kB

4. STRAWMAN SOLUTIONBefore describing the construction we show the notation

used throughout this paper in Table 1.We initially describe a solution which assumes a central-

ized keying authority establishes the user keys based on thesocial network graph. This scheme is not secure against amalicious or compromised key server and it assumes that asingle server knows the entire social network. These weak-nesses are mitigated by our later schemes that remove thecentralized key authority, however this strawman solutionintroduces important ideas used by the improved schemes.

The key authority converts the social network graph G =(V, E) into a new access graph G′. For each vertex v ∈ V ,

Notation MeaningG = (V, E) Social network graphdepthG(u, v) Distance from u to v in graph

kdu Depth d key for user u

Fu,d,G Vertices exactly d hops form uF ?

u,d,G Vertices ≤ d hops from uL The maximum derivation depthG′ An access graph created for GVu A master vertex created for user u

V du A content vertex created for user u

that corresponds to depth d`v A label associated with vertex vtv A tag associated with vertex vkv A key associated with vertex v

yu,v A label associated with edge (u, v)su Secret for user u

Table 1: Notation in paper

G′ has L + 2 vertices. One vertex, Vv, is referred to as themaster vertex, and the other vertices V 0

v , . . . , V Lv are referred

to as the content vertices. The Setup algorithm from a keyallocation scheme with key indistinguishability (such as [1])is applied to G′ to produce public information pub and secretinformation sec. User u is given the secret corresponding tovertex Vu. Furthermore, u’s content key for users within dhops from u in the social network is the key associated withcontent vertex V d

u . For each edge (v, u) in the social network(e.g., u should be able to derive v’s keys), an edge is addedfrom V i

u to V i+1v (this facilitates friends that are i hops from

u can obtain the i + 1 hop key for v). A crucial propertyof the construction of G′ is that there will be a path fromVu to V d

v if and only if there is a path from v to u in Gwith length ≤ d. It is important to note that the directionof the edges in the access graph is the opposite of the edgedirection in the social network graph. This is because, inthe social network graph an edge from u to v implies that utrusts v, but in the access graph an edge from u to v impliesthat u can derive v’s key (i.e., v trusts u). The full detailsof the SOGEN algorithm are described in Algorithm 3. Toderive keys in the social network, the SODER algorithmsimply invokes Der on G′ 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 V d

v using the secret of Vu.The full details are described in Algorithm 4.

4.1 Example

Figure 3: Example Social Network

We now clarify SOGEN and SODER using an example.Consider the social network in Figure 3. The graph that re-sults from SOGEN(G, L, 1n) is depicted in Figure 4. Noticethat there is a path from VB to V 1

A but there is not a pathfrom VC to V 1

A. Thus B will be able to obtain the depth 1

14

Algorithm 3 SOGEN(G, L, 1n)

1: V ′ = {}2: E′ = {}3: for all v ∈ V do4: V ′ = V ′ ∪ {Vv}5: for i = 0 to L do6: V ′ = V ′ ∪ {V i

v }7: E′ = E′ ∪ {(Vv, V i

v )}8: if i 6= 0 then9: E′ = E′ ∪ {(V i−1

v , V iv )}

10: end if11: end for12: end for13: for all (v, u) ∈ E do14: for i = 0 to L− 1 do15: E′ = E′ ∪ {(V i

u , V i+1v )}

16: end for17: end for18: (pub, sec)← Setup(1n, G′) {G′ is the graph (V ′, E′)}19: pub′ := pub20: for all v ∈ V do21: sec′v := secVv

22: end for23: return (pub′, sec′)

Algorithm 4 SODER(1n, pub, u, v, d, secu)

1: kdv := Der(1n, pub, Vu, V d

v , secu)2: return kd

v

key for A, but C cannot. However, C can obtain the depth2 key for A, since there is a path from VC to V 2

A in G′.

4.2 AnalysisFor each vertex of G, there are O(L) vertices in G′, thus|V ′| = O(L|V |). In Steps 7 and 9 of SOGEN , O(L) edgesare created for each vertex, and in Step 15 O(L) edges arecreated for each edge in E. Thus |E′| = O(L|V | + L|E|).Assuming that (Setup, Der) is the scheme in [1], then to de-rive a depth d content key, SODER must find a path to theappropriate content key and then must perform O(1) crypto-graphic operations for each edge on this path. Thus the totalnumber of cryptographic operations required by key deriva-tion is O(d). Finding the path will require O(|V ′|+ |E′|) =O(L|V | + L|E|) operations, assuming that a breadth firstsearch is used to find the path.

4.3 Proof of SecurityAs will be shown in Lemma 1, the access graph created

in SOGEN will have a path from Vv to V du if and only if

the distance from u to v in the social network is ≤ d. In thekey allocation mechanism when Setup is applied to a graphG, vertex s can derive vertex e’s key if and only if there isa path from s to e in G. Combining the above implies thatwhen given secVv (i.e., the secret information for user v) andpub it is possible to derive the key for V d

u if and only if thereis a path in the social network from u to v of length ≤ d.

Lemma 1. Let G′ be the access graph created bySOGEN(G, L, 1n) for a social network graph G. There is apath from Vu and V d

v if and only if depthG(v, u) ≤ d.

Proof: Suppose depthG(v, u) ≤ d, then there exists a

path u, u1, . . . , u`, v in G where ` ≤ d−1. Thus the followingis a path from Vu to V d

v in G′:

Vu, V 0u , V 1

u1 , V 2u2 , . . . , V `

u`, V `+1

v , V `+2v , . . . , V d+1

v

Note that the edge (Vu, V 0u ) exists because of Step 7,

the edges (V iui

, V i+1ui+1) exist because of Step 15, the edge

(V `u`

, V `+1v ) exists because of Step 15, and the edges (V i

v , V i+1v )

exist because of Step 9.To show the other direction, suppose there is a path in G′

between Vu and V dv . Since master vertices have no incoming

edges, this path contains only one such node (namely, Vu).Denote this path by:

Vu, V i0u , V i1

u1 , V i2u2 , . . . , V in

un, V d

v

All edges from nodes created in Steps 9 and 15, increasethe index by one; that is if there is an edge from V i

x to V jy ,

then j = i + 1. Thus i1 = i0 + 1, i2 = i0 + 2, . . . , in = d− 1.Since there is a path from V 0

u to V iu for all i, WOLOG we

assume the i0 = 0. Thus, WOLOG assume that the path is:

Vu, V 0u , V 1

u1 , V 2u2 , . . . , V d−1

ud−1 , V dv

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 u′1, . . . , u

′n, denote the vertices on the above path

with duplicates removed, then u, u′1, . . . , u′n, v is a path in

G, and furthermore, n′ < d. Therefore this is a path in Gwith length ≤ d from u to v. 2

Theorem 2. If the underlying key allocation system issecure against key indistinguishability (key recovery), then(SOGEN, SODER) provide key indistinguishability (key re-covery) for social networks.

Proof Sketch: The security of this scheme follows fromLemma 1 and the security of the key allocation scheme(Setup, Der). That is, suppose an adversary who has notcorrupted any nodes within d hops of A can distinguish thekey kd

A from a randomly chosen value. This means that theadversary can distinguish the key for vertex V d

A from a ran-dom key. By Lemma 1, the adversary has not corrupted anynodes that have a path to V d

A , and thus the adversary musthave broken the original key allocation scheme. 2

5. DECENTRALIZING THE SCHEMEIn this section we remove the key authority. This scheme

suffers from the drawback that the social network graphis reconstructed and posted publicly, but this is mitigatedlater. The main difference is that the actions performed bySOGEN will now be distributed amongst the users. Thesame access graph is created, but it will be built by indi-vidual users and pairs of users in various steps. These stepsinclude:

• Vertex Creation: Each individual user will create theirown piece of the graph, that is they will create a masternode, their content nodes, and the edges between thesenodes. Figure 5 shows the subgraph for user A. Sincethe user has now created his own keys, only the userhimself will have these keys at this point. The publicinformation created for this subgraph is posted.

15

Figure 4: Example Access Graph

• Edge Creation: This is done in two steps. First theedge source sends information to the destination. Ba-sically, the source sends its key information to the des-tination vertex; that is it sends enough informationso that the user corresponding to the destination ver-tex can compute the edge label. The destination ver-tex then creates edge information in the access graphwhich is then posted.

Figure 5: Subgraph for user

Notice that this scheme still requires a server, howeverthis server is different from the server in the previous sec-tion. Mainly it doesn’t know the users’ content keys. Thisserver simply stores pub and allows users to access this in-formation. However, to prevent users from adding edges toother user’s sub-graphs, this server authenticates users be-fore allowing them to modify pub. Specifically, it will allowusers to modify only their own subgraphs. In the protocolsbelow we achieve this authentication with a password, but itis trivial to modify the protocol to use other authenticationmechanisms.

5.1 Server SetupWe assume that the following services are available:

1. CREATE(name, pwd): This creates a user accountwith a specific username. The password, pwd, is usedto authenticate the user at a later point in time. Ifa user’s account cannot be created this method willreturn false otherwise it will return true.

2. MERGEPUB(username, pwd, userPub) This takes thepublic information for a user’s subgraph and merges itinto the server’s graph. This assumes that the new sub-graph is isolated (i.e., has no common vertices) from

the server’s graph. This is acceptable because this isonly done during user setup.

3. ADDEDGE(username, pwd, src, dest, edgeLabel) Thisadds an edge with a specific label between two verticesin pub. The server enforces access control over this op-eration; that is a user can only add edges to verticesthat this user created.

4. GETPUB(): This returns the public information. Notethat this operation is anonymous and does not requirethe user to authenticate to the server. One downsideto this is that it requires downloading the entire socialnetwork. A possibile mitigation to this problem is thatthe user can request a particular subgraph.

5. SEND(send, rec, mess): This sends a message fromsend to rec. We assume that this is done via a privateand authenticated channel. We assume that the serveris unaware of who is sending/receiving the messages aswell as to the content of the messages. This could beachieved by using a communication channel outside ofthe system, but in order to authenticate the commu-nication channel a PKI appears to be necessary.

5.2 Scheme

5.2.1 User setupThe user creates an account on the server, and then he

creates an access subgraph for himself. This corresponds tothe master vertex and the content vertices. The user thenapplies Setup to his subgraph to establish a key allocationscheme for this graph. The user posts this access subgraphon the server. The details of the algorithm for creating theaccess graph is described in Algorithm 5.

5.2.2 Offer EdgeWhen A wants to offer an edge to user B, A simply sends

the tag and key of content node V 1A to B. That is, B will

have to create edges to A’s vertices, and so B needs thenecessary information to compute the public edge labels.

We assume that the algorithm dDer is the same as Der (from[1]) except that it will return both the tag and the key fora specific vertex–rather than just the key. This is a trivialmodification of Der, since Der already computes the tag.

16

Algorithm 5 SERSETUP (1n, A, pwd, L)

1: bool := CREATE(A, pwd)2: if bool = false then3: FAIL4: end if5: {Create access subgraph G′}6: V ′ := {}7: E′ := {}8: V ′ := V ′ ∪ {VA}9: for i = 0 to L do

10: V ′ := V ′ ∪ {V iA}

11: E′ := E′ ∪ {(VA, V iA)}

12: if i 6= 0 then13: E′ := E′ ∪ {(V i−1

A , V iA)}

14: end if15: end for16: {Compute graph keys and post}17: (pubA, secA)← Setup(1n, G′)18: MERGEPUB(username, pwd, pubA)19: sA := secVA

Algorithm 6 OFFER(A, B, 1n, sA)

1: pub := READPUB()

2: t1A||k1A := dDer(1n, pub, VA, V 1

A, sA)3: SEND(A, B, t1A||k1

A)

5.2.3 Accept EdgeWhen B accepts the edge from A, he adds edges from his

subgraph to A’s subgraph. The details are in Algorithm 7.

Algorithm 7 ACCEPT (A, B, 1n, t1A||k1A, sB , pwd)

1: pub := READPUB()

2: t0B ||k0B ← dDer(1n, pub, VB , V 0

B , secB)3: y1

A,B := CREATE(`V 1A

, k0B , t0B , k1

A, t1A)

4: ADDEDGE(B, pwd, V 0B , V 1

A, y1A,B)

5: for i = 2 to L do6: ti

A||kiA ← FOLLOW (ki−1

A , ti−1A , y

V i−1A

,V iA

, `V iA

)

7: ti−1B ||ki−1

B ← dDer(1n, pub, VB , V i−1B , secB)

8: yiA,B := CREATE(`

V i−1B

, ki−1B , ti−1

B , kiA, ti

A)

9: ADDEDGE(B, pwd, V i−1B , V i

A, yiA,B)

10: end for

5.3 Proof of Security (sketch) and AnalysisSecurity follows because the public information in this

scheme is identically distributed to that created in the cen-tralized scheme from the previous section. It is straight-forward to see that the graph created by the distributedalgorithms has the same vertices and edges as the graphcreated in Algorithm 3. Furthermore, if the (Setup, Der)are the algorithms from [1] then edge and vertex informa-tion is generated in the same manner. Thus if the previousscheme is secure, then this new scheme is also secure.

Since the graph is the same as before, the analysis doesnot change from the previous section. However, it is worthnoting that the user must now perform O(L) work to douser setup and to accept a relationship.

6. EXTENSIONS

6.1 Hiding the Social NetworkThe previous scheme does not protect the social network.

That is, pub will contain the entire access graph from whichthe social network can be recovered. To mitigate this we usethe technique from [7]. The idea is as follows: we hide thedestination of the edges as well as the public edge informa-tion with encryption. That is if there is an edge from V i

A andV j

B then the system encrypts the destination (i.e., V jB) and

the edge information yV i

A,V

jB

with the key for V jB . By doing

this the only users who can obtain the edge information arethose that could already access V j

B . Thus a specific user willonly be able to see his or her neighborhood in the graph.A downside to this strategy is that key derivation will beslower as it will require multiple decryptions to perform thederivation. Another downside is that the every time a useraccesses the social network, he will have to download theentire social network. And so the scheme is not scalable; weleave the mitigation of this problem as future work.

6.2 Dynamic ChangesThe key allocation scheme for access hierarchies from [1]

supported dynamic changes to the graph. Assuming thatat most one user was assigned to every node (which is thecase 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 withoutrekeying any individual user, and required only changes tothe public information. At first glance this would appearto solve the problem of dynamic changes for social networkaccess control. In fact, for the strawman protocol (section4) this is the case, because there is a server to manage thepublic information. Furthermore, adding vertices and edgesis straightforward in all of the schemes. However the decen-tralized scheme presents several difficulties, including:

1. When a content vertex is rekeyed, all incoming edgesneed to be updated. However, the owner of the con-tent vertex does not necessarily know the key of of thesource vertex. Referring back to Figure 4, if A wantsto change the key for V 1

A, then it would need to updatethe edge from V 0

B , but A does not have the necessaryinformation to update this value.

2. When removing a vertex then all vertices that arereachable from this vertex need to change keys. Re-ferring back to Figure 4, suppose user B wants to beremoved. Then A should update her keys, in order toprevent C and D from accessing her content (as theyno longer have a path to A in the social network).

3. When removing an edge (e.g., if A no longer trusts B),then A will need to rekey her content vertices. How-ever, this will require changing all incoming edges tothese vertices. Furthermore, all users that trust A (ei-ther directly or indirectly) need to update their keys.For example, suppose B wants to remove his trust re-lationship with C in Figure 4. B would have to changethe keys associated with V 1

B and V 2B . The edges coming

from D’s nodes would have to be update (and B doesnot have the information to do this). Also A shouldrekey her vertices in order to prevent C from access-

17

ing her content, and again B does not have enoughinformation to make all of these changes.

Clearly, the above system is unusable for dynamic keymanagement in the social network. However, by makingtwo small changes to the system, this situation is signifi-cantly improved. These changes are: i) to add a level ofindirection to make key changes possible, and ii) to rekeyall users periodically. In the remainder of this section, thesetwo ideas are explored in more detail.

In this new system, when a user, A, wants to offer a rela-tionship to another user, B, then the following steps occur:

1. A creates L new vertices V 1AB , . . . , V L

AB , creates edgesfrom VA to V i

AB for all i ∈ [1, L], creates edges betweenV i

AB and V i+1AB (for i ∈ [1, L − 1]), and creates edges

from V iAB and V i

A (for i ∈ [1, L]). A also creates tags,keys, and labels for these new vertices and assigns la-bels to the edges (as in the key allocation scheme). Aposts these new vertices to the public information.

2. A sends the tag key pair t1AB ||k1AB to B.

3. B creates edges between V i−1B and V i

AB for i ∈ [1, L]

See Figure 6 for an example of a graph between two usersafter the above process has been completed. With thischange if A wants to change the content key kd

A, then Acan assign a new key to V d

A (and later keys) and simply up-date all of the edges to this vertex; note that A can makethis change since it knows the keys for vertices V i

AM for alltrusted nodes M and i ∈ [1, L]. This does increase the size ofthe graph from O(L|V |) to O(δLV ) where δ is the maximumnumber of relationships for any vertex in the graph.

Figure 6: Graph for A and B

The second problem, i.e., of updating the keys of usersthat trust A when A removes an edge, is not as easily solved.A naive solution would be to update all of users that trust Awhenever A removes any relationships. However, this wouldrequire notifying all users that have a trust chain to A of sizeL or less. As this could be a large number of users (manyof which A may not know), this is clearly not a workablesolution. However, a better way to mitigate this problem isto have users rekey their keys periodically. In the extremecase this is done for every login. Now a user would be en-sured that when content is posted, it would be for the accessgraph at the time of the last login.

6.3 Relationship TypesIn all of the previous schemes we have considered only

a single relationship type. A more flexible approach for aweb-based social network would be to allow users to indicatevarious types of relationships (e.g., friend, family, etc). Hav-ing this extra information would allow more flexibility thanthe single-relationship type system. For example, a policycould be made that allows family to access some content,and friends to access other content. An even more flexiblemodel would allow users to specify a hierarchy of relation-ships, such as there could be relationships family, friend, andboth. People with the both relationship would be able to seeeverything that family and friends could access.

Supporting multiple relationships is straightforward. Eachuser will create L + 1 vertices for every relationship type.When establishing a relationship with another user, the usersimply sends the keys for the appropriate relationship to thatuser. To support a hierarchy of relationships, the contentvertices are connected to allow derivation. Figure 7 showsa subgraph for a user A, with three types of relationshipsfriend, family, and both. For example, if Bob was Alice’sfriend, then she would give him access to V 1

A and V 2A. How-

ever if Bob was friend and family, then she would give himaccess to V 1′′

A and V 2′′A . From these keys he could derive the

keys for V 1A, V 2

A, V 1′A , and V 2′

A .

Figure 7: Example access graph with different rela-tionship types

6.4 Relationship StrengthsSo far the scheme has considered all relationships to be the

same, which is not necessarily true. In this section we extendthe scheme to support a more flexible model. The modelthat we consider is an adaptation of the model consideredin [5, 6, 4, 9, 13]. Each relationship is assigned an integerfrom 0 to M that indicates the level of trust, where M is ahigh level of trust and 0 means that no trust exists. Trust istransferred in the multiplicative manner. That is, if A trustsB with level i and B trusts C at level j, then A trusts Cat level b ij

Mc. We take the approach from [13], and assume

the trust between two users is the maximum trust level thatcan be found on any path between the two users.

By making minor modifications to the previous schemesit is possible to support this new trust model. However,it is important to note that this new scheme does not hidethe relationship trust levels as previous synchronous schemessuch as [13] have. Instead of having a content vertex forevery node, a user will have M content nodes (one for eachtrust level); denote these by V M

A , . . . , V 1A. If user A wants to

18

establish a relationship with user B at level i, then A sendsthe tag and key for V i

A to B. B then adds an edge from V jB

to Vb ij

Mc

A for all j ∈ [1, M ]. As an example consider Figure8, where M = 4, and A trusts B at level 2.

Figure 8: Graph for A and B when M = 2 and rela-tionship strength is 2

While this modification supports a more flexible accesscontrol model, it does reveal the strength of each relationshipfor every edge on the path, which is undesirable in somecircumstances.

7. SUMMARY/FUTURE WORKIn this paper we have made a first step to the creation of a

key management mechanism that enforces access control fora social network. With this mechanism it is possible to cre-ate a social networking service that protects user’s contentfrom the server and other untrusted users. As future workwe plan to implement the system to analyze its effectiveness.Other issues to be considered in future work include: i) edgeremoval leaves much to be desired in the current scheme, ii)to access other user’s data one has to download the informa-tion for the entire social network (which is clearly not scal-able), and iii) nothing prevents malicious users from sharingother user’s keys with unauthorized users in the system.

AcknowledgementsThe authors would like to thank the anonymous reviewersfor their comments and useful suggestions.

8. REFERENCES[1] M. Atallah, M. Blanton, N. Fazio, and K. Frikken.

Dynamic and efficient key management for accesshierarchies. 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 keyassignment schemes. In ACM Conference on Computerand Communications Security (CCS’06), 2006.

[3] L. Backstrom, C. Dwork, and J. Kleinberg. Whereforeart thou r3579x?: anonymized social networks, hiddenpatterns, and structural steganography. InInternational Conference on World Wide Web(WWW’08), pages 181–190, 2007.

[4] B. Carminati and E.: Ferrari. Privacy-awarecollaborative access control in web-based socialnetworks. In V, editor, Atluri, pages 81–96. Springer,V., ed.: DBSec. Volume 5094 of Lecture Notes inCom-puter Science., : DBSec. Volume 5094 of LectureNotes in Com-puter Science., Springer, 2008.

[5] B. Carminati, E. Ferrari, and A. Perego. Rule-basedaccess control for social networks. In Proc. of theOTM Workshops number, pages 1734–1744, 2006.

[6] B. Carminati, E. Ferrari, and A. Perego. Privaterelationships 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. Preservingconfidentiality of security policies in data outsourcing.In WPES ’08: Proceedings of the 7th ACM workshopon Privacy in the electronic society, pages 75–84, NewYork, NY, USA, 2008. ACM.

[8] L. Ding, L. Zhou, T. Finin, and A. Joshi. How thesemantic web is being used: An analysis of foafdocuments. In Proc. of the, 113(3), 2005.

[9] J. Domingo-Ferrer. A public-key protocol for socialnetworks with private relationships. in Lecture Notesin Computer Science, pages 373–379, August 2007.

[10] M. Freedman and A. Nicolosi. Efficient privatetechniques for verifying social proximity. InInternational Workshop on Peer-to-Peer Systems(IPTPS), 2007.

[11] K. Frikken and P. Golle. Private social networkanalysis: how to assemble pieces of a graph privately.In ACM Workshop On Privacy In The ElectronicSociety (WPES’06), pages 89–98, 2006.

[12] M. Hay, G. Miklau, D. Jensen, D. Towsley, andP. Weis. Resisting structural re-identification inanonymized social networks. Proceedings of the VLDBEndowment, 1(1):102–114, 2008.

[13] Viejo Alexandre J. Domingo-Ferrer, Sebe Francesc,and Gonzalez-Nicolas Ursula. Privacy homomorphismsfor social networks with private relationships. Elsevier,Computer Networks, 2008.

[14] F. Kerschbaum and A. Schaad. Privacy-preservingsocial network analysis for criminal investigations. InACM Workshop on Privacy in the Electronic Society,pages 9–14, 2008.

[15] L. Liu, J. Wang, J. Liu, and J. Zhang. Privacypreserving in social networks against sensitive edgedisclosure. Technical Report CMIDA-HiPSCCS006-08, Department of Computer Science, Universityof Kentucky, 2008.

[16] M. Lucas and N. Borisov. Flybynight: mitigating theprivacy risks of social networking. In ACM WorkshopOn Privacy In The Electronic Society (WPES’08),pages 1–8, 2008.

[17] E. Zheleva and L.Getoor. Preserving the privacy ofsensitive relationships in graph data. In First ACMSIGKDD Workshop on Privacy, Security, and Trustin KDD (PinKDD 2007), 2007.

[18] B. Zhou and J. Pei. Preserving privacy in socialnetworks against neighborhood attacks. InInternational Conference on Data Engineering(ICDE’08), pages 506–515, 2008.

19