Secure and Policy-Private Resource Sharing in an Online Social Network
Providing functionalities that allow online social network users to manage in a secure and private way the publication of their information and/or resources is a relevant and far from trivial topic that has been under scrutiny from various research communities. In this work, we provide a framework that allows users to define highly expressive access policies to their resources in a way that the enforcement does not require the intervention of a (trusted or not) third party. This is made possible by the deployment of a newly defined cryptographic primitives that provides - among other things - efficient access revocation and access policy privacy. Finally, we provide an implementation of our framework as a Facebook application, proving the feasibility of our approach.
Online social networks (OSNs from now on) are nowadays used by hundreds of millions of users as the primary way of interacting and sharing of information and digital resources, as examples such as Facebook, Flickr, LinkedIn and many others OSNs testify. As the widespread adoption of OSNs increases and diversifies into various contexts (such as corporate OSNs), the need for mechanisms protecting and regulating the publishing of users’ sensitive resources is becoming paramount. The totality of OSNs allows users to specify – usually in a rather limited way – policies protecting their privacy and the confidentiality of their sensitive data/resources. In this way, access to such data is restricted to the users that satisfy such policies. Usually, the enforcement of users’ specified policies is delegated to the central authority that manages the entire OSN, and this state of affairs assumes – of course – a large degree of trust in such central authority. This may be not acceptable when the shared resources are highly sensitive (as, for example, in the case of healthcare-related data). A (quite radical) solution would delegate the entire management (storage and access control) of resources to their legitimate owner. This is clearly not feasible in a real world setting.
In this work, we propose a framework for publishing resources and for establishing social links over an OSN that gives the owner of the resource a fine-grained control on who can access the resources without having to trust the manager of the OSN; in our framework, the task of the OSN manager is reduced to that of providing reliable storage of the resources. Specifically, in our framework user can establish a social relationship with other users and for each such relationship can specify the type of resources that can be accessed. In addition, for each published resource the owner can specify an access policy specifying the type of relationship needed for a user to access it. Enforcement of access policies is guaranteed by means of novel cryptographic primitive, Distance-Based Revokable Attribute Encryption (DBRA in short, see Section 3), for which we give an efficient implementation based on the Hidden Vector Encryption of  and the Hierarchical Identity-Based Encryption of . Roughly speaking, in the implementation of the framework based on DBRA, the establishment of a link involves the transfer of a set of restricted decryption keys that depend on the type of resources that can be accessed. On the other hand, publishing a resource involves publishing an appropriately encrypted version of . We stress that restricted decryption keys are transferred only when a new link is established (or removed).
Access policies and key propagation In our framework, a user can express access policies that are closely tied to the OSN graph that is modeled as a directed graph in which nodes represent the users of the OSN and edges represent relationships among users. For example, an access control policy may state that a user directly connected to the resource owner is able to access the resource (given that she/he possibly satisfies other additional conditions). In this case, our framework guarantees that is encrypted in such a way that keys held by all directly connected users are sufficient for decryption. Notice that this holds even for users that have not made any explicit request for accessing and for keys that were transferred even before was published. Our framework also allows to express policies in terms of the distance in the OSN. For example, an access policy might specify a maximum distance at which a resource can be accessed. For such policies our framework provides a way for users to propagate decryption keys to their neighbors until the limit distance from the owner, as specified by the access policy, has been reached.
Key management In our framework a user needs to generate only one key (the master secret key msk) during enrollment. The master secret key is then used to derive the appropriate keys that are transferred whenever a new link is created. Publishing a resource does not involve generating new keys and thus the number of keys that a user need to manage depends only on the number of incoming links in the OSN and not on the number of resources he or his neighbors have published. Similarly, the size of the master secret key of a user does not depend on the number of resources published or on the number of outgoing links. New resources and links can be added without affecting already published resources and already established links.
Non-Interactive access to resources. We also stress that access to a resource by a user that has the appropriate keys can be achieved without interacting with the resource owner. Rather the users downloads the encrypted version of the resource from the OSN and uses keys obtained during the establishment of the link with the owner of the resource to decrypt it.
Privacy of access policies In several settings, the access policy associated with a resource is itself sensitive information. In our framework the access policy for a resource is determined by the owner upon publishing the resource and affects the way the resource is encrypted. DBRA not only guarantees that the resource cannot be accessed without an appropriate key but also that the associated policy is kept confidential. All that a user can do is to try to decrypt the resource using the keys that he has received during the establishment of the social link with the owner of the resources. If decryption fails then the user does not have any information on why the decryption has failed (e.g., which credential was missing).
Fast revocation An OSN is for its own nature extremely dynamic and thus it is expected that relationship links might be removed. One way to deal with such a case would be to have the user re-enroll, re-encrypt all resources and generate new keys for all of his neighbors. We stress that in case a link is revoked it is necessary to modify each encrypted resource, for otherwise nothing would prevent the removed user to use the old keys to access the unmodified resource. Our revocation procedure does so without having to completely recompute the encryption. In turn, if encryptions of resources are modified then old keys do not work anymore and need to be updated. Again, our revocation procedure does so without having to generate keys from scratch. Obviously, revocation is not retroactive and thus a user retains all resources that he has decrypted before the link was revoked.
Flexible OSN In the case a user missing a relationship link with the resource owner wishes to access the corresponding resource, it may ask for the creation of a link. After the link has been created, the decryption key is passed to it, provided – of course – that it satisfies the other conditions expressed in the access policy. Since the OSN may be very dynamic, with creation and deletion of friendship links, our access control mechanisms offer the possibility to update an access policy, by allowing a resource owner to revoke the access to a set of previously entitled users.
We do not assume that all links and all resources published by a user belong to the same social (sub-)network but rather we allow each user to specify for each resource and for each relationship a set of attributes (that identifies the social sub-network to which they belong). Specifically, resources are labeled with pairs where is a vector of some pre-specified length encoding (conditions over) resources’ attributes and is an integer encoding distance. Links instead are labeled with pairs where is also a vector of length and is an integer. If user Alice publishes a resource specifying , then user Bob sharing a link of type with Alice can access the resource if and only if . The predicate is true iff and only if vectors and agree in all positions in which is not and .
We now introduce our motivating scenario, describing how to use our ABE scheme to codify social relationships.
Alice uses an OSN to keep in touch with people she knows and she decides to classify his published resources according to the following categories: Friends and Coworkers. Alice has friends from high school, college and the music club or neighbors; similarly co-workers can be partitioned according to the different projects Alice is working on. Thus a resource is labeled with a vector of length over . Notice that since Alice is only involved in projects, no resource will ever be labeled with a vector having as second component. In addition for each resource Alice specifies a maximum distance at which the resource can be accessed. Obviously any such classification is likely to be partial and to change over time; as we shall see, our system is flexible enough to allow Alice to dynamically and efficiently change the classification of her links and resources.
2 Our framework
We assume that each user owns a set of resources. Each resource is denoted by a name and by a tuple of pairs (attribute, value) , where , are attribute names. Attributes describe relevant features (in terms of access control purposes) of the resource and take corresponding values . We represent a resource with the expression . Further, we assume that each user is in charge of her/his own set of resources. Attributes not only represent features of of resources to be accessed, but may also store information about their owners, for example who they are or where they work. We refer to such sets of attributes as credentials. Given a resource (or – more generally – a set of resources), a corresponding access policy expresses under what conditions a requester may gain access to the stated resource. More specifically, an access policy for a resource specifies the predicates that attributes and corresponding values stored in resources/credentials owned by a user have to satisfy in order for to access resource .
Now suppose Alice wants to publish an announcement regarding a concert to all of her friends from the music club; then she can specify attribute vector . Here the first attribute (that is, ) specifies the category of friends to which it is addressed ( stands for friends from the music club) and the second attribute specifies the category of co-workers (in this case Alice does not want co-workers to receive the announcement about the concert from her and thus specifies ). In addition Alice can specify a maximum distance she wants are announcement to be propagated. For example, makes the concert announcement accessible to Alice’s friends from the music club and to their friends.
2.1 The policy language
We express access control policies by means of access rules specified by resource owners. Access rules express under what conditions – which we divide into conditions about distance and about credential attributes – are to be satisfied a requesting user gain access to a stated resource. Such access rules and policies are specified by the resource’s owner.
We introduce the (fairly standard) language we will use to express access policies over resources in the OSN, starting with the definition of distance condition and attribute-based condition. Then, we introduce the precise definition of access rule and access policy.
An attribute condition is written as , where is the name of an attribute belonging to resource (we omit the user and/or resource name when there is no ambiguity in referring to the right attribute), is a predicate belonging to and is valid value for the attribute . a distance condition is written as and it is verified in the case that there is a path between user (usually requesting access to resource ) and the user stating such condition having length less or equal than . Given (attribute or distance) conditions and a resource , a access rule for the resource is written as . The meaning of such expression is that, in order to access resource , the requester has to possess resources satisfying all the conditions . When the resource is clear from the context, we will omit it, writing the conditions’ list only: . An access policy for the resource is defined as the set , where , are access rules. A resource , protected by a corresponding access policy , can be accessed by requester in the case that satisfies at least one of the access rules in . Such access control language allows for quite expressive access policies defined over resources owned by users of the OSN.
Using the above presented policy language, the access policy for Alice’s announcement and stated by Alice herself can be written as
In addition, Alice wants to disclose such announcement to her college friends as well, and this can be expressed as
Overall, the access policy is thus expressed as
Note that the condition means that users accessing have to be at most at distance from Alice in the OSN graph, that is they have to be friends with Alice, or friends with Alice’s friends.
2.2 Resource publication and access
Once a user has defined the appropriate access control policy for resource , he computes the encryption of the resource using the DBRA scheme, described in Section 3, and (apart the resource , of course) the policy . Then, the user publishes on the (possibly untrusted) OSN repository.
After having published the encrypted version of the resource , the user propagates – according to the access policy – to his friends that satisfy the access control policy (and only to them) the corresponding decryption keys .
Once published on the OSN repository, the metadata related to the encrypted resource (including, for example, the owner’s identifier) can be searched by all the OSN’s users. In this way, once a OSN user – without any connection with user – is willing to access resource , sends a link creation request to . Such request contains the attributes of as well. Upon checking whether the attributes of satisfy the access policy , decides upon the creation of a friendship link with . In the positive case, computes a decryption key and sends it to . Of course, a user has as many decryption keys as sensitive resource it is entitled to access. We call such set of decryption keys the key ring of user .
Alice can specify attributes also for relationships by giving a pair where is a vector of length over . For example, Alice’s link to Bob, a senior colleague of Alice’s working on , could be be labeled with the pair . The distance in this case can be used to assign weights to links. For example, the link to Carol, a junior colleague of Alice’s working on Project1, could be labeled with the pair . In this way a document addressed to senior personnel of could be labeled with . In classifying links, a user is also allowed to use wild cards. For example, Alice’s supervisor David will be linked to Alice with a link labeled which gives David access to documents from all projects Alice is working on.
As we have seen, resources are tagged with an attribute vector and a distance encoding the set of users and the distance in the social up to which owner allows the resource to be accessed. Going back to our previous example of Alice publishing a concert announcement with attribute , we make two remarks. First of all, the distance restriction does not mean that the announcement cannot be made available at distance greater than from Alice. Indeed, a friend of Alice’s can read the announcement and re-post it herself. The distance restriction only guarantees that if the announcement is read at distance greater than from Alice, then it cannot be linked to Alice. As a second remark, in our OSN, the attributes to links and to resources are not to be taken as recommendations. For example, by tagging the concert announcement with attribute , Alice does not mean that co-workers should not look at the announcement and that she relies on the the co-workers’ honesty in not looking at the announcement (experience shows that such a labeling would be too strong of a temptation to resist for most people). Rather the resource will not be made available to co-workers and this will not be enforced by the central manager of the OSN but rather we will provide Alice with a publishing procedure that will cryptographically enforce Alice’s decision of the set of users with which we wants to share the announcement.
3 Cryptographic notions
A DBRA scheme consists of six algorithms . The key generation algorithm returns an encryption key and a master secret key . The encryption algorithm takes as input the encryption key , a plaintext and ciphertext type in the form of a pair consisting of an attribute vector of length over a fixed alphabet and a integer distance . The master secret key can be used to derive, by means of the algorithm, restricted decryption keys that can be used to decrypt ciphertexts. Restricted decryption keys are also associated with a pair where is an attribute vector of length over the alphabet and is an integer called the distance. Keys and ciphertexts interact in the following way. For vectors and and distances , define the value of the predicate to be true iff for each it holds that or and . In other words, the vectors must match for all positions in which is not and the ciphertext must have a larger distance than the key’s. The decryption algorithm takes as input a ciphertext and a restricted decryption key and, if the attributes, , of and, of satisfy the predicate then the plaintext associated with is returned. If the attribute vectors do no match, then fails and returns . We stress that the decryption algorithm is oblivious to the attributes of and associated with ciphertext and key, respectively, which need not to be available in clear to the decryption algorithm. We observe that the master secret key can be seen as the restricted secret key associated with the all- attribute vector and distance .
In addition to the above algorithm, a DBRA scheme includes a key delegation algorithm that takes as input a restricted decryption key for and an integer and returns a key for pair . We stress that the algorithm need not to know the attribute vector associated with the key being delegated.
Finally, the DBRA.Revoke algorithm is used to revoke encryption keys. More specifically, the DBRA.Revoke algorithm takes as input an encryption key with the associated master secret key and a sequence of old ciphertexts and old restricted decryption keys . The DBRA.Revoke algorithm returns a new pair of encryption and new ciphertexts and new restricted decryption keys . The crucial property of the DBRA.Revoke algorithm is that the new ciphertexts encrypt the same plaintexts with respect to the new key as the old ciphertexts did with respect to the old key and, similarly, the new restricted decryption keys have, with respect to the new encryption and master secret key, the same attribute that the old keys had with respect to the old encryption and master secret key. A trivial way to obtain revocation is to generate a new pair of encryption and master secret key using the algorithm and then to decrypt and re-encrypt the ciphertexts with the new public key and to generate the new restricted decryption keys using the DBRA.Delegate algorithm. In our construction of a DBRA, we will use a much more efficient algorithm.
3.1 Security properties of Dbra
In this section we describe the security guarantee that are provided by a secure implementation of a DBRA scheme. As a first security property, we require that a ciphertext computed with the encryption algorithm of a DBRA scheme hides the plaintext to anyone that does not have the appropriate key. Specifically, suppose that user encrypts plaintext using a secure DBRA scheme and specifying attribute and obtains ciphertext . Then suppose that user requests and obtains restricted decryption keys relative to attribute . Then we require that is able to decrypt and thus recover if and only if . In addition to protecting the plaintext , we also require that a ciphertext does not leak any information about the attribute than what can be obtained from the attribute . In other words, might be able to check if . If this is the case then knows that and agree in all positions in which but should have no information about for all positions if which . On the other hand, if then knows that there is at least one position in which and ; but should not know where the mismatch occurs and if it occurs for one position or for more than one position.
4 Construction of a secure Dbra
First, we present HVE and HIBE and then we show how they can be used to construct a DBRA scheme.
4.1 Hidden Vector Encryption
A Hidden Vector Encryption (HVE for short) scheme consists of four algorithms . The syntax and semantics of a HVE scheme is very similar to that of a DBRA scheme. For sake of completeness we include it. The key generation algorithm returns an encryption key and a master secret key . The encryption algorithm takes as input the encryption key , a plaintext and ciphertext type consisting of an attribute vector of length over a fixed alphabet . The master secret key can be used to derive, by means of the algorithm, restricted decryption keys that can be used to decrypt ciphertexts. Restricted decryption keys are also associated with a vector where is an attribute vector of length over the alphabet . Keys and ciphertexts of HVE interact in the following way. For vectors and , define the value of the predicate to be true iff for each it holds that or . In other words, the vectors must match for all positions in which is not . The decryption algorithm takes as input a ciphertext and a restricted decryption and, if the attributes, , of and, of satisfy the predicate then the plaintext associated with is returned. If the attribute vectors do no match, then fails and returns . We stress that the decryption algorithm is oblivious to the attributes of and associated with ciphertext and key, respectively, which need not to be available in clear to the decryption algorithm. We observe that the master secret key can be seen as the restricted secret key associated with the all- attribute vector.
Security properties of HVE
In this section we describe the security guarantee that are provided by a secure implementation of a HVE scheme. As a first security property, we require that a ciphertext computed with the encryption algorithm of a HVE scheme hides the the plaintext to anyone that does not have the appropriate key. Specifically, suppose that user encrypts plaintext using a secure HVE scheme and specifying attribute and obtains ciphertext . Then suppose that user requests and obtains restricted decryption keys relative to attribute . Then we require that is able to decrypt and thus recover if and only if . In addition to protecting the plaintext , we also require that a ciphertext does not leak any information about the attribute than what can be obtained from the attribute . In other words, might be able to check if . If this is the case then knows that and agree in all positions in which but should have no information about for all positions in which . On the other hand, if then knows that there is at least one position in which and ; but should not know where the mismatch occurs and if it occurs for one position or for more than one position. For our implementation we use the HVE system of .
4.2 Hierarchical Identity-based Encryption
A Hierarchical Identity-based Encryption (HIBE for short) scheme consists of six algorithms . The key generation algorithm returns an encryption key and a master secret key . The encryption algorithm takes as input the encryption key , a plaintext and ciphertext type consisting of a vector of length over the alphabet . The master secret key can be used to derive, by means of the algorithm, restricted decryption keys that can be used to decrypt ciphertexts. Restricted decryption keys are also associated with vectors of length over the alphabet . Keys and ciphertexts of a HIBE interact in the following way. For vectors and , , define the value of the predicate to be true iff for each it holds that . In other words, the predicate checks if vector is a prefix of . The decryption algorithm takes as input a ciphertext that encrypt a plaintext and a restricted decryption key and, if the vectors, , of and, of satisfy the predicate then is returned, otherwise fails and returns . We observe that the master secret key can be seen as the restricted secret key associated with the length vector. In addition to the above algorithm, a HIBE scheme includes a key delegation algorithm that takes as input a restricted decryption key for and another vector such that holds and returns a key for the new vector .
Finally, the algorithm used for revocation has the same properties than the one for .
Our HIBE system
Our implementation uses the same HIBE of Boneh, Boyen and Goh  (BBG for short) that is efficient and offers constant-size ciphertexts. In addition our HIBE system include a revocation procedure not present in the original scheme. In the following, we assume that the reader is familiar with bilinear groups. The procedure works as follows. Recall that in the BBG system the secret is an element in the base group and the public key contains so all these elements are given as input to the revocation procedure. The revocation procedure re-randomizes by setting the new to be equal to for a random group element . Then, the procedure re-randomizes the only term in the decryption key where the old appeared. Indeed, in the BBG system the first group element of the decryption keys contains the term so the procedure can multiply such first group element by to obtain a new key consistent with the new secret . Analogously, the public key is multiplied by to obtain a new public key with the consistent distribution. Finally, notice that the only group element in the ciphertext containing is and notice that the ciphertext also contains the group element so the re-randomization can be obtained by computing and multiplying by to obtain the new value with the right distribution. It is easy to see that the old keys can not decrypt the new ciphertexts anymore and viceversa. We stress that the above procedure is efficient because it takes time independent of , the maximum length of the identity vectors.
Security properties of HIBE
We require that a ciphertext computed with the encryption algorithm of a HIBE scheme hides the the plaintext to anyone that does not have the appropriate key. Specifically, suppose that user encrypts plaintext using a secure HIBE scheme and specifying vector and obtains ciphertext . Then suppose that user requests and obtains restricted decryption keys relative to vector . Then we require that is able to decrypt and thus recover if and only if .
4.3 Implementation of a secure Dbra scheme using HVE and HIBE
We now show how to construct a secure DBRA scheme by using a secure HVE and HIBE schemes. The algorithm calls the algorithms and to obtain the pairs and and sets and .
The encryption algorithm take as input a message and a pair , and proceeds as follows. It encrypts and by using the HVE encryption with public key to produce ciphertext . Finally it encrypts by mean of and public key the message with identity , that is the distance codified in unary. The encryption returns the output .
The algorithm takes as input the master secret key and a pair and proceeds as follows. It calls to obtain . It calls , where is a vector that codifies in unary, to obtain . The key output by is set to the pair and .
The decryption algorithm takes as input a key and a ciphertext that encrypts the plaintext and works as follows. It uses the decryption algorithm of HIBE with key to decrypt (recall that is a ciphertext type of HIBE) and obtains . Now use the procedure of HVE with input and key to obtain the plaintext .
The procedure takes as input a key for distance and a new distance and works as follows. It computes , where is an encoding of in unary, and returns the new key pair .
The procedure calls the revocation procedure for the HIBE system.
It is possible to prove that the so constructed DBRA scheme is correct and secure assuming the correctness and security of the underlying HVE and HIBE schemes.
5 Access policy enforcement
We now describe the protocols required to perform the functionalists introduced in Section 2. We refer to the terminology introduced in Section 2. Moreover, in the following we assume that each user of the social network has already executed the requested cryptographic setup (parameters generation, etc.).
Furthermore, in the following we assume that the user executing the protocols for protecting her/his resources, has defined the set of the conditions which she/he is going to use in the definition of the policies protecting the sensitive resources owned by her/him. We recall from Section 2.1 that a condition is an expression of the form where is a resource name, is an attribute name from the ones over which the resource is defined, is a valid value from the corresponding domain of the attribute and is a binary predicate from .
We assume that the OSN has fixed a DBRA scheme and a symmetric key encryption scheme SKE. Upon enrolling into the OSN, a user generates a pair of encryption and master secret key for DBRA by running algorithm DBRA.KG on input the maximum distance . The encryption key is published in a publicly-accessible repository whereas the master secret key is kept by in a private repository.
5.2 Resource publication and access
The encrypted version of the sensitive resource is published on an untrusted repository. As such, we cannot assume the repository enforces the access control policy associated with the resource. As we have explained in the sections above, the access control policy is encoded by means of a policy pair consisting of an attribute vector and of a maximum distance . The policy pair is used by the encryption procedure of DBRA. More precisely, the publication of a resource protected by access policy (and therefore by the corresponding policy pair ) is carried out by performing the following three steps:
User generates a random secret key for symmetric encryption scheme SKE by running algorithm ;
resource is encrypted with key by running algorithm on input and obtaining the permanent ciphertext for resource ;
secret key is encrypted using encryption key with policy pair and algorithm DBRA.Enc to obtain the revocable ciphertext for resource .
The pair of permanent ciphertext and revocable ciphertext are sent to the public repository.
A user that wants to access a resource with policy pair using a restricted decryption key with policy pair such that first decrypts the revocable ciphertext using algorithm DBRA.Dec and thus obtaining secret key and then uses as input to to decrypt the permanent ciphertext .
5.3 Link creation and revocation
In this section we describe how user can establish link to user and assign to the link policy pair where is a vector over and is an integer. User runs algorithm DBRA.Derive on input the master secret key msk computed at enrollment and pair to obtain a restricted decryption key that is sent to user along with encryption key . The restricted decryption key will be used by to access all resources published by . In addition, upon receiving the pair user propagates the restricted decryption key to all users user for which has established a link. Specifically, suppose has established a link with policy pair . Then, using the DBRA.Delegate algorithm derives a key with policy pair and sends it to . does the same with all her neighbors until maximum distance is reached.
When user wants to revoke her link with user , she executes the DBRA.Revoke algorithm on input the encryption key , the master secret key , the revocable ciphertexts , for all published resources and the restricted decryption keys for all for which has established a link. As output, obtains a new public key , a new master secret key , new revocable ciphertexts , for each resource and new restricted decryption keys .
Finally, replace with in the public repository, with in the private repository, replaces the revocable ciphertexts with in the public repositories and sends the new restricted decryption key to each user .
6 Experimental results
In order to evaluate the feasibility of the proposed access control model and of the related enforcement protocols, we developed a prototype application providing the features described in the previous sections. The prototype has been developed in Java 6 using the jPBC ([3, 4]) and the BouncyCastle  cryptographic libraries and it is deployed as a Facebook application.
The application architecture follows the client-server paradigm, as shown in Figure 1. A user interacts through a web interface with the client module, which is in charge of generating the user keys and of the encryption/decryption of the resources. The user is allowed to define the access policy to be associated to the resource which she/he is currently uploading on Facebook. Upon the upload in the client module of the resource, such module execute the steps described in paragraph on resource publication and it sends the encrypted resource to the server module, which is in charge of storing it in the resource repository.
The client module is also in charge of retrieving the list of friends of the executing user and, after a check against their attributes, generates the search keys required to access the uploaded resources. Further, upon receiving a search key, the client module propagates such key to the owner’s Facebook friends, following the steps described for creating a link.
The purpose of the server module is to store the encrypted resources, alongside with metadata such as the resource names and the references to owners, and to provide a common interface to search and retrieve them. Note that the decryption of the resource is performed on the client side. Thus, no cryptographic material – such as keys – is available to the server module, other than the encrypted resources.
We performed two series of experiments to evaluate the performances of the DBRA scheme. More precisely, we tested the encryption algorithm varying the size of the shared resource and the size of the vector encoding the access control policy. The obtained results show that the performances are linear with respect of both the parameters, as shown in Figure 2.
7 Related Work
Access control in OSNs is a relatively new research area in which – nevertheless – several access control models and related mechanisms have been presented, aiming to overcome the restrictions of the mechanisms provided by current OSNs (see  for a survey). One of the common characteristics of almost all the defined access control models is that access control is relationship-based, that is, authorized users are denoted on the basis of constraints on the relationships the requester should have with other network users. In particular, such constraints refer to the depth of the relationship and/or its type. As an example, in  the authors present a framework for OSN access control that allows the definition of suitable policies with respect to the relationships occurring among the users and the corresponding associated trust values.
In the recent years,several work have been done to the definition of cryptographic schemes and protocols to store sensitive data over untrusted storage. As an example, in  the authors propose the deployment of a cryptographic layer over existing network file systems to provide privacy and confidentiality of the stored files. Their approach uses asymmetric cryptography to allow the sharing of the files among different users. In  it is presented an alternative approach which avoid the use of asymmetric cryptography in order to achieve better performance, with respect to computational time, however maintaining the flexibility of the key management typical of asymmetric scheme.
In  is presented a mechanism to perform access control to IPtv streaming data using an ABE scheme. In particular, the authors evaluate the impact of the deployment of ABE schemes in a system requiring massive scalability. In  the authors present an information management architecture based on an ABE scheme. Similarly to our approach, the architecture proposed uses the attribute-based crypto machinery in order to enforce access control policies, which are defined upon verifiable users’ attributes.
The introduction of cryptographic primitives in OSN in order to enhance the privacy and the security of shared data is an active research topic. In , the authors propose an alternative architecture for a distributed OSN, in which a four-layer client-server deploys cryptographic primitives and sandboxed environments to safely share and access information.
The Persona framework The work with which we share more common traits is Persona . In it, the authors present an access control framework for OSN using an ABE schema, namely the schema deployed in in the library cpabe . In this way, Persona allows users to apply fine-grained policies stating which users view their data. The main differences between Persona’s and our approach can be summarized in the following four points: (i) more expressive access policy definition language. Namely, our access policy language allows the definition of more comprehensive access control policies. First of all, in our policy definition language it is possible to express distance constraints and, more importantly, link labels can also contain entries. This means that if the label of the link from Alice to Bob has a in position , then Bob can access resources regardless of the -th attribute. (ii) Access delegation. That is, our framework allows a user to delegate access to certain resources to her/his contacts, according to the propagation limits defined. (iii) Efficient access revocation. Our framework allows a user to efficiently revoke all the generated keys which allow access to a given resource, automatically revoking the delegation as well. Note that in Persona access delegation and revocation are not supported. (iv) Privacy of the access control policy. Using our framework, the policy which protects a resource is known only to the owner. This is because the policy is encoded by a pair and vector is used to encrypt the resource. However, we require (and our implementation supports) that the encrypted resources not only hides the resource but also the attribute.
We achieve the four improvements listed above by developing a new cryptographic primitives, DBRA, and by showing that such a more powerful primitive can still be implemented in an efficient way.
In this work we have introduced a framework allowing users of a OSN to express and enforce access control policies for sharing sensitive information/resources without relying on a possibly untrusted third party, except for the storage of the encrypted information/resource. Our solution is based on a novel attribute-based encryption scheme and offers several advantages with respect to the existing literature, such as the possibility of expressing private access policies based on the topology of the OSN graph, with efficient revocation. We have implemented our framework as a Facebook application demonstrating the viability of our approach and showing that we can reach high levels of privacy with reasonable performances.
As further work we are currently working on a fully distributed OSN setting in which we plan to deploy the framework proposed in this work. Subsequently we plain to perform more extensive experiments and to test other cryptographic primitives.
- V. Iovino and G. Persiano, “Hidden-vector encryption with groups of prime order,” in Pairing, 2008, pp. 75–88.
- D. Boneh, X. Boyen, and E.-J. Goh, “Hierarchical identity based encryption with constant size ciphertext,” in EUROCRYPT, ser. Lecture Notes in Computer Science, R. Cramer, Ed., vol. 3494. Springer, 2005, pp. 440–456.
- A. De Caro, “Java pairing-based cryptography.” [Online]. Available: http://gas.dia.unisa.it/projects/jpbc/index.html
- A. De Caro and V. Iovino, “jpbc: Java pairing based cryptography,” in IEEE symposium on Computers and Communications (ISCC), 2011.
- “Bouncy castle crypto apis.” [Online]. Available: http://www.bouncycastle.org/
- B. Carminati and E. Ferrari, “Privacy-aware Access Control in Social Networks: Issues and Solutions,” in Privacy and Anonymity in Information Management Systems, J. Nin and J. Herranz, Eds. Springer, to appear.
- B. Carminati, E. Ferrari, and A. Perego, “Enforcing access control in web-based social networks,” ACM Trans. Inf. Syst. Secur., vol. 13, no. 1, 2009.
- E.-J. Goh, H. Shacham, N. Modadugu, and D. Boneh, “Sirius: Securing remote untrusted storage,” in NDSS. The Internet Society, 2003.
- D. Naor, A. Shenhav, and A. Wool, “Toward securing untrusted storage without public-key operations,” in StorageSS, V. Atluri, P. Samarati, W. Yurcik, L. Brumbaugh, and Y. Zhou, Eds. ACM, 2005, pp. 51–56.
- P. Traynor, K. R. B. Butler, W. Enck, and P. McDaniel, “Realizing massive-scale conditional access systems through attribute-based cryptosystems,” in NDSS. The Internet Society, 2008.
- M. Pirretti, P. Traynor, P. McDaniel, and B. Waters, “Secure attribute-based systems,” Journal of Computer Security, vol. 18, no. 5, pp. 799–837, 2010.
- J. Anderson, C. Díaz, J. Bonneau, and F. Stajano, “Privacy-enabling social networking over untrusted networks,” in WOSN, J. Crowcroft and B. Krishnamurthy, Eds. ACM, 2009, pp. 1–6.
- R. Baden, A. Bender, N. Spring, B. Bhattacharjee, and D. Starin, “Persona: an online social network with user-defined privacy,” in SIGCOMM, P. Rodriguez, E. W. Biersack, K. Papagiannaki, and L. Rizzo, Eds. ACM, 2009, pp. 135–146.
- “Advanced crypto software collection,” Available on-line at http://acsc.csl.sri.com/cpabe/.