PaperlayerView exact revision on arXiv

Source-linked AI summary

BlendCAC: A BLockchain-ENabled Decentralized Capability-based Access Control for IoTs

Ronghua Xu, Yu Chen, Erik Blasch, Genshe Chen

arXiv:1804.09267v1cs.NIcs.CRcs.DC

TL;DR

IoT access control must protect resources and information despite scalability, heterogeneity, dynamic interactions, and centralized-authority weaknesses. BlendCAC uses blockchain, smart contracts, and capability delegation to decentralize authorization and token management. A prototype on Raspberry Pi devices and a private Ethereum network demonstrates feasibility and lightweight, scalable, fine-grained access control.

  • Problem

    IoT access control must handle scalable, heterogeneous, dynamic networks, while centralized authorization can create performance bottlenecks or single points of failure.

  • Method

    BlendCAC combines blockchain-deployed smart contracts with identity-based capability tokens, delegation, propagation, revocation, and access-right validation.

  • Results

    The prototype and experiments demonstrate BlendCAC's feasibility and effective, efficient authorization in distributed IoT environments.

  • Takeaways & Limitations

    BlendCAC offers a decentralized, scalable, lightweight, and fine-grained access-control approach for IoT devices, services, and information.

Abstract

from arXiv · show

The prevalence of Internet of Things (IoTs) allows heterogeneous embedded smart devices to collaboratively provide smart services with or without human intervention. While leveraging the large scale IoT based applications like Smart Gird or Smart Cities, IoTs also incur more concerns on privacy and security. Among the top security challenges that IoTs face, access authorization is critical in resource sharing and information protection. One of the weaknesses in today's access control (AC) is the centralized authorization server, which can be the performance bottleneck or the single point of failure. In this paper, BlendCAC, a blockchain enabled decentralized capability based AC is proposed for the security of IoTs. The BlendCAC aims at an effective access control processes to devices, services and information in large scale IoT systems. Based on the blockchain network, a capability delegation mechanism is suggested for access permission propagation. A robust identity based capability token management strategy is proposed, which takes advantage of smart contract for registering, propagation and revocation of the access authorization. In the proposed BlendCAC scheme, IoT devices are their own master to control their resources instead of being supervised by a centralized authority. Implemented and tested on a Raspberry Pi device and on a local private blockchain network, our experimental results demonstrate the feasibility of the proposed BlendCAC approach to offer a decentralized, scalable, lightweight and fine grained AC solution to IoT systems.

I. INTRODUCTION

IoT growth increases security and privacy concerns, with access control becoming difficult to scale across heterogeneous, dynamic, resource-constrained networks. BlendCAC addresses these needs through blockchain-enabled, decentralized, capability-based authorization.

  • Motivation: Access control is critical for protecting IoT resources and information, but conventional ACL, RBAC, and ABAC approaches do not adequately meet emerging IoT requirements.The identified requirements include scalability, heterogeneity handling, and support for causal or spontaneous interactions.
  • Challenges: Large IoT deployments create increasing access-control management workload across heterogeneous devices, technologies, and application domains.Different domains may require distinct identity-authentication and authorization-policy enforcement approaches.
  • Challenges: IoT access-control protocols should remain lightweight because devices have constrained resources and communicate through low-power, lossy networks.The paper frames lightweight operation as avoiding significant overhead on devices and communication networks.
  • Research Need: IoT networks need decentralized authentication and authorization so policy intelligence can be distributed among edge devices rather than concentrated in cloud authorities.The stated motivation is to support scalable, flexible, lightweight access control in large, dynamic, heterogeneous networks.
  • Approach: BlendCAC combines blockchain, smart contracts, capability tokens, delegation, and contextual access validation to provide scalable, fine-grained, lightweight IoT access control.The paper also reports a prototype and experimental evaluation against RBAC and ABAC.

II. BACKGROUND KNOWLEDGE AND RELATED WORK

IoT access control must protect security and privacy while supporting scalability, flexibility, lightweight operation, and dynamic interactions. Related work progresses from centralized and role- or attribute-based models toward capability-based approaches, but delegation, revocation, contextual trust, and centralization remain challenges.

  • Access Control in IoTs: IoT access control determines which subjects may exercise communication rights over resources under specified security models and policies.Effective systems are expected to support confidentiality, integrity, availability, scalability, flexibility, lightweight operation, and causality.
  • Traditional Models: RBAC assigns resource authorization through roles but can suffer role explosion, while ABAC associates policies directly with subject attributes.ABAC was introduced in IoT settings partly to reduce the number of rules produced by role explosion.
  • Capability Models: Capability-based access control is considered promising for IoT because it supports distributed, user-driven systems with delegation and revocation.The capability model associates subjects with capability lists representing access rights to objects.
  • Limitations: Centralized ACL management becomes difficult to scale and manage as subjects and resources increase, and it remains vulnerable to a single point of failure.The related-work discussion also notes limited granularity in centralized ACL approaches.
  • Prior Capability Work: Existing capability-based proposals address propagation, revocation, contextual awareness, or federation, but may require centralized components or pre-established trust relationships.SICAP uses monitoring and exception lists for propagation and revocation, while CCAAC assumes prior inter-domain trust.

B. Blockchain and Smart Contract

Blockchain provides a decentralized ledger for recording transactions without relying on a centralized authority, while smart contracts extend this model to programmable agreements. These properties motivate blockchain-based access control for trustless IoT environments, although prior proposals may retain external centralized components.

  • Blockchain: Blockchain records and updates data distributively, with miners approving transactions and appending them chronologically to blocks.Consensus mechanisms maintain the integrity of data recorded on the blockchain.
  • Blockchain: Blockchain supports trustless transactions by distributing the public ledger across nodes instead of requiring trust in a counterparty or third-party intermediary.The cited discussion presents blockchain as an architecture for distributed transactions in trustless environments.
  • Access Control Applications: Blockchain-based access control can publish policies and distribute access-right transfers while providing distributed auditability.A cited proposal prevents third parties from fraudulently denying rights granted by an enforceable policy.
  • Smart Contracts: Smart contracts use blockchain to achieve agreements among parties without relying on third parties to maintain their trust relationship.They support customized transaction types beyond cryptocurrency applications.

III. BLENDCAC: A BLOCKCHAIN-ENABLED DECENTRALIZED CAPAC

BlendCAC replaces centralized IoT access-control coordination with smart-contract policies deployed across a blockchain network. It builds on capability-based authorization and aims to distribute policy enforcement and access verification across edge devices.

  • Prior Approach: FedCAC reduces centralized policy-decision workload by delegating authentication and authorization tasks to domain delegators and local devices.Its device-to-device processing supports scalability and interoperability, but the model remains centralized.
  • System Architecture: Figure 1 presents BlendCAC as a system for two isolated IoT service domains whose owners manage devices and services without pre-established trust.Each domain owner enforces predefined security policies for its domain.
  • Prior Approach: FedCAC still retains single-point-of-failure and performance-bottleneck weaknesses because it is essentially a centralized access-control scheme.This limitation motivates the decentralized design of BlendCAC.
  • BlendCAC Design: BlendCAC encapsulates access-control policies in smart contracts deployed across the blockchain, allowing users to control their own data or devices.The framework enforces authorization and access-right verification among distributed edge devices.

A. System Architecture of BlendCAC

BlendCAC organizes access control around domain-owned identities, blockchain accounts, and identity-based capability tokens. Capabilities associate subjects, objects, actions, delegation rights, and context constraints so domain owners can control resources without third parties.

  • Domain owners define authorization policies and directly control their devices or resources instead of depending on third parties.
  • Entities are classified as subjects requesting services and objects providing resources or services, with either humans or smart devices serving either role.
  • Each registered entity receives a globally unique Virtual Identity linked to its blockchain account address for profile identification.
  • A capability specifies which subject may access a target object's resources by associating the subject, object, actions, and condition constraints.
  • The capability structure includes a one-way hash, subject and object virtual IDs, delegation rights, access rights, and context constraints.

C. Capability-based Access Right Authorization

BlendCAC implements authorization through smart-contract-managed capability tokens and a domain-owner policy service. Its procedure covers capability generation, local access validation, delegation, and revocation.

  • The authorization procedure consists of capability generation, access right validation, capability delegation, and revocation.
  • Capability tokens and their operations are deployed as smart contracts, while domain owners run the access-right decision service.
  • During capability generation, the domain owner associates a virtual identity with access rights and stores the resulting token in a smart contract.
  • For validation, the service provider retrieves a subject's capability token from the smart contract and applies local access-control policy before granting service access.

IV. IMPLEMENTATION AND EXPERIMENTAL RESULTS

The authors implemented BlendCAC as a smart contract on a private Ethereum blockchain and enforced authorization through a Python Flask web service. The evaluation compares it with RBAC and ABAC using similarly structured smart contracts.

  • BlendCAC was implemented as a smart contract in Solidity and deployed on a real private Ethereum blockchain network.
  • A Python Flask web service implements the access authorization and validation policy for resource-constrained IoT devices.
  • The experiment implements RBAC and ABAC benchmark models alongside BlendCAC to evaluate performance and overhead.
  • All evaluated access-control models use similar smart-contract data structures except for their authorization representations.

A. Environmental Setup

The environmental setup assigns mining to laptop and desktop systems running Ubuntu 16.04, with six miners distributed across the machines. Each miner uses two CPU cores.

  • Six miners run across one laptop and four desktops, with two miners on the laptop and one on each desktop.
  • The laptop uses a 2.3 GHz eight-core Intel Core i7 processor and 16 GB RAM, while the desktops use 3 GHz two-core processors and 4 GB memory.
  • All mining systems run Ubuntu 16.04, and each miner uses two CPU cores.

B. Performance Evaluation

BlendCAC was evaluated against RBAC and ABAC on Raspberry Pi devices using repeated access requests. Its main cost came from token processing, while authorization verification was faster than both comparison models.

  • B. Performance Evaluation: 50 test runs measured BlendCAC access requests between Raspberry Pi client and service-provider devices.The scenario measured processing time and network communication delay for a client data query requiring access permission.
  • B. Performance Evaluation: 243 ms was the average total BlendCAC retrieval delay, approximately matching RBAC and ABAC.The total includes round-trip time, smart-contract capability queries, request JSON parsing, and access-right validation.
  • B. Performance Evaluation: 210 ms, nearly 86% of total process time, was spent on token processing.Token processing fetched token data from the smart contract and was the most computationally intensive stage.
  • B. Performance Evaluation: 0.86 ms was the average authorization-process time, comprising 0.12 ms for token validation and 0.74 ms for authorization verification.Authorization verification required more computation than the simple token-validity check.
  • B. Performance Evaluation: BlendCAC authorization verification took 0.74 ms, compared with 2.47 ms for RBAC and 2.07 ms for ABAC.RBAC and ABAC searched database-managed role or attribute rules, whereas BlendCAC enforced local access-control policies directly.

2) Communication Overhead:

BlendCAC reduces repeated communication overhead by caching token data locally and synchronizing it with the smart contract periodically. After initial setup, its added latency remained small relative to access without control and was generally below RBAC and ABAC.

  • 2) Communication Overhead:: Token-data caching lets service providers validate authorization locally instead of querying the smart contract for every request.Cached data is refreshed by checking smart-contract status, with synchronization aligned to approximately 15-second Ethereum block generation.
  • 2) Communication Overhead:: 36 ms was BlendCAC’s average latency versus 31 ms without access control, adding about 5 ms.The initial request incurred a longer delay while token data was obtained and cached; subsequent requests stabilized at a low level.
  • 2) Communication Overhead:: BlendCAC had lower latency than RBAC and ABAC during most of the measured period.The comparison included overall network latency for BlendCAC, RBAC, ABAC, and a no-access-control benchmark.
  • 2) Communication Overhead:: The measured 5 ms network overhead was no more than 2% of the approximately 300 ms average network latency.The experiments used HTTP on the same testbed to simulate ordinary inter-domain transactions.
  • 2) Communication Overhead:: Periodic token-status queries run in a separate service thread, reducing overhead on service-request communication.The approach supports quality-of-service requirements while requiring additional resources for cached-token synchronization.

C. Discussions

BlendCAC uses blockchain and smart contracts to decentralize capability-based authorization for IoT resources. Prototype experiments support its feasibility, while the authors identify complete decentralized IoT security as future work.

  • BlendCAC decentralizes authorization by allowing domain owners to control devices and resources without a centralized third authority.It supports domain-specific authorization policies for scalable, heterogeneous, and dynamic IoT applications.
  • Experiments validate efficient and effective distributed authorization in a trustless IoT network.The authors characterize the framework as scalable, fine-grained, and lightweight for IoT access control.
  • The framework transfers access-control intelligence from centralized cloud servers toward IoT network edges.This design mitigates performance bottlenecks and single points of failure while letting devices enforce user-defined security mechanisms.
  • BlendCAC combines capability-based access control with blockchain and smart contracts in a physical IoT-network prototype.The model was implemented as smart contracts and deployed on a private Ethereum blockchain with Raspberry Pi edge nodes.
  • The authors state that a complete decentralized security solution for IoT and edge computing remains future work.They propose further exploration in real-world applications, including smart surveillance systems.
Loading 1804.09267v1…