Source-linked AI summary

Smart Contract-Based Access Control for the Internet of Things

Yuanyu Zhang, Shoji Kasahara, Yulong Shen, Xiaohong Jiang, Jianxiong Wan

arXiv:1802.04410v1cs.CR

TL;DR

The paper addresses IoT access control challenges involving centralized validation and potentially compromised validating devices. It proposes an Ethereum-based smart-contract framework with access-control, judging, and registration contracts, and demonstrates feasibility in a small IoT case study.

  • Problem

    IoT access control can rely on centralized validation, creating a single point of failure, while low-capability IoT objects used for distributed validation may be compromised.

  • Method

    The framework uses multiple ACCs for static and behavior-based dynamic validation, a JC for misbehavior judgments and penalties, and an RC for managing these methods and contracts.

  • Results

    The Ethereum-based case study demonstrated the feasibility of the framework for distributed and trustworthy IoT access control.

  • Takeaways & Limitations

    Smart-contract execution verified by most system participants provides the framework’s proposed basis for trustworthy, distributed access control.

Abstract

from arXiv · show

This paper investigates a critical access control issue in the Internet of Things (IoT). In particular, we propose a smart contract-based framework, which consists of multiple access control contracts (ACCs), one judge contract (JC) and one register contract (RC), to achieve distributed and trustworthy access control for IoT systems. Each ACC provides one access control method for a subject-object pair, and implements both static access right validation based on predefined policies and dynamic access right validation by checking the behavior of the subject. The JC implements a misbehavior-judging method to facilitate the dynamic validation of the ACCs by receiving misbehavior reports from the ACCs, judging the misbehavior and returning the corresponding penalty. The RC registers the information of the access control and misbehavior-judging methods as well as their smart contracts, and also provides functions (e.g., register, update and delete) to manage these methods. To demonstrate the application of the framework, we provide a case study in an IoT system with one desktop computer, one laptop and two Raspberry Pi single-board computers, where the ACCs, JC and RC are implemented based on the Ethereum smart contract platform to achieve the access control.

I. INTRODUCTION

IoT interconnection creates important access-control and trust challenges because traditional validation is often centralized or delegated to potentially compromised devices. The paper proposes a smart-contract framework intended to provide distributed and trustworthy access control through blockchain-based execution.

  • Motivation: IoT connects diverse devices and resources through networks, enabling data collection, sharing, and services while creating risks of illegal resource access.The considered system includes servers, storage devices, gateways, user devices, sensors, and actuators connected through a peer-to-peer network.
  • Related Work: Traditional IoT access control commonly uses RBAC, ABAC, or CapBAC models to assign rights based on roles, attributes, or transferable authority tokens.These models establish access decisions through organizational roles, policy conditions, or capabilities.
  • Problem: Centralized access-right validation creates a single point of failure, while distributed validation by low-capability IoT objects remains vulnerable because those objects may be compromised.These limitations motivate using blockchain and smart contracts for distributed and trustworthy access control.
  • Contribution: The proposed framework combines multiple access control contracts, one judge contract, and one register contract to manage distributed access control methods.Each ACC handles a subject-object pair, the JC judges reported misbehavior, and the RC manages method information and contract registration, updating, and deletion.
  • Contribution: Each ACC performs static validation against predefined policies and dynamic validation based on subject behavior, with execution and verification by most system participants.The framework also supports adding, updating, and deleting access-control policies.
  • Case Study: An Ethereum-based case study implements the ACCs, JC, and RC in an IoT system containing one desktop computer, one laptop, and two Raspberry Pi computers.The case study demonstrates the framework’s application to access control in the described IoT setting.

III. SMART CONTRACT PLATFORM

The paper uses Ethereum as the smart contract platform underlying its distributed access-control framework. Ethereum accounts, contracts, transactions, messages, blockchain replication, and mining provide the execution and consensus mechanisms.

  • Ethereum identifies externally controlled accounts and contract accounts by 20-byte addresses.Contract accounts contain code and state and expose ABIs for interaction.
  • Transactions sent by accounts execute contract ABIs, while messages sent by contracts execute ABIs in other contracts.
  • Each network node may maintain a local blockchain copy containing blocks of transactions and smart contracts linked by previous-block hashes.
  • Mining validates transactions and contract execution across nodes, producing tamper-resistant consensus when no participant controls more than half the computing power.
  • The framework includes access control contracts as smart contracts within the Ethereum-based system.

B. System Configurations

The framework configures Ethereum participants and organizes access control through ACCs, a JC, and an RC. ACCs combine policy-based and behavior-based validation, while the JC judges misbehavior and the RC manages contract methods.

  • System Configurations: Each peer uses an Ethereum account, while non-IoT peers run synchronized clients that deploy contracts, send transactions, and may mine blocks.IoT devices lack Ethereum clients because of limited energy and computing power.
  • System Configurations: IoT gateways act as trusted agents by storing local device accounts and signing contract transactions on their behalf.The framework assumes gateways are physically accessible and unlikely to be compromised.
  • Access Control Contract: Each ACC serves one subject-object pair and performs static validation against policies plus dynamic validation based on subject behavior.A subject-object pair may use multiple ACCs, but each ACC is associated with only one pair.
  • Access Control Contract: ACC policy records specify resources, actions, permissions, and time of last request, enabling permission checks and frequency-based behavior detection.
  • Judge Contract: The JC receives potential misbehavior reports from ACCs, judges subjects using misbehavior history, determines penalties, and returns decisions to reporting ACCs.Its records include the object, misbehavior details, time, and imposed penalty.
  • Register Contract: The RC maintains a lookup table for access-control and misbehavior-judging methods, recording names, subject-object identities, creators, contract addresses, and ABIs.

B. Main Functions of the Framework

The framework supports lifecycle management for access-control methods and policies, and executes access requests through the RC, ACC, and JC. Blockchain mining supplies consensus for the resulting access decision.

  • The framework supports registering, updating, and deleting access-control methods, managing judging methods, managing ACC policies, and performing subject-object access control.
  • Registering a new access control method: Registering a method creates and deploys an ACC, then records its information in the RC lookup table through methodRegister.
  • Updating an existing access control method: Updating a method deploys a replacement ACC, updates its RC fields such as ScName, ScAddress, and ABI, and destroys the old ACC.
  • Deleting an existing access control method: Deleting a method removes its lookup-table entry through methodDelete and destroys the corresponding ACC.
  • Access control: For access control, the requester retrieves an ACC address and ABI from the RC, then submits the request to accessControl for static and dynamic validation.The transaction executes after mining includes it in a new blockchain block.
  • Access control: When an ACC detects potential misbehavior, it calls the JC, receives the penalty decision, and returns the final access result to both subject and object.The local gateway informs an IoT device of access requests and results through secure local interactions.

V. CASE STUDY

The case study demonstrates the proposed framework for distributed IoT access control. It introduces the study hardware and software, implements access control with the framework, and reports experiment results.

  • The case study evaluates an implementation of the framework for distributed access control in an IoT system.
  • The study includes hardware used to demonstrate the framework's IoT access-control application.

A. Hardware and Software

The case study uses a desktop computer, laptop, and two Raspberry Pi single-board computers, with desktops and laptops as user devices and Raspberry Pis as local gateways. Each device runs an Ethereum node in a private blockchain network, while web3.js connects subject- and object-side software to the smart contracts.

  • Hardware: The case study includes one Dell Inspiron 3650 desktop, one MacBook Pro laptop, and two Raspberry Pi 3 Model B computers.The desktop and laptop represent user devices, while the Raspberry Pis represent local gateways.
  • Software: Each device runs a geth client and has an Ethereum account in a private blockchain network.The desktop and laptop serve as miners, while the single-board computers function as lightweight nodes.
  • Software: At the object side, Remix compiles Solidity ACCs, while web3.js deploys them and monitors access-control results through geth.web3.js communicates with the geth client through HTTP connections.
  • Software: At the subject side, web3.js sends access requests to the ACC through geth and receives the access-control results.

B. Implementation

The implementation of the ACC, RC, and JC follows the examples presented in Section IV-A.

  • Implementation: The ACC, RC, and JC implementations are based on the examples in Section IV-A.

1) ACC:

The ACC combines policy-based access validation with behavior-based misbehavior detection. It blocks requests after detected misbehavior and returns both the access decision and any penalty.

  • ACC: The ACC detects misbehavior when requests are sent too frequently, then asks the JC to judge it and computes a new unblock time from the penalty.
  • ACC: Policies are stored in a two-dimensional mapping keyed by resource and action, with fields including minimum request intervals and frequent-request thresholds.A later request is frequent when its interval is less than or equal to minInterval; misbehavior is judged when NoFR reaches threshold.
  • ACC: The ACC takes a resource, action, and time as input and returns an access-control result and penalty.
  • ACC: The ACC first checks whether the resource is currently unblocked before evaluating the request policy.
  • ACC: Detected misbehavior is added to the resource’s misbehavior list, while the final result combines policyCheck and behaviorCheck.
  • ACC: The ACC emits a returnResult event containing the access result and penalty, and its implementation follows the examples in Section IV-A.
  • RC: The RC constructs a lookup table that maps each method name to stored method information using a struct.
  • JC: The JC records subject misbehavior dynamically and determines penalties using base and interval parameters based on the number of exhibited misbehaviors.The penalty is calculated as penalty = (base)^floor(ℓ/interval), with parameters initialized when the JC is deployed.

4) JavaScripts at the subject and object:

The subject-side JavaScript retrieves the ACC from the RC, submits access requests, and receives results through events. The object-side JavaScript continuously monitors those events to observe requests and penalties.

  • JavaScripts at the subject and object: The subject-side script retrieves the ACC address and ABI from the RC before creating an ACC instance.
  • JavaScripts at the subject and object: The access-control result is returned to both the subject and object sides through the ACC interaction.
  • JavaScripts at the subject and object: The subject-side script sends resource, action, and time parameters to the ACC through an accessControl transaction.
  • JavaScripts at the subject and object: When returnResult is captured, the subject-side script obtains the result and penalty from the event.
  • JavaScripts at the subject and object: The object-side script continuously watches returnResult events to identify the requester, resource, time, result, and penalty.

C. Experiments

The experiments implement access monitoring through the register and access control contracts, then test penalties after repeated subject misbehavior. The observed blocking durations increase consistently with the penalty equation.

  • Experiment setup: The experiment configures minInterval to 100 seconds, threshold to 2, and the judge contract base and interval to 2 and 3.
  • Experiment setup: The Access Monitor JavaScript creates a register instance, retrieves a named access-control contract, instantiates it, and displays returned results and penalties.It captures the returnResult() event while monitoring access outcomes.
  • Results: 1, 2 and 4 minutes: subject requests are blocked after misbehavior occurring once, three times, and six times, respectively.These durations are reported as consistent with the penalty determining equation in (1).

VI. CONCLUSIONS

The paper concludes that its smart contract-based framework enables distributed and trustworthy IoT access control. A case study with heterogeneous computing devices demonstrated the framework's feasibility.

  • The framework uses multiple ACCs for subject-object access control, one JC for judging misbehavior, and one RC for managing the contracts.
  • The case study used one desktop computer, one laptop, and two Raspberry Pi single-board computers to demonstrate access control.
  • The case study demonstrated the feasibility of achieving distributed and trustworthy access control for the IoT.
Loading 1802.04410v1…