Stefan Contiu
email: stefan.contiu@scille.fr

Emmanuel Leblond
email: emmanuel.leblond@scille.fr

Laurent Réveillère
email: laurent.reveillere@u-bordeaux.fr

Benchmarking Cryptographic Schemes for Securing Public Cloud Storages (Practical Experience Report)

Keywords: cloud storage, security, block cipher modes, digital signatures

Much research has focused during the last years on the security and privacy concerns of public cloud storages. Cryptographic primitives are commonly used to ensure user data confidentiality, authenticity and integrity. Confidentiality has been addressed by the use of symmetric-key encryption algorithms, while integrity and authenticity have been achieved by using message authentication codes, secure hashes or digital signatures. The choice of a specific configuration for securing an untrusted cloud storage highly depends on the expected security level, the size and type of data to store and the access pattern to these data. In this work, we are interested in overcoming the lack of comprehensive comparison of the costs and effectiveness of cryptographic primitives for securing public cloud storage, and ease an informed choice between them based on target usage conditions. We describe the results of an independent experimental study of six cryptographic schemes, representative of the principal design alternatives. Our practical experience report reveals that the best scheme for a given situation, such as a write-heavy workload of mostly small files, is not necessarily the most appropriate for a different situation such as a read-only workload of large files. We identify the scheme characteristics that are correlated with these differences and discuss the pros and cons of each design. Our experimental framework and results are available in the open for use by the community.

Introduction

Public clouds storage services such as Dropbox or Google Drive provide a convenient way for users to store and share personal data. As a result, we have witnessed a rapid adoption of these services in recent years [START_REF] Seybert | Internet and cloud services-statistics on the use by individuals[END_REF]. Indeed, the cloud storage market is forecasted to grow from about $24 billion in 2016 to about $75 billion in 2021 [1]. However, despite its success, public cloud storage space is commonly assumed to be entirely untrusted, providing no guarantees over unauthorized exposure of user sensitive data. Therefore, it is not surprising that security and privacy issues in that context has gained increasing momentum within research community [START_REF] Zhou | Security and privacy in cloud computing: A survey[END_REF].

A traditional approach to ensure user data confidentiality, authenticity and integrity is the use cryptographic primitives. Confidentiality is addressed by the use of symmetric-key encryption algorithms, while authenticity and integrity are achieved by using message authentication codes, secure hashes or digital signatures. Cryptographic schemes are then constructed by selecting among these primitives depending on the expected level of security and privacy.

Among existing solutions, different configurations have been explored. For example, CloudProof [START_REF] Popa | Enabling security in cloud storage SLAs with CloudProof[END_REF] relies on AES in CTR mode for symmetric-key encryption, SHA-1 for hashing and RSA with 1024 bits key for signing. DepSky [START_REF] Bessani | DepSky: Dependable and secure storage in a cloud-of-clouds[END_REF] uses similar cryptographic schemes except that it relies on AES in CBC mode instead of CTR. BlueSky [START_REF] Vrable | BlueSky: A cloud-backed file system for the enterprise[END_REF] relies on AES for encryption and uses a message authentication code based on SHA-256 to provide both authenticity and integrity. In SafeSky [START_REF] Zhao | SafeSky: A secure cloud storage middleware for end-user applications[END_REF] the encryption and authentication are combined by using AES in CCM mode.

Although widely used for general purpose usage, there exists very few studies comparing the costs and effectiveness of cryptographic primitives for securing public cloud storage. In this practical experience report, we are interested in overcoming this lack of a comprehensive comparison between them. We argue that the choice of a specific cryptographic construction has a direct impact on the performance and scalability of the secured cloud storage system, thus requiring a sound knowledge of its intrinsic properties. We consider different usage conditions such as various data size models and cloud workload scenarios and describe the results of an independent experimental study of six cryptographic schemes, representative of the principal design alternatives. We consider three different block cipher modes for AES encryption: chaining mode (CBC), counter mode (CTR), and an authenticated encryption mode that also covers integrity (GCM). For the public-key signature primitives, we evaluate the usage of cryptosystems based on RSA and Elliptic Curve Cryptography (ECC).

In our experiments, we perform both a set of micro-benchmarks and macrobenchmarks. Micro-benchmarks measure the intrinsic performance of a cryptographic primitive when varying the size of the cryptographic key. Macrobenchmarks assess how cryptographic primitives perform when a user interacts with a secured public cloud. We perform read and write operations on three large data sets modeled by considering different block sizes: uniform sizes, mostly small sizes, and mostly large sizes. The interaction between the user and the cloud is modeled based on four cloud workloads inspired from Yahoo! Cloud Serving Benchmark (YCSB) [START_REF] Cooper | Benchmarking cloud serving systems with YCSB[END_REF]. The workloads mimic mostly-write, write-heavy, readheavy, and read-only operations.

The contributions of our performance comparison study aim at helping practitioners to decide which is the most appropriate cryptographic scheme for a target security level under certain usage conditions. Firstly, our results show that there is no one-size-fits-all to security in public cloud storage. Secondly, we identify which are the schemes that better match the studied usage scenarios. Although AES in CBC in conjunction with RSA is the preferred cryptographic scheme in the literature [START_REF] Bessani | DepSky: Dependable and secure storage in a cloud-of-clouds[END_REF][START_REF] Vrable | BlueSky: A cloud-backed file system for the enterprise[END_REF][START_REF] Burihabwa | On the cost of safe storage for public clouds: an experimental evaluation[END_REF], we show that other algorithms can out-perform it by a factor of 10 under specific conditions. These findings can further be used to design a cryptographic approach that changes its behavior at runtime based on contextual information.

The rest of this paper is organized as follows. Section 2 presents the cryptographic primitives we evaluate in our experiments. We describe our experimental setup in Section 3. Section 4 presents our evaluation results and discusses the pros and cons of each cryptographic scheme with respect to target usage conditions. Section 5 reviews related work. Finally, Section 6 concludes.

Cryptographic Building Blocks

Various cryptographic primitives are used together for ensuring confidentiality, authenticity, and integrity of user data stored in public clouds. As illustrated in Figure 1, securing data for public cloud storage is commonly a three step process. First, the data bock is encrypted using symmetric-key algorithm (step ). Second, a fixed size message digest is produced by using a one-way collision resistant function (step ) on the input data block. Third, a digital signature algorithm is used to prove the authenticity of the message digest with respect to the user private key (step ). In the remainder of this section, we describe in more details each step and related cryptographic algorithms.

Symmetric-key Algorithms

A symmetric-key algorithm provides data confidentiality by the use of the same secret key for both encrypting and decrypting the data. Among existing algorithms, the one specified by the AES specification has become the de facto standard and is used worldwide [START_REF] Chown | Advanced encryption standard (AES) ciphersuites for transport layer security[END_REF]. It is a block cipher algorithm, operating on fixed-length group of 128 bits called a block with a key size of 128, 192 or 256 bits. To securely transform amounts of data larger than a block, the cipher's single-block operation needs to be repeatedly applied accordingly to a block cipher mode. Many modes of operation have been defined [START_REF] Ferguson | Practical cryptography[END_REF], each one offering a different level of performance and robustness. We now describe the three major modes that we cover in our study.

CBC. Cipher Block Chaining (CBC) works by chaining each block to its predecessor. At each step, the current block of plaintext is xor-ed with the ciphertext of the previous block, and then encrypted with the secret key. Since the first block has no predecessor, a random initialization vector is used instead. The initialization vector can then be publicly stored together with the ciphertext. Due to the chaining nature of this mode, the encryption is sequential and can not be parallelized. However, because each block is xor-ed with the ciphertext of the previous block, not the plaintext, decryption can be parallelized. Note that the reuse of the same initialization vector can leak information only about the first block.

CTR. Counter (CTR) mode generates keystream blocks, which are then xor-ed with the plaintext blocks to get the ciphertext. It generates the next keystream block by encrypting successive values of a counter. The counter can be any function which produces a sequence which is guaranteed not to repeat for a long time, although an actual increment-by-one counter is the simplest and most popular. A nonce is combined together with the counter to produce the actual unique counter block for encryption. Since counter values at different block offsets are known, this mode can be fully parallelized. However, reusing the same nonce can leak information about all blocks, making the implementation of CTR more sensitive than CBC. Nevertheless, this mode is proven to respect tight security requirements and is formally approved by NIST [START_REF] Dworkin | Recommendation for block cipher modes of operation. methods and techniques[END_REF].

GCM. Galois Counter Mode (GCM) is a block cipher mode that performs both encryption and authentication by combining counter mode and operations in a finite (Galois) field. GCM is defined for block ciphers with a block size of 128 bits. Implementing GCM can make efficient use of Carry-less Multiplication (CLMUL), an extension to the x86 instruction set used by microprocessors from Intel and AMD [START_REF] Gueron | Intel R carry-less multiplication instruction and its usage for computing the GCM mode[END_REF]. Similarly to CTR mode, GCM takes as input a nonce and thus reusing the same nonce with the same key leaks information about the whole message.

Message Digests

Message digests or simply hash functions are one-way collision resistant functions, mapping an input data block to a short fixed size output. The role of hash functions is to provide integrity guarantees over the data. Also, they are utilized as a preceding operation in digital signature schemes, reducing an arbitrarily large amount of data to a small output on which the signature is applied.

Hash functions work by splitting the data into fixed size blocks, and iteratively applying a compression function with an intermediate state [START_REF] Ferguson | Practical cryptography[END_REF]. Secure Hash Algorithms (SHA) are a class of secure hashes standardized by NIST in three family sets (SHA-1, SHA-2, and SHA-3). The first set has been proved insecure due to collision attacks [START_REF] Wang | Finding collisions in the full SHA-1[END_REF]. The second set is a popular choice, coming with 32 and 64 bits processing variants, and producing outputs of 256, 384, and 512 bits. Lastly, the third family SHA-3 was recently standardized by NIST, not as a replacement to the previous SHA-2, but as an alternative [START_REF]SHA3-Standard: Permutation-based hash and extendable-output functions[END_REF].

Digital Signatures

Digital signature algorithms are employed for proving the authenticity of a data block with respect to the user private key. Moreover, they provide the properties of non-repudiation and integrity, meaning that the signing user can not deny herself as the signer and that the data block content is not altered. The verification of the message and signature pair can be openly performed by anybody knowing the user public key.

RSA is a public key cryptosystem, based on the difficult mathematical problem of factoring the product of two arbitrarily large prime numbers. The key sizes employed by RSA require a much larger length as compared to symmetric encryption, because solving the mathematical problem is faster than a brute force attack iterating over all possible keys. Elliptic Curve Cryptography (ECC) is a relatively novel direction in public key cryptosystems [START_REF] Koblitz | Elliptic curve cryptosystems[END_REF], that besides a considerable interest from academia, has also been integrated within technical solutions like Bitcoin, SSH, and TLS [START_REF] Bos | Elliptic curve cryptography in practice[END_REF]. The advantage of ECC over the traditional RSA is the small nature of key sizes, implying an increase of computational speed. ECC is based on the difficult mathematical problem of discrete logarithm when the computations are performed over the points of an elliptic curve. The security of the ECC cryptosystem is highly correlated to the choice of the curve equation. Various curves have been proposed and formally reviewed, such as the ones standardized by NIST [START_REF] Kerry | Digital signature standard (DSS)[END_REF].

Cryptographic Strength of Key Sizes

The size of the cryptographic key is the principal factor affecting the performance and the security level of cryptographic primitives. Sufficiently large key sizes protect the cryptographic algorithms from brute force attacks on the key values. Therefore, the security strength of a cryptographic algorithm is upper-bounded by the size of the key used.

Table 1 lists three strength levels (Low, Medium, High) as specified by NIST [START_REF] Barker | Recommendation for key management part 1: General[END_REF]. The security strength level represents the upper bound protection

Experimental Cloud-Based Data Store

In order to easily and efficiently evaluate the wide spectrum of cryptographic schemes described previously, we designed and implemented an experimental testbed, consisting of a single client accessing data on a public cloud storage. We assume that only the client can be trusted and thus data must be encrypted prior transmission to the storage node. The client component performs the actual processing and transformation (e.g, encryption, hashing) of data blocks before they are stored, as well as the reverse decoding operation (e.g., decryption, digital signature). We describe in the remainder of this section the cryptographic schemes we used in our evaluation, the model of data and the cloud workloads.

Cryptographic Schemes

We constructed six cryptographic schemes (CBC-RSA, CTR-RSA, GCM-RSA, CBC-ECC, CTR-ECC, GCM-ECC) using the main primitives described in Section 2. The schemes are constructed by varying the block cipher mode (CBC, CTR, and GCM) for AES symmetric encryption, and the digital signature algorithm (RSA and ECC). Message digests are generated using the SHA-2 secure hash algorithm. For each scheme, we use three different cryptographic key sizes covering the security strength levels defined in Table 1. Each key is pre-generated before the experiments using a pseudo random generator.

Data Sets

Users use cloud storage services for data files of various types among them most popular ones are photos, documents, and music [START_REF] Seybert | Internet and cloud services-statistics on the use by individuals[END_REF]. Such files commonly have sizes from few hundreds of kilo bytes to several mega bytes. Smaller block sizes, of the magnitude of tens of kilo bytes, are specific for systems that perform deduplication [START_REF] Li | Cdstore: Toward reliable, secure, and cost-efficient cloud storage via convergent dispersal[END_REF] or for modeling the entire set of files on a user machine [START_REF] Tanenbaum | File size distribution on UNIX systems: then and now[END_REF].

On the other hand, larger block sizes such as 64 mega bytes are utilized by distributed file systems operating on fixed size chunks [START_REF] Ghemawat | The google file system[END_REF]. To cover this variety of file sizes, we defined three different data sets, as depicted in Table 2, by varying the probability distribution of sizes. The mostly-small data set follows a log normal distribution with a mean at 256 KB and contains a total of 0.5 GB of data. The mostly-large data set follows a reversed log normal distribution of files sizes for a total amount of 1.2 GB of data. The mixed-sizes data set follows a uniform distribution holding 3.1 GB of data. For all the three data sets the file sizes range from 1 KB to 64 MB.

Cloud Workloads

The ratio of read and write operations that a client performs over a cloud storage is specific to a given usage scenario. For example, when using the cloud storage to backup local files, the workload is governed by write operations. On the other hand, when sharing files such as photos with a large number of users, the workload is dominated by read operations.

To model the diversity of cloud workloads, we leverage on YCSB [START_REF] Cooper | Benchmarking cloud serving systems with YCSB[END_REF], a reference framework for benchmarking cloud storages. In addition to the three workloads defined by YCSB (write-heavy, read-heavy, read-only), we introduced a fourth one (mostly-write) composed of 5% or reads and 95% of write operations to mimic the behavior of backup scenarios. Table 3 lists the four workloads of our study and the corresponding ratios of read and write operations. The mostly-write workload performs a small number of reads (5%). The write-heavy workload consists of an even number of writes and reads. The two intensive read workloads, read-heavy and read-only, consider a small amount of writes (5%) and no writes respectively.

Implementation

Our implementation of the cryptographic schemes under evaluation relies on the open-source openssl3 (v1.1.1) library. This library is implemented in a mix of To test in isolation the raw performance of each cryptographic primitive, we have implemented a set of microbenchmarks in C. Our implementation uses rtdsc processor instruction to collect the number of cycles from the time stamp counter (TSC) register.

To evaluate the primitives in realistic settings, we have implemented a testbed in Python to facilitate the integration with the cryptography.io4 (v1.8) the reference Python binding for openssl.

The cloud storage implementation contains both a Dropbox interface and a locally simulated cloud provider as an in-memory key-value store. To prevent variations of real cloud access latencies interfering with the observed outcomes and to better isolate the performance of cryptographic primitives, we report the results when utilizing the simulated cloud storage. To mimic the behavior of a public cloud storage, we added a delay of 50ms to each request to simulate a realistic round-trip latency.

Results

This section presents our extensive evaluation of the previously described cryptographic schemes. We perform our experiments on a 4-Core Intel i7-6600U processor at 3.4 GHz with 16 GB of RAM, and operating on Ubuntu v16.04 LTS. We first test in isolation the cryptographic primitives via a set of microbenchmarks, and we finally evaluate the primitives in realistic settings.

Micro-benchmark

Our first set of experiments evaluate the intrinsic performance of cryptographic primitives for increasing security strength levels. In this scenario, the primitives are tested in isolation via a specialized client that sequentially perform an operation (e.g., encryption, signature) on block sizes from 512 KB to 64 MB. We repeatably execute 50 times each operation on randomly generated data and averaging the consumed CPU cycles. Our preliminary results confirm that the number of CPU cycles is always linear with respect to the size of the input data. In the remainder, we thus only show the average number of cycles per byte. Figure 2 presents our results for AES encryption and decryption. We notice that parallelizable operations have a considerable performance improvement compared to the non-parallelizable encryption in CBC mode. This large performance improvement by a factor of 4.5 for encryption is due to the pipelining technique supported by the AES-NI instruction set at the processor level. We also notice that the performance overhead increases almost linearly with the targeted security strength level. The cost of the SHA-2 hashing function is shown in Figure 3. The SHA-256 method, for a low security strength level, requires on average 6.4 cycles per byte. Hashing for stronger security strength levels always perform better with an improvement of about 33%. The reason is that the calculation is done on a larger length of data at a time. Performances of SHA-384 is comparable to SHA-512, confirming that it uses the same algorithm, but truncating the hash to a smaller output. As SHA-512 offers both the higher security strength and the best performance, we use it in our macrobenchmark. The performance results of digital signatures based on RSA and ECC are depicted in Figure 4. Both signing and verification operations work over the secured hash produced using a hashing function such as SHA-2. Therefore, the time does not depend on the size of the input data. We thus consider only the total number of cycles required to perform the operation. The cost of the signing operation using RSA drastically increases with the size of the key. For example, the performance cost increases up to 614 millions of cycles for the strongest security strength level (values are truncated to 10 millions in Figure 4a), more than 100 times the cost required for the lowest security level. On the other hand, elliptic curve signature is dramatically faster, providing a performance of 7, 58 and 153 times faster than RSA for equivalent key strengths. For the verification operation, contrary to singing, the performance of the two cryptosystems reverses. RSA performs better than Elliptic Curve, however the difference between the two is not at all as dramatic as in the case of signing.

Macrobenchmark

In this section we evaluate the cryptographic schemes in a more complex scenario that involves realistic data sets and cloud workloads, as described in Section 3. We measure the total time required by a client to perform all the read and write operations on the input data set. For each entry of the data set, we randomly select an operation (either read or write) to follow the probability distribution defined by the cloud workload. Figure 5 shows our results for the mostly-small test set. We can notice that RSA performs worse on mostly-write and write-heavy workloads when the security strength increases. On the other hand, read-heavy and read-only workloads do not present this trend as the verification process of the RSA signature is cheap. The CTR-ECC cryptographic scheme shows always a good performance independently of the cloud workload or the security strength.

The results of our experiments for mostly-large sizes are shown in Figure 6. Except for RSA that performs worse with mostly-write and write-heavy workloads, we observe that differences between cryptographic schemes reduce as read operations dominate more and more the workload. We notice that RSA outper- Similarly to mostly-large sizes, we observe for mixed-sizes (see Figure 7) that RSA performs worse with mostly-write and write-heavy workloads and that the gap between the different schemes tends to reduce as the number of read operation increases.

L

Discussion

Our results show that CTR-ECC performs better in almost all usage scenarios. This scheme should be preferred if there is no prior knowledge on the workloads or data sizes. However, we note that specific scenarios may require fine tuned schemes to maximize performances. Indeed, CTR-ECC performs better for mostly-writes and write-heavy workloads while CTR-RSA performs slightly better for readheavy and read-only workloads. Furthermore, for read-only workloads CTR-RSA can be safely replaced by CBC-RSA, as their performances are very similar within this context. If information about data sizes is available, then a CTRbased scheme performs better as the data sizes increase.

When security is not a constraint, CTR-ECC and CTR-RSA are interchangeable as best performers. Contrary, when strong security strength is required, schemes relying on RSA should be avoided as they may induce severe performance penalties.

Related work

Many previous work make use of cryptographic schemes for securing cloud storages. However, to the best of our knowledge, none of them report the result of a study to evaluate the rationale behind specific cryptographic choices. Some use of AES in CBC mode [START_REF] Bessani | DepSky: Dependable and secure storage in a cloud-of-clouds[END_REF] while others use the CTR mode [START_REF] Popa | Enabling security in cloud storage SLAs with CloudProof[END_REF]. Furthermore, some even omit to describe the cipher mode they rely on [START_REF] Kamara | Cryptographic cloud storage[END_REF][START_REF] Li | Cdstore: Toward reliable, secure, and cost-efficient cloud storage via convergent dispersal[END_REF]. Our benchmarking study shows that CTR outperforms CBC almost always and should be preferred. Moreover, we indicate that schemes using RSA for digital signatures [START_REF] Bessani | DepSky: Dependable and secure storage in a cloud-of-clouds[END_REF][START_REF] Popa | Enabling security in cloud storage SLAs with CloudProof[END_REF] are suitable only for corner cases characterized among others by read-heavy and read-only workloads, and that ECC outperforms RSA in most usage conditions.

The costs of confidentiality, integrity and authenticity have been evaluated by Burihabwa et al. [START_REF] Burihabwa | On the cost of safe storage for public clouds: an experimental evaluation[END_REF] within the cloud storage context. Besides a single cloud model, the study also considered the dispersal of confidential data over multiple storages by using erasure encoding. Although the study makes use of cryptographic primitives, there is no debate over different strength levels achieved by cryptographic keys, nor about the modeling of both the replayed test set and the read/write requests. Furthermore, the study makes use of AES in CBC mode coupled with RSA, a cryptographic scheme that, according to our findings, it is suitable only for read-only cloud workloads over mostly-small sizes.

A performance comparison study for digital signatures based on RSA and ECC has been addressed in a general context [START_REF] Jansma | Performance comparison of elliptic curve and rsa digital signatures[END_REF]. The authors propose the use of ECC for scenarios dominated by signing operations, while RSA have been proposed for scenarios dominated by verification operations. Similarly, the results of our study suggest the use of ECC for mostly-write and write-heavy workloads, and RSA for read-heavy and read-only workloads.

Conclusion

We have studied and compared, in this practical experience report, the performance of several cryptographic primitives that are widely used to implement security and privacy in public cloud storage. The objective of this experimental study was to compare the costs and effectiveness of cryptographic primitives for securing public cloud storage, and not to develop original schemes.

We conducted a wide range of experiments on six different cryptographic schemes both to measure their raw speed and their performance when used in a realistic cloud storage setup. Our observations notably highlight that the best scheme for a given situation, such as a write-heavy workload of mostly small files, is not necessarily the most appropriate for a different situation such as a read-only workload of large files.

We hope that our study will bring valuable insights and guidance to other researchers interested in using cryptography techniques for data storage in the cloud.

Availability. Our experimental framework and results are available in the open for use by the community at the following webpage: https://github. com/stefan-contiu/cloud-crypto-benchmark.

Fig. 1 :

 1 Fig. 1: Securing data for public cloud storage

Fig. 2 :

 2 Fig. 2: Performance of AES (cycles per byte)

Fig. 3 :

 3 Fig. 3: Performance of SHA-2 (cycles per byte)

Fig. 4 :

 4 Fig. 4: Performance of digital signature

Fig. 6 :

 6 Fig. 6: Total time for large file sizes

Fig. 7 :

 7 Fig. 7: Total time for uniform file sizes

Table 1 :

 1 Computational equivalence of key sizes (in bits).in bits for a brute force attack employed on the key values. The key sizes displayed within the same row are computationally equivalent with respect to the same security strength level. The strength for symmetric encryption is by design identical to the key size. RSA requires much larger key sizes up to 15,360 bits for a security strength of 256 bits, because solving the factorization problem is faster than a brute force attack on the key. Elliptic curve cryptography and secured hash methods require roughly the double in length.

	Security Strength	AES	RSA	ECC	SHA-2
	Low	128	128	3,072	256-383	256
	Medium 192	192	7,680	384-511	384
	High	256	256	15,360	≥ 512	512

Table 2 :

 2 Data sets.

Table 3 :

 3 Cloud workloads C and hand-written Assembly and can take advantage of hardware acceleration provided by AES-NI and CLMUL extension instruction sets.

		Reads	Writes
	mostly-write	5 %	95 %
	write-heavy	50 %	50 %
	read-heavy	95 %	5 %
	read-only	100 %	0 %

https://www.openssl.org/

https://cryptography.io/

Acknowledgment. This work was partially supported by Scille and DGA under contract RAPID-172906010.


Damiano Di

Francesco Maesa
email: damiano.difrancescomaesa@for.unipi.it

Paolo Mori
email: paolo.mori@iit.cnr.it

Laura Ricci
email: laura.ricci@unipi.it

Blockchain Based Access Control

Keywords: Bitcoin, blockchain, access control, xacml

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.

Introduction

Access Control systems are used in computer security to regulate the access to critical or valuable resources such as data, services, computational systems, storage space, and so on. The rights of subjects to access resources are typically expressed through access control policies, which are evaluated at access request time against the current access context. In Attribute-based Access Control (ABAC) [START_REF] Vincent | Guide to attribute based access control (abac) definition and considerations[END_REF], policies consist of a set of conditions over the attributes which describe the features of the subjects, resources, environment, etc., involved in the access request. Among the subject attributes there could be, for instance, his ID, the ID of the company he works for, his role in this company, the name of the projects assigned to him, his physical position, the number of resources he is currently using, and so on. Some scenarios require that access rights can be transferred from a subject to another for some reasons. For instance, a user could sell its access right to another user. Another example is the one where an employee of a company who was supposed to perform a given computation on a Virtual Machine delegates the execution of this task to another employee, who needs to access that same Virtual Machine.

Moreover, the evaluation of the access control policy in order to decide whether the requested access to a resource can be executed is performed by a party which is trusted by (the owner of) that resource, but it could be not trusted for the subject of the request who, instead, would like to to be guaranteed against unduly denial of access. For example, the Access Control system can run directly on a server of the owner of the resource. In fact, the party which actually evaluates the policy and enforces the result on the resource could maliciously force the system to deny the access to a subject although the policy would have granted it. Hence, in this scenario there is the need for the subjects to have a mean for verifying which policy has been enforced when they performed an access request which has been denied.

This paper proposes an approach based on blockchain technology to represent the right to access a resource and to allow the transfer of such right among users. The proposed approach is validated by a preliminary implementation exploiting the Bitcoin framework.

The paper is structured as follows: Section 2 presents a background on blockchain technology and Bitcoin as well as a survey of related works on the subject at hand, while Section 3 gives a brief overview of our proposed novel approach. In Section 4 we describe the architecture of the access control scheme proposed and Section 5 presents our real world implementation example. Finally, Section 6 discusses the conclusions and presents our future work.

Background and Related Work

A blockchain is a distributed, always available, irreversible, tamper resistant, replicated public repository of data. It allows trustless users to agree on an immutable and auditable piece of data without third party interaction. In other words, blockchain technology allows to build an append only secure database relying on a distributed consensus protocol to decide what valid new data to add in a distributed manner.

Historically blockchain technology was first introduced to support cryptocurrencies and, up to date, cryptocurrencies are still its main field of real practical application, even if several proposals in other fields are being studied. The first blockchain was used by the Bitcoin cryptocurrency protocol [START_REF] Nakamoto | Bitcoin: A peer-to-peer electronic cash system[END_REF] and today Bitcoin is still the most popular and widespread example of blockchain technology adoption. This is why we have decided to provide an implementation of this paper proposed approach on this particular protocol.

Bitcoin, as other cryptocurrencies, exploits the blockchain as a public ledger to store value exchanges called 'transactions'. This ledger is divided in blocks where each single block is a collection of non conflicting transactions. The linking between blocks is achieved by saving the hash of the header of the previous block in the header of the next block of the chain. To make each block header (and so its hash) dependent from all transactions contained in that block, the root of the (implicit) Merkle tree [START_REF] Merkle | A digital signature based on a conventional encryption function[END_REF], built from the block transactions hashes is included in the block header. Deciding which block to add to the ledger at each step is resolved by a distributed consensus algorithm called 'Nakamoto consensus' that relies on HashCash Proof-of-Works [START_REF] Dwork | Pricing via processing or combatting junk mail[END_REF].

From a data point of view, the Bitcoin blockchain can be seen simply as a list of transactions. Transactions are created to exchange funds between users, represented by their addresses. An address is a double hash (firstly SHA-256 [START_REF] Nist | Descriptions of sha-256[END_REF] is applied and then Ripemd-160 [START_REF] Preneel | The cryptographic hash function ripemd-160[END_REF]) of a public key derived from a ECDSA key pair [START_REF] Johnson | The elliptic curve digital signature algorithm (ecdsa)[END_REF]. Addresses (and hence public keys) are used by users to send and receive payments, while the corresponding private keys are used to provide proofs of ownership (through digital signatures). Creating new addresses is as cheap as creating new ECDSA key pairs, so each user can create and use multiple addresses. Moreover, users are incentivized to use different addresses since the pseudonymity given by addresses is the only (weak) anonymity protection in Bitcoin.

Since the entire state of the system is only defined by the list of transactions saved in the blockchain, transactions are the only mean to manage funds. Funds can be divided or aggregated only by being spent. Transactions are multi input and multi output, hence a transaction may withdraw funds from more than one address and can transfer funds to more than one output address. Furthermore each input is signed by the owner with the private key corresponding to the address spending the funds. A transaction can also specify a voluntary fee to cover the expenses of the validation process. This fee is meant as an incentive for users to take part in the consensus protocol mentioned previously. In a transaction, each output can be seen as a couple (amount, receiver address). Each input specifies, instead, where to withdraw the funds, i.e., the previous transaction (through its hash) where the funds were created. The Bitcoin protocol uses a not Turing complete stack based scripting language, and scripts are (mostly) used in transactions to specify conditions needed to redeem the funds of that transaction. It is beyond the scope of this paper to analyze in detail Bitcoin scripting language, we will only mention its features relevant to this work in Section 5. Finally we note that new transactions are created by any user and notified to the community with a gossip style broadcast message on the P2P Bitcoin network.

According to [START_REF] Pilkington | Blockchain Technology: Principles and Applications[END_REF] even if blockchain technology is mostly well known for applications in cryptocurrencies such as Bitcoin, it can be used outside of the monetary domain as well, for instance to trace the origin and transformation in a supply chain. [START_REF] Huckle | Internet of things, blockchain and shared economy applications[END_REF] shows how blockchain can be exploited to create decentralized, shared economy applications that allow people to monetize, securely, their things to create more wealth. [START_REF] Mainelli | Sharing ledgers for sharing economies: an exploration of mutual distributed ledgers (aka blockchain technology)[END_REF] observes that the ability to have a globally available, verifiable and untamperable source of data provides anyone wishing to provide trusted third party services the ability to do so cheaply and robustly.

Proposed Approach

In this paper we propose to use blockchain technology to represent the rights to access resources and to transfer them from one user to another. In particular, we propose to store the representation of the right to access a resource in a blockchain, allowing the management of such right through blockchain "transactions" 3 .

The main advantages of the proposed approach are:

the right to access a resource can be easily transferred from a user to another through a blockchain transaction created by the last right owner, without the intervention of the resource owner; the right is initially defined by the resource owner through a transaction, and all the other transactions representing the right transfers are published on the blockchain. Hence, any user can inspect them at any time in order to check who currently holds the rights to perform a given action on a given resource. Consequently, a user who had its access request denied, can check whether the entity in charge of verifying the existence of the required right actually made the right decision.

A common way of expressing access control rights is through Attribute-Based Access Control (ABAC) policies. Roughly speaking, an attribute-based access control policy combines a set of rules expressing conditions over a set of attributes paired to the subject, to the resource or to the environment. The rules are conjunctively or disjunctively combined and they must be satisfied accordingly in order for the access right to be granted. A well-know policy language allowing to express ABAC policies is the eXtensible Access Control Markup Language (XACML), defined by the OASIS consortium [START_REF]OASIS: eXtensible Access Control Markup Language (XACML) version 3[END_REF].

The actors of our reference scenario are the resource owner, say P , (unique for each resource) and a number of subjects, S i . The resource owner is the entity who has the control of the policy for each of its resources, say R j , and it creates, updates and revokes such policies. Note that we consider for simplicity that the policy issuer is also the corresponding resource owner. The subjects hold the rights to perform actions on resources, as specified by the respective policies. The subjects can transfer the action rights specified by policies, even by refining or splitting them (as explained in Section 3.1).

Hence, our approach requires that P and S i perform distinct actions, independently one from the others. The policy issuer takes no part in the policy rights exchange, and, similarly, the subject currently owning a right takes no part and needs not to be online when the policy issuer modifies the policy (even if this action might of course affect the subject right).

Policy Creation, Update, and Revoke

The policy which defines the access rights on the resource R is defined by the resource owner P , and it is stored in the blockchain through a new transaction called Policy Creation Transaction (PCT). After its creation, a policy can be updated by P any number of times and, at the end, it can be revoked, i.e., canceled.

In our approach, the policy consists of:

the condition which defines the ID of the subject to whom the policy grants the access right; the conditions which define the sets of values allowed for the attributes of the subject, resource and environment for the access to be granted.

In other words, the resource owner decides the subject to whom it wants to initially grant the access right and a set of conditions that must hold to grant the access. In our scheme we allow these conditions to be properly modified by the right holders when they transfer these rights to other users. By properly modify we mean that the current right holder is allowed to:

add new conditions in AND with the conditions already defined in the policy; split the set of values allowed for an attribute by an existing condition C of the policy in two (or more) sets by defining proper disjunct conditions, C i and C j . i.e. the set of attribute values which satisfy C i OR C j is the same set of values which satisfy C, and there is no value of the condition attribute which satisfies both C i and C j .

We note that adding conditions (done by a right holder) is not the same as executing policy updates (doable only by the policy issuer). Since the conditions added to the policy by right holders are combined with the existing ones through an AND operator, the resulting overall policy can only be more restrictive than the original one. This means that the original policy conditions cannot be violated. During a policy update step, instead, the meaning of the policy can be completely changed. This is correct since the policy issuer is the only one that can update a policy. We also remark as the conditions added by a right holder are added incrementally for each exchange of rights, so they cannot be modified by the new right owners. This is correct since a right owner should be allowed only to restrict the rights it wants to transfer, not to expand them.

For the sake of simplicity, we suppose that each policy concerns one subject ID only. This is not a limitation, because when P wants to grant the access to a resource to several subjects, it can simply produce a distinct policy for each one of these subjects. Moreover, in our approach we suppose that each policy includes one rule only, and this rule includes all the conditions of the policy, properly combined with AND and OR logic operators.

We remember that a blockchain can be seen as a distributed append-only database replicated among all the users. This means that every piece of data added to the blockchain cannot be subsequently removed and it will constitute a permanent burden on the entire network. This is the reason why, when defining a new protocol, we should try to minimize the amount of data saved on the blockchain, storing essential information only. The problem with our approach is that the standard policy language XACML is a very verbose formalism and policies can be relatively big. Storing policies in XACML format directly on a blockchain will result in a serious space occupation problem.

The easiest solution would be to store in the blockchain only a link to an external source containing the policy, coupled with a cryptographic hash of the policy itself to make it tamper proof. For example, the blockchain could save only a tinyurl or a torrent descriptor pointing to an external source hosting the actual policy (written in a standard format as, for example, XACML) [START_REF] Zyskind | Decentralizing privacy: Using blockchain to protect personal data[END_REF]. The advantage of this solution is obviously to minimize the quantity of information to be stored on the blockchain, since the space occupation of the policy is constant independently of the policy size. The main disadvantage is that policies themselves are stored outside of the blockchain, thus not benefiting of blockchain technology advantages (i.e. availability, security, etc.).

Our approach (shown in Figure 1) adopts an hybrid solution between saving in the blockchain the entire policy or just a link to it. We chose to store policies directly in the blockchain but coded in a custom built efficient format that favors compression and avoids information repetitions.

First we rewrite a policy expressed directly in ABAC format as a list of basic conditions over attributes. Each condition can be written as three pieces of information:

the right attribute name; the operand connecting right and left term; the left term that can be either an attribute name or a constant value (possibly a set of constant values).

Conditions are combined through the logic operator AND/OR to form a unique condition.

If we want the policy storage to be scalable in the size of the policy we would want each of the above listed informations of a condition to be represented with constant size. The logic connector of the policy is of course easy to codify with one bit (0 for OR and 1 for AN D). To try to compress the rest of the condition as much as possible we want to compress both attribute names and operands in a fixed size field (for example one byte). To compress operands we can define a protocol defined table of symbols representing the mapping between every possible operand usable in a policy and a numerical code. This map would be maintained at protocol level (open source) and updated with new usable symbols during future protocol versions. We can then follow a similar approach to map attribute names to a short numerical value. The difference is that attribute names are different between users and so the mapping have to be defined by the policy issuer. The attribute mapping is a publicly available mapping of attribute names (identifier in the verbose XACML format) with one unique code of fixed size (for example one byte). The list to be validly published (and accepted by other users to be used in policies) must be signed by the issuer. This public key/identity should be the same used to create new policies using such mapping in the blockchain. A cryptographic hash of this list is then inserted in every policy using the attributes of the list. Such hash is necessary to know what mapping is being used and it prevents the policy issuer from creating a new mapping, potentially changing the meaning of an already existing policy. The policy issuer could still delete the mapping at a future point (since it is stored locally and not on the blockchain), so it is recommended for the user buying the rights derived from a policy to locally save the corresponding mapping. In case of future dispute the right owner can prove that the mapping is correct because the hash matches and the policy issuer cannot deny to be the mapping creator because of the signature attached to the mapping.

We note that this solution allows to save verbose informations about an attribute off the chain, so without space constraints. For example we can save the attribute values type, making the type of operand non ambiguous (i.e. for example differentiating an equality over integers from an equality over strings).

If we adopt this solution, the left term of the condition is the only one of potentially variable length. If it is a parameter name it can be represented as a reference to an entry of the issuer attribute table as for the right term, but if it is a constant value we need to represent it directly, eventually in a compressed format. Furthermore, since we know the type of the attribute (expressed in the verbose attributes table) we can save the values in a suitable format. For example we would save a number or a date in a numerical representation rather than in its string representation.

Right Transfer

A relevant feature of our approach is that the right to access a resource R can be transferred from the subject who is the current right holder, say S i , to another subject, say S j , through a custom data structure stored in in the blockchain, called Right Transfer Transaction (RTT). Each RTT must contain a (direct or indirect) link to the policy whose rights are being exchanged. It is worth noting that the only parties involved in a RTT are S i and S j , the RTT is created by S i , and so the intervention of the owner of the resource is not required during any rights transfer.

When transferring its right through a RTT, S i can modify the mutable conditions regulating its right only by restricting them. For instance, supposing that a changeable condition defined by the resource owner (or by the previous right owner) states the access can be performed from 9.00 AM to 5.00 PM, S i could transfer this right to S j by restricting the access time from 9.00 AM to 1.00 PM. S i can also split its right in two (or more) parts, and transfer a part of it to a subject, and the other part to another subject. With reference to the previous example, S i could transfer the access right from 1.00 PM to 5.00 PM to a third subject S h .

We note that the subjects are only owners of rights to perform actions, in general they have no other right neither on the policy nor on the resource. We also remark that the subjects are able to freely exchange action rights between themselves without any interaction with the policy issuer. That implies that the policy issuer (in general corresponding to the resource owner) has no knowledge in advance of which subjects will be the policy right beneficiaries (even if it can of course model a subject prototype by specifying the correct attributes conditions to be satisfied inside the policy).

We also note that policy updates from a resource owner can potentially change the meaning of a policy. This means that subjects can gain rights on a certain resource that can be later changed by the policy issuer, but, since the blockchain never forgets and timestamps both the right transfer and the policy updates, those changes are manifest and traceable.

Architecture of the Proposed Framework

The architecture of the framework we propose for the enforcement of blockchain based access control, shown in Figure 2, is based on the XACML reference architecture [START_REF]OASIS: eXtensible Access Control Markup Language (XACML) version 3[END_REF], which has been integrated with blockchain technology. Specifically, in order to allow the enforcement of blockchain based access control policies, we customized the Policy Enforcement Point (PEP) and the Policy Administration Point (PAP). The resulting workflow is hence an extension of the standard one.

When requesting to perform an action on the resource, beside the IDs of the subject, of the resource, and of the action, the PEP must also retrieve an additional information to unequivocally link the subject S i with a RTT in the blockchain. As an example S i might be required to sign a challenge nonce with the private key corresponding to the identity it used to get the access rights in the RTT. This is no different from a classical authentication scheme in a classical access control scenario. All those informations are properly included in the request which is passed to the Context Handler (CH). The CH is in charge of managing the workflow of the decision process, interacting with all the other components of the authorization system.

First of all, the CH sends the request to the PAP. The PAP extracts the RTT link from the request, and retrieves from the blockchain this RTT and all the other RTT related to this policy, as well as the initial policy and the related policy updates issued by the resource owner. The PAP combines the retrieved data to produce a standard XACML policy, and sends this policy back to the CH.

Once the security policy has been reconstructed from the blockchain and verified, its evaluation against the access request follows the process defined by the XACML standard and described in [START_REF]OASIS: eXtensible Access Control Markup Language (XACML) version 3[END_REF]. Briefly, the CH asks the Policy Information Points to retrieve the relevant attributes, it embeds these attributes in the original request, and it passes the policy and the new request to the Policy Decision Point (PDP), which evaluates it and returns to the CH the decision: permit or deny. The CH then forwards the decision to the PEP, which enforces it on the resource by executing the request or not.

Bitcoin-based Implementation

This section describes an example of how the proposed model is deployable in a blockchain technology model. In particular, we developed a proof of concept implementation scheme based on the Bitcoin blockchain. Aim of this section is also to show how our protocol can be immediately deployed on top of an already existent real world blockchain, as the Bitcoin blockchain is, without any modification to the underlying blockchain implementation required. As an example we report in Figure 3 a real PCT Bitcoin transaction we broadcasted in the Bitcoin network as publicly visible from the site https://blockexplorer.com.

In our scenario firstly a resource owner creates a new policy. Then, an arbitrary number of policy updates and right transfers can be executed, where each of the two actions can be performed independently of the other one. Finally the resource owner can revoke the policy. In our implementation each step (policy creation, policy update, policy revoke or right transfer) is performed atomically by a single Bitcoin transaction.

Storing data

As described in Section 2, the Bitcoin blockchain was designed to be used as a distributed ledger to manage a very specific kind of data: transactions. In other words, the Bitcoin blockchain was not designed to store arbitrary data. To overcome this limitation, we employ two commonly used methods based on Bitcoin transactions scripting language to store arbitrary data on the blockchain: the OP RETURN script op code and the MULTISIG transactions (either through a MULTISIG output script or a multisignature P2SH output) [13]. Without going in further details we only note that our implementation automatically chooses the method to be exploited without the need of user intervention. Whatever storage method we use the policies and conditions data is encoded in a compressed custom format that follows the hybrid approach showed in Section 3.1.

Since each step is performed exploiting a Bitcoin transaction, each step has a price, i.e., the price of the underlying transaction, defined as the transaction fee paid by the transaction, which is dependent on the transaction size [14]. So we can evaluate the cost of a step as the size of the underlying transaction necessary to perform it. Every Bitcoin full node also keeps in its main memory a data structure to keep track of all unspent transactions outputs (UTXO), so if we include a big output in a transaction (e.g. by including a big multisignature output) this will also encumber precious main memory space of all the users. Finally, we point out that during each step the transaction price is payed by the beneficiary of the action. For policy creation, revoke and update transactions the price is payed by the policy owner (that is the one benefiting from such operations), while for a rights exchange the price is payed by the buyer (since the buyer is the one who will benefit from the rights).

To embed data in a transaction we first need to create a Bitcoin transaction and so we need value to be exchanged. To build transactions we will use fixed amounts of BTC to represent tokens, using an approach similar to the Colored-Coins proposal [15]. We call them tokens because the value they represent will be used in transactions to carry data through the connected scripts, so we are not interested in the monetary value they represent but rather on the information they carry (visible only to those who take part in our protocol). The actual trade value of such tokens is completely independent from their nominal value (i.e. the number of BTC they represent). The fixed amount chosen for a token should be low enough so that it is easy to be owned by any user (otherwise only rich users could take part in the protocol) and its economical value is not relevant compared to its protocol specific value, but also high enough so that it can be transacted freely between users (above the dust limit [16]). In our current implementation we chose 0.0001BTC that corresponds to few euro cents at the exchange rate at the time of writing. We will indicate this value as CommonAmount in the rest of this paper.

Policies Management

Policy Creation A new policy is issued by the resource owner by creating a new Bitcoin transaction with one or more inputs and two or three outputs. Each of the first two outputs will create a new token, so it is paying out the value of CommonAmount. The only purpose of the inputs is to provide enough funds to create these two tokens and so should include any number of resource owner funds so that (input values) ≥ 2 * CommonAmount + f ee. The first two outputs are mandatory, and their structure is defined by the protocol, while the third output is optional, and it represents the change address for the resource owner to keep the unspent input . The order of the first two outputs is important (it can not be changed):

the first output creates the token that will be subsequently used to perform rights exchanges among subjects. It is credited either to an address that will be used by the policy issuer to sell the action rights to the first subject, or to the first subject directly. the second output creates a token containing as data the policy encoded in our custom format. This token is credited to an address controlled by the resource owner and it will be used by the policy issuer to update/revoke this policy in the future.

When the resource owner creates this transaction, the network is notified and, eventually, this PCT will be inserted in the blockchain. If the policy is too large to be included in the second output data field, the policy issuer creates a normal PCT and then creates a chain of policy update transactions (as explained later) to include all the information required. We note that the policy creator does not have to wait for the PCT to be included in a block before starting to create policy update transactions, since he is the owner of all input and output addresses in both policy creation and update transactions and, consequently, there is no risk of double spending attempts. In the end, this means that a very long policy will generate several transactions and, consequently, it will be simply more expensive for the owner (due to more fees to pay).

Policy Update/Revoke At any time the policy issuer can update or revoke a policy it created before. To do so, it creates a new transaction spending the second output of the creation policy transaction if the policy was never modified before, or spending the output of the last update policy transaction if the policy was already updated at least once. Obviously, only the policy issuer can create those transactions because it is the only one that can spend the corresponding output.

-Update: the update transaction has two (or more inputs). The first input corresponds to the previous update or PCT output and the additional inputs are meant to provide the value necessary to be spent as fees to pay for this transaction. The transaction has one or two outputs, the first one carries on the token of the previous policy update or creation step, while the second one is only used as change address to collect the money left after paying the transaction fees. The update token contained in the first output is used to store the data containing the policy update informations. -Revoke: to revoke a policy, the policy issuer must spend the related token (even to himself), i.e., it must use it as value instead of using the embedded information. To this aim, it just creates a transaction spending the input corresponding to the previous update or PCT. This effectively destroys the token, thus canceling the policy.

Rights Exchange

To allow the exchange of access rights between two (or more) subjects we assume the existence of some kind of marketplace (or any way of exchanging messages between users) where subjects interested in selling or buying action rights take part. We also note that, since each policy and its updates are publicly visible in the blockchain, each subject can first check a policy to verify the actual rights it is buying. The right exchange between two subjects is achieved through the participation of the subjects in a message exchange protocol to allow them to jointly build and sign the RTT. Main goal of the message exchange is to guarantee that both subjects sign the RTT only after checking that it fulfills the exchange agreement. The RTT is basically a transaction where the token representing the access right is passed from the current subject to the new one and, in exchange, the new subject accredits some money (expressed in BTC) to the current owner. Furthermore the token can be enriched by the old owner with new data to refine the policy conditions and it can be divided in different tokens (as explained in Section 3.1). We have seen in Section 5.2 that the right transfer token is created initially by the resource owner in the policy creation transaction, this means that the resource owner is the first one to sell the rights to a subject.

Note that the fact that rights are represented by a token, coupled with the fact that every output can be spent only once, guarantees that the same rights can be transferred only once. Note also that the subject that has currently the policy action rights can also decide to destroy those rights. To do so it only needs to spend the corresponding token as if it was just normal value (using the same process explained previously used by the policy owner to revoke a policy). This is semantically correct since the current owner has payed for the rights and so it can do with them whatever it wants. It could as well decide to never sell the rights again, which is the same for the other users as if it had destroyed them. The advantage is that the resource owner can see from the blockchain when a subject rights token has been destroyed, and so it could choose to revoke the old policy and issue a new one. We also note that revoking a policy or destroying subject rights actively removes the policy data heavy outputs from the UTXO (see Subsection 5.1) of all the users, so any policy stops encumbering the network once it is not active anymore.

Policy Evaluation

Let us suppose that a policy granting access rights to the resource R has been created and updated m times, and that this right has been transferred among subjects n times. This means that the blockchain includes a PCT, say pt, defined as in Section 5.2 with a chain (actually a tree in case of rights splits) of n RTT defined as in Section 5.3 originating from the first input of pt and a single chain of m policy update transactions originated from the second output of pt.

When the PEP receives a request, it only receives a link (for example a cryptographic hash) to the last RTT, say rt, and this is the only information it needs to pass forward in a request to the CH (see Section 4). Given a request the PAP can access the blockchain and navigate backward the chain of n RTT from rt all the way back to pt, collecting at each step the additional conditions added by right owners. Once the PAP has reached pt it can read the policy from the blockchain. Then it traverses forward the chain of all m policy update transactions, updating the policy accordingly with the data read at each update step. Once it has the fully updated policy it can add the restricting conditions inserted by right owners and read during the RTT chain traversal. At the end of this process the PAP has derived the completely updated policy in a standard format ready for evaluation by the PDP.

Note that the above policy reconstruction can be done by anyone, given a RTT, since all the informations are publicly visible in the blockchain. This is particularly important for the interested subjects that can retrieve the same way the updated policy from the blockchain and then decide whether to buy the rights for themselves or not.

Conclusions

This paper defines an approach to create, manage and enforce access control policies exploiting blockchain technology. The main advantages of this approach are that the policy is published on the blockchain, thus being visible to the subjects of the scenario, and that the access rights can be transferred from one user to another simply through a blockchain transaction. The approach has been validated through a reference implementation based on Bitcoin.

We plan to extend our work to study how to better embed an access control system in blockchain technology. In particular we are studying the possibility of using smart contracts to obtain self enforcing policies. We are exploring how to formulate the classical access control scheme (see Section 4) as a smart contract that can be stored and executed in the blockchain to automatically evaluate and enforce policies. Moreover we plan to improve our approach in order to also manage multi-rule XACML policies and policy sets. We are also currently studying the privacy implications of our approach and how to mitigate them.

Fig. 1 .

 1 Fig. 1. Proposed hybrid policy storage approach.

Fig. 2 .

 2 Fig. 2. Architecture of the Blockchain based access control framework.

Fig. 3 .

 3 Fig. 3. A real example of PCT in our Bitcoin-based proof of concept implementation.

In the following, we refer to cryptocurrency style blockchains, because they are the main application of blockchain technology currently implemented. Consequently, we assume to have transactions, which are typical of cryptocurrencies. However, cryptocurrencies are just one of the possible applications of blockchain technology. In those cases, we have to define proper transactions to implement the approach we propose.