Self-sovereign Management of Privacy Consensus using Blockchain

Francesco Buccafurri

and Vincenzo De Angelis

DIIES, University Mediterranea of Reggio Calabria, Reggio Calabria, Italy

Keywords:

Self-sovereign Identity, Privacy, Consensus, Blockchain.

Abstract:

In this paper, we propose a solution implementing a self-sovereign approach to manage privacy consensus in

a open domain. The idea is allowing the user to set her policies in a unique way, in such a way that she keeps

the full control on her personal data. The goal is achieved by combining blockchain with Attribute-Based

Encryption and Proxy Re-encryption. Blockchain is also used to implement the notarization of the critical

actions to obtain accountability and non-repudiation.

1 INTRODUCTION

In the recent years, a new paradigm, called Self-

Sovereign Identity (SSI), is emerging (Baars, 2016).

SSI architectures ensure that users have the full con-

trol over their personal data. The idea is that the user

is the real owner of personal data, they are stored in

a unique place, and the user can establish the right

privacy policies just enforcing how the different par-

ties can access them. The beneﬁts of this paradigm

mainly regard the effectiveness of the control the user

can perform on data. Indeed, one of the major prob-

lems of privacy consensus management is the prolif-

eration of sites where data are stored together with

the related privacy policies. Typically, for each ser-

vice provider which needs to use personal data of the

customer (which is the most frequent case), a speciﬁc

data entry and consensus setting is required to the

user. This makes infeasible an effective control on

data, but also on the compliance of data usage with

privacy policies. Also unauthorized transfer of data

to third parties is hardly controllable. SSI aims at a

sort of manifest-based approach, in which the user de-

clares what is possible and what is not, and everyone

can verify (even ex-post), if data were managed cor-

rectly of some abuses occurred.

To reach this goal is not simple. A ﬁrst problem

(say P1) to tackle is that the manifest should not be in

clear, because it would be a powerful source of infor-

mation leakage itself, so an intolerable threat to pri-

vacy. A second problem (P2) is that, for the user, enu-

merating all the policies for every potential service

https://orcid.org/0000-0003-0448-8464

provider is infeasible, in general. But, on the other

hand, we can expect that policies can be expressed as

general rules, on the basis of the features of service

providers (with possible exceptions). For example, a

possible user’s rule could be: all medical data can be

accessed by public Health institutions. A third prob-

lem (P3) is that the user should have the possibility

to securely publish data and privacy policies in such

a way that no trust is required to the party publishing

them.

In this position paper (which is related to an in-

dustrial research project), we deﬁne a solution to

the above problem by suitably combining different

paradigms. The ﬁrst is blockchain. Indeed, it is often

stated that blockchain can be very powerful to imple-

ment SSI-based solutions. However, no effective so-

lution for privacy consensus management (to the best

of our knowledge) has been so far proposed. As mat-

ter of fact, besides the intuition that blockchain can

help SSI, no concrete declination of this statement is

available at moment. In our solution blockchain al-

lows us to really give the user the control on personal

data and privacy policies in such a way that no party

can tamper this information and also critical actions

can be notarized to obtain accountability. Basically,

blockchain solves problem P3, stated above.

But to deal with the other problems intro-

duced earlier (P1 and P2), we need to integrates

blockchain with two advanced cryptographic tech-

niques: Attribute based encryption (ABE) and proxy

re-encryption (PRE). Classical Public-key cryptogra-

phy requires the sender of the message knows exactly

who the recipient is. In many situations, it is not im-

portant to know the identity of the recipient but it is

426

Buccafurri, F. and De Angelis, V.

Self-sovereign Management of Privacy Consensus using Blockchain.

DOI: 10.5220/0008493804260431

In Proceedings of the 15th International Conference on Web Information Systems and Technologies (WEBIST 2019), pages 426-431

ISBN: 978-989-758-386-5

enough that this latter owns some attributes. ABE

schemes allow users to decrypt a message, encrypted

under a certain policy, if they own the attributes that

satisfy such policy. Instead, PRE schemes allow to

delegate a third part (proxy) to re-encrypt a chipertext

(i.e. to change the policy associated with it) without

exposing the content of plaintext.

Our solution resumes the scheme of public digital

identity (Union, 2014), where the role of the Iden-

tity Provider is replaced by the Consensus Provider

(CP). When a service provider SP, during the inter-

action with a (still anonymous) user, needs her per-

sonal data, a procedure is established in which CP

is required to allow the access to all data compliant

with the consensus released by the user for those ser-

vice providers having the right attributes. Thanks to

the blockchain, we can notarize all the critical ac-

tions in such a way misbehavior can be detected. As

a ﬁnal remark, we observe that the choice of using

an ABAC (Attribute-based-access-control) approach

to express privacy consensus is coherent with the ap-

plication context in which, typically, the user has no

reason to allow or deny the access to personal data

to a speciﬁc service provider. Conversely, the user

protects her privacy by stating general rules, mostly

related to the scope of the service provider. On the

other hand, if the user wants to deﬁne a policy speciﬁc

for a given service provider, it sufﬁces to include, as

attribute, just the identiy of this service provider.

The structure of this paper is the following. In the

next section we contextualize our paper in the related

literature. In Section 3, we give some preliminary no-

tions useful for the sequel of the paper. In Section 4,

we describe our reference scenario, to better highlight

which are the motivations of our proposal. In Section

5, our solution is presented in detail. In Section 6,

we sketch some additional features of our model, al-

lowing the notarization of critical actions. Finally, in

Section 7, we draw our conclusions.

2 RELATED WORK

In the recent years, a new type of public-key encryp-

tion technique, called ABE (Attribute based encryp-

tion) has been developed. ABE is characterized by

attributes and policies and the decryption of a mes-

sage is allowed if the policies are satisﬁed by the at-

tributes. The ﬁrst ABE scheme was proposed in (Sa-

hai and Waters, 2005), in which the authors present a

new type of Identity-based encryption scheme, where

the identity is composed of a set of attributes. Sub-

sequently, in (Goyal et al., 2006) and (Bethencourt

et al., 2007) respectively, the notions of KP-ABE and

CP-ABE were formalized. The difference is that, in

CP-ABE the policy is associated with a chipertext and

the attributes with a secret key belonging to a user,

while in KP-ABE the policy is associated with the se-

cret key and the attributes with the chipertext.

ABE techniques can be integrated with PRE

(proxy re-encryption) (Blaze et al., 1998). In PRE

a user delegates a semi-trusted proxy to re-encrypt a

chipertext intended for him/her into another chiper-

text for a different user. The integration of ABE and

PRE is called ABPRE and is useful, for example, in

those contexts when a user wants to change the policy

associated with the chipertext (CP-ABPRE) (Liang

et al., 2013).

In this paper, we combine ABPREs with

blockchain. The notion of blockchain takes origin

from the original paper of (Nakamoto et al., 2008) .

In this survey (Zheng et al., 2018), the reader may

ﬁnd an overview on all the features of blockchain. In

(Zyskind et al., 2015; Fan et al., 2018) two solutions

are proposed to share private data that use blockchain.

However, our proposal is different because we imple-

ment access control by leveraging to ABE and PRE

schemes. To the best of our knowledge, no proposal

combining blockchain and ABPRE can be found in

the literature.

3 BACKGROUND

In this section, we provide the technical background

necessary to understand our proposal.

Access Structures (Beimel, 1996): Let

, P

. . . , P

} be a set of parties. A collection

A ⊆ 2

...,P

}

is monotone if ∀B, C: if B ∈ A and

B ⊆ C then C ∈ A. An access structure (respectively,

monotone access structure) is a collection (respec-

tively, monotone collection) A of non-empty subsets

of {P

, P

. . . , P

}, i.e., A ⊆ 2

...,P

}

\ {

0}. The

sets in A are called the authorized sets, whereas the

other sets are called the unauthorized sets. A is also

called policy.

CP-ABPRE Scheme: A CP-ABPRE Scheme con-

sists of 6 algorithms:

• Setup(k): This algorithm receives a security pa-

rameter k and returns a public parameter PK and

a master secret key MSK.

• Encrypt(PK;M; A): This algorithm encrypts a

message M under the policy (access structure) A

by using PK. It outputs a ciphertext CT that can

be decrypted only by a user who owns the at-

tributes that satisfy A.

Self-sovereign Management of Privacy Consensus using Blockchain

427

• KeyGen(MSK;S): This algorithm takes as input a

set of attributes S and the master secret key MSK.

It outputs a private key SK associated with S.

• Decrypt(CT ; SK; PK): This algorithm takes as in-

put a public parameter PK, a private key SK as-

sociated with attributes S and the ciphertext CT

encrypted under the access structure A. If S satis-

ﬁes A, the algorithm outputs M.

• ReKeyGen(PK, SK;A

): This algorithm takes as

input a private key SK associated with a set of at-

tributes S and an access structure A

. It outputs

a re-encryption key RK that can be used, by a

proxy, to re-encrypt a ciphertext CT , encrypted

under a policy A, into a new ciphertext CT

en-

crypted under the policy A

.The re-encryption is

allowed only if S satisﬁes A.

• ReEncrypt(PK, CT, RK): This algorithm uses the

re-encryption key RK to re-encrypt the ciphertext

CT , under a certain policy, into another ciphertext

under a new policy.

4 THE REFERENCE SCENARIO

In this section, we describe our reference scenario,

to better highlight the motivations of our proposal.

The proposal is quite general, because refers to all the

cases in which personal data of given user are required

by a service provider (i.e., a company, a research in-

stitution, etc.), and we want to make the access com-

pliant with privacy consensus stated by the user. Just

as example, we consider a medical scenario.

The main entities we consider in our solution are:

(1) the user U, (2) the service provider SP, (3) the

consensus provider CP. Associated with the user U,

a set of personal data exists, which can be composed

of different segments. Without loss of generality, we

assume that segments are just ﬁles and the granular-

ity of privacy rules is at level of ﬁles. For example

a segment for a user can be represented by her health

data. According to a self-sovereign approach, data are

stored somewhere, and the user keeps a full control on

them. If a service provider want to access some seg-

ments of these data, it has to refer to the above repos-

itory and must be compliant with privacy consensus

stated by the user. The user establish privacy consen-

sus in a sort of manifest, which cannot be public, for

privacy reasons, but its management is delegated to a

third party, that is the consensus provider CP. It is

worth noting that, in our solution, there is no infor-

mation leakage towards CP. In other words, the role

of CP does not give any privilege in terms of right to

access personal data of users. CP works in our solu-

tion to implement the way to store somewhere privacy

consensus and enforce the application of such rules.

As our solution is based on blockchain and aims

to decentralize the most information/management, the

repository of personal data is not centralized. Instead,

we use the InterPlanetary File System (IPFS) (Benet,

2014). It is a new protocol, based on blockchain,

to store and share data in a distributed ﬁle system.

Blockchain is used as index of such data and to no-

tarize the critical actions.

In our example, a possible consensus rule could

be something like: all health data can be accessed

by service provider belonging to the category health

institution.

This means that when a service provider SP be-

longing to this category is interacting with the user

(initially completely anonymous) and needs to access

to her health data, an authorization procedure is per-

formed involving the user and CP, to check if the re-

quest is compliant with the privacy consensus. The

innovation of our solution is that the CP does not per-

form a classical access control enforcement. When

SP requires to access the data, CP does not need to

check if it satisﬁes the policy because it is, intrinsi-

cally, performed by the cryptographic ABE scheme

used. The only requirement is that SP is able to

demonstrate the attributes it holds. The solution in-

cludes also a notarization mechanism to prevent mis-

behavior of all the involved parties. As a ﬁnal note,

we observe that the access rights granted by U are al-

ways temporary and she can revoke or change such

rights at any time.

5 PROPOSED SOLUTION

In Figure 1, the architecture and the entities involved

in our solution are depicted. We introduce the nota-

tion used in the following.

1. let U be the user who needs a service s provided

by a service provider SP.

2. let SP be the service provider of the service s. To

provide s, SP needs the access to some ﬁles in F

3. let F

= { f

, f

, ..., f

} be a list of ﬁles owned by

4. let K

= {k

, k

, ..., k

} be a set of symmetric keys

(owned by U ), where k

∈ K

is used to encrypt a

ﬁle f

∈ F

or to decrypt a ﬁle c

∈ C

IPFS

5. let C

IPFS

= {c

, c

, ..., c

} be the list of U ’s

ﬁles encrypted and stored in IPFS. Speciﬁcally,

IPFS

i=1

E(k

, f

WEBIST 2019 - 15th International Conference on Web Information Systems and Technologies

428

Figure 1: Architecture for the privacy consensus management.

6. let IPFS be the repository containing all the ﬁles

of the users. We use this acronymous to mean that

it is implemented by using the InterPlanetary File

System (Benet, 2014). When U stores a new en-

crypted ﬁle c on IPFS, an index i

IPFS

turned that can be used to recover the ﬁle c.

7. let Add

be the blockchain address of U.

8. we model a transaction T as a tuple

hid

, Add

src

, Add

dest

, datai, where id

is the

identiﬁer (usually, it is the digest of the transac-

tion), src and dest are the sender and receiver

of the transaction, respectively, and data is the

payload.

9. let PKG be the entity responsible for the genera-

tion of ABE public key PK and ABE master secret

key MSK. Moreover, it generates the ABE private

keys SK for U and SP.

10. E(k, f ) denotes the encryption of a ﬁle f with the

symmetric key k.

11. D(k, c) denotes the decryption of a ciphertext c

with the symmetric key k.

12. let CP be the consensus provider. It manages the

access policies and plays the role of proxy re-

encryptor.

13. Setup(s),Encrypt(PK, M, A),Decrypt(CT, SK),

KeyGen(MSK, S), ReKeyGen(PK, SK, A

ReEncrypt(PK, CT, RK) are the ABPRE algo-

rithms as deﬁned in Sec.3.

14. let V

be a set, owned by CP, that contains

the symmetric keys in K

encrypted, with ABE,

under a certain policy. Speciﬁcally, V

i=1

Encrypt(PK, k

||id

, A

) where A

is the

policy associated with the ﬁle f

and id

is the

identiﬁer of the blockchain transaction generated

when the ﬁle f

(encrypted) has been stored on

IPFS.

15. let RK

be a set of re-encryption keys owned by

CP. Speciﬁcally, RK

i=1

ReKeyGen(PK,

, A

), where SK

is the ABE secret key asso-

ciated with U’s attributes and A

is a new policy

associated with the ﬁle f

. So, each rk

∈ RK

computed by U and sent to CP.

To be more accurate, we should include in the ar-

chitecture the attribute provider AP that are in charge

on checking if SP or U own the declared attributes.

For simplicity, we assume that this function is per-

formed, directly, by the PKG. In this position paper,

this aspect is not treated in detail.

Now, we describe the steps carried out by the dif-

ferent actors of our scenario. These steps are also

summarized in Figure 1.

Step 1: Setup. PKG invokes Setup(s) (where s is

an implicit security parameter) and generates PK

and MSK. U and CP shall exchange a seed to

initialize a PRNG. This PRNG is used to generate

a not guessable number that identiﬁes a request

of U. In this way, the different requests of U are

unlinkeable.

Self-sovereign Management of Privacy Consensus using Blockchain

429

Step 2: File storage. U wants to share a new

ﬁle f . First, U updates F

← F

{ f }, se-

lects a new symmetric key k, updates K

←

{k} and computes c = E(k, f ). Now, U

stores c on IPFS and obtains i

IPFS

1-2). IPFS updates C

IPFS

← C

IPFS

{c}. Fi-

nally, U generates a self-transaction (message

3) T = hid

, Add

, datai where data =

IPFS

(c), HMAC(k, f )).

Step 3: Delegation to CP. This step is performed

right after the Step 2. U contacts the PKG and

declares the set of attributes P that he/she owns

(message 4). At least, P is composed of the at-

tribute ID

that identiﬁes unequally U . PKG

checks that U really owns all the attributes in P,

and if the check is positive, it returns the ABE

private key SK

associated with P (message 5).

Observe that this request to PKG is performed by

U just once. Indeed, SK

can be used for fu-

ture ﬁles. At this point, U chooses a policy U

that requires the possession of the attribute ID

and computes v = Encyrpt(PK, k||id

, U). So, in

word, v is the symmetric key, used to encrypt the

ﬁle f , encrypted with ABE in a way that only U

can decrypt it (id

is used in the next Step).

Now, U chooses a policy A

, and invokes rk =

ReKeyGen(PK, SK

, A

). So, U sends the tu-

ple (v,rk) to CP (message 6) that updates V

←

{v} and RK

← RK

{rk}

Step 4: Service request. U requires a service s pro-

vided by SP. He/She generates a random num-

ber R (through the PRNG) that identiﬁes this re-

quest and sends (ID

, R) to SP (message 7).

is the identiﬁer of the CP in charge to man-

age U’s policies. Through ID

, SP contacts

CP and sends (ID

, R) (message 8), where ID

is the identiﬁer of SP. Now, CP veriﬁes that

U really has asked SP for the service s. So,

CP extracts R

from the PRNG and checks that

R = R

, then it performs a mutual authentica-

tion with U (by means of a challenge-response

mechanism)(messages 9-10). At this point, CP

computes Q

i=1

ReEncrypt(PK, v

, rk

). In

word, Q

contains all the symmetric keys used

by U, re-encrypted each one with an appropri-

ate policy. So, CP sends Q

to SP (message

11). Now, in order to decrypt the keys in Q

SP needs the ABE private key SK

associated

with its attributes. The procedure is similar to

Step 3. So, SP contacts PKG and declares a

set of attributes P

(message 12), PKG checks if

SP owns these attributes and send SK

(message

13). At this point, for each q

∈ Q

, SP invokes

Decrypt(q

, SK

) and retrieves k

||id

. Obvi-

ously, Q

contains all the private keys of U, but

SP can access (i.e. decrypt) to only some of them

(those for which it satisﬁes the policy). Now, for

each q

∈ Q

that SP is able to decrypt, it looks

for the transaction with identiﬁer id

and retrieves

IPFS

), HMAC(k

, f

)) (messages 14-15). Fi-

nally, SP contacts IPFS and asks for the ﬁle c

at the position i

IPFS

) (message 16-17). Once

SP obtain c

, it retrieves the ﬁle f

= D(k

, c

) and

checks the integrity computing HMAC(k

, f

Step 5: Policy change and Revocation. Suppose U

wants to change the policy A

associated with a

ﬁle f

∈ F

, with a new policy A

. We can distin-

guish two cases:

• All users that satisfy A

, also satisfy A . In this

case, the new policy allows new users to ac-

cess the ﬁle and maintains the access right of

old users. So, it is sufﬁcient that U invokes

= ReKeyGen(PK, SK

, A

) and sends rk

CP. CP updates rk

← rk

• The policy A

is generic. In this case, if U

doesn’t want to give (wants revoke) the access

right to old users, he has to change the symmet-

ric key k

. So, U remove the c

from IPFS and

starts Step2 and Step3 again.

6 NOTARIZATION

In this section, we describe an additional feature we

can include in our solution. It is the notarization of

a number of the critical operations aimed to obtain

accountability and non-repudiation. Obviously, no-

tarization is obtained by leveraging the properties of

blockchain. First, we assume that the user U and

the Consensus Provider CP, in a preliminary stage,

exchange their blockchain addresses through a non-

repudiable way. We want to notarize two critical ac-

tions: (1) the policy setting/change done by the user,

and (2) the policy enforcement done by CP.

The beneﬁt of the notarization (1) is that the mis-

behavior of both U and CP can be detected. For ex-

ample, it could happen that when U changes the poli-

cies, CP could keep the old policies. Notarization is

obtained (concerning the policy of a ﬁle f ), through

the publication on the blockchain of a transaction T =

hid

, Add

, datai, where data = (H(rk|| f )).

H is a hash function and rk is the new re-encryption

key generated by U (see Step 5 in section 5). There-

fore, in the previous example, if CP doesn’t use the

new policy (i.e. the new rk), U can prove it through

rk and f .

Notarization (2) prevents the misbehavior of CP

WEBIST 2019 - 15th International Conference on Web Information Systems and Technologies

430

or SP. In this case, we want to be sure that, when CP

sends Q

(message 11) to SP, it includes all and only

the symmetric keys of U. This goal is reached by gen-

erating a transaction T = hid

, Add

, datai

where data = (H(q

||q

||. . . ||q

)) and ∀i ∈ [1, n], q

∈

We highlight that other action can be notarized, as

those regarding the interaction between SP and AP. In

this position paper, we do not care this aspect which

will be treated in the next steps of our research.

7 CONCLUSIONS

In this paper, a self-sovereign-based approach to

manage privacy consensus to access personal data

is provided. The solution leverages the combina-

tion of blockchain with some advanced cryptographic

schemes, like attribute-based encryption and proxy

re-encryption. As message exchange ﬂow, our pro-

tocol resumes the scheme of federated authentication,

like SAML2 (Lockhart and Campbell, 2008) or Open-

Id Connect (Sakimura et al., 2014). So, a full imple-

mentation of our protocol can be done by extending

the features of one of the protocols mentioned earlier.

In a real-life adoption of our solution, we should also

understand who play the role of the various entities, in

particular CP, PKG and AP. While no high-level trust

is required to CP, which can be a company (as the

identity provider in public digital identity systems),

AP and PKG play a more critical role. Therefore,

they should be government institutions, or solutions

to decentralize also these function should be studied.

Observe that this problem exists also for the attribute

providers of public digital identity systems compliant

with the EU regulation (Union, 2014). As a future

work, we plan to address the above problems (i.e.,

implementation and real-life setting), together with a

careful security analysis to state more formally which

are the security features of our solution,

ACKNOWLEDGEMENTS

This paper is partially supported by the project

“SecureOpenNets-Distributed Ledgers for Secure

Open Communities”, funded by Ministry of Research

and Education (MIUR), project id ARS01 00587.

REFERENCES

Baars, D. (2016). Towards self-sovereign identity using

blockchain technology. Master’s thesis, University of

Twente.

Beimel, A. (1996). Secure schemes for secret sharing and

key distribution.

Benet, J. (2014). Ipfs-content addressed, versioned, p2p ﬁle

system. arXiv preprint arXiv:1407.3561.

Bethencourt, J., Sahai, A., and Waters, B. (2007).

Ciphertext-policy attribute-based encryption. In 2007

IEEE Symposium on Security and Privacy (SP ’07),

pages 321–334.

Blaze, M., Bleumer, G., and Strauss, M. (1998). Divert-

ible protocols and atomic proxy cryptography. In

Nyberg, K., editor, Advances in Cryptology — EU-

ROCRYPT’98, pages 127–144, Berlin, Heidelberg.

Springer Berlin Heidelberg.

Fan, K., Wang, S., Ren, Y., Li, H., and Yang, Y. (2018).

Medblock: Efﬁcient and secure medical data shar-

ing via blockchain. Journal of Medical Systems,

42(8):136.

Goyal, V., Pandey, O., Sahai, A., and Waters, B. (2006).

Attribute-based encryption for ﬁne-grained access

control of encrypted data. In Proceedings of the 13th

ACM Conference on Computer and Communications

Security, CCS ’06, pages 89–98, New York, NY, USA.

ACM.

Liang, K., Fang, L., Susilo, W., and Wong, D. S. (2013). A

ciphertext-policy attribute-based proxy re-encryption

with chosen-ciphertext security. In 2013 5th Interna-

tional Conference on Intelligent Networking and Col-

laborative Systems, pages 552–559. IEEE.

Lockhart, H. and Campbell, B. (2008). Security assertion

markup language (saml) v2. 0 technical overview. OA-

SIS Committee Draft, 2:94–106.

Nakamoto, S. et al. (2008). Bitcoin: A peer-to-peer elec-

tronic cash system.

Sahai, A. and Waters, B. (2005). Fuzzy identity-based

encryption. In Annual International Conference on

the Theory and Applications of Cryptographic Tech-

niques, pages 457–473. Springer.

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and

Mortimore, C. (2014). Openid connect core 1.0 incor-

porating errata set 1. The OpenID Foundation, speci-

ﬁcation.

Union, E. (23 July 2014). Regulation EU No 910/2014

of the European Parliament and of the Coun-

cil. http://eur-lex.europa.eu/legal-content/EN/TXT/

HTML/?uri=CELEX\%3A32014R-0910&from=EN.

Zheng, Z., Xie, S., Dai, H.-N., Chen, X., and Wang, H.

(2018). Blockchain challenges and opportunities: A

survey. International Journal of Web and Grid Ser-

vices, 14(4):352–375.

Zyskind, G., Nathan, O., and Pentland, A. . (2015). De-

centralizing privacy: Using blockchain to protect per-

sonal data. In 2015 IEEE Security and Privacy Work-

shops, pages 180–184.

Self-sovereign Management of Privacy Consensus using Blockchain

431