BDABE

Blockchain-based Distributed Attribute based Encryption

Georg Bramm, Mark Gall and Julian Sch

utte

Fraunhofer AISEC, Garching near Munich, Germany

{

Keywords:

Blockchain, Attribute based Encryption, Key Revocation, Key Issuing, Key Management, Cryptographic

Access Control.

Abstract:

Attribute Based Encryption (ABE) denotes asymmetric cryptographic schemes where key pairs are created

for attribute owners and often applied to realize a ﬁne-grained, cryptographic access control mechanism for

outsourced data. Despite the beneﬁts of ABE systems, there are still drawbacks when ABE systems are trans-

formed into real world applications. Mainly, ABE systems suffer from non-efﬁciency or non-existence of revo-

cation mechanisms and user key coordination problems. By introducing a consensus driven approach, we try

to mitigate these issues in distributed systems. In this paper, we propose a collaborative attribute management

protocol for Ciphertext-policy attribute-based encryption (CP-ABE) schemes based on our own scheme called

a Blockchain-based Distributed Attribute Based Encryption (BDABE) scheme. Our construction realizes dis-

tributed issue, storage and revocation of private attribute keys by adding a consensus driven infrastructure, a

blockchain. We enhance both security and efﬁciency of key management in distributed CP-ABE systems for

the application of cloud data sharing.

1 INTRODUCTION

Ten years after the introduction of Bitcoin, the Block-

chain technology has evolved from a mere cryptocur-

rency system to a plethora of distributed ledger sys-

tems which establish trust in the correctness of code

execution and shared storage without the need for a

common trusted party. High availability, Immutabi-

lity, transparency, and the distribution of trust make

Blockchains not only interesting for all kinds of ﬁnan-

cial applications, but also for cryptographic schemes

which currently often rely on an ultimately trusted key

server, such as Attribute Based Encryption (ABE).

ABE is a new class of encryption schemes that

allow the encryption of data under an access po-

licy comprised of attributes. In Ciphertext-policy

attribute-based encryption (CP-ABE) schemes the

access policy becomes part of the ciphertext, during

the encryption of data. In classic public key crypto-

graphy data is encrypted for a speciﬁc recipient using

his private key, i.e. you have to know the intended

recipient of the data and her public key. It is obvi-

ous that such constructions do not scale when the set

of collaborators changes continuously, as the data set

would have to be encrypted respectively re-encrypted

for every legitimate user whenever a collaborator is

added or removed. Hybrid schemes offer a solution,

but are also complex to handle, when the number of

participants rises.

By contrast, a CP-ABE scheme allows a user to

encrypt data for any attribute such as ”supervisor” or

”employee” without knowing exactly the respective

individuals in possession of these attributes. Even

further, ABE allows the decryption of ciphertexts cre-

ated long before a corresponding key, in the assump-

tion that the attributes of the key match the access

policy. A salient advantage of ABE systems is that

problems solved by trusting traditional access cont-

rol systems can now be solved cryptographically. As

a result of this, the data itself can be stored publicly,

but can only be decrypted by legitimate users. A cen-

tral key management service is in charge of assigning

attributes to users and issuing individually generated

private keys to them. However, a major challenge

in ABE systems has been efﬁcient revocation of user

keys and the absolute trust in the key server with re-

spect to correctly issuing private keys only to legiti-

mate users. Another challenge is the lack of transpa-

rency regarding access rights from the perspective of

an encryptor. We try to address these challanges in

the following work.

Bramm, G., Gall, M. and Schütte, J.

BDABE - Blockchain-based Distributed Attribute based Encryption.

DOI: 10.5220/0006852600990110

In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 2: SECRYPT, pages 99-110

ISBN: 978-989-758-319-3

1.1 Related Work

With Attribute Based Encryption (ABE) a ﬁne-

grained, cryptographic access control mechanism for

outsourced data was introduced by Goyal et al. (2006)

and Bethencourt et al. (2007), which followed and

improved the idea introduced by Boneh and Franklin

(2001) to build a cryptographic scheme based on attri-

butes. Many successors expanded and improved these

schemes regarding efﬁciency like Agrawal and Chase

(2017) but also regarding functionality, like introdu-

cing a decentralized setting, such as Chase (2007),

uller et al. (2008) and Lewko and Waters (2011).

But there are still a lot of open problems concer-

ning the practical usage of ABE schemes, especially

in terms of key management and revocation mecha-

nisms. Recent work from Lin et al. (2017) as well as

Jemel and Serhrouchni (2017) and Jahid et al. (2011)

tries to address these issues in one way or another.

While Jemel and Serhrouchni (2017) used an additio-

nal temporal dimension for revocation purposes, Lin

et al. (2017) and Jahid et al. (2011) introduced ad-

ditive entities such as Key Authorities or Decryption

Proxies in order to solve these open issues.

Our approach differs from the previous ones in

that we propose to mitigate key revocation and mana-

gement issues by introducing a distributed infrastruc-

ture, a distributed Blockchain, as a solution.

DAC-MACS by Yang and Jia (2014) and DACC

by Ruj et al. (2011) also offer promising approa-

ches to realize a system for distributed cryptographic

access control, utilizing ABE. However, DAC-MACS

requires a global certiﬁcate authority (CA) and impo-

ses some overhead in the management of users and

authorities. A disadvantage of DACC is given by the

fact that each user is given a ﬁxed set of attributes

when it registers with an authority. The set of attribu-

tes of attributes can not be changed dynamically.

Another approach for distributed cryptographic

access control by Sarhan and Carr (2017), called

”ADB-SMC”, combines ABE with active data bund-

les and secure multiparty computation. Besides intro-

ducing computational and communication overhead,

their system involves an additional infrastructure, but

in difference to our approach it uses a Distributed

Hash Table rather than a blockchain infrastructure

that we build upon.

FairAccess by Ouaddah et al. (2016) is a fully

decentralized pseudonymous and privacy preserving

authorization management framework. FairAccess

uses and adapts the blockchain as a decentralized

access control management tool. The idea to use a

blockchain as a distributed ledger for access control

management decisions is similar to ours, but unlike

ours their proposed solution does not provide com-

plete conﬁdentiality of the data by utilizing a crypto-

graphic access control approach.

1.2 Our Contribution

We propose a Blockchain-based Distributed Attribute

Based Encryption (BDABE) protocol as a means to

apply a distributed ABE scheme to the real-world

using a consensus driven infrastructure to solve ge-

neral problems of ABE schemes. BDABE is a new

access control mechanism, where an Attribute Autho-

rity (AU) decides which of the attributes in its domain

should be assigned to a user. Users, data owners as

well as data consumers, can combine different attri-

butes from multiple AU in keys for decryption and

in access policies used for the encryption of cipher-

texts. The novelty of our protocol is the addition of

a Blockchain, which casts the trust of the attribute to

user mapping in the system from a single authority

to a distributed ledger. The Blockchain acts as a re-

ference for reﬂecting the mapping between all users

and all attributes in the system, thus enabling a reli-

able, traceable chain of delegated access rights. The

Blockchain provides everyone with a working proof

of a decentralized trust.

1.3 Structure

The remainder of this paper is structured as follows.

In section 2 we introduce the notation and give back-

ground information for our work. In section 3 we then

describe our BDABE protocol by illustrating the rela-

tionship between roles, attributes and keys. After that,

we introduce our distributed ABE scheme in section 4

and then show how the scheme can be used in our

BDABE protocol with a blockchain in section 5. Af-

ter a security analysis in section 6 and a discussion in

section 8, we ﬁnally give conclusions and show future

directions of research in section 9.

2 PRELIMINARIES

Before we describe our BDABE construction, we give

some background information on bilinear pairings,

our notation, access structures and the complexity as-

sumptions our protocol is based on.

2.1 Bilinear Pairings

Let G

, G

be groups of prime order p > 3, and

let g

and g

be generators of groups G

and G

, i.e.

SECRYPT 2018 - International Conference on Security and Cryptography

100

= hg

i and G

= hg

i. Let e : G

× G

→ G

a bilinear map, with the following properties:

1. Bilinearity: For random u ∈ G

, v ∈ G

and a,b ∈

∗

we have e(u

, v

) = e(u, v)

2. Non-degeneracy: e(g

, g

) 6= 1

3. e can be efﬁciently computed

We say that e is an asymmetric pairing, if G

6= G

and call it a Type-3 pairing (as opposed to Type-2)

iff no efﬁciently-computable isomorphism ψ : G

→ G

is known from G

to G

(or from G

) as Galbraith et al. (2008) deﬁned.

2.2 Notation

We use H : {0, 1}

∗

→ Z

to denote a hash function

that maps any arbitrary string to elements of the tar-

get group G

. With a = {0, 1}

∗

we denote a wallet

address in a permissioned Blockchain. A Blockchain

is denoted B, an attribute authority is given by AU,

attributes are represented using A. A policy descri-

bing the access rights to the underlying plaintext, in

Disjunctive normal form (DNF), is called an access

structure A and is deﬁned in the following subsection.

2.3 Access Structure

Let {P

, P

, . . . , P

} be a set of parties. A collection

A ⊆ 2

,...,P

}

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

C ⇒ C ∈ A. An access structure (respectively mo-

notone access structure) or policy is a collection (re-

spectively, monotone collection) A of non-empty sub-

sets of {P

, P

, . . . , P

}, i.e., A ⊆ 2

,...,P

}

\ {}.

The sets in A are called authorized sets, and the sets

not in A are called unauthorized sets. In our proto-

col, the role of the parties is taken by the attributes.

Thus, the access structure A in DNF will contain one

or more authorized sets of attributes, i.e. the set of

attributes necessary to decrypt a ciphertext, combined

by a disjunction.

2.4 Complexity Assumptions

Our distributed ABE scheme is build on an asymme-

tric Type-3 pairing and therefore is based on the follo-

wing complexity assumption, as deﬁned by Chatterjee

and Menezes (2011):

2.4.1 Discrete Logarithm in Type 3 (DLP-3)

Given g

∈ G

, g

∈ G

and y ∈ G

, no probabilistic

polynomial-time algorithm can compute P ∈ G

that e(P, g

) = y or Q ∈ G

so that e(g

, Q) = y.

2.4.2 Decisional Bilinear Difﬁe-Hellman in Type

3 (DBDH-3)

For an arbitrary group of exponents α, β, γ ∈ Z

∗

, gi-

ven a tuple (g

, g

, δ), no pro-

babilistic polynomial-time algorithm can distinguish

the following two tuples with a non-negligible advan-

tage:



, g

, e(g

, g

)

α·β·γ





, g

, e(g

, g

)



3 MODEL OF A BDABE

We now introduce our Blockchain-based Distribu-

ted Attribute Based Encryption (BDABE) protocol by

describing the roles of entities and the handling of at-

tributes and keys and their interaction in the protocol.

Additionally, we detail our utilization of a distribu-

ted ledger in combination with CP-ABE. The con-

struction of our distributed ABE scheme will be de-

tailed in the section 4, while the protocol ﬂow will be

discussed in section 5.

3.1 Roles

There are ﬁve different entities involved in our

BDABE model:

1. Distributed Blockchain (BC): The Blockchain is

the distributed ledger used to represent the cur-

rent state of delegated access rights in the system.

Permissions to interact with the Blockchain are

handled by the Root Authority and the Attribute

Authorities.

2. Attribute Authority (AU): An AU is responsible

for a set of users and a set of attributes, which we

will call a domain. Each AU may register users in

its domain and hand out the attribute keys of its

domain to users. Besides creating users, attribute

assignment is the main purpose of an AU. It may

assign attributes to users outside its own domain,

i.e. a user created by AU

may receive attribu-

tes given out by AU

. We assume that each AU is

semi-trusted in our system, i.e. it might be curi-

ous about the value of a plaintext in the system,

but has no intention of tampering with it.

3. Root Authority (RA): A RA is a central component

in our system. It is responsible for creating the se-

cret keys of attribute authorities and handing them

to an AU. The RA is capable of key escrow and

therefore needs to be fully trusted by all system

participants.

BDABE - Blockchain-based Distributed Attribute based Encryption

101

Table 1: Summary of BDABE keys.

Key Description Usage

PK public key Common ground and input for nearly all algorithms.

Publicly available for everyone.

MK master key Creation of AUs by the RA.

secret key of attribute authority AU Used by an AU to create users and attributes.

public key of address a Used to generate SK

A,a

by an AU.

secret key of address a Used to decrypt a ciphertext.

public key of attribute A Used to encrypt a plaintext with the given attribute.

Publicly available.

A,a

secret key of attribute A for address a Used to decrypt a ciphertext with a policy using at-

tribute A in combination with the S K

of address a.

4. Data Reader (DR): A DR is an authorized user

who intends to access encrypted data. The DR re-

gisters with an AU and obtains one or more attri-

bute sets. If one of the DR’s attribute sets satisﬁes

an access policy associated with a ciphertext, the

DR will be able to decrypt and acquire the plain-

text.

5. Data Owner (DO): A DO is any user, even

unauthorized, who owns data to be uploaded and

shared. A DO deﬁnes an access policy A for the

data, so that only the desired DRs with matching

attribute sets are granted permission to decrypt

and get access to the plaintext data.

3.2 Attributes, Keys and Wallets

An attribute in our system is a tuple consisting of an

identiﬁer AU of an Attribute Authority, an identiﬁer

A describing the attribute itself (an arbitrary string)

and a set of elements from G

and G

that belongs to

this attribute. We will use the shortcut AU

to denote

the attribute authority, who issued A.

In blockchain systems users often have a wallet,

which serves as a keychain. A wallet in BDABE is

owned by a DR and can hold multiple identities. An

identity consists of an address a and an attribute set.

DR obtains an identity by registering with an AU. The

management of attributes of a DR is implemented by

means of transactions to and from a wallet with at

least one identity.

Together with a the secret keys SK

the attributes

can be used to decrypt ciphertexts. In order to prevent

collusion between DR, every attribute set is uniquely

bound to a secret key SK

linked to the identity with

address a in the wallet of a DR. Table 1 shows an

overview of all utilized keys in our protocol.

3.3 Attribute Creation and Assignment

Every attribute in our system is issued by an AU. In

order to introduce a new attribute into the system, the

AU initially issues a new attribute on the blockchain to

its own address in an arbitrary quantity and creates the

new PK

for it, by using the PK and its own private

The assignment and dismissal of an attribute is

done via a transaction on the Blockchain. The PK

must be publicly available for every DO in the system,

meaning the AU should maintain a publicly available

list of all issued attributes and their associated PK

The AU is also allowed to remove attributes from the

wallet of a DR in his domain and thus may revoke at-

tributes from a DR. This is possible only, because the

AU knows the RSA keypair of every DR in his dom-

ain.

3.4 Encryption and Decryption

Figure 1 shows an example workﬂow how encryption

and decryption in our BDABE protocol. In order to

Figure 1: Workﬂow for encryption and decryption, accor-

ding to an example A = A ∧ B.

SECRYPT 2018 - International Conference on Security and Cryptography

102

encrypt a plaintext, a DO needs the PK as well as

all PK

s occuring in the DNF access policy A. The

resulting ciphertext may be decrypted by any regis-

tered DR with a sufﬁcient authorized set of attributes,

bound to his address a, matching any of the conjuncti-

ons in the disjunctive policy.

4 DISTRIBUTED ABE

We construct an efﬁcient distributed Attribute Ba-

sed Encryption scheme by expanding the scheme by

uller et al. (2008) and applying it on an asymmetric

Type-3 pairing. Additionally we modiﬁed it accor-

ding to our needs, as follows:

4.1 Setup

The Setup algorithm is run by the RA. It chooses bili-

near groups G

and G

of prime order p > 3 and a pai-

ring e : G

× G

→ G

. Next it chooses two genera-

tors g

∈ G

and g

∈ G

, two random points P

∈ G

and P

∈ G

, as well a random exponent y ∈ Z

and

a global hash function H : {0, 1}

∗

→ Z

. The public

key of the system is given by:

PK =











, G

, H

e, g

, g

, P

e(g

, g

)











The secret master key of the system is given by:

MK =

{

}

4.2 CreateAuthority(PK, MK, a)

The algorithm CreateAuthority is also run by the RA.

The algorithm chooses a value r

∈ Z

uniformly

at random. This value is used to randomize the re-

sult of the hash function H, modeled as random oracle

for each authority. The MK is split into two compo-

nents. This is done by selecting two random expo-

nents α, β ∈ Z

, such that α+β = y ≡ MK. The rand-

omization factor of the hash function r

, the address

of the authority a together with two elements g

and

, are used as the secret key of attribute authority

AU:

(

AU,I

= g

, SK

AU,II

= g

AU,III

= r

, SK

AU,IV

= a

)

4.3 CreateUser(PK, SK

, a)

The algorithm CreateUser, run by the AU, chooses a

secret value r

∈ Z

and outputs the public user key

of address a as:

{

a,I

= g

, PK

a,II

= g

, PK

a,III

= a

}

Using the secret key of attribute authority AU (SK

the secret key of address a (SK

) is computed as:

{

a,I

= SK

AU,I

· P

, SK

a,II

= SK

AU,II

· P

}

· P

, g

· P

4.4 RequestAttributePK(PK, SK

, A)

The AU has to reach a decision which attributes are

part of its domain. Once it decided that an attribute

is part of its domain, it issues the asset to its own ad-

dress. Additional units may be issued in the future

by the same key, which signed the original issuance,

i.e. by the AU. Furthermore, the AU has to decide

if it is the exclusive authority for attribute A. If ot-

her authorities should be able to issue the same at-

tribute it must grant permissions to do so. If the AU

has not authority over A (i.e. AU

6= a), the algo-

rithm RequestAttributePK returns NULL. Otherwise,

using SK

, it calculates an exponent ε(A, AU) =

H(A) · SK

AU,III

· H(SK

AU,IV

) = H(A) · r

· H(a) and

returns the public attribute key of A, which consists

of three parts:











A,I

= g

ε(A,AU)

A,II

= g

ε(A,AU)

A,III

= e(g

, g

)

y·ε(A,AU)











This public attribute, once requested should be pu-

blicly available for everyone, although it can only be

produced by the respective authority, because it requi-

res the random factor r

from SK

as input.

4.5 RequestAttributeSK(PK, SK

, A,

)

When a DR requests the secret key for an attribute, the

AU runs the RequestAttributeSK algorithm. After de-

termining that the attribute A is handled by AU (e.g.

by querying the blockchain if AU

= a), the authority

AU ﬁgures out, if the user with address a is eligible

for the attribute A. This decision must be taken by

AU. If the user with address a is not eligible to hold

A, RequestAttributeSK returns NULL, otherwise Re-

questAttributeSK calculates the exponent ε(A, AU) =

H(A) · SK

AU,III

· H(AU) = H(A) · r

· H(AU) and

returns the secret key of attribute A for address a

(SK

A,a

) on the ﬂy:

BDABE - Blockchain-based Distributed Attribute based Encryption

103

A,a

(

A,a,I

= (PK

a,I

)

ε(A,AU)

A,a,II

= (PK

a,II

)

ε(A,AU)

)

·ε(A,AU)

, g

·ε(A,AU)

4.6 Encrypt(PK, M, A, PK

, . . . , PK

)

The Encrypt algorithm is run by a DO whenever he

wants to encrypt a plaintext. The access policy A

must be written in Disjunctive normal form (DNF).

A policy in DNF consists of n different sets of con-

junctions

{

, S

, . . . , S

}

. The encryption algorithm

initially iterates over all sets j = 1, 2, . . . , n to gene-

rate a random value r

∈ Z

for each conjunction of

attributes. Afterwards the ciphertext CT

is calcula-

ted as:











j,I

= M ·

∏

A∈S

A,III

j,II

= P

j,III

= P

j,IV

∏

A∈S

A,I

j,V

∏

A∈S

A,II











The resulting ciphertext CT is ﬁnally obtained as:

CT =

{

,CT

, . . . ,CT

}

4.7 Decrypt(PK, CT, A, SK



, . . . , SK



)

The Decrypt algorithm is run by a DR whenever he

wants to access a plaintext. To decrypt a ciphertext,

Decrypt ﬁrst checks if any conjunction in the given

policy A can be satisﬁed by attribute set of address a:

{

, . . . , SK

}

. If this is not the case, the al-

gorithm outputs NULL. Otherwise it uses the set with

the smallest amount of matching attributes to compute

the plaintext message M as:

M = E

j,I







j,II

∏

i∈S

A,a,II







·e







j,III

∏

i∈S

A,a,I







(

j,IV

,SK

a,II

)

·e

(

j,V

,SK

a,I

)

In order to see that the decryption is correct, see Ap-

pendix 9.

5 BDABE AND THE

BLOCKCHAIN

Most of the current blockchain solutions are desig-

ned with a crypto currency in mind. In our BDABE

protocol, we deﬁne an authorization attribute rather

than a Bitcoin. This attribute represents the access

i.e. decryption rights deﬁned by an Attribute Autho-

rity (AU), the creator of the transaction to its receiver.

BDABE provides several useful mechanisms

using the blockchain. In BDABE, like in FairAccess,

the blockchain is considered to be a database that sto-

res all access control attributes in the form of tran-

sactions. Furthermore, it is able to provide a judicially

usable proof of evidence of the access i.e. decryption

rights of all users in the distributed system. Additio-

nally the access right delegation to users by multiple

authorities is tamper proof.

5.1 Integration of BDABE into the

Blockchain

Our protocol consists of six fundamental pro-

tocol operations: Setup

, CreateAuthority

CreateUser

, CreateAttribute

, IssueAttribute

and RevokeAttribute

. The details of the Encrypt

and Decrypt

protocol operations are omitted here,

as the retrieval of public key of attribute A (PK

)

is carried out away from the blockchain and the

reception of secret key of attribute A for address a

(SK

A,a

) to the wallet address a is included in the

IssueAttribute

protocol operation. The protocol

operations utilize algorithms of our distributed

ABE scheme in combination with operations on the

blockchain and and will be introduced now:

1. Setup

(): The purpose of the initial setup pro-

tocol is to setup the BDABE protocol by sprea-

ding key material and by initializing the block-

chain. This is done by setting up a distribu-

ted ABE scheme as well as a permissioned chain

through the RA. The new chain is created by the

RA on the blockchain, including mining the gene-

sis block, and the scheme is setup by running the

Setup() algorithm once. The Setup algorithm ge-

nerates a public key (PK) and a master key (MK).

The PK is made publicly available for everyone,

while the MK needs to be kept secret and is only

used to generate SK

s for AUs. Figure 2 gives

an overview of the different roles and interactions

during the setup of the system.

2. CreateAuthority

(AU): The master key (MK)

is used by the RA to generate a new SK

for each and every AU in the system. The

SECRYPT 2018 - International Conference on Security and Cryptography

104

Figure 2: Creation and issuing of keys and attributes in the

Blockchain-based Distributed Attribute Based Encryption

protocol.

RA generates a new address and RSA keypair

{a, RSA

priv

, RSA

pub

} on the blockchain. The

is generated using address a as authority

name. After giving the SK

the public key (PK)

as well as the newly generated RSA keypair to all

AUs in a secure manner, all AUs receive the ”con-

nect”, ”send”, ”receive” and ”issue” permission

by the RA. This can be seen in Figure 3. If an

additional AU wants to join the system at a later

date, this procedure needs to be repeated by the

RA.

CreateAuthority

(AU

)

createkeypairs



a, RSA

priv

, RSA

pub



grant permissions to a

CreateAuthority(PK, MK, a)

{

}



a, RSA

priv

, RSA

pub

, SK



Figure 3: Protocol operation CreateAuthor ity

(AU

3. CreateUser

(a): A user is created by an AU and

can only be created by an AU because a SK

needed as input to CreateUser. This means that an

address a in combination with a linked RSA key-

pair, as well as the personal SK

, linked to a user

address a are created by an AU. This is done by

ﬁrst calling ”createkeypairs” on the blockchain,

which generates a new tuple {a, RSA

priv

, RSA

pub

The address a receives the ”connect”, ”send” and

”receive” permission by the AU. A new SK

, lin-

ked to a user address a is created and ﬁnally the

set



a, RSA

priv

, RSA

pub

, SK



is given to the user

in a secure manner. The RSA keypair is kept by

the AU. This enables the AU to ”revoke” attribu-

tes from address a later on. An overview of the

protocol operation is given in Figure 4.

CreateUser

(DR

)

createkeypairs



a, RSA

priv

, RSA

pub



grant permissions to a

CreateUser(PK, SK

, DR

)

{

}



a, RSA

priv

, RSA

pub

, SK



Figure 4: Protocol operation CreateUser

(DR

4. CreateAttribute

(AU, A): This operation is ini-

tialized by an Attribute Authority and creates an

new attribute A in the belongings of an Attribute

Authority. An AU gives out the PK

s of attribu-

tes on request and releases these public attribute

keys available for everyone. Everyone in the sy-

stem is allowed to request PK

s from the AU, as

s are needed by everyone during encryption.

An asset representing the attribute string is crea-

ted on the blockchain by issuing it to the address

of the AU. Afterwards the AU must decide if ot-

her AUs should also be able to give out this at-

tribute to users. If it decides to do so it should

grant the ”issue” permission to all the address of

AUs that should be able to issue. In order to track

the assignment of the attributes to users, the At-

tribute Authority ”subscribes” to the issued attri-

bute. By subscribing, the AU instructs its node to

start tracking the issued attribute. This protocol

operation can be seen in Figure 5.

5. IssueAttribute

(AU, A, a): This operation issues

an attribute A from an Attribute Authority AU to

a user with address a, if the user is eligible to own

attribute A. Attribute Authority has to decide if

the user is eligible. The Attribute Authority sends

the asset in a transaction on the blockchain, inclu-

ding the secret key of attribute A for address a in

the metadata, to the address a in a quantity of ”1”.

This protocol operation can be seen in Figure 6.

6. RevokeAttribute

(A, a): This operation revokes

an attribute A from an user with address a. The

operation is executed by an AU and is possible

only, because the AU still knows the RSA key-

BDABE - Blockchain-based Distributed Attribute based Encryption

105

CreateAttribute

, DR

)

RequestAttributePK(PK, SK

, A

)

{

}

issue A

grant AA

: A

.issue

altalt

∀ j ∈ (AU

, AU

, . . . AU

)∃A

∈ AU

altalt

∈ B

Figure 5: Protocol operation CreateAttribute

, AU

)

with AU

being also able to issue A

in the future.

IssueAttribute

, DR

)

RequestAttributeSK(PK, SK

, A

, PK

)

{

,DR

}

send DR

: SK

,DR

: SK

,DR

altalt

∃A

∈ B ∧ A

∈ AU

Figure 6: Protocol operation IssueAttribute

, DR

RevokeAttribute

, DR

)

send AU

: A

,SK

,DR

send burn: A

,SK

,DR

Figure 7: Protocol operation RevokeAttribute

, DR

pair of a. The implications of this are staggering,

as this means that the AU that created the DR ini-

tially is also responsible for the attributes in the

DRs custody, even attributes issued by other AUs.

The AU that created the SK

for a is also respon-

sible for the revocation of all attributes from that

user.

6 SECURITY

We begin by establishing a security model for our dis-

tributed ABE scheme and conclude with a formal se-

curity analysis.

6.1 Security Model

We model the security of the distributed ABE scheme

similar to the DABE security model of M

uller et al.

(2008) in the form of a security game. The challenger

takes over the role of all attribute authorities and is

responsible for the setup.

6.1.1 Setup

The challenger runs the Setup algorithm to obtain PK

and MK and sends PK to the adversary.

6.1.2 Phase 1

The challenger creates empty dictionaries L

Atb

, L

Aut

and L

. The adversary can ask the challenger for

an arbitrary number of user and attribute keys with a

couple of restrictions. On each query the challenger

checks, if there exits an entry for AU

in L

Aut

. If not, it

calls CreateAuthority and stores (AU

, SK

) in L

Aut

It answers the adversary’s queries as follows:

• User Key Query (a, AU

): If there is an entry

(a, AU) in L

with AU 6= AU

return ⊥. Other-

wise, call CreateUser, store (a, AU

) in L

and re-

turn (PK

, SK

• Attribute Key Query (A, AU

, PK

): If there is

an entry (A, AU) in L

Atb

with AU 6= AU

return

⊥. Otherwise, call RequestAttributePK and Re-

questAttributeSK, store (A, AU

) in L

Atb

, update

the entry for the user key PK

in L

by adding at-

tribute A to it, and return (PK

, SK

A,a

Users and attributes belong to a single authority,

the challenger will reject requests for the same user

or attribute key from different authorities. For a user

key request the adversary sends the address a and an

identiﬁer for the authority AU

responsible for a to

the challenger. The challenger checks if L

contains

the address. If L

does not contain the address, or the

stored dictionary value is AU

the challenger answers

the request, otherwise he rejects it. If authority AU

does not exist, the challenger calls CreateAuthority.

To answer the request the challenger calls CreateU-

ser, stores the tuple (a, AU

) in L

and sends the re-

sulting private and public user keys to the adversary.

For an attribute request, the adversary sends the

public user key PK

, the authority identiﬁer AU

re-

sponsible for the attribute and the attribute identiﬁer

A to the challenger. The challenger checks if L

Atb

contains the attribute. If L

Atb

does not contain the

attribute, or the authority identiﬁer stored in L

Atb

the challenger answers the request, otherwise

SECRYPT 2018 - International Conference on Security and Cryptography

106

he rejects it. If authority AU

does not exist, the chal-

lenger calls CreateAuthority. The challenger calls Re-

questAttributePK and RequestAttributeSK, stores the

tuple (a, AU

) in L

Atb

, updates the entry for PK

in L

by adding the the attribute A and returns the public at-

tribute key PK

and the private attribute key SK

A,a

the adversary.

6.1.3 Challenge

The adversary submits two messages M

and M

and

an access policy A with the restriction that no user in

may satisfy A. If any user in L

has the attributes

to satisfy A, the challenger returns ⊥. If the access

policy A contains at least one attribute A for which

there is no entry in L

Atb

, the challenger returns ⊥. The

challenger ﬂips a coin, b encrypts M

under A and

sends the ciphertext ct to the adversary.

6.1.4 Phase 2

Similar to Phase 1, the adversary can ask the challen-

ger for an arbitrary number of user and attribute keys

with the same restrictions. Additionally, the challen-

ger will reject any attribute key query that would re-

sult in creating a user with an attribute set that satisﬁes

A. In this case the challenger sends ⊥.

6.1.5 Guess

The adversary outputs guess b

. The advantage of the

adversary in this game is deﬁned to be Adv

BDABE

Pr[b

= b] −

, where the probability is taken over

all coin tosses of both challenger and adversary. A

BDABE scheme is secure if all polynomial time ad-

versaries have at most a negligible advantage.

6.2 Security Analysis

In order to decrypt a ciphertext an adversary needs to

ﬁnd e(g

, g

)

y·ε( j)·r

for any 1 ≤ j ≤ n, while ε( j) =

∑

A∈S

H(A)·r

·H(a). This would allow an adversary

to obtain M from E

j,I

by computing a pairing of g

and

y·δ

for some γ, δ ∈ Z

, such that γ · δ = ε( j) · r

The adversary can only use keys that he has

obtained before in a security game such as in sub-

section 6.1 to create such a pairing. We now show

that an adversary is not able to compute this value,

assuming the attributes of the adversary may not sa-

tisfy the access policy A.

The value of g

appears in the secret user key

(y = α + β), besides from the pairing in the PK and

the MK itself. Thus the adversary has to use the SK

to calculate the pairing for some λ:

e(λ · SK

a,I

, g

) = e(g

, g

) · e(P

, g

) · e(λ, g

)

e(g

, λ · SK

a,II

) = e(g

, g

) · e(g

, P

) · e(g

, λ)

Given all values that the adversary knows, the only

useful choice for g

and g

are E

j,IV

and E

j,V

for

any conjunction of attributes in a ciphertext. Pairing

j,IV

with SK

a,II

gives:

e(E

j,IV

, SK

a,II

) = e(g

, g

)

β·ε( j)·r

· e(g

, P

)

·ε( j)·r

While pairing E

j,V

with SK

a,I

gives:

e(E

j,V

, SK

a,I

) = e(g

, g

)

α·ε( j)·r

· e(g

, P

)

·ε( j)·r

To obtain e(g

, g

)

α·ε( j)·r

and e(g

, g

)

β·ε( j)·r

, the se-

cond factors of the previous mentioned pairing equa-

tions have to be eliminated each. Despite all three

exponents of e(g

, P

)

·ε( j)·r

and e(g

, P

)

·ε( j)·r

being unknown to the adversary, he cannot compute

the value of y = α + β.

7 IMPLEMENTATION

The BDABE protocol was implemented using a pai-

ring cryptography library written in pure Rust by the

developers of z-cash, called ”bn” library. It makes

use of the Barreto-Naehrig (BN) curve construction of

Ben-Sasson et al. (2014) to provide two cyclic groups

and G

, with an efﬁcient bilinear pairing. The

communication protocol between the distributed ABE

scheme and the Multichain is implemented using its

JSON-RPC API. The Hash function H is implemen-

ted using blake2b (cf. Aumasson et al. (2013)) in our

solution. The source code to our BDABE protocol in

rust, as well as the implementation of the JSON-RPC

protocols, the DR Decryption algorithm and the DO

Encryption algorithm will be made available publicly.

We developed the attribute backend using Multi-

Chain by Greenspan (2015) as blockchain technology.

MultiChain is a permissioned blockchain technology

which is based on Bitcoin core. The developers of

MultiChain have introduced additional features, such

as support for asset transactions. This means that as-

sets can be created on the blockchain and can be send

between addresses. We used MultiChain as an inter

organizational blockchain for exchanging attribute as-

sets, in other words for mapping attributes from aut-

horities to users.

8 DISCUSSION

In this section, we accentuate the implications of is-

suing, revocation and delegation regarding attributes

BDABE - Blockchain-based Distributed Attribute based Encryption

107

on a blockchain.

8.1 Issuing of Attributes

An attribute is introduced into the system by an AU

through issuing it on the blockchain to itself. The at-

tribute should be issued openly, meaning it should be

possible that additional units might be issued in future

by the same key which signed the original issuance.

The outcome of this is that a speciﬁc attribute may

only be issued by the AU that issued it initially. An

AU may additionally issue an attribute to the address

of another AU, but the sovereignty over the attribute

assignment stays within the AU.

8.2 Evaluation of the Target Function

By subscribing to an issued attribute, any participant

in the blockchain network is able to track the tran-

sactions of a speciﬁc attribute.

In order to lookup

which addresses are able to decrypt a speciﬁc access

policy A, a users needs to subscribe to all attributes in

the access policy. By listing all transactions recipients

and by combining them with mathematical set opera-

tions, each user is able to evaluate the target function

of an access policy live. As access policies in our

protocol are given in DNF, i.e. consisting of n diffe-

rent sets of conjunctions

{

, S

, . . . , S

}

, while each

conjunction consists of an arbitrary number of up to m

attributes S

{

, A

, . . . , A

}

, the list of recipients

can be evaluated live using:

recipients =

j=1



k=1

listassettransactions(A

)



With listassettransactions

beeing the multichain

function that lists all asset transactions for the asset

A with recipient address a.

8.3 Revocation of Attributes

Speciﬁc attributes of users may only be revoked by

the AU that created the user in the ﬁrst place. Attribu-

tes of other AU may also only be removed by the AU

that created the user key. This is because the AU that

initially created the user still owns its RSA keypair.

Altogether this means that a user may mix attributes

from different AUs, but only the one AU that the user

registered with is in the responsibility of conducting

revocations.

The revocation mechanism via the blockchain is

not cryptographically forward secure, as a user might

By using multichains rescan option the node will rein-

dex all transactions from when the assets was created.

export an attribute key he received via his wallet and

use it later on to decrypt ciphertexts besides the block-

chain. This could be done by rewriting the decryption

software, to include attributes off the blockchain. This

issue is currently open and will be addressed in a fu-

ture work.

8.4 Delegation of Attributes

In a BDABE scenario with separate algorithms for the

creation of users and secret keys for attributes tied to

users, the delegation of attributes between users can-

not be supported since it would lead to collusions. In

order to prevent the delegation of an attribute by a

users, the attribute he receives via a transaction on the

blockchain is speciﬁcally tied to his secret user key.

The attribute alone, without an according user key is

useless.

8.5 Performance of the Framework

The performance of the protocol operations mostly

depends on the utilized blockchain. In a multichain

environment, with default settings, the delay for con-

ﬁrming transactions is in average about one minute.

This leads to attributes not being assigned instantly,

but with a delay of about a minute in average. This is

not fast enough to support real time access decisions,

but by way of comparison fast enough for example

for decentralized authentication systems in web based

scenarios.

9 CONCLUSION AND FUTURE

WORK

In this paper, we proposed the concept of a

Blockchain-based Distributed Attribute Based En-

cryption (BDABE) protocol as a way to apply an

adaption of the DABE scheme by M

uller et al. (2008)

to the real-world, that supports an arbitrary number

of distributed attribute authorities. It allows the ge-

neration of users by an attribute authority. Further-

more it allows the creation and deletion of new at-

tributes dynamically at any time by a transaction on

the blockchain. We provided an efﬁcient construction

of the distributed ABE scheme and showed how the

most fundamental operations can be integrated into

the blockchain for efﬁcient key and attribute manage-

ment. The integration of a forward secure revocation

mechanism is left open for future development.

SECRYPT 2018 - International Conference on Security and Cryptography

108

ACKNOWLEDGMENTS

This work has been funded by the Fraunhofer Clus-

ter of Excellence ”Cognitive Internet Technologies”

http://www.cit.fraunhofer.de

REFERENCES

Agrawal, S. and Chase, M. (2017). Fame: Fast attribute-

based message encryption. In Proceedings of the 2017

ACM SIGSAC Conference on Computer and Commu-

nications Security, pages 665–682. ACM.

Aumasson, J.-P., Neves, S., Wilcox-O‘Hearn, Z., and Win-

nerlein, C. (2013). Blake2: simpler, smaller, fast as

md5. In International Conference on Applied Crypto-

graphy and Network Security, pages 119–135. Sprin-

ger.

Ben-Sasson, E., Chiesa, A., Tromer, E., and Virza, M.

(2014). Succinct non-interactive zero knowledge for a

von neumann architecture. In USENIX Security Sym-

posium, pages 781–796.

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

Ciphertext-policy attribute-based encryption. In Secu-

rity and Privacy, 2007. SP’07. IEEE Symposium on,

pages 321–334. IEEE.

Boneh, D. and Franklin, M. (2001). Identity-based encryp-

tion from the weil pairing. In Annual international

cryptology conference, pages 213–229. Springer.

Chase, M. (2007). Multi-authority attribute based encryp-

tion. In Theory of Cryptography Conference, pages

515–534. Springer.

Chatterjee, S. and Menezes, A. (2011). On crypto-

graphic protocols employing asymmetric pairings-the

role of ψ revisited. Discrete Applied Mathematics,

159(13):1311–1322.

Galbraith, S. D., Paterson, K. G., and Smart, N. P. (2008).

Pairings for cryptographers. Discrete Applied Mathe-

matics, 156(16):3113–3121.

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, pages 89–98. Acm.

Greenspan, G. (2015). Multichain private block-

chain, white paper. URl: http://www. multichain.

com/download/MultiChain-White-Paper. pdf.

Jahid, S., Mittal, P., and Borisov, N. (2011). Easier:

Encryption-based access control in social networks

with efﬁcient revocation. In Proceedings of the

6th ACM Symposium on Information, Computer and

Communications Security, pages 411–415. ACM.

Jemel, M. and Serhrouchni, A. (2017). Decentralized access

control mechanism with temporal dimension based on

blockchain. In 2017 IEEE 14th International Con-

ference on e-Business Engineering (ICEBE), pages

177–182. IEEE.

Lewko, A. and Waters, B. (2011). Decentralizing attribute-

based encryption. In Annual international confe-

rence on the theory and applications of cryptographic

techniques, pages 568–588. Springer.

Lin, G., Hong, H., and Sun, Z. (2017). A collaborative key

management protocol in ciphertext policy attribute-

based encryption for cloud data sharing. IEEE Access,

5:9464–9475.

uller, S., Katzenbeisser, S., and Eckert, C. (2008). Dis-

tributed attribute-based encryption. In International

Conference on Information Security and Cryptology,

pages 20–36. Springer.

Ouaddah, A., Abou Elkalam, A., and Ait Ouahman, A.

(2016). Fairaccess: a new blockchain-based access

control framework for the internet of things. Security

and Communication Networks, 9(18):5943–5964.

Ruj, S., Nayak, A., and Stojmenovic, I. (2011). Dacc:

Distributed access control in clouds. In Trust, Se-

curity and Privacy in Computing and Communicati-

ons (TrustCom), 2011 IEEE 10th International Con-

ference on, pages 91–98. IEEE.

Sarhan, A. Y. and Carr, S. (2017). A highly-secure self-

protection data scheme in clouds using active data

bundles and agent-based secure multi-party compu-

tation. In Cyber Security and Cloud Computing

(CSCloud), 2017 IEEE 4th International Conference

on, pages 228–236. IEEE.

Yang, K. and Jia, X. (2014). Dac-macs: Effective data

access control for multi-authority cloud storage sys-

tems. In Security for Cloud Storage Systems, pages

59–83. Springer.

APPENDIX

Decryption of an BDABE Ciphertext

In order to see that the decryption is cor-

rect, let ε( j) =

∑

A∈S

H(A) · r

· H(a), then

j,I

= M · e(g

, g

)

y·r

·ε( j)

, E

j,IV

= g

·ε( j)

j,V

= g

·ε( j)

and thus:

BDABE - Blockchain-based Distributed Attribute based Encryption

109

j,I

j,II

∏

i∈S

A,U,II

· e

j,III

∏

i∈S

A,U,I

e(E

j,IV

, SK

a,II

) · e (E

j,V

, SK

a,I

)

=M · e(g

, g

)

y·r

·ε( j)

e(P

, g

·ε( j)

) · e(g

·ε( j)

, P

)

e(g

·ε( j)

, g

· P

) · e(g

· P

, g

·ε( j)

)

=M · e(g

, g

)

y·r

·ε( j)

e(P

, g

)

·r

·ε( j)

· e(g

, P

)

·r

·ε( j)

e(g

, g

)

β·r

·ε( j)

· e(g

, P

)

·r

·ε( j)

· e(g

, g

)

α·r

·ε( j)

· e(P

, g

)

·r

·ε( j)

=M ·

e(g

·ε( j)

, g

)

e(g

·ε( j)

, g

α+β

)

=M , exactly when α + β = y ≡ MK

SECRYPT 2018 - International Conference on Security and Cryptography

110