User authentication and access control to blockchain-based forensic log data

Abstract

For dispute resolution in daily life, tamper-proof data storage and retrieval of log data are important with the incorporation of trustworthy access control for the related users and devices, while giving access to confidential data to the relevant users and maintaining data persistency are two major challenges in information security. This research uses blockchain data structure to maintain data persistency. On the other hand, we propose protocols for the authentication of users (persons and devices) to edge server and edge server to main server. Our proposed framework also provides access to forensic users according to their relevant roles and privilege attributes. For the access control of forensic users, a hybrid attribute and role-based access control (ARBAC) module added with the framework. The proposed framework is composed of an immutable blockchain-based data storage with endpoint authentication and attribute role-based user access control system. We simulate authentication protocols of the framework in AVISPA. Our result analysis shows that several security issues can efficiently be dealt with by the proposed framework.

1 Introduction

In day-to-day life, citizens of a city or community use various utility services such as water, electricity, gas, healthcare, communication, attendance facilities, and so on. They store a huge amount of data in the system. After storing data at any time, such as after few months or few years, dispute may arise from any end (customer or service holder) of the service. On the other hand, logging of data is very much useful for forensic purposes [1], which may help reduce disputes related to real-life issues. Therefore, the primary target of the proposed framework is to store user log data in a tamper-proof data storage and provide forensic access control for dispute resolution.

For any dispute resolution in a community, recording user activity log data is highly required to investigate any dispute event. On the other hand, loss of data can turn the whole system into a catastrophe. The authentication scheme by Sharma et al. [2] lacks tamper-proof data storage. The use of blockchain can make data tamper-proof as it is itself immutable [3]. As data is a highly confidential asset, proper user identification and authentication are indispensable parts of the system. After identifying and authenticating users, granular access control should be used to access the individual data or record. Authors in [4,5,6] use blockchain technology to facilitate tamper-proof data storage, but Jangirala et al. [5] do not use asymmetric cryptography and lack focus on the integrity of authentication keys. We use asymmetric cryptography for authentication key generation and maintain their integrity along with access control of users. Here we should identify who can access which data or record considering the type of access right (roles and privileges). To ensure controlled access to data, management of user roles and privileges are required together to form an access control framework. So, in this paper, we propose a blockchain-based authentication and access control framework for forensic log data.

In our proposed framework, citizen-specific edge devices store activity log data in the blockchain data storage, where the blockchain itself is an immutable data structure residing in a cloud storage. That immutability of blockchain data ensures zero possibility of data tampering [7]. We implement that immutable data storage in permissioned blockchain within an edge network as edge computing also increases the scalability by executing computations close to the end devices [8]. In our edge network, we also use blockchain for smart contract. The data storage is in a cloud server, so geographically dispersed users can access them. For accessing, edge device, edge server, corporate user, and forensic user are examples of users of these data. During the accessing of activity log data storage, each of the devices must be identified and authenticated to restrict any intrusion, where intrusion may lead to a severe threat to any citizen’s (user) privacy. The access control module holds the user roles, attributes, and policies related to data access. According to these data, the authentication module decides access to proper users based on their user credentials and keys. For authentication purposes, some keys are pre-generated and some are generated at runtime to make the system more secured. To generate authentication keys, we combine secret key (part of user credentials) and existing asymmetric cryptography (RSA). In addition, we apply hash functions for the integrity of the keys. For restricting any unwanted activity, access control and authentication framework work together. Policy level admins approve user creation. In parallel, the framework generates appropriate keys where required. Policy level admins manage user roles, attributes, and policy data. The following sections elaborate on these procedures.

The key contributions of this paper are as follows:

• 1. Design of a framework of authentication and attribute as well as Role-Based Access Control (ARBAC) has been proposed for securing forensic data.

• 2. Design of two authentication protocols (users to edge server and edge server to main server) along with their formal analyses and simulations using AVISPA.

• 3. Evaluation of how an authentication and ARBAC framework can facilitate forensic users to access an immutable data storage according to their roles and privileges.

• 4. An approach that combines edge network, cloud storage, and blockchain data structure with a newly designed authentication and access control framework, where blockchain contributes as an immutable data structure.

The rest of the paper is organized as follows. First, we review related literature, background concepts, and the problem statement. Then we introduce our proposed framework that includes the system design, the design of the protocols, and formal analyses of the protocols. Next, we discuss the use cases of our proposed framework. Subsequently, we describe the blockchain data storage, consensus and the system functionality interacting blockchain. Then, a discussion on the security aspects of the framework follows. Finally, we conclude the paper.

2 Related works

According to Noura et al. [9], confidentiality, integrity, and authentication of devices (or users) are essential to restrict the misuse of data where data logs can play a role of evidence in digital forensics. Chen et al. [10] describe blockchain as an immutable data structure that facilitates append-only data storage. It makes blockchain a non-alterable data structure. To add any new block to the blockchain ledger, consensus is achieved by proof of work according to Andreas Ellervee et al. [11]. Koutsoupias et al. [12] describe how consensus is achieved in blockchain for Bitcoin (public blockchain platform). Public blockchain platforms allow anonymous users to join the consensus [13], which increases the public exposure of peers and data storage raising the possibility of security concerns. So, we adapt permissioned blockchain (also known as consortium blockchain) as it only allows authenticated users from within the system for consensus, reducing public exposure [14]. In addition, a lightweight consensus can achieve scalability in a permissioned blockchain [4]. So, our proposed framework uses authenticated devices within the system to achieve consensus. Kirli et al. [15] denote smart contract as a self-executing computer program in a blockchain. In our proposed framework, smart contract acts as an interface between users and the blockchain data storage. It works based on some predefined conditions. Only if the conditions met then specific permissions of operations are granted. Samanta et al. [16] stated that introduction of smart contract reduces the need of keeping mediator who can ensure trust among parties; rather, smart contract itself acts as an automated middleman. Smart contract facilitates any transaction to be trustworthy by replacing intermediaries [17]. All kinds of users access data through smart contract. Edge devices through edge network and smart contract push data into data storage. Xu et al. [18] and Uddin [19] et al. describe that edge devices can help reduce the load on the main or cloud server.

In Internet of Things (IoT), authentication, and access control are very important security issues according to Joshi et al. [20] and Ali et al. [21]. As multiple endpoint devices communicate with each other, trust-building is a must for all the IoT devices to ensure trustworthiness within the distributed blockchain system stated by Yuanyu Zhang et al. [22]. For this trust maintaining process in our framework, there are some security techniques that help to authenticate and apply access control mechanism among devices. For authentication purpose, asymmetric mutual authentication of all the devices can be used which is described by Ali et al. [21], additionally with our new incorporation of secret key generation module. We use public key cryptography (asymmetric cryptography) for basic services to provide enhanced authentication and access control. Both Attribute Based Access Control (ABAC) [23] and Role-Based Access Control (RBAC) are showed by Rajpoot et al. [23]; for better access controlling, we have integrated these two access control concepts for our proposed framework. RBAC holds a pre-defined set of roles of users presented by Hu et al. [24]. Kamboj et al. [25] utilized RBAC-based authentication system for blockchain network, but they used a public blockchain platform. The hierarchy of devices and their variety in an edge network are not suitable for the openness of such a public blockchain platform. On the other hand, ABAC holds the collection of attributes that collectively form policy described by  Hu et al. [24]. In our proposed framework, we show how ABAC and RBAC combinedly form ARBAC (Attribute and Role-based Access Control) mechanism that uses attributes to form roles for a variety of devices and users. For these devices and users, our proposed framework generates the authentication keys that provide better features in terms of the integrity of the keys and scalability than Jangirala et al. [5].

3 System design

To generate authentication keys, we combine password as a secret key with asymmetric key. We further ensure the integrity of the authentication keys using cryptographic hash functions. This section describes various authentication key generation processes and presents formal analyses of the protocols.

3.1 System architecture

Communications between edge devices and edge servers take place through the smart contract in edge network, when edge servers and smart contract work as an interface between edge devices and main server [26]. Blockchain facilitates smart contract as its inherent technology [27]. On the other hand, a forensic user also requires an edge server to communicate with the main server. Overview of the situations depicted in Fig. 1, which exhibits the whole scenario. For the whole system to be functional, all the users must be preregistered in the ARBAC repository. Each edge device is assigned against its regional edge server; each time an edge device tries to connect with edge server it requires to pass the authentication phase; in the same way if edge server wants access to main server, it is given access only if authentication is passed. On the other side, a forensic user is required to go through authentication process if s/he or it wants access to main server, for this first level authentication is done by edge server then edge server passes it to main server for the next level authentication. Each area has a relevant edge server, so the second level authentication is important as it also helps the main server identify the area for which the forensic user requests data access.

Fig. 1

Overview of the smart architecture

3.2 Assumptions and notations

Edge server (ES) contains users’ data. Edge server will be location oriented. As such, each region of a city has an edge server. There are n edge servers of n regions of a city. After processing data, edge server sends them to corporate/main server for permanent storing. There will be a separate blockchain ledger for each service-oriented data to modularize the storage for reducing data access and block verification time. For example, there will be separate blockchain ledgers for phone logs, water/electricity bills, and so on.

• 1. All the devices/users must be registered users. Any user can be registered to one or more server(s).

• 2. Users must be authenticated by respective edge server(s) through smart contract provided by blockchain.

• 3. Each edge server must be registered server as a user to cloud or main server. On the other hand, forensic users must be registered to the main server. All users of the main server will be authenticated using separate authentication process.

3.3 User authentication to edge server

In this process, each user or device is a registered user. The system assigns or suggests ID (id) to each user and s/he chooses a password (pwd) according to the server’s suggestion. In this section, server represents the edge server. The respective server stores ID and password in hashed form. Each server has its id and a registered user gets it. A user must pass through an authentication process to get service from the server.

• 1. The user sends her/his id, pwd, and id of the server from which s/he wants to get service. For example, if the i_th user wants service from the k_th server, the user then sends the following credentials to the server:

  $$\begin{aligned} id_{ik}, id_{k}, and pwd_{ik} \end{aligned}$$

  More detail on the above credentials is available in Table 1.

• 2. After getting the credentials from the user, the server generates a secret number as below:

  $$\begin{aligned} SN_{ik} = H (id_{ik} | | pwd_{ik} || id_{k} || TS_{i} || R_{k}) \end{aligned}$$

  Timestamp means date and time when the number is computed.

• 3. Next, the server computes a session key as:

  $$\begin{aligned} K_{s-ik} = H( id_{ik} || SN_{ik} || id_{k} || N_{ik}) \end{aligned}$$

• 4. The server generates an authentication key for the user as follows:

  $$\begin{aligned} K_{au-ik}= H (id_{ik} || K_{s-ik} || TS_{i} + 1) \end{aligned}$$

  $TS_{i} + 1$ denotes next timestamp (date and time) for the i_th user.

• 5. The server sends the authentication key, K_au-ik to the user.

• 6. Next, the user submits the K_au-ik to the server to get the service.

Table 1 Notation and respective description for user authentication to edge server

This protocol seems a bit time-consuming due to a variety of computations, but distributed nature of edge servers will reduce the execution load by decentralizing the execution. We conduct a formal analysis of the above protocol as follows.

3.3.1 Formal analysis of the protocol

• 1 The protocol have three messages between the user and the server. We have used the notations used in [28] according to GNY logic.

  • Message 1. $U_{ik} \rightarrow ES_{k}: id_{ik}, pwd_{ik}, id_{k}$  

  • Message 2. $ES_{k} \rightarrow U_{ik}: H(id_{ik} || K_{s-ik} || TS_{i}+1)$

  • Message 3. $U_{ik} \rightarrow ES_{k}: K_{au-ik}$  

• 2 The parser algorithm would describe the protocol as follows:

  • (a) $U_{ik} \ni id_{ik}, pwd_{ik}, id_{k}$  

  • (b) $ES_{k} \triangleleft : *id_{ik}, *pwd_{ik}, *id_{k}$

  • (c) $ES_{k} \ni id_{ik}, pwd_{ik}, id_{k}$

  • (d) $ES_{k} \ni H(X)$

  • (e) $ES_{k} \ni H(X')$

  • (f) $U_{ik} \triangleleft :*K_{au-k}$

  • (g) $U_{ik} \ni K_{au-ik}$

• 3 Protocol Analysis: It can be assumed that the following holds at the starting of every run of the protocol.

  • (a) $U_{ik} \ni id_{ik}, pwd_{ik}, id_{k}$

  • (b) $ES_{k} |\equiv U_{ik}$

  • (c) $ES_{k} \ni H (id_{k} || pwd_{k} || id_{k} || TS_{2} || R_{k})$

  • (d) $ES_{k} |\equiv \#(TS_{i})$

  • (e) $ES_{k} |\equiv \#(R_{k})$

  • (f) $ES_{k} |\equiv \#(SN_{k})$

  • (g) $ES_{k} \ni H(id_{ik} || SN_{ik} || id_{k} || N_{ik})$

  • (h) $ES_{k} |\equiv \#(N_{ik})$

  • (i) $ES_{k} \ni H(id_{ik} || K_{s-ik} || TS_{i}+1)$

  • (j) $ES_{k} |\equiv \# (k_{s,ik})$

  • (k) $ES_{k} |\equiv \# (TS_{i}+1)$

  • (l) $ES_{k} |\equiv \# (K_{au-ik})$

  • (m) $U_{ik} |\equiv ES_{k} |\equiv K_{au-ik}$

  • (n) $ESk |\equiv K_{au-ik}$

3.4 Authentication key generation and storing process

The K_{au, ik} is the final product of this phase, where this key is assigned to i_th user of k_th server by authentication key table illustrated in Fig. 2. This key is created and assigned during user creation on request of user. In Fig. 3, user requests access to edge server with proper credential and response is given upon successful authentication key generation by edge server.

Fig. 2

Authentication key generation and storing process

Fig. 3

Dialogue between user and edge server

When a user wants to get access to an edge server, the server computes authentication key using steps 1 to 4 (in sub-section:user authentication to edge server). If the currently computed key is equal to the key stored in the table, the user is authenticated and the response will be a success message. Otherwise the response will be a failure message.

3.5 Access token for corporate user

Now we explain how a user to the main server is authenticated. As we mentioned, the users of the main server are edge servers, corporate users, and forensic users. A corporate user can get access to the edge server as well as main server. The edge server uses special tag to the corporate user, which is generated as follows:

$$\begin{aligned} TAG_{ck} = H(id_{k} || pwd_{ck} || K_{pr, es} || TS_{tag}) \end{aligned}$$

where pwd_ck is the password of a corporate user of the k_th edge server and K_{pr, es} is the private key of the edge server.

When a corporate user wants access to main server s/he must go through edge server. The server authenticates the user and checks its tag also. If her/his tag is also okay, his access will render to the main server by sending the encrypted tag. The tag is encrypted by the private key of the edge server. The main server authenticates the edge server and decrypts the tag. Next, it gives access to the corporate user.

3.5.1 Operations for access token for corporate user

The four parties related to the phase for communication between corporate user and main server are depicted in Fig. 4, which shows corporate user is the requester to get access to main server with the predefined user credentials. The same figure shows ARBAC repository stores user credentials.

Fig. 4

Corporate user gains access to main server through edge server

3.5.2 Simulation of Fig. 4 using AVISPA

AVISPA is a cryptographic protocol verification tool based on HLPSL language [29] which is used in our work to verify the goals mentioned below for the authentication of TAG_ck.

• 1 Authentication of TAG_ck when sent from ES to U

• 2 Authentication of TAG_ck when sent from U to MS

• 3 No attack by intruder

We depict the whole authentication process in Fig. 4. Both Figs. 5 and 6 show verification result of goals of the process, where these figures show that AVISPA successfully verifies authentication of TAG_ck when transmitted among edge server(ES), user(U), and main server(MS). No intruder can impersonate the edge server, user, or main server as the verification results prove that the protocol depicted in Fig. 4 ensures authentication of TAG_ck. When TAG_ck is encrypted by K_{pr, es} and sent to user, sender of TAG_ck is authenticated by the receiver. On the other hand, user sends the encrypted TAG_ck to main server by encrypting the message using private key of sender and main server uses public key of sender for authentication of the message. So, in both situations, intruder cannot impersonate any user as authentication is maintained using public-private keys of the users.

Fig. 5

Simulation of protocol in Fig. 4 using AVISPA—no attack by intruder

Fig. 6

Simulation of protocol in Fig. 4 using AVISPA—when protocol is safe

On the other hand, when abovementioned public-private keys are not used to send and receive TAG_ck among the users, authentication cannot be maintained. In this situation, intruder takes over and impersonates user and edge server which is depicted in Fig. 7. Due to authentication failure, the protocol is proved to be unsafe by AVISPA verification tool which we depict in Fig. 8.

Fig. 7

Simulation of protocol in Fig. 4 using AVISPA—when authentication is not maintained

Fig. 8

Simulation of protocol in Fig. 4 using AVISPA—when authentication is not maintained

3.5.3 Computation time for access token for corporate user

Key generation time shown in Table 2 is recorded using Intel Core i3 2GHz CPU with RAM of 4 GB. For this experimental phase: corporate user, edge server, main server, and ARBAC Repository were setup within a single system. Secret keys are generated using PHP as a scripting language in Apache server. Time shown in the table is recorded in milliseconds. For this, PHP benchmark tool is used to measure execution time.

Table 2 Required Computational Time to Generate Secrets for communication among corporate user, edge server and main server, time in milliseconds

To generate TAG_ck which is mentioned in Table 2, it requires private key of the edge server. This private key is a part of public key-based cryptosystem. Private and public key are the examples of asymmetric key cryptosystem [30]. For this phase of experiment, 2048 bits RSA asymmetric keys are created using OpenSSL [31].

In Fig. 9, comparison of computational times shows that encryption of TAG_ck takes the highest time. Decryption of the tag takes around 0.16698 ms. On the other hand, creation of TAG_ck is the fastest among all of the three, which is also shown in Table 2.

Fig. 9

Computational time to generate secrets for corporate user, edge server and main server

3.6 Authentication of edge server by main server

Each edge server and forensic user are the registered user of the main server. The authentication process is as follows.

• 1 The main or cloud server generates its secret as follows:

  $$\begin{aligned} MSS = H (id_{es, k} || id_{ms} || pwd_{es,k} || TS_{mss}) \end{aligned}$$

• 2 Next the server computes a token for the concerned edge server using the process:

  $$\begin{aligned} ET = E(K_{pr, ms}, [MSS || TS_{ET}]) \end{aligned}$$

  K_{pr, ms} is a private key of main server. TS_ET is a timestamp.

• 3 Next, the server encrypts the token (ET) and sends it to the edge server:

  $$\begin{aligned} C-ET = E(K_{pb, es} [ET || N1]) \end{aligned}$$

  K_{pb, es} is a public key of edge server and N1 is a nonce. After getting the cipher text (C-ET), the edge server opens it by decrypting it using its private key as D(K_{pr, es}, [C-ET]). After deciphering the token, the edge server gets ET and N1.

• 4 Next, the edge server sends access request as follows:

  $$\begin{aligned} ER = E(K_{pb, ms}, [id_{es} || ET || N1]) \end{aligned}$$

  The main server decrypts the ER (encrypted request) to the server using ET and N1. After finding ET and N1, which were sent by the main server, the respective edge server is authenticated.

All communications required for getting access to main server are depicted in Fig. 10, where at the first step ID and password of edge server are required for authentication purpose. Upon authentication, C-ET which is an access token required for edge server is issued and sent back for the next step to be accomplished. Having the C-ET, edge server issues and sends an access request (ER) to the main server. If verification of ER by main server is successfully completed, then the edge server is given access permission.

Fig. 10

Overview of dialogue between edge server and main server

3.6.1 Operations for authentication of edge server by main server

The four parties related to the phase for communication between edge and main servers are depicted in Fig. 11, which shows edge server is the requester to get access to main server. Admin is the creator of edge server and assigns user credentials, where ARBAC repository stores user credentials. We conduct a formal analysis of this phase of the communication as follows.

Fig. 11

Dialogue between edge server and main server

3.6.2 Formal analysis of the protocol

• 1 The protocol has messages between the edge server and main server as follows. We have used the notations used in [28] according to GNY logic (see Table 3 for further notation detail).

  • Message 1. $ES_{k} \rightarrow MS: id_{es,k}, pwd_{es,k}, id_{ms}$

  • Message 2. $MS \rightarrow ES_{k}: \{ET, N1\}K_{pb,es}$

  • Message 3. $ES_{k} \rightarrow MS: \{id_{es,k}, ET, N1\} K_{pb,ms}$

• 2 The parser produces the following output:

  • (a) $ES_{k} \ni id_{es,k}, pwd_{es,k}, id_{ms}$

  • (b) $MS\triangleleft : * id_{es,k}, *pwd_{es,k}, *id_{ms}$

  • (c) $MS \ni H(x)$

  • (d) $MS \ni K_{pr,ms}$

  • (e) $MS \ni \{MSS, TS_{ET}\} K_{pr,ms}$

  • (f) $MS \ni N1$

  • (g) $ES_{k}\triangleleft : *\{\{MSS, TS_{ET}\} K_{pr,ms}, N1\} K_{pb,es}$

  • (h) $ES_{k} \triangleleft : * N1$

  • (i) $MS\triangleleft : * \{id_{es}, ET, N1\} K_{pb,ms}$

  • (j) $MS \ni ER$

• 3 Protocol Analysis: We assume that the following holds at the beginning of each run of the protocol.

  • (a) $ES_{k} \ni id_{es, k}, pwd_{es,k}, id_{ms}$

  • (b) $MS |\equiv id_{es,k}$

  • (c) $MS \ni H(id_{es,k} || id_{ms} || pwd_{es,k} || TS_{ms})$

  • (d) $MS |\equiv \#(TS_{mss})$

  • (e) $MS \ni K_{pr, ms}$

  • (f) $MS |\equiv \#(TS_{ET})$

  • (g) $MS |\equiv \xrightarrow {+K_{pb,es}} ES$

  • (h) $MS \ni ET$

  • (i) $MS |\equiv \#(N1)$

  • (j) $ES |\equiv \xrightarrow {+K_{pb,ms}} MS$

  • (k) $ES |\equiv N1$

  • (l) $ES |\equiv C-ET$

  • (m) $ES \ni C-ET$

  • (n) $MS \ni ER$

  • (o) $MS |\equiv ER$

  • (p) $ES |\equiv MS |\equiv ER$

Further verification of the above protocol is as follows.

Table 3 Notation and respective description for edge server authentication to main server

3.6.3 Simulation with respect to Fig.11 using AVISPA

Verification of the protocol depicted in Fig. 11 is conducted using HLPSL language in AVISPA. In the mentioned protocol, authentication of users who are sharing the C-ET over the network is verified. Below mentioned goals are achieved using AVISPA when main server passes C-ET to edge server.

• 1 Authentication of C-ET proves that authentication of ER is possible when encrypting using private key of main server.

• 2 No attack by intruder.

When main server sends C-ET to edge server, K_pr,ms and K_pb,es are used for authentication of sender and receiver. Using HLPSL language in AVISPA, this scenario has been simulated. It proves that authentication of sender and receiver are maintained; thus, no intruder can impersonate any of the users. Figure 12 shows intruder cannot impersonate user due to authentication using K_pr,ms and K_pb,es. So, the protocol is safe with respect to authentication of users which we depict in Fig. 13.

Fig. 12

Simulation of protocol in Fig. 11 using AVISPA—no attack by intruder

Fig. 13

Simulation of protocol in Fig. 11 using AVISPA—when protocol is safe

On the other hand, unsafe state is depicted collectively in Figs. 14 and 15 when K_pr,ms and K_pb,es are not used to authenticate the users. These figures show that when authentication procedure is intentionally not maintained in AVISPA, intruder can impersonate users and the protocol is proved to be unsafe.

Fig. 14

Simulation of protocol in Fig. 11 using AVISPA—when public-private keys not used

Fig. 15

Simulation of protocol in Fig. 11 using AVISPA—when public-private keys not used

3.6.4 Computational time for authentication of edge server by main server

Key generation time shown in Table 4 is recorded in Intel Core i3 2GHz CPU with RAM of 4 GB. For this experimental phase: edge server, admin, main server and ARBAC Repository were setup within a single system. In that setup, secret keys are generated using PHP as a scripting language in Apache server. We use PHP benchmark tool for recording execution time. During generating all the secret keys mentioned in Table 4, both public and private keys of edge and main server are required. These keys are part of public key-based cryptosystem, in which asymmetric keys are used. For this phase, we use 2048 bits of RSA private and public key. These keys are created by admin when new user creation is done and stored into ARBAC repository.

Table 4 Required computational time to generate secrets for dialogue between edge and main server, time in milliseconds

Figure 16 shows comparison among execution time required for generating MSS, ET, C-ET and ER. Among them, ET is the slowest when created, that takes around 78% of total time required for all four. Among the four, the fastest generated secret is the MSS, which takes almost 0% (around 0.00758 ms) of time. On the other hand, C-ET and ER require 15% and 7% of total time respectively.

Fig. 16

Computational time to generate secrets for dialogue between edge and main server

3.7 Asymmetric key generation by admin

Figure 17 shows the admin-level users have the responsibility to assign public and private keys required during each user creation. Where each RSA-based key is created with the help of OpenSSL. Each user gets a pair of keys, including a public key that is known to all, but the private key is only exposed to the respective user. In all phases of the proposed framework, for most of the secret key generations, public-private keys are required for authentication and verification purposes of the users.

Fig. 17

Asymmetric key generation for all users

After authentication of the users, ARBAC can be activated. Here we can use role-based and attribute-based access control for data in forensic use. This hybrid access control module with roles and attributes will be called ARBAC for the proposed framework. The role and attribute-based system is consisted of the following steps depicted in Fig. 18 to perform operation on the request object by the user. Here object refers to the resource requested by user. On the other hand, subject is the user who requests access to object. Providing access to proper object, all the repositories such as policy, subject attribute, and object attribute repositories are used.

Fig. 18

Basic components of ARBAC

• 1 Subject seeks access to object.

• 2 Access control module evaluates: rules, conditions, subject attributes, object attributes, and environment attributes [23].

• 3 Subject gained access to object.

As ARBAC is the next part after authentication, so no un-authorized user or agent can execute access control method. This ensures that only authenticated subject/users can gain access through ARBAC module and subjects are given privileges according to their roles. In our work, example of subject is user who seeks forensic data and the edge server that is the actual source of new data to be added into activity log ledger. On the other hand, example of object is the basic unit of each of the data stored in activity log ledger as a form of block in the blockchain, where block refers to the unit element of each blockchain ledger as depicted in Fig. 19.

Fig. 19

A chain of three blocks

3.8 Access request of object by subject

One common thing between subject and object is that both of them have attributes. These attributes help to identify the roles of any subject based on the subject attribute and access permissions of each subject are assigned accordingly. As such, a role of a subject may have attributes in name value pair like, department: water, userType: admin, objectType: water, read: yes, write: no, deleteUser: no, status: active. The role refers to a user from water department authority who has access to water data s/he has read operation privilege and no write privilege on object or data. As these are some confidential data of citizens, data can only be added by some edge servers but not by any human agent. On the other side, a single object consists of multiple attributes which help to identify each of them from the blockchain ledger. Example of object attributes: type:waterlog, status:active, location: 23.7104, 90.4074, creationTime:2038-01-19 03:14:07.

3.9 Attributes and privileges in ARBAC

Subject attributes, object attributes, rules, privileges, and environment attributes are processed in combination to achieve a decision whether a subject will get access to object or not. Privileges define which subject will be allowed which operation on which object. Again, rules are written in perspective of object type. So, privileges assigned to subjects through roles and rules related to objects are the bridging elements for allowing access to the users or subjects to perform specific operation with the contribution of attributes. Operation refers to the execution of any function on any object. Examples of operation are execute, read, write, delete, upload, download, and so on.

Subject and object attributes are created and assigned by the respective creators; these creators are the admin users who are not the forensic users. Creator of subject attributes are also the admin users who are responsible for managing all the subject attributes and subject itself. On the other hand, objects are created by the edge servers and object attributes are assigned by the edge servers according to the rules stored in policy repository. But object attributes are created and stored by the admin-level users. For all the above situations, admin-level users are the users which are not related to the forensic users. So forensic users and admin-level users are not the same type. For example, a forensic user only has the read operation privilege, but admin-level users have no write operation privilege on object but the write operation privilege only in the policy and attribute repository. Management of these admin-level users is out of the scope of the proposed ARBAC.

3.10 Types of access requests

There can be two varieties of user/subject requests to get object access—one is identifier-based request and another is attribute-based request [23]. In identifier-based request, against each request unique identifier of a single object is given by the subject and that object is retrieved only. For this approach, user or subject needs to know the unique identifier of that specific object. On the other hand, for attribute-based object requests, the subject can access multiple objects based on the attributes provided. An example of attribute based object request can be like:

$$\begin{aligned} \begin{array}{c} Request= <session,(oType=phoneLog \& \\ forensicDept=telco \& \\ area=dhaka \& oStatus=active), read\,>\end{array} \end{aligned}$$

The above request denotes the owner of the session who is actually a user seeking for read operation approval only for the objects for which the object expression is matched upon evaluation. The object expression is evaluated for each of the objects in the repository. Only if the object expression is true for each object is added to the list of authorized objects for the owner of the current session.

To execute the above request by the subject, each subject/user must have the permission to get access of the required objects. For this, a permission request is placed as:

$$\begin{aligned} \begin{array}{c} p= ((oType(o) = phoneLog \& \\ oStatus(o) = active), read) \end{array} \end{aligned}$$

In the above request, the subject is seeking for read operation permission for each object related to water log data from the blockchain ledger. But to get a permission to be approved, the subject has to fulfill some set of conditions. An example of condition can be:

$$\begin{aligned} \begin{array}{c} c=(uMember(u)=admin \& accessTime()<\\ userDutyExpire(u)) \end{array} \end{aligned}$$

Each function of the above condition denotes that the subject has to be an admin and access time should be within the office time. In the above object expression, access time and user duty expiration time are evaluated from some environmental attributes. Examples of environmental attributes: current time, location and client device type.

To implement the ARBAC, required repositories are subject attribute repository, object attribute repository, and policy repository. Among them, subject attributes and data required for roles are stored in the subject attribute repository. They are used for subject-related data required for evaluating conditions/rules for approving permission to subject for accessing object. Object attribute repository holds all attributes related to objects those are required for allowing object access to certain user roles, it is required to enforce decision on which user role get access to relevant objects. Policy repository can be treated as a guardian of the whole ARBAC system that holds the rules/conditions that actually help to determine whether a user should be granted any object access or not.

Environmental conditions and attributes are such as current time, time, location, system status, and any security threat. These are some independent attributes which are detectable on runtime by the help of execution system. Policy Decision Point (PDP) is liable for evaluating subject attributes, object attributes, and environmental conditions and gives a decision to the policy enforcement point [24, 32]. Policy Enforcement Point (PEP) receives object access request from subject and requests PDP for access control decision whether any subject will get object access approval or not [24, 32]. Actual access decision is made by PDP where PEP is the mediator among subject, object, and PDP. All the functional modules described in this sub-section are depicted in Fig. 20.

Fig. 20

Functional modules in ARBAC

3.11 Communication between subject and ARBAC

After successful authentication of any user(subject), it requests for object access to ARBAC, where ARBAC is the sole responsible module for allocation of object according to the roles and privileges of subject. In ARBAC, PDP evaluates subject attributes, object attributes, and environmental conditions collectively that helps PEP to decide whether a subject will get access permission to object or not. Here, PEP works as a mediator between PDP and subject. If PDP gives positive response to PEP, a subject gets object access permission. We depict these steps in Fig. 21. Next section describes use cases of ARBAC.

Fig. 21

Communication between subject and ARBAC

4 Use cases of ARBAC

In this section, we have shown some use cases of ARBAC module.

4.1 ARBAC roles and attributes

In Table 5, RWX denotes the user privileges where RWX of Admin is 4 represent binary 1 0 0. In this binary pattern, first bit represents R for read operation, second bit represents W for write operation, and X means delete operation. RWX = 4 for Admin means, this user only can read but no write and delete privilege assigned. In the same table, DutyTime for ForensicUser is 0917; it means forensic user’s duty time is 09:00 AM to 05:00 PM. Table 8 exhibits examples of forensic department names and Table 7 gives idea regarding types of objects. On the other hand, Table 6 represents the assignment of object type against each type of forensic department, where Table 7 shows a list of object types and the same for the forensic departments in Table 8.

Table 5 Roles with user privileges and access time

Table 6 Forensic user and object assignment

Table 7 Types of objects

Table 8 Forensic departments

4.2 Experimental use cases for ARBAC

Figure 22 shows that violation of environmental rules may occur due to invalid subject as subject requests access from any location where the location is not registered. On the other hand, in Fig. 23, another type of environmental rule violation is due to invalid access time which occurs when any user requests access out of his/her office time. In Fig. 24, this is shown that if a user with fire department user credential tries to access phone log data, then the request is rejected. Because a user credential used by fire department authority is assigned to a specific role relevant to a fire department person. The last depiction in Fig. 25 illustrates a user tries to delete certain object which is not possible because no user has a delete privilege. Blockchain being an immutable data structure, no party can delete or remove any block or object from the ledger. The detail on this is as follows.

Fig. 22

Use case of ARBAC—invalid subject location

Fig. 23

Use case of ARBAC—invalid access time

Fig. 24

Use case of ARBAC—subject with different role

Fig. 25

Use case of ARBAC—subject with wrong privilege

5 Blockchain ledgers as data storage

A blockchain is a growing list of records (blocks) that are linked using the cryptographic hash value [33]. Each block contains a header or block number, a timestamp, a nonce, hash value of the previous block and transaction, or hash value of the current block. The transactions are verifiable and the data entered into it cannot be deleted [14]. Blockchain technology is useful in financial, commercial, industrial, and other sectors as well. In blockchain, the blocks are interlinked. Blockchain also provides data storage using distributed ledger for peer-to-peer communications [34]. Each block is constructed using a data structure called a Merkle tree as shown in Fig. 26.

Fig. 26

Merkle Tree

In Fig. 26, T₁, T₂, T₃ and T₄ are transactions (records of a user) and H denotes a cryptographic hash function such as SHA-512. The upper level of the transactions d₁, d₂, d₃, and d₄ represent the hash codes (values) of the respective transactions. The hash value d₁₂ is a new hash value created from the hash values of its children in the tree. Similarly, the hash value d₃₄ is produced from the hash values d₃ and d₄. At the root level, there is a final hash value, which is the output from the hash values of its children. Actually, in the root, there is other information such as block header or number, timestamp, a nonce, and the hash value of its previous block. A structure of a block is given in Fig. 27. In the figure, we consider the i_th block of a blockchain ledger. H_i, TS_i, and N_i represent the header, timestamp (date and time), and nonce (a random number or string). The hash values of the (i-1)_th block and i_th block are denoted by d_i-1 and d_i respectively. In a ledger (blockchain), the blocks are chained (linked) as shown in Fig. 19.

Fig. 27

Structure of a block

In our proposed framework, there is a blockchain ledger for each specific service, such a ledger is for electricity bills, another ledger is for water bills, and so on. All the ledgers are stored in a main server or a cloud server, which facilitates the proper management of data for forensic use in a smart city. The ledgers in the main server are shown in Fig. 28.

Fig. 28

Interaction of user with ledgers in main server

5.1 Lightweight proof of work and consensus

Proof of Work (PoW) consensus in Bitcoin is computationally time-consuming as it requires numerous participants to participate in consensus [35]. So, in the proposed framework, we minimize the number of participants by selecting edge servers and main server as the only users to add new block through a lightweight consensus. This lightweight consensus also increases scalability as we utilize it within a consortium blockchain [4]. To add a new block to a blockchain ledger, an edge device finds relevant edge server through smart contract and sends the data to relevant edge server after successful authentication. So, broadcasting of new block is not required as an edge device finds its related server required. For this case, edge server plays the role of a miner. Edge device chooses miner and then it approaches the main server to add the new data block to respective blockchain ledger. Main server authenticates an edge server with the help of ARBAC module; at the same time, main server validates the new data to be added based on some predefined requirements or rules set by the system admin. Based on these requirements or rules, relevant edge server conducts checking of data prior to adding the data block into the blockchain ledger. In this phase, edge server checks whether proper data come from the relevant edge device or not; if checking is successful, then it proceeds to main server. Now, as the edge server is authenticated by the main server, targeted ledger for the new block must be chosen by the main server. Proof of work is done by main server based on some predefined requirements set. Thus, main server and relevant edge server come to a consensus based on proof of work. So, the new block is added to the relevant ledger upon consensus.

$$\begin{aligned} \begin{array}{c} Authentication\;of\;ES>data\;validation\;by\;MS>\\ PoW\;by\;MS>\\ Consensus\;by\;ES\;and\;MS>New\;Block\;Added \end{array} \end{aligned}$$

Sequence for proof of work and consensus achieved can be described as above, where first step is to authenticating the edge server (ES) by the main server (MS) and at last new block is added to relevant ledger by the main server (MS).

5.2 Distributed system for blockchain

As data in the immutable blockchain ledgers grows simultaneously, each of the ledgers will grow a long way which is almost impossible by a single system to handle. On the other hand, proof of work for achieving consensus when finding the right place to add new block and verifying the whole chain (blockchain ledger) take huge overhead. No data can be deleted from any blockchain ledger as all the blocks are interlinked, so new version of data or block can be added. For the purpose of load balancing the overhead and smooth operation, whole blockchain data storage is designed in distributed manner. How devices interact themselves to store data into the main server is as follows.

5.3 System functionality

The proposed framework in this paper includes five groups of behaviors: SmartContract (SC), EdgeDevice (ED), EdgerServer (ES), ForensicUser (FU), and MainServer (MS) as depicted in Fig. 29. Blockchain facilitates SC that mediates the communication between ED and ES. ED plays the role of a peripheral device of the whole framework that utilizes SC for all communications to ES. ED finds the relevant ES in the area to submit the activity log through SC. ES preregisters itself with the MS for all future communications to collect activity log data from ED upon authentication and send it to MS. MS further authenticates requests from ES to establish direct communication to ED for adding new data into the ledger within MS. ES also takes part in consensus with MS to validate and add new block of data. Finally, MS itself decides the type of ledger according to the types (example in Table 7) of activity log data. In addition, MS also preregisters FU and authenticates it on request.

Fig. 29

Class diagram that shows system functionality

Above algorithm 1 shows that blockchain-based SC initializes separate lists of ED, ES, and area in lines 1 to 3 and waits for a request from ED in line 4 to connect it to relevant ES. In the next line, SC authenticates the requester. Upon successful authentication, SC finds the relevant ES for ED, sends activity log to proper ES, set the ES as miner, and finally connects the ED to ES in lines 7 to 10. The next section discusses the security aspects of the framework.

Algorithm 1. Process of SC in edge network 

6 Discussion on security aspects

Some propositions and their proofs based on a few security use cases from our experiment along with a comparison of security features are described below:

6.1 Security propositions

Proposition 1: Mixed type of verification and authentication system provides better security

Proof: In our proposed framework, verification and authentication are conducted using conventional id, password, and asymmetric keys. As such, when a corporate user wants access to main server the user is verified using its credentials (username, password) and the edge server signs the TAG_ck using its own private key. Later main server verifies the signature of the edge server using the public key of edge server. Where public key is a publicly available key, but private key is not. User credential-based login approach, asymmetric cryptography, and new concepts of key generations together form a strong verification and authentication system.

Proposition 2: Time-based key generation process ensures randomization of secret keys

Proof: For all the secret key generation processes mentioned in this article, are randomized based on timestamp of the respective devices. For instance, TS_i, TS_ess, TS_tag, TS_mss and TS_ET all are timestamps of respective devices required for computing secret keys.

Proposition 3: The proposed approach prevents fraud

Proof: Multiple levels of security key generations processes, use of existing id-password-based credentials, and use of asymmetric key ensure the prevention of any kind of unauthenticated access.

Proposition 4: Ensures integrity of secret key

Proof: In all of the phases, most of the secret key computations are backed up by hash function. For this, implementation SHA-1 is used with variety of salt values.

Proposition 5: The proposed framework prevents impersonation attack

Proof: All computed secret keys are encrypted and sometimes hashed if it is required to transmit within multiple devices, so any intruder cannot get it beneficiary if it is impersonated. Even if any key is required to be stored, it is done in a secured manner. Such as, main server encrypts the C-ET with the public key of edge server when sending it over the network to edge server.

Proposition 6: Proper distribution of appropriate objects to subjects

Proof: In our framework, object refers to data and subject refers to user requesting data access. ARBAC is the module which decides the object allocation to proper users according to user roles and privileges, which helps to ensure selective data access for the users of the system, that also reduces system execution overhead because only the allocated data is accessed by the user rather than accessing whole data.

Proposition 7: Data integrity due to immutability of blockchain

Proof: Implementation of blockchain ensures data integrity because data within blockchain ledger are unchangeable. Blockchain is immutable, which ensures that data within blockchain ledger is not changeable. Each block of blockchain holds the hash of current and previous block hash. If any block of the blockchain is to be altered, the whole chain of data is required to be changed, which is impossible.

6.2 Comparison of security features

We compare Wang et al. [4], Jangirala et al. [5], Bonnah et al. [6], and Sharma et al. [2] with the security features in our proposed framework in Table 9. It shows that the proposed framework provides even better security and scalability than its close contender in [5] as we combine secret key, asymmetric key, and hash function together in edge computing using consortium blockchain.

Table 9 Comparison of the proposed framework with other state of the art methods

7 Conclusion

The main contribution of this research work is the proposed authentication process that efficiently authenticates all users and devices with newly developed code (value) generation processes. Combination of lightweight consensus and consortium blockchain in edge network enhanced scalability of the proposed framework and integrity of authentication keys. Furthermore, it enriched the endpoint device authentication, so any unwanted device cannot add a new block of data to the blockchain data storage. On the other hand, ARBAC module is our hybrid implementation composed of role and attribute based access control system for our research which played a vital role to the overall work to control forensic user access. In our experiment, the proposed approach prohibits users from modifying any data stored in blockchain data storage for several test cases. That ensures data immutability which is an inherent feature of blockchain. In system design section, authentication of users are verified using AVISPA when sharing secret information among them assuming that intruder may interfere the communication. When transmitting secrets among users, result analysis phase shows that highly confidential citizen data are accessed only by authenticated forensic users with appropriate roles assigned by admin-level users, where no intruders can alter data.

Appendix

Tables 1 and 3 show the details of all the notations used.