Delegation by smart contract built on RBAC based authentication in a distributed architecture

Prvious discussion on the challenge in security in delegation is available here.

To address the aforementioned issues as stated in the previous acticle, we would like to pose the following decision question:

• What are the suggested authorization delegation mechanisms for IoT architecture?

• How do delegation exchange resource/ device material in IoT environment?

• How to verify the delegation and ensure the policy consistency along the delegation chain?

N. Tapas et al. use blockchain technology to build an authorization and delegation mechanism for an OpenStack-based IoT platform with distributed system architecture. The proposal aims to transition trusts from the standard OpenStack approach to smart contracts on the way to model a fully decentralized IoT framework for smart city initiatives.

While Keystone in the OpenStack architecture handles all authentication, a separate delegation agent is introduced to handle authorization and delegation. The blockchain manage the data model for delegation and roles.

The proposed IoTronic system employs a multi-level delegation scheme. Cascade revocation is adopted. In particular, when a delegation is revoked, all delegations stemmed from that delegation are also revoked. A collection of operations that are logged on blockchains are specified, they are: Create, Delete, List, Login, Read, Config and Inject.
The team conducted theoretical analysis in time and space complexity to evaluate the efficiency of operations. For performance assessment, the team presented a prototype and tested the it on the public Ethereum test network.

Processes of delegation in requesting permission in delegation agent and smart contracts

As referred to the Figure, the interactions that occur when a user requests access to a particular operation on an IoT resource are as followed. First the request is forwarded to the S4T IoTronic delegation agent. Second, the agent validates the user request by querying the S4T IoTronic database. Third, the S4T IoTronic delegation uses Web3 client to call the Delegation.sol contract. Forth, Delegation.sol contract demands the Role.sol contract to update the role to grant access to the operation. Fifth, Role.sol returns a list of roles which is used by Delegation.sol to check if the user is granted the permission to the resource. Sixth, the Delegation.sol contract records the output in the blockchain. Seventh, it returns the result to the S4T IoTronic delegation agent. Consequently, access to the resource is allowed or denied based on the return result.

Advantages:

1 Decentralized Architecture

The overall solution provides a decentralized architecture at different stages of the communication of IoT that enables data sharing among participants across a peer-to-peer network. The proposal provides a solution of a flexible and scalable IoT deployment.

2 Reaching Consensus in A Distributed Way

Smart contracts are distributed, and consensus is achieved each time a smart contract is executed. The election of a leader in Ethereum's consensus process is based on a complex calculation. The actor who can solve the puzzle is promoted to the role of leader. The blockchain's next block is then decided by the leader. The solution of the leader can be checked by all other actors in the network. In this way, a distributed consensus can be reached.

3 Logging and Auditing

It also brings transparency in use case such as auditing and logging. Each activity is recorded on the blockchain, users can verify whether a given operation or resource has been allowed or refused, thanks to the blockchain and Ethereum events and logs.

Disadvantages:

1 Time Consumption Validation

The average time needed for a Ethereum is around 14s, which could be unacceptable in some use cases.

Novelty of The Solution

1 Blockchain on OpenStack Architecture

Both blockchain and OpenStack are distributed service, and the combination of usage of them share the advantages in scalability and flexibility. The targeted IoT framework worked on in the proposal is the Stack4Things framework, which employs the OpenStack Keystone subsystem for the authentication mechanism. The proposal leverages blockchain technology and devise for the authorization and delegation mechanism of Stack4Thing framework.

2 Innovative Use of RBAC with Blockchain

The OpenStack architecture protects resources with the use of RBAC model. Each Keystone token contains a list of the user's roles. However, it could be difficult to enforce delegation because of the need to dynamically associate API calls to roles, giving the user permissions to execute an API calls temporarily and then revoking for a certain subset of services available as a whole.

The Proposal could maintain the use of authentication system and permission definition by Keystone, at the same time, empower the RBAC based authentication with Blockchain based delegation mechanism.

3 Two Levels of Delegation

The work provides a systematic classification of delegation by defining two levels of delegations.

Delegations at the first level represent roles assigned by default or by an administrator to users. The role of the owner of an IoT node is automatically created when the user creates an IoT node in the system, for instance, a user who adds a node to the system shall have all of the permission for that node such as list, login, read and write.

Lower-level delegation refers to temporarily assigned roles that is granted by any user that holds that role, as well as those that have been given to it. Any other users would like to get access to the resource API can ask the node owner for the permission. The node owner will then issue a second-level delegation to the user. The delegation assumes the trust between the delegator and the delegatee and delegator take the responsibility of the actions.

Experiments and Methology

The team has conducted performance evaluation of the models on Ganache, a local blockchain, and Rinkeby, a public testing network. Execution time of three operations is recorded: The insertion, removal of delegation into the system and access right checking of a user. The results are averaged out over the repeated 100 times experiments. For each solution, the average and worst case are both measured.

For results of tests conducted in Ganache, the execution time of insertion of the delegation varies proportionally to the existing number of delegations. The average insertion time is around 100ms when there is 1 delegation and is around 700ms where there is 200. The other operations in the proposed approaches show linear relationship or quadratic relation or quadratic growth for initial number and then linear growth for the remaining, which adheres to previous theoretical analysis. The same is also done in the system for Rinkeby. For most of the operations, the execution time is the comparable to average block confirmation time of blockchain at 14s for Rinkeby.

More Discussion

1 Actions Dependent to the RBAC system

It is a limitation of the design of the proposed framework as the delegation agent is relying on the keystone agent for authorization control. Although Blockchain has the advantage in trustiness, it is insufficient to achieve a full trustfulness in the proposed system as the authorization rules of a role is defined with the underlying Keystone service. Malicious user could bypass the delegation agent and access directly to the system through the underlying OpenStack based system. However, since the blockchain is introducing a public auditing system, the public can look for misuse of resource in the network.

2 Limited Delegation due to Underlying Blockchain Platform

The constraint has less to do with the implementation and more to do with the underlying network. The transaction may fail due to the gas consumption of operations exceeding the block gas limit. At the time of publication, the Rinkeby and Ropsten network had a gas limit of 7.7 and 4.7 million respectively. As the number of individuals delegation operations is limited by the gas limit, the depth of the delegation process is limited by this constraint. However, it is suggested by the authors to use pagination which divides the list of operations into discrete batch and invoke the block by each batch.

3 Verification During Mining

While the loggings being kept on the blockchain allows users to verify the signaling message sent by the delegation agent, the access checking request must wait until the mining of blockchain is finished. As a result, the long time it takes for an authorization request to be granted is inconvenient and makes the access management process inefficient.

To overcome this challenge, the team proposes a countermeasure which is applying pending transactions to be collected in a temporary pool while the blockchain is waiting to be mined. The pending block is added to the blockchain when consensus is reached. As a result, user can verify the permission by checking the pending block. As the experiment shown in section 5.3, the transaction verification is fast, by reaching consensus takes time. The response time of access request can thus be reduced by using the pending block.

4 Absence of Privacy Consideration

Privacy was not considered in the proposal. As the proposal is creating a public system that is verifiable and auditable by the general public, privacy is difficult to achieve in such context.

5 Logging and Auditing

The ability to verify and audit the delegation is an important key to reliable delegation across the chain. The blockchain proposal provides a possible solution for IoT clouds as something like event-based logs. With the availability of an audit trials stored at a common accessible source for users and authority, logging employs a user to double-check the decision made to them by the authorizing agent and report any discrepancies.