# A novel access control method via smart contracts for internet-based service provisioning

Fariba Ghaffari, Emmanuel Bertin, Noel Crespi, Shanay Behrad, Julien Hatin

► To cite this version:

Fariba Ghaffari, Emmanuel Bertin, Noel Crespi, Shanay Behrad, Julien Hatin. A novel access control method via smart contracts for internet-based service provisioning. IEEE Access, 2021, 9, pp.81253-81273. 10.1109/ACCESS.2021.3085831. [hal-03245473](https://hal.science/hal-03245473)

HAL Id: hal-03245473

https://hal.science/hal-03245473

Submitted on 1 Jun 2021

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>

Distributed under a Creative Commons Attribution 4.0 International License
# A Novel Access Control Method via Smart Contracts for Internet-based Service Provisioning

FARIBA GHAFFARI<fnref n="1" />, EMMANUEL BERTIN<fnref n="1" />, (Senior Member, IEEE), NOEL CRESPI<fnref n="2" />, (Senior Member, IEEE), SHANAY BEHRAD<fnref n="3" />, and JULIEN HATIN<fnref n="4" />

Corresponding author: FARIBA GHAFFARI (e-mail: fariba.ghaffari@orange.com).

**ABSTRACT** The dramatic rise in internet-based service provisioning has highlighted the importance of deploying scalable access control methods, facilitating service authorization for eligible users. Existing centralized methods suffer from single-point-of-failure, low scalability, and high computational overhead. In addition, in these methods, users pay for the service provider as well as the network provider independently for a specific service, imposing extra cost for the user. New business models are needed to resolve such shortcomings. The realization of these models calls for sophisticated access control methods which consider the requirements of all parties who want to: 1) access a service; 2) provide that service; and 3) provide the network connection. Blockchain is an enabling technology that provides unprecedented opportunities to novel distributed access control methods for new business models. We propose an Attribute-based access control solution by leveraging Blockchain to share network providers' and service providers' resources. Our solution offers access flexibility based on the requirements of the parties while fulfilling reliability, accountability, and immutability. Besides, it decreases the overall service cost which is beneficial for each party. Our solution makes it possible for service providers to outsource their access control procedures without requiring a trusted third party. The experiments confirm that our solution can provide a fast, comprehensive, and scalable access control mechanism.

**INDEX TERMS** ABAC, Blockchain, Ethereum, flexible access control, network, service provisioning, smart contract, trusted payment, 5G.

## I. INTRODUCTION

THE dramatic increase in network-based services (e.g., video/audio streaming and internet calls) has led both network providers and service providers to implement a variety of techniques to meet the growing need for network security. Given that service providers offer their services to users (e.g., websites similar to Netflix for video streaming) and network providers provide the network infrastructure, Access Control (AC) is one of the vital aspects in the effort to assess users' eligibility to access services. AC can be implemented by deploying one or more different solutions. The majority of these solutions are deployed in centralized systems, in which a user's request is sent to a Central Authority (CA) and the CA then decides about their eligibility to access the system based on certain rules.

As a typical scenario of current internet-based service provisioning, when a user wants to use an online service (e.g., video streaming), he/she first subscribes to both a network provider and a service provider and then requests the service provider to access the service. The service provider then authorizes the user via its central authority. If the user is eligible, she can watch the video. While watching the video, the user is consuming not only the already paid service, but also her available internet. In the other word, user is paying for the service provider as well as the network provider. This scenario undergoes several drawbacks from both business and technical perspectives. From the technical viewpoint, the central authority in the access control procedure is a single point of failure. So, it causes low scalability, management difficulties (e.g., in the maintenance of the server),

<footnote n="1">¹Orange Telecom, Institut Polytechnique de Paris, IMT, Telecom SudParis (e-mail: {fariba.ghaffari, emmanuel.bertin}@orange.com)</footnote>

<footnote n="2">²Institut Polytechnique de Paris, IMT, Telecom SudParis(e-mail: noel.crespi@mines-telecom.fr)</footnote>

<footnote n="3">³b-com Institute of Research and Technology</footnote>

<footnote n="4">⁴Orange Telecom</footnote>
lack of automation in the access control process, and low fault tolerance. From a business model perspective, another shortcoming is that the user has to do extra payment for the service. Regarding these parameters, any solution bringing flexibility in access management, rules' immutability, distributed management of requests, fault tolerance, possibility to implement a new business model (to reduce extra payments), and eliminates the need for a trusted third party can be a promising candidate as a new access control mechanism.

Blockchain [1] was introduced in 2008 as a distributed technology. In 2014, the first extension of this technology emerged as smart contracts [2]. These technologies are cryptographically secure, and all changes in the system require the consensus of all the eligible nodes. After the consensus of the nodes, the updates are applied in the distributed ledger stored in each node of the network. Thanks to their features, Blockchain, and smart contracts are changing many aspects of business models, management, and operations in a range of fields. Indeed, Blockchain can be a game-changing technology in access control, because: Its distributed nature can remove the single point of failure and increase the availability of the system;

* The consensus among nodes provides a more reliable access management process;

* It can offer the immutability of rules, due to its cryptographically secure nature;

* Smart contracts provide the ability of access flexibility using agreements among parties, based on their needs;

* Signing the transactions can support non-repudiation;

* Removing the need for a CA can reduce the access management load of the service provider side, as well as decrease the maintenance cost.

In this paper, we propose a solution, based on smart contracts to provide flexible access control in a new business model. In this system we aim to 1) remove the central authority to decrease the maintenance cost and remove the inherited threats of centralized systems, and 2) eliminate the user's extra payment for the service. It is important to mention that in our proposed method, we do not remove the user's payment to the network provider. We assume that the user is subscribed to the network provider, but, while using the specific service through our platform, the user is exempt from payment (e.g., does not use the available internet capacity). To achieve the first goal, the service provider outsources the authorization process to a Blockchain-based platform, and for the second target, after user authorization, the service provider is the party who pays the network provider on behalf of the user.

In this setting, there are three main parties (user, service provider, and network provider) that do not trust each other. For instance, the network provider does not trust the service provider to pay the network cost. In this paper, we aim to resolve the above-mentioned challenges in centralized systems and to provide a trusted connection among the three mentioned parties. Also, to deploy a new business model using

the proposed access control solution. The main contributions of this paper are:

1) *Outsourcing the access control* process to an entity without requiring any trusted third party. This feature has two advantages, first, it can decrease the processing load of the service provider (i.e., by simplifying the user registration, access control, etc.), and second, there is no need for any other organization as a trusted third party (i.e., decreases the operation cost).

2) Providing *flexible access control solution*. Smart contracts can be designed to provide authorization possibilities based on the requirements of all parties. These requirements can consider the needs of the network provider (e.g., how much the network provider will be paid), service providers (e.g., which service will be provided at which cost), and users (e.g., which service at which cost and how long is available).

3) Providing *automation* in the access control process. Using smart contracts to handle the access control, there is no need for a central authority. Smart contracts also can make this process completely secure, immutable, and automatic.

4) Make it possible to implement *new business models* for network providers and service providers. Instead of paying twice for a specific service, in our proposed method a user will pay the service provider for its service, and in the next steps the service provider is the entity that pays the network provider on behalf of the user.

The rest of this paper is organized as follows: Section II provides a brief background, followed by a summary of the state of the art in Section III. Section IV outlines the problems of the existing methods and presents our proposed solution. The detailed design and construction of our proposed flexible access control solution to support the new business model is provided in Section V, followed by the experiment and threat analysis in Section VI. Section VII provides our conclusions about the proposed method as well as some future research directions.

## II. PRELIMINARIES

### A. BLOCKCHAIN AND SMART CONTRACT

Blockchain is introduced by Satoshi Nakamoto in 2008 and implemented in 2009 by Bitcoin [1]. Blockchain is a peer-to-peer distributed ledger, immutable, cryptographically secure, permanent, traceable, and transparent technology that is updatable only via consensus among the majority of the nodes that existed on the network [3], [4].

Blockchain is implemented in the structure of linked list, in which, each block is connected to the previous block via its hash. As shown in Fig. 1, using the hash of the preceding block makes it difficult to change the data in a block. Changing a data in one transaction results to change in the hash of that block, and consequently it must be changed in the next block. To change this value, the hash of all next blocks
<figure><img src="image_2.png" /><figcaption>FIGURE 1. The structure of blocks in the Blockchain.</figcaption></figure>

must be calculated again. Due to this feature, Blockchain is immutability; it means that any confirmed transaction or data cannot be altered. Blockchain's permanency means that all data can be available at any time, and nothing may be removed from the network [5], [6].

Fitting the transactions inside a block in an order, and publishing a new block, can be done through solving a consensus puzzle [7]. Higher number of nodes to contribute in the consensus proses, results in the lower the probability that an individual miner can monopolize the ability to alter the order of the transactions [8]. Proof of Work (PoW) [9], Proof of Stake (PoS) [10] and Practical Byzantine Fault Tolerant (PBFT) [11] are three well-known examples of existing consensus models. As one of the extensions of blockchain technology, smart contracts introduced by Szabo in 1998 [2] and implemented by Ethereum in 2015 [12], are defined as computerized transaction protocols that execute the terms of a contract on a Blockchain. The main purposes of smart contracts are to satisfy common contractual conditions, minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries.

## B. ACCESS CONTROL

Access control is a security technique that regulates who or what (i.e., subject) can perform which action on resources (i.e., object) [13]. There are a variety of access control mechanisms that are used for different purposes. Some of the most well-known methods are Capability-based Access Control (CapBAC) [14], [15], Discretionary Access Control (DAC) [16], Role-Based Access Control (RBAC) [17], and Attribute-Based Access Control (ABAC) [18]. Elaboration of all of these methods is not in the scope of this paper, and to be focused on our goal, we only explain the ABAC solution.

Fine-grained access management of ABAC makes this solution a primitive candidate for our method. ABAC is fine-grained because it supports different constraints to define the legitimate user. Also, it provides dynamic and context-specific access which makes the resource owner capable

to define the access control policy based on their needs. ABAC generally uses Boolean logic in which the validator can verify the subject's eligibility in 0/1 logic based on different attributes. In the rest of this part, the ABAC method is formulated and explained comprehensively.

The attribute-based access control method has four sets of attributes to define the access policy and manage the subject's access to the object. These sets are Subject Attributes (SA), Object Attributes (OA), Environment Attributes (EA), and Action Attributes (AA). Let define all the attributes (AT) of access policy as equation (1):

$$AT = (SA, OA, EA, AA) \quad (1)$$

each set of attributes are defined in below:

$$ 
\begin{aligned}
SA &= \{s_1, s_2, \dots, s_n\}, OA = \{o_1, o_2, \dots, o_m\}, \\
EA &= \{e_1, e_2, \dots, e_p\}, AA = \{a_1, a_2, \dots, a_q\}
\end{aligned} 
\quad (2) 
$$

where $n = |SA|$, $m = |OA|$, $p = |EA|$ and $q = |AA|$. Each attribute in ABAC is defined as a pair (attribute_name, value).

Subject attributes specify the subject by its identifiers such as username, token, and so on. Object attributes distinguish the resources that the subject wants to access; for instance the file name, the network resource, the service name, etc. Action attributes are the actions that can be performed by the subject (e.g., “read”, “write”, and “execute”). Finally, Environment attributes describe the context in which access is requested (e.g., the time and location from where access is requested, the type of communication channel, etc.).

The request of the subject u to access a resource can be formulated as equation (3). To shorten the formulation, we avoid expanding each attribute set.

$$Req_u = \{SA_r, OA_r, EA_r, AA_r\} \quad (3)$$

Different validators in a system may need a subset of the attributes to validate the subject to perform a specific action based on the access policy. Let's define the attribute subset for validator v as:

$$AT_v = \{SA_v, OA_v, EA_v, AA_v\} \quad (4)$$

The validation result for each attribute set based on the predefined access policy is as (5):

$$V_{SA} = \begin{cases} 1, & \text{if } SA_v = SA_r, \\ 0, & \text{otherwise} \end{cases} \quad (5)$$

The validation process for OA, EA, and AA sets is the same as (5).

Finally, access control result (AR), based on the policies defined by the owner, which is returned as “allow” or “deny” to the user, can be formulated as (6):

$$AR = \begin{cases} 1(allow), & \text{if } V_{SA} = V_{OA} = V_{EA} = V_{AA} = 1 \\ 0(deny), & \text{otherwise} \end{cases} \quad (6)$$
### III. RELATED WORKS

Due to the significance of access control, a variety of solutions are proposed in this field. A considerable part of the literature is dedicated to centralized systems in which there is a trusted central authority that manages users' requests (see Fig. 2 (a)). Despite the low complexity in implementation of these methods and time efficiency of access validation, they suffer from having a single point of failure, low scalability, low availability, and low non-repudiation [19], [20].

Most of these drawbacks can be resolved by a reasonable trade-off between the advantages and disadvantages of using Blockchain technology. As an example, using Blockchain for access control procedure may decrease the time efficiency, while it increases the non-repudiation and removes the single point of failure. Existing Blockchain-based access control methods can be classified into two main categories [21]. In the first category, they use Blockchain as a distributed database to store rules (see Fig. 2 (b)); Even though these

<table><caption>TABLE 1. General Comparison among Access control solutions</caption><thead><tr><th>AC Model Parameter</th><th>Centralized model</th><th>Blockchain as DB</th><th>Blockchain in whole Process</th></tr></thead><tbody><tr><td>removing SPoF</td><td>Low</td><td>Moderate</td><td>High</td></tr><tr><td>Immutability</td><td>Low</td><td>High</td><td>High</td></tr><tr><td>Rule Integrity</td><td>Low</td><td>High</td><td>High</td></tr><tr><td>Non-repudiation</td><td>Low</td><td>Low</td><td>High</td></tr><tr><td>availability</td><td>Low</td><td>Moderate</td><td>High</td></tr><tr><td>time efficiency</td><td>High</td><td>Moderate</td><td>Low</td></tr><tr><td>Implementation complexity</td><td>Low</td><td>Moderate</td><td>High</td></tr><tr><td>Scalability*</td><td>Low</td><td>Moderate</td><td>High</td></tr><tr><td>auditability</td><td>Low</td><td>Low</td><td>High</td></tr></tbody></table>

*Scalability in terms of the number of users. Note that scalability in the number of transaction(s) per second (TPS) in the Blockchain is generally lower than centralized systems [22]

methods improve the centralized solutions regarding non-repudiation, rule immutability, etc., they could suffer from a single point of failure. Because in these methods, access decision is made by a central authority outside the Blockchain. In the second category, the Blockchain is used not only as a database, but also as a decision point (see Fig. 2 (c)); it means the rules are stored in the Blockchain, and the access decision can be done using smart contracts. Even though the complexity of implementation of these methods is high, and their time efficiency is marginally lower than the centralized solutions, they can provide high scalability (in terms of the number of users), availability, fault tolerance, the immutability of rule and decision, non-repudiation, and audibility (Table 1).

Following, some of the existing Blockchain-based access control solutions are introduced. To the best of our knowledge, using Blockchain for access control in internet-based service provisioning in our proposed business model is not seen in other works. So, in the following we introduce the works that are more related to our work regarding their use-case purpose or implementation.

#### A. USING BLOCKCHAIN AS A DATABASE FOR RULES

Shafeeq et al. [23] proposed an ABAC mechanism in which the object's owner can define the access rules and store them in the Blockchain. In the access request, the owner sends the authorization token to the requester only if the requester meets the conditions defined in the access control policy. Another ABAC method for cloud computing is proposed by Qin et al. [24] in which the Central Authority (CA) is responsible for managing the security of the whole system. First, the CA issues an attribute key to the user and adds the validity period of the key in the smart contract. BlendCAC [19] is a CapBAC mechanism in which, smart contracts are used for storing the access control matrix. Each node interacts with the smart contract through the provided contract address and the Remote Procedure Call interface. Another CapBAC scheme is proposed by Tan et al. [25], that Blockchain stores capability set and access logs of the users. Wang et al. [26] proposed a fine-grained access control method using attribute-based

<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /></figure>

<figure><img src="image_5.png" /><figcaption>FIGURE 2. Access control approaches. (a) centralized model, (b) using Blockchain as a distributed database, (c) using Blockchain in all access management procedure.</figcaption></figure>
encryption (ABE) scheme [27]. At first, the owner encrypts the system's master key and saves it to the Blockchain, and then deploys a smart contract. The user sends the registration request to the owner; the owner manages the secret key for the user and saves it on the Blockchain and sends transaction ID and smart contract's address to the user through a secure channel. These data will be used for the next connections. Moreover, Guo et al. [28] proposed a traceable attribute-based encryption method named as TABE-DAC to provide the capability of sharing private data in cloud. This system uses the ABE method. In TABE-DAC the Blockchain is used to store the encrypted key and policies. Ling et al. [29], [30] proposed an ABAC model using Blockchain Radio Access Network (BRAN) in which the user and network provider reach an agreement on some parameters such as payment and digitized spectrum assets, written in the smart contract. After the validation of the smart contract concerning the user's balance and network's spectrum assets, the user will be granted time-limited access to the resource, and the access point will automatically receive the payment for the access.

## B. USING BLOCKCHAIN IN ACCESS MANAGEMENT PROCESS

Yang et al. [31] proposed AuthPrivacyChain in which, the policies and access logs are stored in Blockchain and access control is done by the smart contract. This system is designed to handle the user's request to access the data in the cloud and supports all access control models. RBAC-SC [32] is an RBAC mechanism that consists of a smart contract and a challenge-response protocol. The smart contract is used for the creation, changing, and revoking of the user's role assignments, while the challenge-response protocol is for the authentication of the owner. Fabric-IoT [33] is an ABAC method that uses three kinds of smart contracts to: 1) store the URL of the data that is produced by devices, 2) store ABAC policies, and 3) implement access control methods. The main problem of this method is its low scalability in the context of IoT. Zhang et al. [34] proposed a smart contract-based ABAC framework in which multiple contracts are used for access management. The environment attributes in this method are limited to the time attributes. Another similar system for data sharing in IoT is proposed by Sultana et al. [35], [36]. In this system, the user sends an access request to a central server. This server redirects the request to the access control contract. If the user's history is clear, the user's permission level is verified, and an access decision is made. The main problem is that both systems have a central point that can be a single point of failure.

## IV. PROBLEM STATEMENT AND PROPOSED SOLUTION

To explain the problem of existing internet-based service provisioning, we start with an example depicted in Fig. 3. Assume that user ($u_a$) wants to watch a video from the website of a service provider ($sp_a$). The scenario is described as follows:

<figure><img src="image_6.png" /><figcaption>FIGURE 3. An example of a current scenario for service provisioning</figcaption></figure>

1) $u_a$ subscribes to network provider $np_a$ for the internet connection. In this step, the user's information is stored in the authorization database of $np_a$ for further connections.

2) $u_a$ subscribes to $sp_a$ and pays for the service based on her needs. In this step, the authorization information of $u_a$ is stored in the database of $sp_a$ for the next connections.

3) $u_a$ connects to the website of $sp_a$ using her internet provided by $np_a$ and requests to watch the video.

4) $sp_a$ sends $u_a$'s credentials and identifiers to its centralized access control server.

5) The access control server returns the authorization result to $sp_a$, which specifies the user's permission to use the service.

6) If $u_a$ is eligible to use the service, she can watch the video. In this scenario, not only the user is subscribed in $sp_a$, but using the service consumes her share of internet access from $np_a$.

We have identified several drawbacks in this scenario. First, there is a central authorization server for $sp_a$, which can be a single point of failure. Moreover, $u_a$ must pay twice to watch a video. The processing loads of $sp_a$ and $np_a$ are high, because they need to authorize the $u_a$ separately for each connection. Finally, there are several general issues in centralized access control solutions which this scenario has inherited. For example, the risk of losing the user's data in a centralized server, denial of an action done by a malicious user (low non-repudiation), the possibility of an attacker changing a user's permissions, and the high maintenance cost of the centralized server.

Addressing these constraints, we propose a novel flexible access control solution to share network and service with users. This solution provides a trustful payment capability to pay network provider based on Blockchain technology, without the need for a central authority. Moreover, this system can eliminate users' extra payments for a service, which is a new business model for both service and network providers.
<figure><img src="image_7.png" /><figcaption>FIGURE 4. Proposed scenario for Internet-based service provisioning via Blockchain-based access control solution</figcaption></figure>

A schematic of the method is presented in Fig. 4.

Assume that user $u_b$ wants to watch a video from the website of the service provider $sp_b$ and she uses the network provider $np_b$. The procedures to follow in this system are outlined below (Fig. 4):

1) Service provider registration in the system:

a) $sp_b$ and $np_b$ agree on the price of network media.

b) After reaching a compromise, registration token is sent to Blockchain by $np_b$.

c) $sp_b$ is registered in the system using the one-time token.

2) Subscription for the internet:

a) $u_b$ subscribes to $np_b$ for the internet connection. This process is off-chain. After the user's subscription in $np_b$, her next connections, is authenticated by $np_b$ in the first step, and then the user can use the system.

3) User subscription and registration for the service:

a) $u_b$ sends the registration request to the Blockchain and gets the URL of $sp_b$ for registration.

b) The user is redirected to $sp_b$ for subscription to the service and getting the one-time registration token.

c) After payment, $sp_b$ sends a one-time registration token to the $u_b$ and also stores it in the Blockchain for further process.

d) $u_b$ sends the registration request accompanied by the token. If the token is valid and available, the agreement of $u_b$ and $sp_b$ can be added to the Blockchain as a smart contract.

4) User authorization (access control) procedure:

a) After registration, $u_b$ send the access request to the Blockchain a request for using the service.

b) The access request result is returned to $u_b$, and if she is validated, the URL of $sp_b$ accompanied by a one-time access token is sent to the user.

c) $u_b$ connects to the URL and sends the token. Then, $sp_b$ validates the token stored in the Blockchain. If the request is valid, $sp_b$ can have access to the service and in our example scenario, while $u_b$ watching the video, her internet will not be consumed.

5) Termination and payment:

a) When $u_b$ finished using the service, the termination trigger will be sent to the Blockchain.

b) In Blockchain, after receiving the trigger, the payment of $np_b$ will be performed through the account of $sp_b$.

Considering the drawbacks of the current methods, the advantages of this system are listed in Table 2. Before focusing on a detailed presentation of the system, it is important to mention that in this method we don't eliminate the user's subscription fee in the network provider. Rather, we want to remove the user's extra payment for using that specific service.

## V. SYSTEM DESIGN

Our proposed method consists of four main steps: 1) setup; 2) registration; 3) access control, and 4) payment. In the setup, we deploy all the unique contracts that are needed for the further steps. Next, in the registration step, the service provider and the user register in the system. After registration, in the access control step, the user requests authorization to use the service without internet consumption, based on her desired connection level and service plan. Finally, after using the service, the termination feedback is sent to the Blockchain to pay the network provider. All symbols used, are listed in Table 3. Our general assumptions for deploying the system are listed below:

* The connections between the user, Blockchain, service provider, and network provider are secure;

* There is only one network provider in the system and the user is subscribed to the network provider;

* User is authenticated to use the Blockchain (as mentioned in step 2.a in Fig. 4);

* User is limited to use the service at the granularity of their contract (e.g., just watch one episode of a series, or have a call lasting 1 hour, etc.);

Before describing the steps, we first introduce the smart contracts used in the on-chain part of our system.

## A. DESIGN SMART CONTRACTS

Following, are the designed smart contracts:

1) *Known_Addresses*: six contracts in our system are each deployed once. *Known_Addresses* stores the addresses of these single contracts, enabling them to collaborate safely. In this contract, the names of contracts are mapped to their addresses:
<table><caption>TABLE 2. Key advantages of the proposed method</caption><thead><tr><th>Feature</th><th>Description</th><th>Advantages</th></tr></thead><tbody><tr><td>Access control outsourcing</td><td>The ability to outsource the access control procedure on the service provider side</td><td><ul><li>the processing load and maintenance cost</li></ul></td></tr><tr><td>No need to Trusted Third- Party</td><td>Thanks to using smart contracts for payments, no trusted third party is needed.</td><td><ul><li>Reduces the outsourcing and payment costs</li></ul></td></tr><tr><td>Supports a new business model</td><td>Provides a new business model for service providers and network providers which can bring new business opportunities.</td><td><ul><li>Avoids double payment by the user</li></ul></td></tr><tr><td>Trusted payment</td><td>After the use of the service has been terminated by the user, the platform sends a trigger to the Blockchain. The Blockchain then pays the network provider from the service provider's account.</td><td><ul><li>Provides trustful payment in trustless environments.</li></ul></td></tr><tr><td>Access flexibility</td><td>The access control attributes are based on the agreement between the user and the service provider.</td><td><ul><li>Meets the user's, the service provider's and the network provider's needs</li></ul></td></tr><tr><td>Removing Single point of Failure</td><td>All of this access control procedure is done via distributed and fault-tolerant smart contracts; there is no central authority for access control.</td><td><ul><li>High availability</li><li>High fault tolerance</li></ul></td></tr><tr><td>Immutability</td><td>Thanks to checking the block hash reference in the Blockchain, and the requirement of consensus for any change in the system, the rules, permissions, and user's service level agreement cannot be altered.</td><td><ul><li>Reduces the probability of misuse</li><li>Improves the level of trust in the whole system</li></ul></td></tr><tr><td>Accountability</td><td>Traceability of access requests increases the accountability of the system. Also, the users' signatures on contracts and transactions remove the possibility of access or request denial.</td><td><ul><li>Non-repudiation</li><li>Traceability</li></ul></td></tr></tbody></table>

<table><caption>TABLE 3. Symbols and their descriptions</caption><thead><tr><th>Symbol</th><th>Description</th></tr></thead><tbody><tr><td>Attr<sub>u</sub></td><td>User access attributes</td></tr><tr><td>Attr<sub>sp</sub></td><td>The attributes and identifiers of service provider</td></tr><tr><td>Addr<sub>admin</sub></td><td>Address of System admin</td></tr><tr><td>Addr<sub>KAddr</sub></td><td>Known Addresses contract address</td></tr><tr><td>Addr<sub>sp</sub></td><td>The address of service provider</td></tr><tr><td>Addr<sub>u</sub></td><td>User's Blockchain address</td></tr><tr><td>Addr<sub>SPDB</sub></td><td>Service_Provider_DB contract address</td></tr><tr><td>Addr<sub>ACM</sub></td><td>ACollateral contract address</td></tr><tr><td>Addr<sub>Reg</sub></td><td>Registration contract address</td></tr><tr><td>Addr<sub>User_Contract</sub></td><td>User and service provider's contract</td></tr><tr><td>Addr<sub>Contract<sub>sp, np</sub></sub></td><td>Service provider and network provider's contract</td></tr><tr><td>Addr<sub>UCDB</sub></td><td>User_Contracts_DB contract</td></tr><tr><td>Addr<sub>NP</sub></td><td>Network provider</td></tr><tr><td>CAddr</td><td>All addresses stored in the contract Addr<sub>KAddr</sub></td></tr><tr><td>Code<sub>sp</sub></td><td>The unique code of sp to retrieve its information</td></tr><tr><td>URL<sub>reg<sub>sp</sub></sub></td><td>The URL for registration in sp</td></tr><tr><td>URL<sub>con<sub>sp</sub></sub></td><td>The URL for connection to the sp</td></tr><tr><td>Hash(M)</td><td>Representation of hash function (Keccak256)</td></tr></tbody></table>

$$CAddr \leftarrow^{name_{contract}} Addr_{contract}$$

name<sub>contract</sub> is in string format and has a set of predefined values (Table 4 in the setup step). It is important to mention that we designed this contract to 1) avoid using hardcoded addresses and resolve the maintainability [37] defects of smart contracts, and 2) having a list of predefined addresses that let us state-specific requirements per functions.

2) **SP_NP_Contract**: A unique contract between the network provider and a service provider. Since the service provider must pay for the user's connection, the Internet price per service unit is declared in this contract. Also, the amount of network providers owe from the service provider is indicated in *Owe*.

3) *Service_Provider_DB* is a distributed database to store the attributes of all registered *sp* as a mapping of *Code<sub>sp</sub>* to a tuple of five parameters:

$$Attr_{sp} \leftarrow^{Code_{sp}} (Addr_{sp}, URL_{reg_{sp}}, URL_{con_{sp}}, Addr_{Contract_{sp, np}}, Balance) \quad (7)$$

*Code<sub>sp</sub>* is a unique identifier to retrieve the *Attr<sub>sp</sub>*. We use an incremental function to generate *Code<sub>sp</sub>* (i.e., *Code<sub>sp</sub>* = *i*, where *i* is the number of registered *sp*). two URLs are the web addresses for user's registration or connection, and *Addr<sub>Contract<sub>sp, np</sub></sub>* is the address of *SP_NP_Contract* between *sp* and *np*.

4) **User_Contract**: this is a unique contract between a user and a specific service provider to which that the user is subscribed to. These contracts store the user's access attributes, which are used to check the user's eligibility to use the service. The stored attributes of user *u* in these smart contracts are:

$$Attr_u \leftarrow^{Addr_u} (ExpT, Balance, Price_{service})$$

Addr<sub>u</sub> is the address of *u* in the Blockchain. *ExpT* is the expired time of the subscription of *u* in *sp*. In the first registration *ExpT* is:

$$ExpT = block\_time + (t \times 86400)$$

where block time is the Unix timestamp of the contract deployment and *t* is the number of subscription days. *Balance* indicates the remaining balance of *u* to use the service in *sp*, and *Price<sub>service</sub>* is the price of using a predefined unit of the service (e.g., the price of each video available on the website of *sp*). In this contract, there is a flag as *Active<sub>User_Contract</sub>* which indicates if the user is currently using the service or not.
5) User_Contracts_DB stores the Addr$_{User\_Contract}$$_{u,sp}$ for each pair (u, sp). To store these data, we defined a structure for a user's contract as a tuple of two parameters:

$$UC\_str = (Addr_{User\_Contract}u, sp, Code_{sp}).$$

Addr$_{User\_Contract}$$_{u,sp}$ is the address of the contract deployed between u and sp. A user may have registered with several service providers, and so to have all the contracts of u, we map the Addr$_{u}$ to the set of UC\_str:

$$All\_UC = \left\langle \overleftarrow{Addr}_u \right\{ UC\_str_{u,sp_1}, \dots, UC\_str_{u,sp_n} \}$$
where n is the number of service providers to which the user is registered.

6) Registration aims to register the users and service providers in the system. To do so, after the registration of sp, its data is added to the Service\_Provider\_DB contract, and after registration of u in service s, the address of deployed User\_Contract will be added to the User\_Contracts\_DB.

7) AC\_Manager handles the access control and the payment. When the user requests access to a service, this contract validates the request based on the user's access control attributes stored in User\_Contract$_{u,sp}$. Also, after the user terminates their use of the service, this contract manages the payment to np.

## B. SETUP STEP

The first step in the deployment of our system is the setup. This is where we deploy the smart contracts, store their addresses in Known\_Addresses, a tamper-proof safe contract, and initiate the system by the required variables. First of all, the system admin deploys the Known\_Addresses contract. Initially, the contract stores Addr$_{admin}$ as the owner. After deploying the Known\_Addresses, the procedure for the deployment of other single contracts is as follows. The deployment of Service\_Provider\_DB, is given as example. To deploy Service\_Provider\_DB, the admin uses the Addr$_{KAddr}$ as the initial parameter. The constructor of the Service\_Provider\_DB calls a function of Addr$_{KAddr}$ by sending a dedicated name (i.e., 'SPDB') to add its address. Known\_Addresses checks the input and if there is no other address stored with that name in CAddr, it stores the new address. After deployment of all single contracts, the stored values in the Known\_Addresses contract are as Table 4. Note that, the Addr$_{NP}$ is a predefined address that is added by the admin to the system and cannot be changed.

## C. REGISTRATION STEP

In this step, the user or service provider is registered in the system. The registration process for the user and also for the service provider is given below.

### 1) SERVICE PROVIDER REGISTRATION

In this step, a service provider sp will be registered in the system. Since the sp should pay the network provider (np) on behalf of the user, registration of service providers is done

<table><caption>TABLE 4. Initial parameters in Known\_Addresses</caption><thead><tr><td>Identifier</td><td>Parameter</td><td>Address of</td></tr></thead><tbody><tr><td>'Owner'</td><td>Addr<sub>admin</sub></td><td>System admin</td></tr><tr><td>'KAddr'</td><td>Addr<sub>KAddr</sub></td><td>Known\_Addresses contract</td></tr><tr><td>'SPDB'</td><td>Addr<sub>SPDB</sub></td><td>Service\_Provider\_DB contract</td></tr><tr><td>'ACM'</td><td>Addr<sub>ACM</sub></td><td>AC\_Manager contract</td></tr><tr><td>'REG'</td><td>Addr<sub>Reg</sub></td><td>Registration contract</td></tr><tr><td>'UCDB'</td><td>Addr<sub>UCDB</sub></td><td>User\_Contracts\_DB contract</td></tr><tr><td>'NP'</td><td>Addr<sub>NP</sub></td><td>Network provider</td></tr></tbody></table>

after the agreement of np and sp for the internet and medium price. Following is the process of registration (see Fig. 5).

1) sp connect to np and ask for the registration token. In this process, sp and np agree on a price (off-chain) and they define the URLs which are free to connect.

2) np generates a one-time registration token for the sp, using the agreed price and the address of both parties. The token (T) is:

$$T = \text{Hash}(Addr_{NP} \parallel Addr_{sp} \parallel \text{price}_{\text{internet}}) \quad (8)$$

the hash function is Ke'accak256 [38].

3) np sends the generated token to Registration contract. This contract checks the sender of the token (Algorithm 1) and if it is Addr$_{NP}$, the token is added to the list of valid tokens for service provider registration.

4) sp calls AddNewSP() from the Registration (Algorithm 2). As shown in Algorithm 2, the Registration checks the validity of the token by generating another token with the same algorithm (Algorithm 2, L:2) and compares it with the token which is sent by the np in step 3. If both tokens are the same and the token is valid, firstly it revokes the token and generates Code$_{sp}$, the unique identifier for sp.

5) Registration contract deploys a SP\_NP\_Contract, and stores the agreement price of sp and np in this contract. Note that, because this contract is deployed after checking the validity of the token, and the price$_{internet}$ is a parameter of the token, then it cannot be changed by sp. To deploy the SP\_NP\_Contract, the Addr$_{KAddr}$ is sent to the contract. If the caller of the contract is Registration, the SP\_NP\_Contract is deployed and its address is sent to the Registration.

6) Registration gets the Addr$_{SPDB}$ and calls AddSP() from Service\_Provider\_DB to insert service provider's attribute in the list of registered service providers (Algorithm 2, L:13, Algorithm 3).

7) As shown in lines 1 to 6 of Algorithm 3, there are two requirements to execute AddSP(). First, this function must be called by Registration. To check this, Check\_Caller (Algorithm 1) is called. Second, another service provider with Addr$_{sp}$ must not exist (Algorithm 3, L: 4-8). If both of the requirements were satisfied, sp will be added to the system (Algorithm 3, L: 9)
<figure><img src="image_8.png" /><figcaption>FIGURE 5. Service Provider registration procedure</figcaption></figure>

<table><thead><tr><th colspan="2">Algorithm 1 Check_Caller</th></tr><tr><th>Input</th><th>name</th></tr><tr><th>Output</th><th>Boolean</th></tr></thead><tbody><tr><td>1:</td><td>Address ← instance of Addr<sub>KAddr</sub></td></tr><tr><td>2:</td><td>value ← Address模Address(name)</td></tr><tr><td>3:</td><td>return (msg sender == value)</td></tr></tbody></table>

<table><thead><tr><th colspan="2">Algorithm 2 AddNewSP</th></tr><tr><th>Input</th><th>Name, URL<sub>reg<sub>sp</sub></sub>, URL<sub>con<sub>sp</sub></sub>, price<sub>internet</sub>, Token</th></tr><tr><th>Output</th><th>Boolean</th></tr></thead><tbody><tr><td>1:</td><td>Addr<sub>NP</sub> ← Known_Addresses模Address('NP')</td></tr><tr><td>2:</td><td>T' = hash(URL<sub>reg<sub>sp</sub></sub> || msg sender || price<sub>internet</sub>)</td></tr><tr><td>3:</td><td>if T' ≠ Token</td></tr><tr><td>4:</td><td>throw</td></tr><tr><td>5:</td><td>end if</td></tr><tr><td>6:</td><td>if !validSPtoken[Token]</td></tr><tr><td>7:</td><td>throw</td></tr><tr><td>8:</td><td>end if</td></tr><tr><td>9:</td><td>validSPtoken[Token] ← false</td></tr><tr><td>10:</td><td>Addr<sub>Contract<sub>sp, np</sub></sub> ← deployNewContract(price<sub>internet</sub>)</td></tr><tr><td>11:</td><td>Code<sub>sp</sub> = counter<sub>registered</sub></td></tr><tr><td>12:</td><td>counter<sub>registered</sub> += 1</td></tr><tr><td>13:</td><td>Service_Provider_DB.AddSP(msg sender, URL<sub>reg<sub>sp</sub></sub>, URL<sub>con<sub>sp</sub></sub>, Code<sub>sp</sub>, Addr<sub>Contract<sub>sp, np</sub></sub>)</td></tr></tbody></table>

## 2) USER REGISTRATION

User registration in the system is done by registering for a service of the specific service provider (sp). To register the user u, after selecting the sp, u asks Registration to get URL<sub>reg<sub>sp</sub></sub>. Registration sends URL<sub>reg<sub>sp</sub></sub> to the user, and

<table><thead><tr><th colspan="2">Algorithm 3 AddSP</th></tr><tr><th>Input</th><th>Addr<sub>sp</sub>, URL<sub>con<sub>sp</sub></sub>, URL<sub>reg<sub>sp</sub></sub>, Code<sub>sp</sub>, Addr<sub>Contract<sub>sp, np</sub></sub></th></tr><tr><th>Output</th><th>Boolean</th></tr></thead><tbody><tr><td>1:</td><td>if !Check_Caller('REG')</td></tr><tr><td>2:</td><td>throw</td></tr><tr><td>3:</td><td>end if</td></tr><tr><td>4:</td><td>while (i ≤ Code<sub>sp</sub>)</td></tr><tr><td>5:</td><td>if SPAddresses[i].address ≠ null</td></tr><tr><td>6:</td><td>throw</td></tr><tr><td>7:</td><td>end if</td></tr><tr><td>8:</td><td>end while</td></tr><tr><td>9:</td><td>SPAddresses[Code<sub>sp</sub>] ← add ← (Addr<sub>sp</sub>, URL<sub>reg<sub>sp</sub></sub>, URL<sub>con<sub>sp</sub></sub>, Addr<sub>Contract<sub>sp, np</sub></sub>)</td></tr></tbody></table>

then u can subscribe to a service and get the one-time registration token to store a unique contract in the Blockchain. The user registration steps (Fig. 6) are given next.

1) u sends the subscription request to URL<sub>reg<sub>sp</sub></sub> accompanied by Addr<sub>u</sub>. u Then, selects her preferred subscription plan and performs an off-chain payment. This plan defines ExpT, Price<sub>service</sub>, and the user's payment indicates initial Balance.

2) sp generates a one-time registration token and sends it to u. The token (T) is the hash amount of the agreement of u and sp on access parameters as well as Addr<sub>sp</sub> and Addr<sub>u</sub>. The token is generated as:

$$T = Hash \left( ExpT \parallel Balance \parallel Addr_u \parallel Price_{service} \parallel Code_{sp} \parallel Addr_{sp} \right) \quad (9)$$

3) sp sends the T to Registration contract to add it to the valid registration tokens. After checking the existence of the service provider, Registration adds the token to valid registration tokens. Note that, adding the token in Blockchain, prevent the user from misbehavior to add arbitrary data in the system.

4) The function RegisterNewUser() is called by u from Registration with the agreed parameters for access accompanied by Code<sub>sp</sub> and T (Algorithm 4).

5) Registration generates a hash amount (T') based on received data and with the same algorithm of sp. The generated hash is calculated as Algorithm 4, L:3. It is important to mention that all addresses (e.g., Addr<sub>SPDB</sub>) are fetched from Known_Addresses, but to make the figures simple, we avoid mentioning the unnecessary details.

6) If T == T' and the token exists in valid registration tokens, Registration deploys a contract between u and sp (User_Contract<sub>u, sp</sub>) with pre-mentioned parameters. To do so, decided parameters and Addr<sub>KAddr</sub> is sent to the constructor of User_Contract<sub>u, sp</sub>.
<figure><img src="image_9.png" /><figcaption>FIGURE 6. User registration procedure</figcaption></figure>

<table><thead><tr><th>Algorithm</th><th>Input</th><th>Output</th></tr></thead><tbody><tr><td>4</td><td>RegisterNewUser</td><td>Boolean</td></tr><tr><td>1</td><td>Addr<sub>SPDB</sub></td><td>KnownAddress.getAddress('SPDB')</td></tr><tr><td>2</td><td>Addr<sub>sp</sub></td><td>Service_Provider_DB.getAddress(Code<sub>sp</sub>)</td></tr><tr><td>3</td><td>T' = Hash(ExpT||Balance||Price<sub>service</sub>||Addr<sub>sp</sub>||msg sender)</td><td></td></tr><tr><td>4</td><td>if T' ≠ Token</td><td></td></tr><tr><td>5</td><td>throw</td><td></td></tr><tr><td>6</td><td>end if</td><td></td></tr><tr><td>7</td><td>if !validUserToken[Token]</td><td></td></tr><tr><td>8</td><td>throw</td><td></td></tr><tr><td>9</td><td>end if</td><td></td></tr><tr><td>10</td><td>validUserToken[Token]</td><td>false</td></tr><tr><td>11</td><td>Addr<sub>User_Contract<sub>u,sp</sub></sub></td><td>deployNewContract(ExpT, Balance, Price<sub>service</sub>, Addr<sub>KAddr</sub>)</td></tr><tr><td>12</td><td>SPDB.increaseBalance(Addr<sub>sp</sub>, Balance)</td><td></td></tr><tr><td>13</td><td>User_Contracts_DB.addNewContract(msg sender, Code<sub>sp</sub>, Addr<sub>User_Contract<sub>u,sp</sub></sub>)</td><td></td></tr></tbody></table>

7) The newly deployed contract must be added in the User_Contracts_DB. So, AddNewContract() is called by Registration, and Addr<sub>u</sub>, Code<sub>sp</sub> and Addr<sub>User_Contract<sub>u,sp</sub></sub> are sent as inputs.

8) The permission of adding a new contract in the database is limited to Registration, therefore Check_Caller('REG') is called and if this requirement passed, the new contract will be pushed to the list of user's contracts.

9) To finish the registration procedure, the available balance of sp must be increased by the user's payment. To do so, Registration calls the increaseBalance() from Service_Provider_DB. The function, after checking the caller (Algorithm 1) and make sure that it is Registration, then increases the balance of sp by Balance.

## D. ACCESS CONTROL

In this step, the registered user u requests for connection to the service of sp. The Attribute-based Access Control

solution to share the service with the user without internet consumption is given in the following steps (Fig. 7).

1) by sending Code<sub>sp</sub>, u calls the AccessToService() function of AC_Manager and a hash amount (Algorithm 5). As explained in Fig. 7, to have a trustful connection between u and sp, after authorization, a token is sent to the user for further connection. To generate the unique and unrecoverable token, in the first step of connection, the user generates a random nonce and calculates its hash with Keccak256.

2) As the first requirement, the user must have a deployed contract with sp. So, AC_Manager gets Addr<sub>User_Contract<sub>u,sp</sub></sub> from User_Contracts_DB (Algorithm 5, L: 1-4).

3) Using Code<sub>sp</sub> AC_Manager gets the URL<sub>con<sub>sp</sub></sub> and the Addr<sub>Contract<sub>sp,np</sub></sub>.

4) One of the environmental attributes to validate the user's access to the service is the balance of sp. This attribute guarantees that as long as np provides the network, the payment is performed safely based on their agreement in SP_NP_Contract. So, the Price<sub>service</sub> is fetched.

5) the user's access attributes (i.e., ExpT, Price<sub>service</sub>, Balance) is fetched from User_Contract<sub>u,sp</sub> by AC_Manager (Algorithm 5, L: 8).

6) To connect the user to the service, all the subject, object, and environment attributes must be validated. The attributes are shown in Fig. 8. Assume that V<sub>SA,OA</sub> is the validation result for the subject and object attributes and that V<sub>EA</sub> is the validation result for the environment attributes. The final validation result based on the predefined policy by the service provider is V as equations (10) - (12). V<sub>SA,OA</sub> is validated in step 4. Algorithm 5, lines 9-11 ensures that the system can safely pay np after using the service, and lines 12-14
user in the first step of connection. the generation of token T is done as follows:

$$T = \text{Hash}(\text{msg sender} \parallel \text{Addr}_{sp}) \parallel \text{hash}(\text{nonce})$$

In this step also AC_Manager calls Activate() function with 'true' parameter to set the flag active of User_Contract_u,sp to indicate that the user is using the service. Activate() function is limited to be able to call only by AC_Manager. (Algorithm 5, L: 21, 22).

8) To be able to pay the np, we need to design a payment procedure that is trustful; it means np can be sure that its payment will be performed after a successful connection. To satisfy this requirement, after user validation, AC_Manager blocks Priceinternet in the contract, automatically. So, three parties (u, np, and sp) who do not know each other but accept the AC_Manager, can safely trust the process. To block the token, AC_Manager calls TransferToACM() function of Service_Provider_DB to virtually transfer Priceinternet from Addrsp to AddrACM.

9) TransferToACM() is limited to be able to call only by AC_Manager. To pass this requirement, the Check_Caller('ACM') is called by the function. If it passed, The Priceinternet will be decreased from sp. Then this amount is increased in the balance on the AC_Manager (Algorithm 5, L: 20).

10) The URLcons_p and the token are sent to the user.

11) The user sends a connection request to the URLcons_p accompanied by {T, nonce, Addr_u}. Note that, in this step, the user sends the nonce itself (not it's hash). sp sends a validation request to the AC_Manager via these parameters.

12) To check the validity of the token AC_Manager calculates T' as following:

$$H = \text{Hash}(\text{nonce}) \\ T = \text{Hash}(\text{Addr}_u \parallel \text{msg sender}) \parallel H$$

If the T is equal to T' (T == T'), and the token is valid, AC_Manager will answer to the sp that the token is valid, and also it will remove the token from valid tokens. If the token is valid, the user can access the service. It is important to mention that the token is unrecoverable, because, in step 1, the user sends the hash amount on the nonce, and in step 11, sends the nonce itself. In this solution, the attacker should be aware of the nonce, to be able to act maliciously.

## E. PAYMENT

After u has used the service and confirmed the termination, the payment to np must be performed. The payment procedure (Fig. 9) is listed below:

1) u calls the Termination() function of AC_Manager and sends Code sp as the input.

2) AC_Manager gets the Addr User_Contract_u,sp from User_Contracts_DB. Also, it gets Addr Contract sp, np from Service_Provider_DB.

3) Executing the rest of the payment procedure depends on the trueness of the flag Active in

Addr User_Contract_u,sp . So, this parameter and Price service are fetched from Addr User_Contract_u,sp .

4) AC_Manager changes the active flag to 'false' and updates the user's available balance in the contract. To do so, it calls Activate() function with 'false' parameter and updateBalance() function. The permission of calling updateBalance() function is limited to AC_Manager. So, Addr User_Contract_u,sp calls the Check_Caller('ACM'). If the requirement passed, the balance of the user is decreased by Price service . It also changes the flag to false .

5) To pay the np using the blocked money in AC_Manager, firstly the contract must know how much to pay. So, it gets the Price internet from SP_NP_Contract .

6) Then AC_Manager increases the balance of SP_NP_Contract by Price internet and decreases this amount from the balance of AC_Manager. It is important to mention that the network provider can call the checkout function of SP_NP_Contract to withdraw its balance (i.e., Owe) from that. The Checkout() function checks the caller, and if it is the np, it transforms the amount Owe from Addr sp to the Addr NP .

## F. UPDATE

This subsection is not part of the regular procedure of access control. However, we believe that some updates will be needed when using the system. Two scenarios are presented.

### 1) UPDATE USER CONTRACT

Assume that user u aims to renew her contract with sp. u is already registered and has Addr User_Contract_u,sp . The update procedure is similar to registration and is as follows.

First, u sends the update request to Registration contract. Registration checks the existence of a contract between sp and u. if the contract exists, URL reg sp will be sent to the user. The next steps are the same as Fig. 6, unless in two steps. 1) step 6 of user registration; In the update, instead of deploying the contract, the update() function is called by the Registration (Algorithm 6), and 2) Steps 7, 8 of Fig. 6 is not needed. As shown in Algorithm 6, to update the expiration time, we check the user's current expiration time, and based on that, the ExpT is updated. Balance will increase by the new balance and Price service is also updated to new values.

### 2) UPDATE THE ADDRESSES

As mentioned before, one of the well-known defects of smart contracts is maintainability [37]. To overcome this problem, we provided a solution to replace an old contract with a new one. The changes can be used to upgrade the system functionality, fix some of the bugs, or make it compatible with new needs. Fig. 10, lists the contracts with the addresses that can be changed and those that cannot. Contracts that are used as distributed databases are permanent and cannot be changed because they store the user's and the service provider's data.
<figure><img src="image_10.png" /><figcaption>FIGURE 9. Payment procedure</figcaption></figure>

<table><thead><tr><th colspan="2">Algorithm 6 update</th></tr><tr><th>Input</th><th><i>ExpT</i>, <i>_Balance</i>, <i>_Price</i><sub>service</sub></th></tr><tr><th>Output</th><th>Boolean</th></tr></thead><tbody><tr><td>1:</td><td>if !<i>Check_Caller</i>(<i>'REG'</i>)</td></tr><tr><td>2:</td><td>throw</td></tr><tr><td>3:</td><td>end if</td></tr><tr><td>4.</td><td>if <i>ExpT</i> > <i>block.timestamp</i></td></tr><tr><td>5:</td><td><i>ExpT</i> ← <i>ExpT</i> + (<i>_ExpT</i> × 86400)</td></tr><tr><td>6:</td><td>else</td></tr><tr><td>7:</td><td><i>ExpT</i> ← <i>block.timestamp</i> + (<i>_ExpT</i> × 86400)</td></tr><tr><td>8:</td><td>end if</td></tr><tr><td>9:</td><td><i>Balance</i> += <i>_Balance</i></td></tr><tr><td>10:</td><td><i>Price</i><sub>service</sub> = <i>_Price</i><sub>service</sub></td></tr><tr><td>11:</td><td>return true</td></tr></tbody></table>

<figure><img src="image_11.png" /><figcaption>FIGURE 10. Permanent and changeable addresses</figcaption></figure>

AC\_Manager and Registration are changeable and the replacement procedure is as follows:

1) Admin calls the function `UpdateAddress()` from `Known_Addresses`.

2) `UpdateAddress()` checks the caller of the function, and if it is the admin, it verifies that the request is to change the address of `AC\_Manager` or `Registration`. If both requirements are passed, it adds a new variable in `CAddr` (`REG` is given as example):

$$ 
\begin{aligned}
CAddr &\leftarrow 'Temp' CAddr['REG'] \\
CAddr &\leftarrow 'REG' 0x0
\end{aligned}
\qquad (13) $$

Having a temporal address in the list helps the system to keep the old address in case of any further problem, and writing the address of zero on the existing parameter allows the admin to generate other contracts of `<Contract_name>`. Admin can deploy the new contract. As mentioned before, the constructor of the contract will add itself to the `Known_Addresses`.

3) When the updated system has proved to function, the admin can remove the temporal address.

## VI. EXPERIMENTS

To evaluate the feasibility of the proposed method, we designed a use case in which the user uses her mobile connectivity (i.e., cellular network) to use the system. As mentioned earlier, we assume that the user's authentication is done by the network provider. To do so we simulated a cellular network environment that the user connects. In this section, we describe the testbed implementation, the architecture of the network, and the implementation of smart contracts. Then we present the performance of the proposed method. We also analyze the security of the system through several thread scenarios.

### A. EXPERIMENT ENVIRONMENT

To simulate the complete procedure of the user connection, access control, and termination of the connection, we need to deploy an environment that supports the connection of the user to the cellular network as well as a Blockchain.

Table 5 lists the hardware and software specifications of the test environment. It is important to mention that, as stated in step 2.a of Fig.4, the user's connection to the system is done after the authentication of the network provider. The user authentication is needed to guarantee that the user is already subscribed to the network. Due to the widespread usage of 5G networks [39], we choose this technology as our
<table><caption>TABLE 5. Environment specifications</caption><thead><tr><th>Part</th><th>Parameter</th><th>Specification</th></tr></thead><tbody><tr><td colspan="3"><strong>Hardware</strong></td></tr><tr><td rowspan="3">5G RAN and Core</td><td>CPU</td><td>Intel quad-core at 2.9 GHz</td></tr><tr><td>RAM</td><td>16 GB</td></tr><tr><td>SDR board</td><td>USRP B210</td></tr><tr><td rowspan="3">Blockchain</td><td>CPU</td><td>Intel i7 Dual-core 1.6GHz</td></tr><tr><td>RAM</td><td>6 GB</td></tr><tr><td>Hard Disk</td><td>128GB SSD</td></tr><tr><td colspan="3"><strong>Software</strong></td></tr><tr><td rowspan="2">5G RAN</td><td>OAI-RAN</td><td>master branch release v1.1.0</td></tr><tr><td>OS</td><td>Ubuntu 16.04-low latency kernel</td></tr><tr><td rowspan="5">Blockchain</td><td>OS</td><td>Xubuntu</td></tr><tr><td>Ganache-cli</td><td>6.12.2</td></tr><tr><td>Ganache-core</td><td>2.13.2</td></tr><tr><td>Web3j</td><td>1.4.1</td></tr><tr><td>Solc</td><td>0.8.2</td></tr></tbody></table>

testbed.

The cellular networks consist of two main parts: Radio Access Network (RAN) and Core Network (CN). To simulate the 5G network, we used OAI (Open Air Interface) consisting of RAN and CN [40]. OAI is open-source software that implements cellular network functions of the RAN named by OAI-RAN and the core named by OAI-CN. To build the RAN part (i.e., the network provider's base station), the OAI-RAN was executed on a PC that is connected to an SDR (software-defined radio) board for radio communications through a USB3 interface. To implement our proposed method, we focused on the CN and implemented a gateway that will send the request from the CN to the Blockchain and authenticate the user. In this system, the user's request is sent to the 5G RAN (Fig. 11) and will be authenticated by the gateway (Fig. 11, 5G Core).

Authentication of the user's equipment and the network provider is done by the AKA procedure (i.e., the existing authentication model in the cellular networks [40]). Once the user has been authenticated, CN sends the user's request to the Blockchain through the gateway (5G core in Fig. 11).

In the Blockchain, we utilized a private Ethereum that allows us to assess the system's performance using a variety of parameters. The smart contracts are written in Solidity language [41]. Solidity supports complex variables such as the mapping of structures, and it provides the capability of defining different requirements per function; also, it is a Turing-complete language (i.e., can be used to simulate any Turing machine).

## B. PERFORMANCE ANALYSIS

The performance analysis of the proposed method is done in two parts: 1) By assessing the execution and transaction costs of the transactions and processes, and 2) By evaluating the scalability of the system in terms of the increasing number of concurrent connection requests.

<figure><img src="image_12.png" /><figcaption>FIGURE 11. The architecture of the testbed</figcaption></figure>

### 1) TRANSACTION COST

For the first analysis, we calculated the GAS price of the processes. The GAS is the fee that must be paid by the sender to submit transactions to the Ethereum network. Calculation of the GAS is formulated in [42]. The cost that is mentioned in this part is the cost of sending a transaction of a contract to the Ethereum blockchain (i.e., transaction cost) [42]. The GAS cost is defined in Gwei (i.e., as $10^{(-9)}$ ETH). Table 6 shows the GAS cost in different processes (i.e., in setup, user registration, service provider registration, access control, and payment). It is important to mention that in private or consortium Blockchains, no currency is required to process or validation of transactions [43]. To make the costs in the public network more tangible, we calculated the price in USD (on 8/04/2021 the average price over 24H was $1,933.91 for each ETH).

### 2) SCALABILITY

To measure scalability, we assess the throughput, and the latency [44], [45]. Throughput can be calculated as:

$$Throughput = \frac{|Tx|}{t} \qquad (14)$$

where $Tx$ is the set of all transactions, $|Tx|$ is the number of transactions, and $t$ is the required time to handle them. latency is another measure similar to throughput which clarifies the average required time to handle one transaction.

$$Latency = \frac{t_f - t_s}{|Tx|} \qquad (15)$$

Where $t_f$ is the finishing time of simulation and, $t_s$ is the time in which we started the simulation. It is important to mention that simulation here means the time of starting to send concurrent requests and finishing to receive the transaction receipt of all of them.

The scalability of the system can be defined as changes in throughput or latency when altering a parameter [46]. Different parameters are used to measure the throughput and latency (see Table 7). It is important to mention that adding the one-time registration token for the service provider cannot be executed concurrently, because only the network provider is eligible to add the token in the Blockchain, and we designed one network provider in the system. One node cannot send concurrent requests to the system without waiting for the receipt of the previous transaction.
<table><caption>TABLE 6. GAS price of processes and transactions of the proposed method</caption><thead><tr><th>Process</th><th></th><th>Transactions</th><th>Tx cost</th><th>Price ($)</th></tr></thead><tbody><tr><td rowspan="3">Registration</td><td>Service Provider</td><td>Add valid token</td><td>21374</td><td>0.04</td></tr><tr><td>Registration</td><td>Registration and deployment of contract</td><td>369490</td><td>0.73</td></tr><tr><td>User Registration</td><td>add valid token</td><td>28079</td><td>0.05</td></tr><tr><td rowspan="2">Access Control</td><td>Access validation</td><td>Registration and deployment of contract</td><td>485536</td><td>0.96</td></tr><tr><td></td><td>ABAC and token generation</td><td>104227</td><td>0.20</td></tr><tr><td rowspan="2">Payment</td><td></td><td>Token checking by SP</td><td>14661</td><td>0.02</td></tr><tr><td></td><td>Pay the network provider</td><td>81228</td><td>0.16</td></tr></tbody></table>

Fig. 12 (a-e) depicts the latency of the system for different block sizes (BS) and block times (BT). This process is also done to assess the throughput, which is shown in Table 8. As shown in Fig. 12 (a-e), systems latency is almost stable for $C \ge 200$ (i.e., when concurrent requests are more than 200). Therefore, based on the definition of scalability, we can claim that the system is scalable and can maintain low latency, based on system configuration in a large-scale request environment.

To analyze the system throughput Table 7 is provided. As shown in the table, by increasing the BS and decreasing the BT to a threshold of the system requirement, the throughput will increase (see Table 7 for $BS = 30$ and $BT = 5$). For example in $BS = 30, BT = 5$ (low complexity of consensus puzzle and a large number of transactions fit in each block) the throughput has the highest amount, while $BS = 15, BT = 15$ (high complexity of consensus puzzle and the small number of transactions fit in each block) has the lowest throughput. But an important issue in this configuration is the system's security; it means decreasing the block time of the Blockchain results in an easier consensus puzzle, that can increase the risk of integrity violation in the PoW model. Based on the requirements of the system, the admin must specify a trade-off between consensus complexity and throughput.

It is important to mention that in $BS = 15, BT = 15$, due to several exceptions of web3j library, we could not reach a precise result for parameters in concurrent request 700. Based on our observation, because the difficulty of consensus puzzle is high and Block size is in minimum, web3j library throws time-out exception. Therefore, in Fig. 12 (a-e), we exceptionally finished the assessment of this configuration in 500.

To assess the latency and throughput of the system for the execution of different processes, Fig. 13 (a-b) depicts these two parameters in the different concurrent requests for $BT = 10, BS = 30$. As shown in Fig. 13, user registration, ABAC procedure, and payment are mostly need more time for execution, while inserting the valid token for registration and service provider registration are the fastest procedures.

<table><caption>TABLE 7. Parameters of analysis</caption><thead><tr><th>Parameter</th><th>values</th><th>description</th></tr></thead><tbody><tr><td>Concurrent requests (C)</td><td>50, 100, 200, 500, 700</td><td>The number of the virtual clients in the system. all requests are sent concurrently and all the virtual clients are full nodes that participate in consensus</td></tr><tr><td>Block Size (BS)*</td><td>15, 30</td><td>The number of transactions fitting in one block.</td></tr><tr><td>Block time (BT)</td><td>5, 10, 15</td><td>The difficulty of consensus puzzle which leads to extraction of blocks in predefined time. The average block time for Ethereum is 13.12 seconds on 08/04/2021.</td></tr></tbody><tfoot><tr><td colspan="3">*in real-world public Blockchains, this parameter is higher, but due to the limitation of the libraries, the mentioned values are tested.</td></tr></tfoot></table>

### 3) DISCUSSION ON EXPERIMENTS

In the previous section, we analyzed the system performance and scalability for at most 700 concurrent requests. In the real-world implementation of our use-case, it is important to assess system performance when an enormous number of requests and smart contracts exist in the system. Regarding this assessment, two features can be taken into account: 1) latency and throughput of the system, and 2) storage scalability.

* **Throughput and latency:** As shown in Fig. 12 and Table 8, the system is highly scalable in terms of the number of requests. Also, an increasing number of user's in the system results in increasing the number of validators. Due to these two reasons, we can state that the system's latency and throughput are not highly dependent on the number of requests.

* **Storage:** Increasing number of transactions, smart contracts, and Blockchain logs, need high storage space for full-nodes in the system. For the time being, in the current version, we store the logs, transactions, and smart contracts directly into the Blockchain, which can be a challenging issue in the real implementation of the system. This issue is discussed in the Section VII-E.
<table><caption>TABLE 8. System throughput with different parameters</caption><thead><tr><th>P</th><th colspan="3">SP registration</th><th colspan="3">Add registration token</th><th colspan="3">User registration</th><th colspan="3">ABAC procedure</th><th colspan="3">Payment</th></tr><tr><th>BT</th><th>5</th><th>15</th><th></th><th>5</th><th>15</th><th></th><th>5</th><th>15</th><th></th><th>5</th><th>15</th><th></th><th>5</th><th>15</th><th></th></tr><tr><th>BS C</th><th>15</th><th>30</th><th>15</th><th>30</th><th>15</th><th>30</th><th>15</th><th>30</th><th>15</th><th>30</th><th>15</th><th>30</th><th>15</th><th>30</th><th>15</th><th>30</th></tr></thead><tbody><tr><td>50</td><td>1.64</td><td>3.20</td><td>0.82</td><td>1.63</td><td>1.63</td><td>3.20</td><td>0.82</td><td>1.62</td><td>1.62</td><td>3.20</td><td>0.77</td><td>1.44</td><td>1.63</td><td>3.19</td><td>0.77</td><td>1.43</td><td>1.64</td><td>3.19</td><td>0.78</td><td>1.47</td></tr><tr><td>100</td><td>1.62</td><td>2.05</td><td>0.89</td><td>1.30</td><td>2.17</td><td>3.24</td><td>0.93</td><td>1.63</td><td>2.13</td><td>3.21</td><td>0.87</td><td>1.45</td><td>2.16</td><td>3.19</td><td>0.87</td><td>1.45</td><td>2.17</td><td>3.22</td><td>0.88</td><td>1.47</td></tr><tr><td>200</td><td>1.26</td><td>1.69</td><td>0.87</td><td>1.43</td><td>2.57</td><td>4.24</td><td>0.93</td><td>1.85</td><td>2.14</td><td>4.05</td><td>0.88</td><td>1.62</td><td>2.14</td><td>3.22</td><td>0.88</td><td>1.62</td><td>2.17</td><td>4.16</td><td>0.89</td><td>1.66</td></tr><tr><td>500</td><td>0.78</td><td>4.81</td><td>-</td><td>0.90</td><td>2.64</td><td>4.58</td><td>0.95</td><td>1.88</td><td>2.26</td><td>3.82</td><td>0.90</td><td>1.67</td><td>2.4</td><td>3.84</td><td>0.90</td><td>1.66</td><td>2.29</td><td>3.81</td><td>0.91</td><td>1.70</td></tr><tr><td>700</td><td>1.08</td><td>2.68</td><td>-</td><td>1.00</td><td>2.58</td><td>4.64</td><td>-</td><td>1.95</td><td>2.35</td><td>3.91</td><td>-</td><td>1.87</td><td>2.31</td><td>3.60</td><td>-</td><td>1.87</td><td>2.35</td><td>3.77</td><td>-</td><td>1.87</td></tr></tbody></table>

<figure><img src="image_13.png" /><figcaption>FIGURE 12. System latency with different values for Block Time (BT) and Block Sizes (BS) in several concurrent requests for service provider registration (a), inserting valid registration token (b), user registration (c), ABAC procedure (d), and payment to the network provider (e).</figcaption></figure>
provider, $Addr_A \neq Addr_{sp}$, therefore, $T \neq T'$ and the scenario is failed.

### 4) TAMPERING ACCESS ATTRIBUTES (IMMUTABILITY)

**Scenario 6:** Adversary $\mathcal{A}$ aims to request registration with modified access attributes (not based on agreement).

**Analysis:** This analysis is the same for both registration and update scenarios, but to make it short, we only explain the scenario for registration. As shown in step 2 of Fig. 6, when the user pays for the subscription, $sp$ generates a token based on all parameters of the agreement. Then it registers the valid token in the Blockchain and sends it to the user. If Adversary $\mathcal{A}$ changes any parameter in Fig. 6, step 4, will cause to $T \neq T'$ in step 5.

**Scenario 7:** Adversary $\mathcal{A}$ aims to change its (or other one's) access attributed in the system by updating the existed $User\_Contract_{u,sp}$.

**Analysis:** To update the access attributes, 2 scenarios can be assumed:

1) $\mathcal{A}$ calls the `Update()` function of Registration (Algorithm 6). As mentioned in the update process, using the update tokens will result in the failure of the adversary attempt.

2) $\mathcal{A}$ calls the `update()` function of $User\_Contract_{u,sp}$. This function checks the sender of the message, and if `msg_sender \neq Addr_{Reg}`, the transaction will fail. As mentioned before, `Addr_{KAddr}` is stored in this contract from deployment step. `update()` fetches the `Addr_{Reg}` from `Known\_Addresses`, and this scenario fails because $Addr_{\mathcal{A}} \neq Addr_{Reg}$.

### 5) THREAT OF MAINTAINABILITY

**Scenario 8:** The controller contracts (i.e., the contracts which are not used as a distributed database), needed to be replaced to be adapted to the new needs of new business models.

**Analysis:** As shown in Fig. 10, two contracts `AC\_Manager` and `Registration`, as two controller contracts in the system, are replaceable. These two contracts do not store any hardcoded parameter. Based on [37], the maintainability problem can be resolved by assigning the variables dynamically.

### 6) IMMUTABILITY OF STORED ADDRESSES

**Scenario 9:** Adversary $\mathcal{A}$ aims to change the addresses stored in `Known\_Addresses`.

**Analysis:** If this scenario can be executed, all other threads in the system would be feasible. To protect the system against this threat, we defined that:

1) The addresses of the database contracts (see Fig. 10), cannot be changed in any circumstances, and

2) Controller contracts can only be replaced by a new contract if `msg_sender == Addr_{admin}`. Note that `Addr_{admin}` is stored in `Known\_Addresses` in the setup phase.

## D. COMPARISON

Table 9 shows the comparison among the proposed method and other related works. As mentioned before, to the best of our knowledge, we could not find a paper that shares the same concerns as us. Thus, we compare the more related state of the arts. So, several works implemented the ABAC method (i.e., [23], [24], [26], [28]–[30], [33], [34]), while other works proposed different access control methods. Important to mention that, in the related works we only focused on the papers that are more related to our use-case and select among them; because of this some papers are not related to the ABAC model.

Focusing on access control solution, our proposed method can be compared with [23], [24], [26]–[30], [33], and [34]. As shown in Table 9, [23], [24], [26]–[30] use Blockchain as a distributed database for rules and policies. They have a central point for access decisions, that can be a single point of failure. While, in our solution, we use Blockchain for both access management and distributed database for rules. This approach can remove any single point of failure in the access control procedure. So, we can claim that the proposed system is more fault-tolerant. [33], [34] are similar regarding the performance, scalability, and fault-tolerant. But, their use-cases are different from our paper and they also do not support payment capabilities.

## VII. CONCLUSION AND FUTURE DIRECTIONS

Blockchain and smart contracts are disruptive technologies that can change different aspects of businesses. In this paper, we proposed a smart contract-based access control mechanism. A high-level abstract of the proposed method is depicted in Fig. 14. The main purpose of the proposed method is to provide a flexible and scalable access control solution without the need for a trusted third party to enable service providers to outsource their access control needs. Our method also supports a new business model to decrease the user's payment, improves the access management automation, removes the single point of failure (increasing the fault tolerance) in access management, increases the security, accountability, and reliability of connection, and addresses the user's, network provider's and service provider's needs. This method also guarantees payment security based on blockchain properties in a trustless environment.

Measuring the scalability of the system using two parameters (i.e., latency and throughput) indicates that increasing the number of nodes in the system can result in decreasing the latency. This change happens, because the validators in the system, participate in the consensus procedure, increase. The variation in latency and throughput in the case of having several different concurrent requests (50 to 700), several block sizes (15 and 30 transactions per block), and different block times (5s, 10s, 15s), show that this system also brings high scalability.

Due to the many challenges in the implementation of a new model, we have postponed some improvements for future work. Detailed suggestions for future work are given next.
<table><caption>TABLE 9. Comparison of proposed method with existing systems</caption><thead><tr><th>refs</th><th>[19]</th><th>[23]</th><th>[24]</th><th>[25]</th><th>[26]</th><th>[27]</th><th>[28]</th><th>[29]<br>[30]</th><th>[31]</th><th>[32]</th><th>[33]</th><th>[34]</th><th>[35]<br>[36]</th><th>Proposed</th></tr></thead><tbody><tr><th>Features</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><th>Access control automation</th><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td><strong>Yes</strong></td></tr><tr><th>Purpose of blockchain usage*</th><td>DB</td><td>DB</td><td>DB</td><td>DB</td><td>DB</td><td>DB</td><td>DB</td><td>DB</td><td>ACM</td><td>ACM</td><td>ACM</td><td>ACM</td><td>ACM</td><td>ACM</td><td><strong>ACM</strong></td></tr><tr><th>Scalability+</th><td>H</td><td>H</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>N/A</td><td>H</td><td>N/A</td><td>N/A</td><td>M</td><td>N/A</td><td>N/A</td><td>N/A</td><td><strong>H</strong></td></tr><tr><th>Access decision making**</th><td>C</td><td>O</td><td>C</td><td>C</td><td>C</td><td>C</td><td>C</td><td>N/A</td><td>D</td><td>D</td><td>D</td><td>D</td><td>D</td><td>D</td><td><strong>D</strong></td></tr><tr><th>Fault tolerance in AC process</th><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td><strong>Yes</strong></td></tr><tr><th>Remove single point of Failure</th><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td><strong>Yes</strong></td></tr><tr><th>Payment capability</th><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>Yes</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td>No</td><td><strong>Yes</strong></td></tr><tr><th>Access control model++</th><td>CB</td><td>AB</td><td>AB</td><td>CB</td><td>AB</td><td>AB</td><td>AB</td><td>AB</td><td>G</td><td>RB</td><td>AB</td><td>AB</td><td>G</td><td>G</td><td><strong>AB</strong></td></tr></tbody></table>

<figure><img src="image_14.png" /><figcaption>FIGURE 14. A high-level abstract of the proposed access control method.</figcaption></figure>

## A. AUTHENTICATION

As mentioned before, our proposed method uses the network provider's AKA-based authentication method to send the user's request to the Blockchain. As future directions, we may have two suggestions:

1) In addition to AKA-based authentication (i.e., a centralized solution), we need to propose another distributed authentication solution. This solution must consider the requirements of all parties (i.e., AKA is only done in network provider side).

2) From another perspective, even though the proposed access control method is done after the AKA-based authentication on the network provider side, in the future it can be introduced as the first step to eliminate the AKA-based access control mechanisms. Also, it can provide an idea and vision about how to implement more software-based and loosely-coupled networks, by outsourcing the authentication and access control process and decoupling it from the network. This solution can remove any single point of failure in whole process; Privacy of all parties, latency, scalability and trust are main challenges to solve in this solution.

## B. PRIVACY PRESERVING

In this version of the proposed method, we did not focus on privacy issues because, we do not store any identifier data about users (e.g., email, phone number, etc.). The only available data of the users in the system is their Blockchain address, a random parameter that cannot be the user's identifier. Despite this reason, when implementing the method in a real-world scenario, the users' and the service provider's privacy would be of vital challenge to focus on.

## C. DECREASING THE LATENCY

One of the main concerns about using Blockchain technology for access management is its delay in getting a response. To overcome this problem, we propose to use a private/consortium Blockchain with a small number of users. In a real-world scenario, the latency of the system must be decreased as much as possible. To do so, one key research challenge will be to reduce the number of messages exchanged in the system while maintaining the constraints and requirements to protect the system's safety and security.

## D. DELEGATION

Using the current system is limited to one user. It means no one rather than the user herself, can use the system. To increase the flexibility of the system, the user can delegate her access permissions to another user to use the services. To do so, several challenges in security and trust will rise. Resolving these challenges can be a future direction to improve the functionality of the method.

## E. STORAGE OPTIMIZATION

Storage requirement is one of the challenges to implement the proposed system in a real-life scenario. Many users of this system utilize resource constraint devices such as mobile phones and laptops that are not highly capable of storing a large amount of data in their storage capacity. So, optimization of storage can be an important upcoming challenge. Two scenarios can be effective for the future direction in this part:

* It is possible to use cloud storage to store Blockchain data (i.e., smart contracts and their data), and then, we

<footnote>* DB (Using blockchain as a database for rules or terms of the agreement) or ACM (Using blockchain for both database and access control process) + Tolerance of latency is low for more than 500 concurrent requests (High(H)), up to 500 concurrent requests (Moderate(M)) in different parameters **C (Centralized), O (the Owner), and D (Distributed) ++AB (ABAC), CB (CapBAC), RB (RBAC), and G(Generic)</footnote>
can only store the URL of those data in the Blockchain. In this scenario, another authentication and access control is needed to access to cloud and avoid data leakage;

* Separation of full-nodes and light-weight nodes can be another solution. To do so, we can designate several nodes with an enormous amount of storage and processing power for consensus, validation, and storage purpose, and all users can participate in the system as light-weight nodes. In this scenario, the challenge of trust must be taken into account.

## F. ANALYSIS IMPROVEMENTS

To improve the assessment and analysis of the proposed method, in the future we aim to perform a detailed study of the cost and performance of the system:

1. With different scenarios of using public, private, or consortium Blockchains. In these experiments, using real traffic patterns and finding the best fitting for shaping the on-chain operations (to maximize the throughput) is the main challenge.

2. With different scenarios of using several Blockchain implementations such as Hyperledger Fabric, Quorum, etc., to select the most appropriate solution for our use-case.

3. With different consensus models such as PoS, PBFT, etc. to find the best solution for the system. The main challenge in this part of the analysis is to find a solution that can provide a suitable compromise between security and the performance of the system.

## REFERENCES

[1] S. Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," p. 9.

[2] "Secure Property Titles with Owner Authority | Satoshi Nakamoto Institute." https://nakamotoinstitute.org/secure-property-titles/ (accessed Mar. 19, 2021).

[3] M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. Maglaras, and H. Janicke, "Blockchain Technologies for the Internet of Things: Research Issues and Challenges," *IEEE Internet of Things Journal*, vol. 6, no. 2, pp. 2188-2204, Apr. 2019, doi: 10.1109/JIOT.2018.2882794.

[4] A. A. Monrat, O. Schelén, and K. Andersson, "A survey of blockchain from the perspectives of applications, challenges, and opportunities," *IEEE Access*, vol. 7, pp. 117134-117151, 2019.

[5] M. S. Ali, M. Vecchio, M. Pincheira, K. Dolui, F. Antonelli, and M. H. Rehmani, "Applications of blockchains in the Internet of Things: A comprehensive survey," *IEEE Communications Surveys & Tutorials*, vol. 21, no. 2, pp. 1676-1717, 2018.

[6] Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, "Blockchain challenges and opportunities: A survey," *International Journal of Web and Grid Services*, vol. 14, no. 4, pp. 352-375, 2018.

[7] Y. Xiao, N. Zhang, W. Lou, and Y. T. Hou, "A Survey of Distributed Consensus Protocols for Blockchain Networks," *IEEE Communications Surveys Tutorials*, vol. 22, no. 2, pp. 1432-1465, Secondquarter 2020, doi: 10.1109/COMST.2020.2969706.

[8] R. Wattenhofer, *The science of the blockchain*. Inverted Forest Publishing, 2016.

[9] M. Jakobsson and A. Juels, "Proofs of work and bread pudding protocols," in *Secure information networks*, Springer, 1999, pp. 258-272.

[10] S. King and S. Nadal, "PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake," p. 6.

[11] M. Castro and B. Liskov, "Practical byzantine fault tolerance," in *OSDI*, 1999, vol. 99, no. 1999, pp. 173-186.

[12] V. Y. Kemmoe, W. Stone, J. Kim, D. Kim, and J. Son, "Recent advances in smart contracts: A technical overview and state of the art," *IEEE Access*, vol. 8, pp. 117782-117801, 2020.

[13] D. Ferraiolo, D. R. Kuhn, and R. Chandramouli, *Role-based access control*. Artech House, 2003.

[14] Y. Nakamura, Y. Zhang, M. Sasabe, and S. Kasahara, "Exploiting smart contracts for capability-based access control in the Internet of Things," *Sensors*, vol. 20, no. 6, p. 1793, 2020.

[15] B. Anggorojati, P. N. Mahalle, N. R. Prasad, and R. Prasad, "Capability-based access control delegation model on the federated IoT network," in *The 15th International Symposium on Wireless Personal Multimedia Communications*, 2012, pp. 604-608.

[16] B. W. Lampson, "Protection," *ACM SIGOPS Operating Systems Review*, vol. 8, no. 1, pp. 18-24, 1974.

[17] R. S. Sandhu, "Role-based access control," in *Advances in computers*, vol. 46, Elsevier, 1998, pp. 237-286.

[18] V. C. Hu, D. R. Kuhn, D. F. Ferraiolo, and J. Voas, "Attribute-based access control," *Computer*, vol. 48, no. 2, pp. 85-88, 2015.

[19] R. Xu, Y. Chen, E. Blasch, and G. Chen, "Blendcac: A smart contract enabled decentralized capability-based access control mechanism for the iot," *Computers*, vol. 7, no. 3, p. 39, 2018.

[20] A. Gauhar et al., "xDBAuth: Blockchain based cross domain authentication and authorization framework for Internet of Things," *IEEE Access*, vol. 8, pp. 58800-58816, 2020.

[21] F. Ghaffari, E. Bertin, J. Hatin, and N. Crespi, "Authentication and Access Control based on Distributed Ledger Technology: A survey," in *2020 2nd Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS)*, 2020, pp. 79-86.

[22] Q. Zhou, H. Huang, Z. Zheng, and J. Bian, "Solutions to scalability of blockchain: A survey," *IEEE Access*, vol. 8, pp. 16440-16455, 2020. VOLUME XX, 2017 1

[23] S. Shafeeq, M. Alam, and A. Khan, "Privacy aware decentralized access control system," *Future Generation Computer Systems*, vol. 101, pp. 420-433, 2019.

[24] X. Qin, Y. Huang, Z. Yang, and X. Li, "An access control scheme with fine-grained time constrained attributes based on smart contract and trapdoor," in *26th International Conference on Telecommunications (ICT)*, 2019, pp. 249-253.

[25] L. Tan, N. Shi, C. Yang, and K. Yu, "A blockchain-based access control framework for cyber-physical-social system big data," *IEEE Access*, vol. 8, pp. 77215-77226, 2020.

[26] S. Wang, Y. Zhang, and Y. Zhang, "A blockchain-based framework for data sharing with fine-grained access control in decentralized storage systems," *IEEE Access*, vol. 6, pp. 38437-38450, 2018.

[27] B. Waters, "Ciphertext-policy attribute-based encryption: An expressive, efficient, and provably secure realization," in *International Workshop on Public Key Cryptography*, 2011, pp. 53-70.

[28] L. Guo, X. Yang, and W.-C. Yau, "TABE-DAC: Efficient Traceable Attribute-Based Encryption Scheme With Dynamic Access Control Based on Blockchain," *IEEE Access*, vol. 9, pp. 8479-8490, 2021, doi: 10.1109/ACCESS.2021.3049549.

[29] X. Ling, J. Wang, T. Bouchoucha, B. C. Levy, and Z. Ding, "Blockchain radio access network (B-RAN): Towards decentralized secure radio access paradigm," *IEEE Access*, vol. 7, pp. 9714-9723, 2019.

[30] X. Ling, Y. Le, J. Wang, Z. Ding, and X. Gao, "Practical modeling and analysis of blockchain radio access network," *IEEE Transactions on Communications*, 2020.

[31] C. Yang, L. Tan, N. Shi, B. Xu, Y. Cao, and K. Yu, "AuthPrivacyChain: A blockchain-based access control framework with privacy protection in cloud," *IEEE Access*, vol. 8, pp. 70604-70615, 2020.

[32] J. P. Cruz, Y. Kaji, and N. Yanai, "RBAC-SC: Role-based access control using smart contract," *IEEE Access*, vol. 6, pp. 12240-12251, 2018.

[33] H. Liu, D. Han, and D. Li, "Fabric-IoT: A blockchain-based access control system in IoT," *IEEE Access*, vol. 8, pp. 18207-18218, 2020.

[34] Y. Zhang, S. Kasahara, Y. Shen, X. Jiang, and J. Wan, "Smart contract-based access control for the internet of things," *IEEE Internet of Things Journal*, vol. 6, no. 2, pp. 1594-1605, 2018.

[35] T. Sultana, A. Almogren, M. Akbar, M. Zuair, I. Ullah, and N. Javaid, "Data sharing system integrating access control mechanism using blockchain-based smart contracts for IoT devices," *Applied Sciences*, vol. 10, no. 2, p. 488, 2020.

[36] T. Sultana, A. Ghaffar, M. Azeem, Z. Abubaker, M. U. Gurmani, and N. Javaid, "Data sharing system integrating access control based on smart contracts for IoT," in *International Conference on P2P, Parallel, Grid, Cloud and Internet Computing*, 2019, pp. 863-874.
[37] J. Chen, X. Xia, D. Lo, J. Grundy, X. Luo, and T. Chen, "Defining smart contract defects on ethereum," *IEEE Transactions on Software Engineering*, 2020.

[38] B. Guido, D. Joan, P. Michaël, and V. A. Gilles, "The K SHA-3 submission," 2011.

[39] D. C. Nguyen, P. N. Pathirana, M. Ding, and A. Seneviratne, "Blockchain for 5G and beyond networks: A state of the art survey," *Journal of Network and Computer Applications*, p. 102693, 2020.

[40] S. Behrad, E. Bertin, and N. Crespi, "Securing authentication for mobile networks, a survey on 4G issues and 5G answers," in *2018 21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN)*, Feb. 2018, pp. 1–8, doi:10.1109/ICIN.2018.8401619.

[41] C. Dannen, *Introducing Ethereum and solidity*, vol. 318. Springer, 2017.

[42] D. G. Wood, "Ethereum: A Secure Decentralised Generalised Transaction Ledger," p. 39.

[43] I.-C. Lin and T.-C. Liao, "A survey of blockchain security issues and challenges.," *IJ Network Security*, vol. 19, no. 5, pp. 653–659, 2017.

[44] P. W. Eklund and R. Beck, "Factors that impact blockchain scalability," in *Proceedings of the 11th international conference on management of digital ecosystems*, 2019, pp. 126–133.

[45] J. Xie, F. R. Yu, T. Huang, R. Xie, J. Liu, and Y. Liu, "A survey on the scalability of blockchain systems," *IEEE Network*, vol. 33, no. 5, pp. 166–173, 2019.

[46] M. Schäffer, M. Di Angelo, and G. Salzer, "Performance and scalability of private Ethereum blockchains," in *International Conference on Business Process Management*, 2019, pp. 103–118.

<figure><img src="image_15.png" /></figure>

NOEL CRESPI holds Masters Degrees from the Universities of Orsay and Canterbury, a "Diplôme d'ingénieur" from Telecom ParisTech and a Ph.D. and Habilitation from Paris VI University. He joined Institute Mines-Telecom in 2002 and is currently Professor and M.Sc. Programme Director, leading the Service Architecture Laboratory. He coordinates the standardization activities for Institute Telecom at ETSI, 3GPP, and ITU-T. He is also an adjunct professor at KAIST (South Korea), an affiliate professor at Concordia University (Canada), and guest researcher at the University of Goettingen (Germany). He is the scientific director the French-Korean laboratory ILLUMINE. His current research interests are in Data Analytics, Internet of Things and Softwarisation. He is the author/co-author of 400 articles and contributions in standardization. He is a senior member of the IEEE.

<figure><img src="image_16.png" /></figure>

FARIBA GHAFFARI is pursuing her Ph.D. with Institut Polytechnique de Paris (Telecom Sud-Paris). She has been involving in the field of Authentication, and access control mechanisms based on Blockchain and smart contracts at Orange Labs, France, since 2019. She received her master degree of science in the field of Information Security.

<figure><img src="image_17.png" /></figure>

SHANAY BEHRAD holds a Ph.D. in computer science from "Institut Polytechnique de Paris". She worked on designing authentication and access control mechanisms for 5G networks during her Ph.D. at Orange Labs. She currently works at b-com institute of research and technology as a research engineer. Her research interests include 5G networks, Microservices and Security.

<figure><img src="image_18.png" /></figure>

EMMANUEL BERTIN is an expert community leader at Orange Labs and an adjunct professor at the Institut Mines-Telecom, France. His activities are focused on 5G and 6G, Blockchain and service engineering, with more than 100 published researched articles. He received a Ph.D. and an habilitation in computer science from Sorbonne University. He is a senior member of the IEEE..

<figure><img src="image_19.png" /></figure>

JULIEN HATIN holds a Ph.D. in computer science from the University of Caen and a "Diplôme d'ingénieur" from Ecole National Superieur Ingénieur de Caen. He currently works at Orange Labs, as a research engineer. His research interests include Smart contract, Blockchain, Identity management and Authentication.

...