978-1-4577-0351-5/11/$26.00 c©2011 IEEE

Key Management in Distributed Online Social Networks

Felix Günther Mark Manulis Thorsten StrufeTU Darmstadt CASED Uni Mannheim

Email: {guenther,strufe}@cs.tu-darmstadt.de, mark@manulis.eu

Abstract—Decentralized approaches for online social net-works (OSNs) have been of recent research interest, enablingusers to create profiles and share data like in other OSNsas, e.g., Facebook. Since the decentralized architecture doesnot contain a central authority that is able perform accesscontrol, encryption is needed to ensure the confidentialityof published data. This paper outlines strict requirementsand weak constraints for the encryption of data attributesin decentralized OSNs. Subsequently, an overview of possiblecryptographic solutions is given and their suitability accordingto these requirements is analyzed. As a result, the differencesand trade-offs between and within the given approaches areexpounded. The outcome of this paper can be used as afoundation for further investigations on this topic.

I. INTRODUCTION

Recently, many different decentralized approaches foronline social networks (OSNs) have been proposed [1], [3]in an attempt to avoid the centralized control and omnipotentaccess of commercial service providers.

Due to their decentralized nature, those approaches lack acentral authority enforcing access control on all user profileswhich is possible on centralized OSNs like Facebook orLinkedIn that are accessed through a single web interface.In contrast to these systems, the profile of a user in decen-tralized OSNs is usually stored on her system itself, all usersystems forming a peer-to-peer network. As the profile of auser may be replicated on the systems of her friends (i.e.,her contacts) for accessibility reasons, she may not be ableto enforce live access control on her profile either.

These constraints yield the need of encryption of userprofile data in decentralized OSNs to guarantee its con-fidentiality. In addition to that, users shall be enabled torestrict access to their profiles in a fine-grained manner onatomic attributes. Thus, the encryption scheme has to offera possibility to encrypt a multitude of single attributes eachfor a single user or a group of users.

Aside of these hard constraints there exist some weakerconstraints. As all operations have to be executable ondevices with restricted resources – as, e.g., users should beable to log in via their mobile phone – and with affectedusers being offline, storage space requirements and the req-uisite interaction between group members in the particularencryption scheme have to be taken into account.

In order to be able to evaluate the weaker constraints in aconcrete setting and extract the trade-off between them, wefocus the analysis of the proposed key management schemesto Safebook, a decentralized approach for an online socialnetwork proposed by Cutillo et al. [3]. This course of actionallows for an exact examination of the different schemes –

e.g., regarding the storage overhead they impose – withoutloosing the general applicability of the presented schemes.

After presenting architectural structures of Safebook thatare relevant for key management, this paper points outthe significant requirements demanded from the encryptionscheme and outlines weaker constraints leading to varyingfocuses among the investigated approaches. Based on theserequirements and constraints, an overview of different en-cryption schemes is given, reflecting different approaches todistribute and manage group keys. Thereupon, these schemesare analyzed regarding the weak constraints by developingabstract formulas for several interesting properties of thepresented approaches which are evaluated later on usingreasonable system parameters.

As a result, it is shown that the examined schemesdiffer heavily in terms of the given constraints, whereasan approach based on broadcast encryption performs bestregarding the outlined properties.

The rest of this paper is organized as follows. First, bene-ficial architectural structures of Safebook are pointed out insection II. In section III, requirements for suitable encryptionschemes are discussed and weaker constraints identified.A survey of applicable approaches is given thereafter insection IV, followed by an evaluation of these in section V.In section VI, approaches related to the described ones arediscussed and their drawbacks regarding the given require-ments are pointed out. The paper concludes in section VIIwith a short summary and gives an outlook on future work.

II. BENEFICIAL STRUCTURE OF SAFEBOOK

The architecture of Safebook includes a Trusted Identifi-cation Service (TIS) that provides each user joining the net-work with an unambiguous node identifier and pseudonym.Along with this, each user generates two public/private keypairs for the peer-to-peer and OSN levels for which shereceives certificates from the TIS.

Furthermore, the peer-to-peer substrate of Safebook al-lows to resolve the public key belonging to a user or to auser’s pseudonym. That way, encryption schemes can utilizethe global availability of keying material (i.e., distributedpublic/private key pairs) for their purpose. The existenceof keying material eases the communication and key dis-tribution needed for key management and renders morecomplex approaches (as they are needed in, e.g., ad-hocnetworks, where no preliminary keying material is available)unnecessary.

Beyond that, the user groups who shall be allowed toaccess certain attributes are – in contrast to members in,e.g., ad-hoc networks or interest groups in Facebook – bothrelatively stable and more likely increasing than decreasing.Thus, member exclusions will occur only rarely, which canbe advantageous for some encryption schemes.

III. REQUIREMENTS AND CONSTRAINTS

In this section, the mandatory requirements for encryp-tion schemes solving the given problem are defined first,followed by weaker constraints, whose degree of fulfillmentcan be quantified for each approach.

A. Mandatory Requirements

The following requirements have to be met by an ap-proach to be suitable at all:

1) Confidentiality: If an attribute a is encrypted for acertain group of users Ua = {Ua,1, Ua,2, . . . , Ua,n}, it hasto be computationally infeasible for any user U 6∈ Ua todecrypt the attribute a.

2) Access Control: Only the owner of a profile canchange the access rules to its attributes, defining who isallowed to access a certain attribute and who is not. Inparticular, the mirroring peers (in case of Safebook, a peermirrors the profiles of all her contacts for accessibilityreasons) must not be able to manipulate the access rules,neither of attributes they are allowed to decrypt nor of thesethat they are not allowed to decrypt.

3) Privacy: It has to be infeasible for any user to discoverthe identity of an authorized user (except for herself) of anattribute as well as to decide whether any other user is or isnot authorized to access an attribute.

4) Key Independence: If the encryption schemes usegroup keys K = {K0,K1, . . . ,Kn} (i.e., a secret share ispublished to and known by all users having access to a givenattribute), it has to be guaranteed that a passive adversaryknowing an arbitrary subset K ⊂ K of group keys is not ableto discover any other group key K ∈ (K\K) (cf. [11]). Keyindependence implies forward and backward secrecy; i.e., anattacker knowing a contiguous subset of group keys cannotdiscover subsequent or preceding keys.

B. Weaker Constraints

Besides the hard requirements given above, there areweaker constraints posed by the architecture of Safebook,which allow for an evaluation of different approaches ap-plying to the requirements. These are:

1) Storage Space: The keys used by encryption schemesin the given setting are duplicated in two ways: On the onehand, the keys the owner has to store in her profile (e.g.,encrypted shared keys for authorized users) are replicatedon the systems of all her contacts. On the other hand, thekeys needed for accessing an attribute have to be stored bythe client user (regarding the access to a profile) for every

attribute she has access to and that for any contact’s profilein her contact list.

It is obvious that especially the client-side storage needscan become very large. Therefore, storing keys on clientsshould be avoided if possible, or at least used on a limitedscale.

Keeping the replication of user profiles in mind, theamount of storage overhead imposed in the profile shouldbe kept as low as possible. It should be noted that not alldata stored at the owner of a profile necessarily has to bestored in the profile itself, e.g., the private key of the ownerclearly has to be stored on her system but – needless to say– not in her profile, replicated on other systems. Encryptionschemes may introduce similar keys or other data, whichhave to be stored on the owner’s system only, not directlyin the profile.

2) Interaction with group users: Since Safebook is basedon a peer-to-peer system, its users’ systems apparently arenot permanently online, which makes direct communicationdifficult. Therefore, live interaction needed between theowner of a profile and users in an access group for a certainattribute should be reduced to a minimum. Otherwise, e.g.,establishment of keys would slow down dramatically, sincedelayed channels would have to be used.

3) Expenditure of resources needed for computations: AsSafebook clients should be able to run on mobile deviceswith limited computing power, access control managementhas to be feasible also on these clients. Thus, the computa-tion of keys is demanded not to be too expensive regardingthe resources needed.

IV. ENCRYPTION SCHEMES

In this section, different approaches suiting the require-ments are described. First, a simple and intuitive schemein two variants is described. Thereafter, a more complexapproach is outlined based on the One-way Function Tree(OFT) scheme [2], [12], [14], which itself bases on theLogical Key Hierarchy approach (LKH) [18], [19]. Thethird scheme – presented in [8] – uses bilinear pairings forbroadcast encryption (BE) to achieve adaptive security (thescheme is subsequently referred to as “Gentry-Waters BE”).

A. Simple Shared Key

The intuitive approach to encrypt attributes for a group ofusers is the following: The profile owner creates a new at-tribute a and defines the group Ua = {Ua,1, Ua,2, . . . , Ua,n}of users authorized to access it. She then chooses a secretkey Ka for this attribute at random, encrypts the attribute aas EncKa(a) and adds the encrypted attribute to her profile.Finally, the key Ka has to be distributed to all users inUa. Regarding the architecture of Safebook, there are twopossibilities to distribute the key Ka, forming the two shapesof this approach:

1) Client-side Key Storage: The first variant is to sendevery user Ua,i the secret key Ka for the new attributeusing the respective public key pki for encryption; i.e., sendEncpki(Ka) to each Ua,i ∈ Ua.

In this case, the owner of the profile only has to storethe current attribute key Ka (which does not have to – andshould not – be stored in the profile), but this key needs tobe stored also on the system of every user in Ua.

When creating an attribute, Ka has to be sent to eachuser Ua,i, resulting in n messages. If a new user Ua,n+1

is added to the group of authorized users Ua, the attributekey Ka needs to be changed and the new key K ′a has tobe transmitted to all users Ua,i ∈ U ′a = Ua ∪ {Ua,n+1}as Encpki(K

′a), thus resulting in n + 1 messages and

encryptions. The owner of the profile then encrypts theattribute with the new key as EncK′

a(a) replacing the old

encryption in the profile. On exclusion of a user Ua,j outof Ua, the owner of the profile also has to choose a newsecret key K ′a and replace the encrypted attribute in theprofile. The key has to be distributed to all users in the newgroup of authorized users U ′a = Ua \ {Ua,j}, resulting inn − 1 messages and encryptions. It should be noted thatthis approach also supports the addition or exclusion ofa subgroup of multiple users Ua = {Ua,j1 , . . . , Ua,jm} atonce: Addition and exclusion of this group can be carriedout like the addition or exclusion of a single user, publishingthe new key K ′a to U ′a = Ua ∪ Ua in case of user additionrespectively U ′a = Ua\Ua in case of user exclusion, resultingin n+m respectively n−m messages.

2) Profile-side Key Storage: The second variant of thisapproach is to store the secret key in the profile rather thandistributing it to all authorized users. For this purpose, theowner of the profile computes Encpki(Ka) for each Ua,i;i.e., she encrypts the secret key Ka for each authorized userUa,i using the respective public key pki. These encodingsof Ka are then stored in the owners profile, accessible forall Safebook users, thus also the authorized ones.

This way, the authorized users do not need to storeanything: To access a an authorized user Ua,i decrypts theencryption of Ka destined for him using his private key skiand receives Ka enabling him to decrypt the attribute. Thiszero-storage at client-side is traded in for greater storageneeds at profile-side, since the owner of the profile in thisvariant has to store not only Ka (outside the profile), butalso n encryptions of Ka in the profile that are replicatedon the systems of her contacts.

Since no information has to be transferred to the autho-rized users in this variant, there is no group interaction atall; i.e., no messages need to be sent. Member addition andexclusion (also of multiple users) are done analogously tothe first variant, storing the new encrypted keys in the profilerather than sending them to the users.

B. OFT-based Approach

The approach based on the One-way Function Tree (OFT)uses a binary tree, containing the shared secret key Ka forthe attribute a at its root and associating the leafs with then authorized users Ua,1, . . . , Ua,n (see Figure 1).

The key tree is of height log n and is initialized as follows(cf. [2]): The profile owner associates every node v with arandomly chosen key Ka,v and sends each user all keysassociated to nodes on the path from the user to the rootencrypted with the respective user’s public key. In the treeof Figure 1 for example, Ua,1 would receive Ka,00, Ka,0

and Ka. Thus, each user receives at most log n + 1 keys,transmitted with n messages. As all users know Ka, theencrypted attribute EncKa

(a) can be stored in the profilewith all authorized users able to decrypt it.

Ka

Ka,0 Ka,1

Ka,00 Ka,01 Ka,10 Ka,11

Ua,1 Ua,2 Ua,3 Ua,4

Figure 1. Exemplary OFT key tree

On user removal, all keys associated to nodes on the pathfrom the removed user U to the root have to be changedto assure forward secrecy. As an enhancement of the LKHapproach, OFT does not choose all new keys on the path tothe root at random, but only assigns the parent node p(U)of the removed user U a randomly chosen value r. Then, apseudo-random generator [9] G which doubles the size ofits input (L(x) and R(x) denoting the left and right halvesof the output of G(x)) is used to determine the new keys onthe path to the root. Every other node v on the path to theroot is assigned a value rv computed as rp(v) = R(rv) =

R|U |−|v|(r) (where p(v) denotes the parent and |v| the heightof v). Based on these values the new key of a node v isdefined as K ′a,v = L(rv) = L(R|U |−|v|−1(r)). Finally, eachvalue rp(v) is encrypted with the key Ka,s(v) (s(v) denotingthe sibling of v) and sent to the users in the subtree of s(v),thus enabling all users to compute the new attribute key K ′a.For example, if user Ua,2 is removed in the tree of figure 2,EncKa,011(r) has to be sent to Ua,3, EncKa,00(R(r)) toUa,1 and EncKa,1(R(R(r))) to Ua,4 and Ua,5, thus dlog neencryptions are needed and n−1 messages sent. Now, eachuser is able to compute the new keys K ′a,01 = L(r), K ′a,0 =L(R(r)) and K ′a = L(R(R(r))).

User addition is accomplished similar to user removal. Toguarantee backward secrecy, all keys on the path from thenew user to the root have to be changed the same way as ifthe new user would have been removed. Thus, the additionof Ua,2 to the tree of figure 2 results in the same encryptions

and n + 1 messages sent (of course, r is chosen newly ateach addition or removal). If user Ua,3 is moved down inthe tree in order to add Ua,2, she keeps her old key Ka,01

as the new key Ka,011.

K╅a K╅a,0 Ka,1

Ka,00 K╅a,01 Ka,10 Ka,11

Ua,1 Ua,2 Ua,3 Ua,4

Ka,010 Ka,011

Ua,5

EncKa,1(R(R(r)))

EncKa,00(R(r))

EncKa,011(r)

Figure 2. OFT user removal or addition

The owner of the profile has to store the whole key tree(not in the profile itself), whereas the authorized users haveto retain at most dlog ne+ 1 keys each.

C. Gentry-Waters broadcast encryption (BE) approach

The Gentry-Waters BE scheme presented in [8], which isa very novel approach in the field of broadcast encryption[4], [5], [7], [13] (especially regarding adaptive security),can be used for the encryption of multiple attributes at thesame time and with low overhead in our setting. Due toits complexity, we will only sketch the approach at thispoint (cf. [8], section 3.1 for more details). The constructioncontains the four algorithms Setup, KeyGen, Enc and Decwhich we will draft subsequently:

Setup generates the basis groups G,GT of prime order pand the bilinear map e. Moreover, it chooses α ∈ Zp andg, h1, . . . , hn ∈ G at random and computes a public and aprivate key PK and SK. Using the private key, KeyGen iscalled for each of n users (where n constitutes the upperbound for the number of users which can be granted accessto an attribute), resulting in a secret key di for each user.These secret keys can be stored in the profile, encryptedwith the public key of the respective user. This concludesthe initialization.

Thereafter, a secret share for each group of authorizedusers can be computed by providing SK and the group ofauthorized users to Enc, which outputs a header Hdr andthe secret key K. Using this secret key, the owner of theprofile can now encrypt the attribute, the group shall haveaccess to and store it in the profile together with the headerHdr. Each authorized user is then able to decrypt the sharedkey K using Dec with her secret key di1, which she is able

1The Dec algorithm also has to be provided with the indices of theusers that are allowed to access a certain attribute. It is arguable how muchinformation about the users with the respective indices can be deduced. Weassume that meaningful linking becomes (statistically) impossible if theattribute is encrypted for a certain percentage of additional dummy indicesnot related to any user.

to decrypt with her private key ski.User addition and removal requires a new execution of

Enc, since the group of authorized users has changed. Aregeneration of the secret keys di is not needed.

The authorized users have to store nothing in this ap-proach. The owner of the profile has to retain the privatekey SK whereas the public key PK and the encryptedsecret keys di for each user as well as the header Hdr andsymmetric encryption EncK(a) for each attribute have tobe stored in the profile.

V. EVALUATION

We will now evaluate the encryption schemes describedin the previous section according to the requirements andweaker constraints presented in section III. First, the relevantmetrics (as storage space, numbers of encryptions needed,etc.) for analysis are defined. Then, abstract formulas aredetermined for all properties and encryption schemes. Ina third step, we apply concrete values for the parametersof the properties to explore the trade-offs imposed by theapproaches. Finally, the differences between the approachesare discussed.

A. Property definitions

We will study the following abstract properties on eachscheme:

1) Storage requirements at the profile owner outside theprofile: The amount of storage in bytes needed for a singleattribute on the system of the profile owner, which is notstored in the profile, is denoted by So.

2) Storage requirements in the profile and its replica-tions: The amount of storage in bytes needed for a singleattribute in the profile is denoted by Sp. This value includesthe storage needed on the systems of the profile owner’scontacts (remember that Safebook profiles are replicated attheir owner’s contacts for accessibility reasons). It does notinclude the storage needed for the symmetric encryption ofthe attribute itself.

3) Storage requirements at the authorized users: Theamount of storage in bytes needed for a single attribute onthe systems of all users authorized to access the attribute isdenoted by Su.

4) Number of encryptions on initialization: The numberof encryptions needed on initialization of the encryptionscheme is denoted by Ei, not including the encryption ofthe attribute itself.

5) Number of encryptions on user addition: The numberof encryptions needed when a user is added to the groupof authorized users is denoted by Ea, not including theencryption of the attribute itself.

6) Number of encryptions on user removal: The numberof encryptions needed if a user is excluded from the groupof authorized users is denoted by Er, not including theencryption of the attribute itself.

Table IABSTRACT PROPERTY FORMULAS

Scheme Storage Encryptions MessagesSo Sp Su Ei Ea Er Mi Ma Mr

S. Shared Key (1) bs 0 Nbs N N + 1 N − 1 N N + 1 N − 1S. Shared Key (2) bs (C + 1)Nba 0 N N + 1 N − 1 0 0 0OFT (2N − 1)bs 0 N(dlogNe+ 1)bs N dlogNe dlogNe N N + 1 N − 1

Gentry-Waters BEbgA

(|PK|+Cba

A + 2bg)

(C + 1) 0 1 1 1 0 0 0

7) Number of messages on initialization: The overallnumber of messages sent on initialization of the encryptionscheme is denoted by Mi.

8) Number of messages on user addition: The overallnumber of messages sent when a user is added to the groupof authorized users is denoted by Ma.

9) Number of messages on user removal: The overallnumber of messages sent if a user is excluded from thegroup of authorized users is denoted by Mr.

B. Abstract property formulas

Table I shows the abstract formulas for all properties andencryption schemes using the notation shown in table II. Wewill now develop these formulas:

1) Simple Shared Key: In both variants the owner has tostore the shared symmetric key Ka, thus So = bs. Sp = 0for the variant of client-side key storage (since the profile isnot needed for storage here) and Sp = (C+1) ·N ·ba for theprofile-side storage, as we have to store the (asymmetrically)encrypted Ka for N users (N is the number of usersauthorized to access attribute a, cf. table II) and this storageis replicated to the C contacts of the profile’s owner. Eachauthorized user has to store Ka in the client-side variant,thus Su = N · bs here. In the profile-side variant, the usershave to store nothing.

The number of needed encryptions is identical for bothvariants: On initialization, the shared key Ka has to beencrypted for each user, resulting in N encryptions. Whenadding or removing a user, Ka has to be encrypted for allmembers of the new group of authorized users, thus N + 1respectively N − 1 encryptions have to be performed.

Whilst the profile-side variant does not need any messagesto be sent, each encrypted key has to be transmitted to theappropriate user in the client-side variant.

2) OFT-based Approach: In the OFT-based scheme, theowner of the profile has store the key tree outside of therepository which contains 2N − 1 nodes, each associatedwith a symmetric key bs. The N users in the tree have toretain the keys on the path to the root (at most dlogNe+ 1symmetric keys of size bs), thus Su = N · (dlogNe+1) ·bs.Nothing has to be stored in the profile.

During the initialization, all keys on the path from auser’s leaf node to the root have to be sent encrypted to therespective user, resulting in N encryptions and N messagessent. Since user addition and removal are quite similar, theyboth need the same number of encryptions: For each subtreeunder a sibling of a node on the path from the removed or

Table IINOTATION USED IN THE PROPERTY FORMULAS

A the number of attributes in the profileN the number of users authorized to access an attributeC the number of contacts of the profile’s ownernBE the maximum number of users chosen for the Setup algorithmbs the size of a symmetric key in bytesba the size of an asymmetric key in bytesbg the size of a pairing-based group element (g ∈ G) in bytesbp the size of a pairing (e(g, g)) in bytes

added node to the root, a value rv is encrypted, resulting inat most dlogNe (and at least logN ) encryptions. All nodesin the tree have an ancestor changing its associated key, thusall N + 1 respectivley N − 1 nodes have to receive a keyupdating message.

3) Gentry-Waters BE scheme: The owner of the profilehas to store the private key SK of size bg in the Gentry-Waters BE scheme. As this key has to be stored only once, itssize has to be distributed over the number of attributes; i.e.,divided by the number of attributes A, resulting in So =

bgA .

The authorized users need not retain anything. The profilehas to provide the public key PK (consisting of nBE +1 elements of the group G and one pairing e(g, g)α) ofsize |PK| = (nBE + 1) · bg + bp and the encrypted secretkeys di for all of the profile user’s contacts (C · ba). Thisstorage – like the private key – is required only once andtherefore divided by A. Further, the header Hdr of size 2·bghas to be stored in the profile for each attribute. Finally, allthis is replicated on the C systems of the user’s contacts.Summarized, Sp =

(|PK|+C·ba

A + 2 · bg)· (C + 1).

Concerning the number of encryptions, we only considerneeded executions of the algorithm Enc, since Setup andKeyGen have to be processed only at the initialization ofthe scheme, not at each initialization of an attribute. Thus,we have a single encryption for initialization as well as foruser addition and removal.

No active messaging is needed in this approach.

C. Analysis of the proposed schemes

Figure 3 shows the plots of all properties over the numberof authorized users for an attribute.

For A, C, nBE , ba, bs, bg and bp, we have used the fol-lowing reasonable values: We have assumed a high averageof C = 250 contacts and a medium average of A = 300attributes in a profile. A maximum of 250 users for a groupof authorized users used in the Setup algorithm of the BEapproach seems reasonable. Furthermore, we have chosen a

1e-05

0.0001

0.001

0.01

0.1

1

10

100

1000

10000

50 100 150 200 250

So [K

Byte

s]

N

Simple Shared Key (1)Simple Shared Key (2)

OFTGentry-Waters BE

(a) Storage at the owner

10

100

1000

10000

100000

50 100 150 200 250

Sp [K

Byte

s]

N

S. Shared Key (1) (= 0)Simple Shared Key (2)

OFT (= 0)Gentry-Waters BE

(b) Storage in the profile

0.01

0.1

1

10

100

1000

50 100 150 200 250

Su [K

Byte

s]

N

Simple Shared Key (1)Simple Shared Key (2) (= 0)

OFTGentry-Waters BE (= 0)

(c) Storage at the users

0.1

1

10

100

1000

10000

50 100 150 200 250

Ei

N

Simple Shared Key (1)Simple Shared Key (2)

OFTGentry-Waters BE

(d) Encryptions during initialization

0.1

1

10

100

1000

10000

50 100 150 200 250

Ea

N

Simple Shared Key (1)Simple Shared Key (2)

OFTGentry-Waters BE

(e) Encryptions on user addition

0.1

1

10

100

1000

10000

50 100 150 200 250

Er

N

Simple Shared Key (1)Simple Shared Key (2)

OFTGentry-Waters BE

(f) Encryptions on user removal

1

10

100

1000

10000

50 100 150 200 250

Mi

N

Simple Shared Key (1)Simple Shared Key (2) (= 0)

OFTGentry-Waters BE (= 0)

(g) Messages during initialization

1

10

100

1000

10000

50 100 150 200 250

Mi

N

Simple Shared Key (1)Simple Shared Key (2) (= 0)

OFTGentry-Waters BE (= 0)

(h) Messages on user addition

1

10

100

1000

10000

50 100 150 200 250

Mi

N

Simple Shared Key (1)Simple Shared Key (2) (= 0)

OFTGentry-Waters BE (= 0)

(i) Messages on user removal

Figure 3. Plots of all properties over the number of authorized users N (logscale, properties of constant 0 are marked accordingly)

bit length of 1024 for asymmetric keys and pairings each(ba = 128, bp = 128) and a bit length of 192 for symmetrickeys and pairing-based group elements each (bs = 24,bg = 192).

D. Discussion

The two variants of the Simple Shared Key approachrequire a considerable amount of storage either in the profileor at client-side, which is rather problematic since storage inthe range of megabytes at profile-side respectively kilobytesat client-side is needed just for a single attribute. Keeping inmind that a user may have thousands of attributes and clientshave to store attribute keys for each attribute of all of theircontacts, the Simple Shared Key approach gets infeasiblerapidly.

Without doubt, the great advantage of the approach basedon the One-way Function Tree scheme is the ease of accessrevocation; i.e., user removal in our case. However, thisscheme requires a comparatively high amount of groupinteraction in form of messages to the authorized users anddepends on an amount of client-side key storage that iseven higher than the one needed by the Simple Shared Keyapproach. As stated before, the amount of client-side storageis multiplied by the number of attributes the user has accessto at the profiles of all her contacts. Thus, this approach

results in large overall storage needs.It is obvious that the Gentry-Waters BE approach based

is most suitable regarding the given constraints. Especiallythe important storage requirements are met as the Gentry-Waters BE scheme performs very well at each of the threerelated properties. Even if it is considered that pairingbased cryptography is more expensive than symmetric orpublic key cryptography, the Gentry-Waters BE approachrequires a tolerable amount of computing power. Moreover,the avoidance of group interaction in form of messages isan advantage of this scheme.

Given the presented evaluation, the Gentry-Waters BEapproach turns out to be the best fitting approach, worthy offurther investigation.

VI. RELATED APPROACHES

Steiner, Tsudik and Waidner proposed an approach thatextends Diffie-Hellman key exchange to groups in [15], [16].This scheme provides cheap member addition but is based onthe contribution of all group members to compute the groupkey, which poses two problems regarding the requirementsand constraints: It requires direct interaction between theauthorized users, which is infeasible regarding the peer-to-peer architecture. Moreover, the key exchange happensdirectly between the members of the authorized user group,

which violates the privacy requirements as the authorizedusers have to know each other.

A recent encryption scheme proposed by Eskeland andOleshchuk [6] uses fractional public keys to compute ashared group key. If Safebook users could be provided with aprivate key based on this scheme, neither they nor the ownerof the profile would have to store any further keys. However,the private keys are generated by a central trusted authoritylike Safebook’s Trusted Information Service, which wouldthen be able to decrypt any communication in Safebook.The authorized users also need to know the other authorizedusers, conflicting with the privacy requirements.

In [10], Jin and Lotspiech present a broadcast encryptionscheme with differently privileged users. They introduce “se-curity classes” to provide different data sets for differentlyprivileged user groups. Even though Safebook attribute usergroups could be arranged in a hierarchy like in role-basedsystems, the proposed approach – since it is designed for alinear hierarchy (i.e., group A > group B > group C, etc.) –imposes conflicts regarding overlapping attribute user groupsand key distribution.

Multiple approaches exist to establish group keys in(mobile) ad hoc networks (cf. [17]) that could generally beused to set up attribute group keys in Safebook. However,these approaches assume that no preliminary keying materialis available and therefore impose much useless overhead ina system like Safebook having public/private key pairs athand for bilateral communication.

VII. CONCLUSION AND FUTURE WORK

The architecture of decentralized online social networksleads to the need for different encryption schemes as theyare used in centralized networks. Private data has to beencrypted in user profiles to guarantee its confidentiality.

The peer-to-peer structure of those networks raises dif-ferent requirements and constraints that we have presentedin this paper, subdivided into strict and weaker ones. Af-terwards, different encryption schemes have been describedthat base upon distinct approaches.

To evaluate the given schemes, interesting propertiesstemming from the outlined requirements and constraintsare defined first. As a second step, abstract formulas forthe computation of these properties are developed for eachencryption scheme using varying system parameters. Allproperties are plotted afterwards with reasonable valuesapplied for the abstract parameters, constituting a basicoverview over the trade-offs imposed between and withindifferent approaches. For the sake of concrete results andwithout loss of general applicability, the evaluation of theproposed schemes has been performed in the setting of aconcrete distributed online social network, namely Safebook.

Though there is evidence that the broadcast encryptionbased approach performs best in the present setting, furtherinvestigations and simulations – especially simulations basedupon real data sets – are needed to provide more insightinto the characteristics of the presented approaches. These

as well as an elaborate security analysis of the proposedschemes from the cryptographic point of view remain forfuture work.

REFERENCES

[1] S. Buchegger, D. Schiöberg, L.-H. Vu, and A. Datta. Peer-SoN: P2P social networking: early experiences and insights.In EuroSys/SNS, 2009.

[2] R. Canetti, J. A. Garay, G. Itkis, D. Micciancio, M. Naor, andB. Pinkas. Multicast security: A taxonomy and some efficientconstructions. In INFOCOM, 1999.

[3] L. A. Cutillo, R. Molva, and T. Strufe. Safebook: A privacy-preserving online social network leveraging on real-life trust."IEEE Communications Magazine", 2009.

[4] Y. Dodis and N. Fazio. Public key broadcast encryption forstateless receivers. In Digital Rights Management Workshop,2002.

[5] Y. Dodis and N. Fazio. Public key trace and revoke schemesecure against adaptive chosen ciphertext attack. In PublicKey Cryptography, 2003.

[6] S. Eskeland and V. A. Oleshchuk. Secure group communica-tion using fractional public keys. In ARES, 2010.

[7] A. Fiat and M. Naor. Broadcast encryption. In CRYPTO,1993.

[8] C. Gentry and B. Waters. Adaptive security in broadcastencryption systems (with short ciphertexts). In EUROCRYPT,2009.

[9] O. Goldreich, S. Goldwasser, and S. Micali. How to constructrandom functions. J. ACM, 1986.

[10] H. Jin and J. Lotspiech. Broadcast encryption for differentlyprivileged. In SEC, 2009.

[11] Y. Kim, A. Perrig, and G. Tsudik. Simple and fault-tolerantkey agreement for dynamic collaborative groups. In ACMCCS, 2000.

[12] D. A. McGrew and A. T. Sherman. Key establishment inlarge dynamic groups using one-way function trees. Technicalreport, TIS Labs at Network Associates, Inc., 1998.

[13] D. Naor, M. Naor, and J. Lotspiech. Revocation and tracingschemes for stateless receivers. In CRYPTO, 2001.

[14] A. T. Sherman and D. A. McGrew. Key establishment in largedynamic groups using one-way function trees. IEEE Trans.Software Eng., 2003.

[15] M. Steiner, G. Tsudik, and M. Waidner. Diffie-hellman keydistribution extended to group communication. In ACM CCS,1996.

[16] M. Steiner, G. Tsudik, and M. Waidner. Cliques: A newapproach to group key agreement. In ICDCS, 1998.

[17] J. van der Merwe, D. S. Dawoud, and S. McDonald. A surveyon peer-to-peer key management for mobile ad hoc networks.ACM Comput. Surv., 2007.

[18] D. Wallner, E. Harder, and R. Agee. Key management formulticast: Issues and architectures. RFC 2627 (Informa-tional), 1999.

[19] C. K. Wong, M. G. Gouda, and S. S. Lam. Secure groupcommunications using key graphs. In SIGCOMM, 1998.