# BDUA: blockchain-based data usage auditing

Nesrine Kaaniche, Maryline Laurent

► To cite this version:

Nesrine Kaaniche, Maryline Laurent. BDUA: blockchain-based data usage auditing. 2018 IEEE 11th International Conference on Cloud Computing (CLOUD), Jul 2018, San Francisco, United States. pp.630-637, 10.1109/CLOUD.2018.00087. hal-03754087

HAL Id: hal-03754087

https://hal.science/hal-03754087v1

Submitted on 3 Jan 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# BDUA: Blockchain-based Data Usage Auditing

Nesrine Kaaniche

SAMOVAR, Telecom SudParis,
University Paris-Saclay, France

Maryline Laurent

SAMOVAR, Telecom SudParis,
University Paris-Saclay, France

***Abstract***—Personal data are often collected and processed in a decentralized fashion, within different contexts. For instance, with the emergence of distributed applications, several providers are used to correlate their records, to provide personalized services to their clients. As such, to protect users' privacy, different pseudonyms are generally used for different contexts. These pseudonyms have to be unlinkable to prevent identifying records to be associated to the same user. Although unlinkable, these pseudonyms have to be processed and exchanged according to their owners' consent and in a privacy-preserving fashion. In this paper, we propose *BDUA*, a new Blockchain-based Data Usage Auditing system, that ensures a controlled yet privacy preserving exchange of distributed data, such that a set of authorized auditing entities are able to conduct an accurate auditing relying on registered blockchains' transactions.

***Keywords***—pseudonymous schemes, homomorphic encryption, blockchain, privacy, auditing.

## I. INTRODUCTION

Several organizations often collect large amounts of sensitive data about their clients. This raises the question of the transparency of usage and protection of the collected data. Indeed, when data collection and processing are produced in a distributed fashion, it is commonly known that different data records associated to the same user can be easily linked. Several countries, such as US, Belgium, Denmark and Sweden rely on a unique identifier, referred to as *national social security number* for preserving linking, for example government datasets and health records.

While such unique nation-wide identifiers across the whole system allow to easily correlate records with no need for data owners' consent, they introduce several security and privacy issues. That is, a number of entities are made powerful over citizens with the capability to trace them, combine their datasets, infer some information... Even worse, any data breach reveals fully identifiable and linkable personal information. As such, several approaches, called pseudonym systems, have been proposed. In fact, they rely on the use of different context-specific pseudonyms that are unlinkable. In order to enable associating different outsourced data sets, a central entity, referred to as a *convertor*, can later be asked to associate pseudonyms to a specific user on a case per case basis.

A pseudonym system is an interesting solution that permits to guarantee auditability and ensure confidentiality of data w.r.t. involved entities. However, as the convertor is the main central entity, he can easily correlate data with their respective users, while tracing users' activities, based on data exchanges. Recently, Camenish and Lehmann [1] presented a blind-convertor

system, where the conversion process, executed by the convertor, is performed in a privacy-preserving (i.e; anonymous and unlinkable) fashion, with no need for learning the pseudonyms or the identity of the concerned user. The authors extended their work by presenting in [2] a system where user-centric audits are set-up by an oblivious convertor, which is still the main central entity. This appended auditability feature is a very important property, for compliance with legal and business requirements. In 2016, the European Union (EU) adopted a new General Data Protection Regulation (GDPR) that aims at effectively ensuring the protection of users' privacy [3].

***Contributions*** — While several systems permit to satisfy transparency and auditability requirements based on a user-centric fashion, we propose *BDUA*, a new Blockchain-based Data Usage Auditing system, that ensures a controlled yet privacy preserving exchange of distributed data, such that a set of authorized auditing entities are able to conduct an accurate auditing relying on registered blockchains' transactions. Our *BDUA* scheme ensures the following properties:

* an unlinkable pseudonym system where a selected convertor obviously collaborates with each user to derive individual pseudonyms for each server. That is, the convertor cannot learn the derived pseudonyms, but is still the only entity that can link pseudonyms together without learning the particular user or pseudonym for which such translation is requested.

* an accurate privacy-preserving auditing process based on blockchain transactions and achieved thanks to transactions being registered by each of the involved participating entity, and enciphering of linking information with respect to a multi-level attribute based encryption.

### Paper Organization

Section II introduces the blockchain technology and reviews the related work. Section III presents the problem statement and highlights the security requirements. Section IV provides a general overview of the proposed schemes, with the different building blocks and details *BDUA* procedures and algorithms. Section V introduces the threat model, discusses the security properties and gives a brief performances analysis, before concluding in section VI.

## II. BLOCKCHAIN TECHNOLOGY

This section reviews the blockchain technologies (cf. section II-A) and discusses related works (cf. section II-B).
A. Background

Blockchain has gained an attractive interest, since 2008, with the bankruptcy of *Lehman Brothers* in the United States. A blockchain is essentially a public ledger of transactions or events recorded and stored in chronologically connected blocks [4]. The philosophy underlying the blockchain technology is that records are *shared by all network nodes, updated by miners, monitored by everyone, and owned and controlled by no one* [4]. Nodes are simple users' computers or mobile devices, while miners are nodes with extensive computational resources that can be used for transaction validation purposes. Two approaches, known as permissionless blockchains, have emerged to implement decentralized services. The first approach relies on the existing Bitcoin blockchain<fnref n="1" />. The main advantage of this approach is that the Bitcoin blockchain already exists and is adopted by many users, which makes it more secure, transparent and resilient. However, blocks are mined every 10 minutes and the scripting language is not Turing-complete [4]. The second approach is to build an alternative blockchain with all the desired features, which promises full decentralization, such as Ethereum<fnref n="2" />. Additionally to functions already supported by other public blockchain-based platforms, Ethereum also provides a contract functionality known as *smart contract*, ensuring a high degree of automation.

Recently, permissioned blockchains are gaining an expanding interest across multiple industries. This concept appeared as a promoting solution for business applications of distributed ledgers, in which participants do not necessarily have full trust on each, yet requiring some means of identification. Unlike permissionless blockchains, there exists a central entity that decides and grants the right to individual peers to participate in the read/write operations.

B. Blockchain-based Data Auditing- Related Work

The nature of the blockchain is particularly suitable for data accounting and auditing features. It has attracted interest of the research community due to its shared and fault-tolerance database. Indeed, several constructions have been introduced to ensure provenance tracking [5]–[8].

In [7], Zyskind et al. presented a personal data management system that combines blockchain, considered as an access control moderator, and off-blockchain storage solutions. That is, clients are aware of data collected about them by service providers and how they are used. When a client subscribes to a service provider, one transaction is created defining the set of access policies and another contains the hashes of data stored in an off-chain database. However, [7] permits to only define simple permit/deny access policies through white/blacklisting. Based on [7], Linn et al. propose an application of the data auditing framework for health scenarios [5]. In their construction, the blockchain is also considered as an access moderator to control the access to outsourced shared data.

Recently, Neisse et al. discussed design requirements of blockchain-based solutions for data provenance tracking [9] and presented an evaluation of their implementation results, in order to give a comprehensive overview of different defined approaches. Later, in [8], Kaaniche and Laurent presented a blockchain-based platform for data usage auditing while preserving users’ privacy. The proposed construction relies on the use of hierarchical ID-based techniques, where a central master authority delegates the process of public/private keys’ generation to the different participating entities.

III. MOTIVATION AND SECURITY REQUIREMENTS

According to the GDPR [3], the data subject's consent is given for specific purposes to which both the data controller and the data processor have to comply. In this context, three main roles are defined. The *data subject* gives his consent to a *data controller* (i.e. organization, enterprise) for processing his personal data, and optionally forwarding them to a *data processor* (i.e. organization, enterprise) that is required to process data on behalf of the data controller. Data controllers are responsible for (i) specifying to the data subject the purpose of data collection, (ii) obtaining the data subject's consent and (iii) processing personal data according to the consented purposes, and not beyond.

From a data controller or processor's perspective<fnref n="3" />, there is a need for a trusted and transparent accountability solution that enables them to get a proof of the data owner's consent prior to processing his personal data. From a data owner's perspective, there is a need for new security mechanisms that support data accountability and provenance auditing when his personal data were forwarded to data processors. Indeed, it is important to conceive a secure and transparent solution that permits data owners to (i) check that data controllers and processors are correctly using their data with respect to the consented purposes, (ii) verify whether data were forwarded without their consent and (iii) withdraw their consent.

Several works have been proposed, mainly based on cryptographic techniques to enable service providers to inform users about the actual data processing that takes place on their personal data. In [10], Wouters et al. proposed a scheme for building a logging-chain of processes for eGovernment services. A data owner can reconstruct the trail of such a process and verify its status if he is the subject of that process. Reconstruction is based on hand-overs (ie; special types of log events) that link data stored by multiple logging servers. The proposal [10] is privacy-preserving in the sense that only data owners can link their related log entries. Afterwards, Pulls et al. presented a privacy-preserving auditing scheme [11]. The proposed mechanism supports dynamic and distributed processes' logging, such that the log entries are world-readable and distributed among several logging servers. However, authors assume that data processors need to be trusted.

<footnote n="1">¹https://bitcoin.org/en/</footnote>

<footnote n="2">²https://www.ethereum.org/</footnote>

<footnote n="3">³In the following, the remainder of the paper refers to the data subject as the data owner and to both the data controller and the data processor as the service provider.</footnote>
In [12], Galindo and Verheul proposed a data exchange solution based on a convertor. This latter could derive and distribute pseudonyms, however these identifiers could be easily linked. In the same vein, Camenish and Lehman proposed a privacy preserving data exchange scheme, based on a blind convertor [1]. As such, their proposal is based on pseudonyms which are per se unlinkable but can be transformed from one server to another with the help of the convertor. However, [1] does not support auditing capabilities. Afterwards, authors extended the main construction to support user auditing [2]. The proposed scheme relies on an oblivious central entity that provides a system where user-centric audits logs are created by the convertor. [2] makes use of several new building blocks and the tag-chaining approach for ensuring user-audits.

Table I presents a comparison between *BDUA* and most closely related schemes, w.r.t. functional requirements.

<table><caption>TABLE I COMPARISON BETWEEN *BDUA* AND MOST CLOSELY RELATED SCHEMES</caption><thead><tr><th>Scheme</th><th>blind conversion</th><th>multi-convertor</th><th>user auditing</th><th>public auditing</th></tr></thead><tbody><tr><td>[10]</td><td>×</td><td>×</td><td>✓</td><td>✓</td></tr><tr><td>[11]</td><td>×</td><td>×</td><td>✓</td><td>✓</td></tr><tr><td>[1]</td><td>✓</td><td>×</td><td>×</td><td>×</td></tr><tr><td>[2]</td><td>✓</td><td>×</td><td>✓</td><td>×</td></tr><tr><td>BDUA</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td></tr></tbody></table>

✓ and × indicate that the requirement is achieved or not, respectively.

## IV. *BDUA*: A NEW BLOCKCHAIN-BASED DATA USAGE AUDITING SCHEME

In the section, we first present an overview of *BDUA* (cf. section IV-A) and introduce the notations used in the paper in section IV-B. Then, we review the different building blocks in section IV-C. Afterwards, we detail our construction IV-D.

### A. Overview

*BDUA* is a new blockchain-based data usage auditing scheme that deals with the challenge of enabling privacy preserving yet transparent and controlled data usage in a decentralized system, while considering a convertor that permits to ensure pseudonyms matching. It relies on Camenish et al. [1], [2] construction, which is adapted and mainly extended to support public auditing by authorized authorities. Indeed, each process is registered in the blockchain, via a set of transactions pushed by the participating entities. Each transaction contains the encrypted identifier of the previous transaction referring to the latest process performed on the user's data. In order to enable public authorized auditing, *BDUA* relies on a multi-level encryption scheme [13], such that deciphering entities have access to different levels of detailed information with respect to their certified attributes.

As depicted in Figure 1, *BDUA* is based on four different entities, namely user *U*, convertor *X*, server *S* and Blockchain BC. Conceptually, each user *U* blindly creates with the convertor *X* an individual pseudonym for each server *S*, derived from his unique main identifier *id*<sub>U</sub>. It is to be noted that the convertor does not learn anything about the derived pseudonyms. The creation of a new user pseudonym

<figure><img src="image_2.png" /><figcaption>Fig. 1. *BDUA* Network Model</figcaption></figure>

with a server, is then registered by *X* in the blockchain. The pseudonym creation transaction has to specify the set of usage actions allowed on shared data between the user and the server. These granted privileges as well as participating entities are then encrypted relying on the ABE scheme, while the associated ABE access policy should allow auditing authorities to access to data when needed.

The core of the pseudonym conversion protocol is similar to Camenish et al. scheme [1]. When a server *S*<sub>A</sub> wants to convert the pseudonym *nym*<sub>U,S<sub>A</sub></sub> of a user *U* towards a server *S*<sub>B</sub>, it sends the pseudonym in a homomorphically encrypted form to the convertor. The convertor blindly computes *nym*<sub>U,S<sub>B</sub></sub>. In *BDUA*, the conversion request and response should be registered in the Blockchain by both servers *S*<sub>A</sub> and *S*<sub>B</sub> as well as the related convertor. These transactions should contain the same session identifier selected by the convertor and accompanied by a freshly generated random that is encrypted by both an ABE algorithm for auditing authorities as well as a dynamic (i.e; randomized) public key of the corresponding user (yet unknown) for user-auditability.

The encrypted audit logs are made publicly available via the Blockchain such that they can be fetched by all users. However, only authorized auditing authorities, referred to as *D* and data owners can respectively decrypt related transactions.

### B. Notations

Each algorithm is denoted as: *out* = *f*<sub>*E*</sub>(*ent*), where *out* is the output of the algorithm *f*<sub>*E*</sub>, executed by *E* based on the set of inputs *ent*, where *E* represents any system's entity, such that *E* = {*U*, *X*, *S*, *D*}.

When the output of *f*<sub>*E*</sub> is exchanged between two system's entities, it is denoted by *out*<sub>*E*<sub>s</sub>, *E*<sub>r</sub></sub>, where *E*<sub>s</sub> presents the sending entity and *E*<sub>r</sub> the receiving entity.

If *f* is a two party oblivious algorithm, it is denoted by *out*<sub>*E*<sub>r</sub>, *E*<sub>s</sub></sub>(*ent*), where *E*<sub>r</sub> and *E*<sub>s</sub> present the participating entities based on the set of inputs *ent* and *out*<sub>*E*<sub>r</sub></sub> is the output of the algorithm retrieved by *E*<sub>r</sub>.

### C. Building Blocks

1) Bilinear Maps: Let $\mathcal{G}$, $\tilde{\mathcal{G}}$ and $\mathcal{G}_t$ be three groups of prime order *q*, where *g* and $\tilde{g}$ are generators of $\mathcal{G}$ and $\tilde{\mathcal{G}}$
respectively. A function $\hat{e}$ is considered as a bilinear map if it
satisfies the following requirements:

* bilinearity: $\hat{e}(g^a, \tilde{g}^b) = \hat{e}(g, \tilde{g})^{ab}$, for all $a, b \in \mathbb{Z}_q$;

* non-degeneracy : for all generators $g \in \mathbb{G}$ and $\tilde{g} \in \tilde{\mathbb{G}}$, $\hat{e}(g, \tilde{g})$ generates $\mathbb{G}_t$;

* efficiency: there exists an efficient algorithm that computes $\hat{e}(x, \tilde{y})$, for all $x \in \mathbb{G}$ and $y \in \tilde{\mathbb{G}}$.

2) **Oblivious Pseudo Random Function:** An oblivious Pseudo-Random Function (OPRF) [14] is a two party protocol between a sender $\mathcal{E}_s$ and a receiver $\mathcal{E}_r$ for securely computing a pseudorandom function $f(k, x)$ relying on the key $k$ computed by $\mathcal{E}_s$ and on input $x$ contributed by $\mathcal{E}_r$, such that $\mathcal{E}_r$ learns only the value $f(k, x)$ while $\mathcal{E}_s$ learns nothing from the interaction. In 2005, Dodis and Yampolskiy [15] presented an OPRF construction that is proven secure in the standard model based on the decisional Diffie-Hellman inversion assumption. BDUA relies on an OPRF to derive the user core identifier, such that each user $\mathcal{U}$ performs with a convertor $\mathcal{X}$ an oblivious process, with inputs $id_{\mathcal{U}}$ and $sk_{\mathcal{X}}$, respectively. As such, $\mathcal{U}$ receives his own core identifier, denoted by $c_{id} = g^{\frac{sk_{\mathcal{X}}+id_{\mathcal{U}}}{1}}$.

3) **Semi-Homomorphic Encryption Scheme:** An encryption scheme (gen, enc, dec) is said to be homomorphic, if it has an efficient operation $\odot$ on ciphertexts such that, if for $(pk, sk) \stackrel{\$}{\leftarrow} \text{gen}(1^{\tau})$, $C_1 = \text{enc}(pk, m_1)$ and $C_2 = \text{enc}(pk, m_2)$, then $C_1 \odot C_2 = \text{enc}(pk, m_1 \cdot m_2)$.

ElGamal Encryption Scheme — is homomorphic, chosen plaintext secure (CPA) under a group $(\mathbb{G}, g, p)$ such as:

* HE.gen(1^τ) – it takes as input the security parameter τ, selects at random x ∈ Z_p, computes y ← g^x and outputs (sk, pk) = (x, y).

* HE.enc(pk, m) - it takes as input a message m ∈ G and the public key pk, selects at random r ∈ Z_p and outputs C = (C_1, C_2) = (pk^r, g^r m).

* HE.dec(sk, C) - it takes as input the ciphertext C and the secret key sk. It outputs m $\leftarrow C_2 \cdot C_1^{-1/\text{sk}}$.

4) Re-randomizable Public Keys: In [16], Waters et al. introduced the notion of incomparable keys for receiver anonymity. The holder of a secret key must be able to generate a large number of public encryption keys such that any message encrypted with any of these public keys can be decrypted by one secret key. Public keys must have the property that they cannot be tested for equivalence without access to the corresponding secret key(s). Waters et al. consider that derivation of several incomparable public keys based on the knowledge of a secret key, instead of a re-randomization based on the unique knowledge of the public key. Recently, Camenish et al. proposed a re-randomizable public key scheme, based on ElGamal instantiation, called R-ElGamal, defined as:

* rkgen(1^τ) – it takes as input the security parameter τ, selects at random x ∈ Z_p and r ∈ Z_p, and computes y_1 ← g^x r and y_2 ← g^x. It outputs (sk, pk) = (x, (y_1, y_2)).

* rand(pk) - it takes as input the public key pk, selects at random r' ∈ Z_p and outputs (spk', ← (y_1^{r'}, y_2^{r'})).

* renc(pk, m) - it takes as input a message m ∈ G and the public key pk, selects at random r ∈ Z_p and outputs

$$
C = (C_1, C_2) = (y_1^r, y_2^r m).
$$

* rdec(sk, C) – it takes as input the ciphertext C and the secret key sk. It outputs m $\leftarrow C_2 \cdot C_1^{-1/\text{sk}}$.

5) Multi-Level Attribute based Encryption: A multi-level encryption scheme based on attribute based mechanisms ensures a selective access to data based on users' granted privileges. Practically, when a party encrypts a data file, she specifies an access structure and a certain number of security levels. Thus, a user is able to decrypt a sub-set of data blocks related to a security level k if that user's private keys satisfy the sub-set of attributes related to the k-security level [13]. Note that that several elementary functions may be used for several encryption sessions (i.e., computation of polynomials and encryption of leaves' nodes). As such, only a few number of exponentiations and multiplication is required by each user. In addition, the decryption process may be partially delegated to a semi-trusted entity, for better performances [17]

D. BDUA Procedures

Our BDUA scheme relies on five different procedures, namely: system initialization, pseudonym generation, pseudonym conversion, granted privileges update, user and authorities' audit, that are detailed hereafter.

1) **System Initialization:** During this phase, the convertor $\mathcal{X}$ and the set of related servers $\mathbb{S}$ generate their respective keys, such that each convertor $\mathcal{X}$ derives a pair of public and private keys $(pk_{\mathcal{X}}, sk_{\mathcal{X}})$, as well as a secret $x_{S_i}$ associated to each server $S_i$, where $i \in [1, |\mathbb{S}|]$. Similarly, each user $\mathcal{U}$ and server $S_i$ {$i \in [1, |\mathbb{S}|]$} generate a pair of private and public keys defined as $(pk_{\mathcal{U}}, sk_{\mathcal{U}})$ and $(pk_{S_i}, sk_{S_i})$ respectively.

Remark 1: consistency of exchanged messages— BDUA relies on exchanging enciphered messages between the participating entities. Hence, for the sake of better security guarantees, BDUA may encompass non-interactive zero-knowledge proofs of knowledge (PoK) of encrypted messages [1]. That is, each encrypted message has to be followed by a PoK, such as the receiving entity may check the consistency of the received encrypted message.

2) Pseudonym Generation: The pseudonym generation process involves three entities: user $\mathcal{U}$, convertor $\mathcal{X}$ and corresponding server $\mathcal{S}$. They jointly and blindly compute a pseudonym $nym_{\mathcal{U},\mathcal{S}}$ for a user $\mathcal{U}$ holding a unique secret identifier $id_{\mathcal{U}}$. During this phase, $\mathcal{X}$ and $\mathcal{S}$ first agree on a pseudonym generation session identifier, defined as $sg_{id} = \{s\tilde{g}_{id}, \mathcal{X}, \mathcal{S}\}$, where $s\tilde{g}_{id}$ is a unique fresh random, $\mathcal{X}$ denotes the identity of the convertor and $\mathcal{S}$ represents the identity of the server.

The pseudonym generation is initiated by the user, relying on a OPRF$_{U,\mathcal{X}}$ function (cf. section IV-C2) based on the convertor's secret key $sk_{\mathcal{X}}$ and the user identifier $id_{\mathcal{U}}$ inputs, such that a core identifier $c_{id}$ is generated and only known to $\mathcal{U}$, as follows: $c_{id} = \text{OPRF}_{U,\mathcal{X}}(id_{\mathcal{U}}, sk_{\mathcal{X}})$.

The core identifier $c_{id}$ is blindly shared with the requesting $\mathcal{S}$, via $\mathcal{X}$. To do so, the user executes the following operations:
1) it relies on a homomorphic encryption (HE) mechanism as defined in section IV-C3, to partially encrypt, using the public key of the server $pk_S$, the generated core identifier $c_{id}$, as $n\tilde{\mathfrak{y}}_{U,S} = \text{HE enc}_{U}(pk_S, c_{id})$.

2) a fresh generated random $t_{U,S}$ is also generated and encrypted using the public key of the corresponding server $S$ and an asymmetric enc$_U$ algorithm, such that $\tilde{t}_{U,S} = \text{enc}_{U}(pk_S, t_{U,S})$.

3) $U$ relies on the attribute based encryption (ABE) scheme to encipher the permitted operations on shared data with $S$, denoted by $AR_{U,S}$, w.r.t. an access structure $\Gamma$ such that only a set of auditors are allowed to decrypt the enciphered contents, such that $\tilde{AR}_{U,S} = \text{ABE enc}_{U}(\Gamma, AR_{U,S})$.

Afterwards, the tuple $(n\tilde{\mathfrak{y}}_{U,S}, \tilde{t}_{U,S}, \tilde{AR}_{U,S})$ is sent to the convertor for further processing. That is, $\mathcal{X}$ homomorphically encrypts $1_{\mathbb{G}}$ using the public key of the corresponding server $S$ and raises the resulting encrypted pseudonym $n\tilde{\mathfrak{y}}'_{U,S}$ with a secret associated to the server $x_S$, such that:

$$n\tilde{\mathfrak{y}}'_{U,S} = [n\tilde{\mathfrak{y}}_{U,S} \odot \text{HE enc}_{\mathcal{X}}(pk_S, 1_{\mathbb{G}})]^{x_S}$$

Then, both $n\tilde{\mathfrak{y}}'_{U,S}$ and $\tilde{t}_{U,S}$ are transferred to the server $S$. This latter can then decrypt $(n\tilde{\mathfrak{y}}'_{U,S}, \tilde{t}_{U,S})$ to retrieve the user pseudonym $nym_{U,S}$ and the related auditing tag $t_{U,S}$, as follows: $t_{U,S} = \text{dec}_{S}(sk_S, \tilde{t}_{U,S})$ and

$$nym_{U,S} = \text{HE.dec}_{S}(sk_S, n\tilde{\mathfrak{y}}'_{U,S}) = c_{id}^{x_S}$$

Note that $S$ may store a different pseudonym for each user in its database, for better security guarantees. This process is then registered in the blockchain by $\mathcal{X}$ in the form of a pseudonym generation transaction which is defined as: $TG_{\mathcal{X}} = (id_{TG_{\mathcal{X}}}, sg_{id}, \tilde{AR}_{U,S}, \sigma_{\mathcal{X}})$, where:

* $id_{TG_{\mathcal{X}}}$ – denotes the transaction identifier associated with the pseudonym generation process.

* $sg_{id}$ – represents the pseudonym generation session identifier, previously generated as $sg_{id} = \{s\tilde{q}_{id}, \mathcal{X}, S\}$.

* $\tilde{AR}_{U,S}$ – denotes the encryption of the access rights, relying on the ABE scheme, where only a set of auditors are allowed to decrypt permitted actions $AR_{U,S}$ over the shared data.

* $\sigma_{\mathcal{X}}$ – is the signature of the convertor over all the transaction fields using his secret key $sk_{\mathcal{X}}$.

Note that the transaction identifier $id_{TG_{\mathcal{X}}}$ is then shared with the server $S$ and the corresponding user $U$.

3) Pseudonym Conversion: This phase starts when a server $S_A$ requests data of user $U$, from a server $S_B$, via $\mathcal{X}$. It relies on two sub-phases, namely: pseudonym conversion request and pseudonym conversion response. Each conversion session is associated a conversion session identifier, referred to as $sq_{id}$. It is defined as $sq_{id} = \{s\tilde{q}_{id}, \mathcal{X}, S_A, S_B\}$, where $s\tilde{q}_{id}$ is a unique fresh random, $\mathcal{X}$ denotes the identity of the convertor and $\{S_A, S_B\}$ represents the identities of involved servers.

During the pseudonym conversion request, the requesting server $S_A$ asks the convertor(s) $\mathcal{X}$ for converting the encrypted pseudonym $nym_{U,S_A}$ towards the pseudonym $nym_{U,S_B}$, associated with the server $S_B$. Thus, $S_A$ encrypts the inner pseudonym of the user using the public key of $S_B$ such as:

$$n\tilde{\mathfrak{y}}_{U,S_B} = \text{HE.enc}_{S_A}(pk_{S_B}, nym_{U,S_A})$$

Then, $S_A$ generates a new fresh tag $t^{(AP)}_{U,S_A}$ related to the actual data processing denoted by $(AP)$ and encrypts it using the public key of the user $pk^{(AP)}_{U}$ known by $S_A$ such as:

$$t^{(\tilde{AP})}_{U,S_A} = \text{renc}_{S_A}(pk^{(AP)}_{U}, t^{(AP)}_{U,S_A})$$

where $pk^{(AP)}_{U} = \text{rand}_{S_A}(pk^{(PP)}_{U})$ is the newly randomized public key of the user based on the previous public key $pk^{(PP)}_{U}$ known and used by $S_A$ for enciphering the relevant session tag during the previous data user processing (PP). The randomization process is presented in section IV-C4. This chaining process enables the user to check himself the consistency of his data usage (cf. section IV-D5). Then, $S_A$ sends the couple $(n\tilde{\mathfrak{y}}_{U,S_B}, t^{(PP)}_{U,S_A})$ to the convertor to attain the conversion process with $S_B$, where $t^{(PP)}_{U,S_A}$ corresponds to the relevant session tag, generated by $S_A$ during the previous data user processing (PP). The very first $t^{(PP)}_{U,S_A}$ is the one provided by $U$ during the pseudonym generation.

Afterwards, the pseudonym conversion response sub-phase starts between the convertor $\mathcal{X}$ and $S_B$ to complete the conversion. First, $\mathcal{X}$ uses the homomorphic property of the encryption mechanism and encrypts $1_{\mathbb{G}}$ using the public key $pk_{S_B}$, such as it raises the encrypted pseudonym to the quotient of servers' secrets $\frac{x_{S_B}}{x_{S_A}}$, such that:

$$n\tilde{\mathfrak{y}}'_{U,S_B} = [n\tilde{\mathfrak{y}}_{U,S_B} \odot \text{HE.enc}_{\mathcal{X}}(pk_{S_B}, 1_{\mathbb{G}})]^{\frac{x_{S_B}}{x_{S_A}}}$$

Once received, $S_B$ can then decrypt the received encrypted pseudonym and retrieves $nym_{U,S_B}$ as stored in its database. If the data request is accepted by $S_B$, this latter similarly sends the tag $t^{(PP)}_{U,S_B}$ corresponding to the random tag, generated by $S_B$, during the previous data user processing (PP).

Three transactions are then added to the blockchain by each participating entity of the conversion process. That is, the convertor adds a conversion transaction defined as $TC_{\mathcal{X}} = (id_{TC_{\mathcal{X}}}, sq_{id}, id_{DU}, (t^{(PP)}_{U,S_A}, t^{(PP)}_{U,S_B}), \sigma_{\mathcal{X}})$, where:

* $id_{TC_{\mathcal{X}}}$ – denotes the transaction identifier associated with the conversion process.

* $sq_{id}$ – represents the generated conversion session identifier known as $sq_{id} = \{s\tilde{q}_{id}, \mathcal{X}, S_A, S_B\}$.

* $id_{DU}$ – is the data usage identifier, specified by $S_A$, when requesting the pseudonym conversion. The $id_{DU}$ identifier may refer to data request, data transfer and so on.

* $(t^{(PP)}_{U,S_A}, t^{(PP)}_{U,S_B})$ – denotes latest conversion processing tags on data user $U$, received respectively from $S_A$ and $S_B$.

* $\sigma_{\mathcal{X}}$ – is the signature of the convertor, using his secret key $sk_{\mathcal{X}}$, over all the transaction fields.

Once added to the blockchain, the convertor shares the conversion transaction identifier, $id_{TC_{\mathcal{X}}}$ with both $S_A$ and $S_B$.
Afterwards, a conversion request and a conversion response transactions are added by $S_A$ and $S_B$ respectively, defined as: $TC_{S_i} = (id_{TC_{S_i}}, sq_{id}, t^{(PP)}_{U,S_i}, t^{(\tilde{AP})}_{U,S_i}, \tilde{M}_{S_i}, \sigma_{S_i})$, where $S_i \in \{S_A, S_B\}$ and:

* $id_{TC_{S_i}}$ – denotes the transaction identifier, added by $S_i$ and associated with the conversion process.

* $sq_{id}$ – represents the conversion session identifier where $sq_{id} = \{s\tilde{q}_{id}, \mathcal{X}, S_A, S_B\}$.

* $t^{(PP)}_{U,S_i}$ – denotes the identifier of the previous data processing tag over the user data, executed by $S_i$.

* $t^{(\tilde{AP})}_{U,S_i}$ – denotes the re-encryption of the new generated identifier using a randomized key of the user, as detailed in section IV-C4.

* $\tilde{M}_{S_i}$ – represents the encryption of a message $M_{S_i}$, using an attribute based encryption mechanism, such as $\tilde{M}_{S_i} = \text{ABE.enc}_{S_i}(\Gamma, M_{S_i})$, where $M_{S_i}$ is defined as $M_{S_i} = id_{TC_{\chi}} || id_{TG_{\chi}} || id_{PT_{S_i}}$, where $id_{TC_{\chi}}$ is the pseudonym conversion transaction identifier, $id_{TG_{\chi}}$ is the pseudonym generation transaction identifier and $id_{PT_{S_i}}$ is the previous transaction identifier identifying the previous $id_{TC_{S_i}}$ relative to the same user data and added by $S_i$. Note that $id_{TG_{\chi}}$ enables auditing authorities to retrieve the granted privileges $AR$ and to check the compliance of server $S_i$ when processing collected user data.

* $\sigma_{S_i}$ – is the signature of the server over all the transaction fields using his secret key $sk_{S_i}$.

**Remark 2: multi-level encryption of data usage transaction's history**— Note that servers $S_A$ and $S_B$ may rely on a multi-level ABE scheme (cf. section IV-C5), to encrypt their messages $M_{S_A}$ and $M_{S_B}$ respectively. That is, depending on their associated credentials (i.e; certified attributes), authorized authorities can access to a sub-set of the encrypted message $M_{S_i}$ defined as $M_{S_i} = id_{TC_{\chi}} || id_{TG_{\chi}} || id_{PT_{S_i}}$. For instance, the authorized auditor $\mathcal{E}$ may be allowed to only check the consistency of the actual transaction. Hence, $\mathcal{E}$ deciphers the subset information $\{id_{TC_{\chi}}, id_{TG_{\chi}}\}$, such that he can verify the transaction by $S$ making use of user data comply with the permissions $AR$ to transfer or request user data, with no need to verify the whole history of operations.

4) **Granted Privileges' Update:** When $\mathcal{U}$ wants to change the granted privileges associated to a server $S$, he has to send the updated $\tilde{AR}_{U,S}^{(up)}$ such as $\tilde{AR}_{U,S}^{(up)} = \text{ABE.enc}_{\mathcal{U}}(AR^{(up)}_{U,S} || id_{TG_{\chi}})$ to the convertor $\mathcal{X}$. This latter has then to inform the associated server $S$ and a new granted privilege transaction is added to the blockchain, as follows: $TU_{\mathcal{X}} = (id_{TU_{\mathcal{X}}}, su_{id}, \tilde{AR}_{U,S}^{(up)}, \sigma_{\mathcal{X}})$, where $id_{TU_{\mathcal{X}}}$ is the transaction update identifier, $su_{id}$ is the session identifier, $\tilde{AR}_{U,S}^{(up)}$ is the encryption of updated access privileges $AR^{(up)}_{U,S}$ associated with the pseudonym generation transaction identifier and $\sigma_{\mathcal{X}}$ is the signature of the convertor.

When a server $S_A$ requests a pseudonym conversion (respectively responds), it similarly adds a pseudonym

conversion transaction, where

$$TC_{S_A} = (id_{TC_{S_A}}, su_{id}, t^{(PP)}_{U,S_A}, t^{(\tilde{AP})}_{U,S_A}, \tilde{M}_{S_A}, \sigma_{S_A})$$

where $\tilde{M}_{S_A}$ is the encryption based on an ABE scheme of the message $M_{S_A}$ defined as $M_{S_A} = id_{TC_{\chi}} || id_{TU_{\chi}} || id_{PT_{S_A}}$.

5) **User and Authorities Audit:** The auditing process can be performed either by the data user $\mathcal{U}$ or by an authorized auditing entities $\mathcal{D}$, with respect to their associated credentials.

The user audit process permits $\mathcal{U}$ to learn all the conversion requests and responses related to his pseudonym, as well as associated data usage. As such, the user starts from the shared tag $t_{U,S_A}$ and $id_{TG_{\chi}}$ shared with the server $S_A$, during the pseudonym generation phase. Hence, $\mathcal{U}$ can iteratively retrieve the chain of new tags that were generated by $S_A$ for every pseudonym conversion or response, as shown in Table II. The new tags are encrypted, relying on a re-randomizable key encryption scheme (cf. section IV-C4). For the sake of efficiency, the user may avoid checking the history of his pseudonym usage (based on the first shared tag with $S_A$). Instead, $\mathcal{U}$ may periodically verify the latest added transactions and finally save the latest deciphered tag, for further auditing.

<table><caption>TABLE II
CHAINING ASSOCIATED TO THE DATA PROCESSING OF $\mathcal{U}$ BY $S_A$</caption><tr><td>t<sup>t</sup><sub>U,S<sub>A</sub></sub></td><td>t<sup>t</sup><sub>U,S<sub>A</sub></sub> = rencc<sub>S<sub>A</sub></sub>(pk'<sub>U</sub>,t<sup>t</sup><sub>U,S<sub>A</sub></sub>)</td><td>where pk<sup>t</sup><sub>U</sub> = rand<sub>S<sub>A</sub></sub>(pk<sup>t</sup><sub>U</sub>)</td></tr><tr><td>t<sup>id</sup><sub>U,S<sub>A</sub></sub></td><td>t<sup>id</sup><sub>U,S<sub>A</sub></sub> = rencc<sub>S<sub>A</sub></sub>(pk''<sub>U</sub>,t''<sup>t</sup><sub>U,S<sub>A</sub></sub>)</td><td>where pk<sup>id</sup><sub>U</sub> = rand<sub>S<sub>A</sub></sub>(pk<sup>id</sup><sub>U</sub>)</td></tr><tr><td>...</td><td>...</td><td>...</td></tr><tr><td>t<sup>(n-1)</sup><sub>U,S<sub>A</sub></sub></td><td>t<sup>(n)</sup><sub>U,S<sub>A</sub></sub> = rencc<sub>S<sub>A</sub></sub>(pk<sup>(n)</sup><sub>U</sub>,t<sup>(n)</sup><sub>U,S<sub>A</sub></sub>)</td><td>where pk<sup>(n)</sup><sub>U</sub> = rand<sub>S<sub>A</sub></sub>(pk<sup>(n-1)</sup><sub>U</sub>)</td></tr></table>

The auditing process may be performed by a dedicated authority $\mathcal{D}$ w.r.t. its certified credentials, relying on a multi-level access scheme. That is, $\mathcal{D}$ has to verify the consistency of the transactions containing the audited server identity $S_A$:

* server's activities auditing — $\mathcal{D}$ is able to verify the consistency of the information included in the transactions added by $S_A$, while comparing for each conversion session, information included in the transactions added by the convertor and the corresponding server, namely, session identifiers $sq_{id}$, data usage identifier $id_{DU}$, ... Thus, in this sub-case, $\mathcal{D}$ checks the server's activities independently, relying on the decryption of $\tilde{M}_{S_A}$ defined as $\tilde{M}_{S_A} = id_{TC_{\chi}} || id_{TG_{\chi}} || id_{PT_{S_A}}$. As such, $\mathcal{D}$ can iteratively chain all the previous transactions based on $id_{PT_{S_A}}$ and verify the permissionned operations w.r.t. $id_{TG_{\chi}}$. Designed as a multi-level ABE algorithm, depending on his certified credentials, the auditor may be able to only decipher $id_{TC_{\chi}} || id_{TG_{\chi}}$. As such, he cannot retrieve the chain of activities w.r.t. each (yet anonymous) user.

* server's activities with respect to a specific data user auditing — similarly, the dedicated auditor $\mathcal{D}$ verifies the consistency of the information included in the transactions added by $S_A$, while comparing for each conversion session, the information included in the transactions added by $\mathcal{X}$ and $S_A$. Thus, in this auditing sub-case, $\mathcal{D}$ can check the server's activities with respect to each (yet anonymous) user, relying on the decryption of $\tilde{M}_{S_A}$
defined as $M_{S_A} = \|id_{TC_X}\|\|id_{TG_X}\|\|id_{PT_{S_A}}\|$.

If granted privileges associated with $S_A$ have been updated by $U$, then $D$ checks the server's activities, based on the decryption of $\tilde{M}_{S_A}$ defined as $M_{S_A} = \|id_{TC_X}\|\|id_{TU_X}\|\|id_{PT_{S_A}}\|$, where $id_{TU_X}$ is the identifier of an updated transaction defined as $TU_X = (id_{TU_X}, su_{id}, \tilde{AR}_{U,S}^{(up)}, \sigma_X)$, such that $\tilde{AR}_{U,S}^{(up)} = ABE.\text{enc}_U(AR^{(up)}_{U,S}\|id_{TG_X}\)$, thus referring to the pseudonym generation transaction. As such, $D$ can iteratively chain all the previous transactions based on $id_{PT_{S_A}}$ and verify whether operations are permitted w.r.t. $id_{TG_X}$ and $id_{TU_X}$. Designed as a multi-level ABE algorithm, depending on his certified credentials, $D$ is able to decipher the whole message. As such, he can iteratively retrieve the chain of activities w.r.t. each user.

Table III shows an example for the *BDUA* chaining process. That is, we consider three pseudonym generation processes, referred to as "AA", "BB" and "CC" associated with $S_C$, $S_B$ and $S_A$, w.r.t. "03", "02" and "01" sessions' identifiers and "0A", "0B" and "0C" shared user tags, respectively. In addition, Table III presents two pseudonyms conversion processes between $(S_B, S_A)$ and $(S_C, S_A)$ associated with "10" and "30" sessions' identifiers respectively.

<table><caption>TABLE III
EXAMPLE OF CHAINING PROCESS FOR DATA PROCESSING AUDITING</caption><tr><td>TC<sub>S<sub>C</sub></sub></td><td>"XX", "30", "0A", renc<sub>S<sub>C</sub></sub>(pk'<sub>U</sub>"1A"), ABE.\text{enc}<sub>S<sub>A</sub></sub>("XY"||"AA"||"OO")</td></tr><tr><td>TC<sub>S<sub>A</sub></sub></td><td>"YY", "30", "1C", renc<sub>S<sub>A</sub></sub>(pk'<sub>U</sub>"2C"), ABE.\text{enc}<sub>S<sub>A</sub></sub>("XY"||"CC"||"FF")</td></tr><tr><td>TC<sub>X</sub></td><td>"XY", "30", id<sub>PU</sub>, ("1C", "0A")</td></tr><tr><td>:</td><td>:</td></tr><tr><td>TC<sub>S<sub>B</sub></sub></td><td>"EE", "10", "0B", renc<sub>S<sub>B</sub></sub>(pk'<sub>U</sub>"1B"), ABE.\text{enc}<sub>S<sub>B</sub></sub>("EF"||"BB"||"JJ")</td></tr><tr><td>TC<sub>S<sub>A</sub></sub></td><td>"FF", "10", "0C", renc<sub>S<sub>A</sub></sub>(pk'<sub>U</sub>"1C"), ABE.\text{enc}<sub>S<sub>A</sub></sub>("EF"||"CC"||"DD")</td></tr><tr><td>TC<sub>X</sub></td><td>"EF", "10", id<sub>PU</sub>, ("0C", "0B")</td></tr><tr><td>:</td><td>:</td></tr><tr><td>TG<sub>X</sub></td><td>"AA", "03", AR<sub>U,S<sub>C</sub></sub></td></tr><tr><td>TG<sub>X</sub></td><td>"BB", "02", AR<sub>U,S<sub>B</sub></sub></td></tr><tr><td>TG<sub>X</sub></td><td>"CC", "01", AR<sub>U,S<sub>A</sub></sub></td></tr></table>

where $pk'_{U}$ is a different randomized user key (cf. Table II) such as $pk'_{U} = \text{rand}_{S_i}(pk_{U})$ and $S_i \in \{S_A, S_B, S_C\}$

## V. SECURITY ANALYSIS

This section presents the threat model and discusses the resistance of *BDUA* against unlinkability, auditability and availability attacks. Then, it gives a brief performances analysis.

### A. Security Model

To design *BDUA*, we consider two different adversaries: the convertor can be corrupted in a passive fashion, thus called *honest but curious*. That is, when corrupted, the adversary sees all the convertor's inputs and outputs and internal state, but the convertor behaviour remains honest. For servers and users, we consider active corruptions by the adversary, referred to as *malicious servers or users*, i.e; upon corruption the active adversary is in full control over the servers' or users' behaviour. Consequently, both attackers are able to read transactions addressed to BC, but only malicious adversaries try to include false information to registered transactions and drop correct ones. In the sequel, we consider a mixed adversarial

setting that can actively corrupt servers and users but only gain passive control over the convertor, such that:

(i) by exploiting protocol messages, namely enciphered information, the convertor's secret key $sk_X$, secret keys associated with servers, a curious $X$ tries to trace or identify users. Similarly, malicious servers may rely on BC's transactions to identify the processing associated to specific data user.

(ii) based on previous data usage sessions, as well as provided BC data, an attacker tries to impersonate a user to afford some extra rights. Thus, a malicious server could use arbitrary combination of pseudonyms, public keys and tags via $X$.

(iii) a malicious server attempts to prevent the publication of a legitimate transaction in BC. For example, an attacker may try a DoS attack against a data usage event or attempt a flooding attack on the blockchain with invalid data usage information.

### B. Security Discussion

In this section, we discuss the resistance of *BDUA* against the considered threat model, as detailed above.

*Unlinkability* — Beyond data secrecy guarantees, strongly related to the security of selected encryption schemes, the unlinkability property is ensured in *BDUA* thanks to:

* a randomized user key is generated for each conversion procedure – to address the trade-off between transparency and auditability features, *BDUA* relies on an iterative tag encrypted chaining process, as detailed in section IV-D5. Clearly, if the public key of the user $pk_U$ is static, this would immediately destroy our privacy features. As such, *BDUA* considers that each new generated tag have to be encrypted with a different user public key $pk_U$ based on ElGamal randomizable public key instantiation.

* different sessions' identifiers – session identifiers include the identities of involved parties as well as a unique fresh random. They have to be added to the set of transactions registered by each participating entity, namely servers and the convertor, thus creating an unlinkable yet controlled means for each pseudonym conversion procedure. As such, different sessions related to the same user cannot be linked. However, consistency of registered transactions may be detected by external readers of BC-transactions.

*Auditability* — *BDUA* ensures the auditibility feature, w.r.t. the integrity and access control requirements, as follows:

* tamper-proof architecture – all the blockchain-specific operations, like transaction anchoring activities, are considered as secure and non-corruptible, thus ensuring non-tamper proofs of data processing and managing events.

* transparent usage – *BDUA* relies on a BC infrastructure, that permits public access (i.e; read privilege) to registered transactions. Thus, it provides a transparent view over how data are processed.

* signed transactions – *BDUA* relies on signed transactions. Both pseudonyms generation and conversion procedures' transactions have to be signed by the involved parties. Signed transactions ensure that each activity is
accounted by the holder of the used private key. As such, the resistance of the chosen encryption and signature schemes against forgery attacks has a direct impact on the fulfillment of the auditability requirement.

* authorized access to enciphered auditing information – the auditing process relies on the security of the selected attribute based encryption scheme. As such, only entities satisfying the access policy set by the data owner may access to auditing information, based on transactions' identifiers chaining process, as detailed in section IV-D5.

**Availability** — As a highly decentralized infrastructure, the blockchain technology helps in terms of availability. It becomes possible to provide liveness guarantees of data usage. Thus, *BDUA* inherits the availability property from the Blockchain intrinsic features, relying on the replication of the whole chain on different independent nodes.

### C. Performance Discussion

Based on the instantiations detailed in section IV-C and the CP-ABE scheme introduced by Bethencourt et al. [18], Table IV details the amount of exponentiation, multiplication and pairing functions in the respective groups.

For more realistic performance results of our scheme, we

<table><caption>TABLE IV
PROCESSING COMPLEXITY *BDUA* PROCEDURES</caption><thead><tr><th>Generation</th><th>U</th><th>X</th><th>S<sub>A</sub></th></tr></thead><tbody><tr><td></td><td>γ<sub>O</sub> + 2γ<sub>M</sub> + 2(2 + γ<sub>F</sub>)γ<sub>E</sub></td><td>4γ<sub>E</sub> + 3γ<sub>M</sub></td><td>2γ<sub>E</sub> + 2γ<sub>M</sub></td></tr><tr><th>Conversion</th><th>S<sub>A</sub></th><th>X</th><th>S<sub>B</sub></th></tr><tr><td></td><td>3γ<sub>M</sub> + 2(4 + γ<sub>F</sub>)γ<sub>E</sub></td><td>2γ<sub>E</sub></td><td>3γ<sub>M</sub> + 2(3 + γ<sub>F</sub>)γ<sub>E</sub></td></tr><tr><th>Audit</th><th>U</th><th>D</th><th>while considering</th></tr><tr><td></td><td>c(γ<sub>E</sub> + cγ<sub>M</sub>)</td><td>c(2γ<sub>P</sub> + γ<sub>E</sub> + γ<sub>M</sub>)Y<sub>T</sub></td><td>c BC transactions</td></tr></tbody></table>

where $γ_O$ denotes the cost of the OPRF function execution, $γ_E$, $γ_M$ and $γ_P$ denote the cost of the exponentiation, multiplication and pairing functions' processing cost and $Y_T$ is the number of attributes in the access policy $Γ$.

conducted some experiments, for several mathematical operations (i.e; exponentiation, multiplication and pairing functions) on an Intel E5-1650-v3 6 cores. Our measurements show that the computation of a symmetric pairing function requires approximately 6 ms, while exponentiations and multiplications take about 1.2 ms and 0.5 ms, respectively.

Referring to the cpabe toolkit<fnref n="4" /> proposed in [18], the computation costs of the key generation, encryption and decryption algorithms are mainly depending on the number of attributes. The cpabe toolkit provides a set of programs implementing CP-ABE schemes, using the PBC library<fnref n="5" /> for the algebraic operations. The code is split into two packages, libbswabe (i.e; a library implementing the core cryptographic operations) and cpabe (i.e; higher level functions and user interface). In addition, as stated above, based on the cpabe toolkit, the encryption algorithm takes about 1.5 second based on an access tree containing around 60 attributes [18].

## VI. CONCLUSION

Personal data are highly exposed to data leakage and misuse by third parties. As such, there is strong interest for users to get

full control on their personal data usage without compromising their privacy or limiting authorities' ability for auditing activities. This paper proposes a new blockchain-based solution for data usage auditing that does not require a fully trusted auditor or convertor, thus answering an open question from [2]. The convertor blindly derives and converts unlinkable pseudonyms approved by involved parties for each *BDUA* procedure. Based on a blockchain infrastructure, *BDUA* enables the user to grant consent to service providers, specify their data access policy and track data usage flows in a trusted and privacy-preserving manner. Second, it provides a regulatory framework to properly enforce the legislation. Third, the deployment of a blockchain infrastructure helps in resolving availability concerns as blockchain transactions are replicated a large number of times on independent nodes.

## REFERENCES

[1] J. Camenisch and A. Lehmann, "(un) linkable pseudonyms for governmental databases," in *Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security*. ACM, 2015.

[2] —, "Privacy-preserving user-auditable pseudonym systems," in *IEEE European Symposium on Security and Privacy (EuroS&P)*. IEEE, 2017.

[3] Regulation(EU), "2016/679 of the european parliament and of the council of 27 april 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing directive 95/46/ec," 2016.

[4] M. Swan, *Blockchain: Blueprint for a new economy*. O'Reilly Media, Inc., 2015.

[5] L. Linn and M. Koo, "Blockchain for health data and its potential use in health it and health care related research," 2016.

[6] A. Fu, S. Yu, Y. Zhang, H. Wang, and C. Huang, "Npp: A new privacy-aware public auditing scheme for cloud data sharing with group users," *IEEE Transactions on Big Data*, 2017.

[7] G. Zyskind, O. Nathan, and A. Pantland, "Decentralizing privacy: Using blockchain to protect personal data," in *IEEE Security and Privacy Workshops (SPW)*. IEEE, 2015, pp. 180–184.

[8] N. Kaaniche and M. Laurent, "A blockchain-based data usage auditing architecture with enhanced privacy and availability," in *NCA 2017: 16th IEEE International Symposium on Network Computing and Applications*. IEEE Computer Society, 2017, pp. 1–5.

[9] R. Neisse, G. Steri, and I. Nai-Fovino, "A blockchain-based approach for data accountability and provenance tracking," *arXiv preprint arXiv:1706.04507*, 2017.

[10] K. Wouters, K. Simoens, D. Lathouwers, and B. Preneel, "Secure and privacy-friendly logging for egovernment services," in *Availability, Reliability and Security, 2008. ARES 08. Third International Conference on*. IEEE, 2008, pp. 1091–1096.

[11] T. Pulls, R. Peeters, and K. Wouters, "Distributed privacy-preserving transparency logging," in *Proceedings of the 12th ACM workshop on Workshop on privacy in the electronic society*. ACM, 2013, pp. 83–94.

[12] D. Galindo and E. R. Verheul, "Microdata sharing via pseudonymization," *Joint UNECE/Eurostat work session on statistical data confidentiality*, 2007.

[13] N. Kaaniche and M. Laurent, "Attribute based encryption for multi-level access control policies," in *SECRYPT 2017: 14th International Conference on Security and Cryptography*. Scitepress, 2017.

[14] S. Jarecki and X. Liu, "Efficient oblivious pseudorandom function with applications to adaptive ot and secure computation of set intersection." in *TCC*, vol. 5444. Springer, 2009, pp. 577–594.

[15] Y. Dodis and A. Yampolskiy, "A verifiable random function with short proofs and keys." in *Public Key Cryptography*. Springer, 2005.

[16] B. R. Waters, E. W. Felten, and A. Sahai, "Receiver anonymity via incomparable public keys," in *Proceedings of the 10th ACM conference on Computer and communications security*. ACM, 2003, pp. 112–121.

[17] S. Belguith, N. Kaaniche, M. Laurent, A. Jemai, and R. Attia, "Phoabe: Securely outsourcing multi-authority attribute based encryption with policy hidden for cloud assisted ot," *Computer Networks*, 2018.

[18] J. Bethencourt, A. Sahai, and B. Waters, "Ciphertext-policy attribute-based encryption," in *IEEE Symposium on Security and Privacy*, 2007.

<footnote n="4">⁴http://acsc.cs.utexas.edu/cpabe/index.html</footnote>

<footnote n="5">⁵https://crypto.stanford.edu/pbc/</footnote>