TLDR
- Blockchain’s immutability can provide a trust enhancement for shared systems, including the Internet of Things (IoT).
- However, IoT requires handling and storing enormous amounts of data.
- Blockchain storage issues have received little attention from researchers, particularly in the areas of improving malicious behavior detection and improving the processing capabilities of smart contract-based systems.
- The authors design and prototype an access control system based on smart contracts, integrating a credit-based misbehavior detection method to better protect an IoT system against security and privacy threats.
Citation
Liu, Yang, Terry Guo, Zhe Chen, and Xueying Jiang. “Efficient Attribute-Based Smart Contract Access Control Enhanced by Reputation Assessment.” arXiv preprint arXiv:2107.00679 (2021).
Core Research Question
How do we resolve the issue of increasingly heavy pressure on blockchain storage from massive IoT data, while also handling malicious access behaviors in the system?
Background
- The Internet of Things (IoT): Refers to the connection of manufactured objects to the Internet. With the sharp increase in smart devices, IoT has influenced vertical domains from industry and transportation to cities and the human body. However, with IoT devices and their complex networks, significant security and privacy concerns arise. Adversaries can gain illegal access to the devices to steal crucial data or perform malicious actions. Consequences can include privacy leaking, system failure, or even human injury.
- Access control: An important line for guarding IoT systems against security and privacy threats. However, traditional access control schemes rely heavily on centralized authorities at the risk of a single point of failure (SPOF) and offer users no control over their data. It is essential and urgent to find effective ways to secure IoT access control.
- Blockchain: A blockchain is a decentralized security framework with transparent, Byzantine fault-tolerant, immutable, and chronological ledgers maintained by distributed users. In recent years, it has received broad attention from both academia and industry due to its decentralized management mechanism. Many researchers have applied it to the field of access control to replace the centralized authorization entity.
- Smart Contracts: A smart contract is an agreement that can be self-executed without involving a third party. Most smart contracts use a Turing-complete language that can implement complex logic and applications. The smart contract expression capability can be fully utilized by describing various access control models, and by storing and managing an Access Control List (ACL). These contract systems either aim to provide sufficient access control capability or focus on specific scenarios. Since little consideration is given to storage footprint, many proposed schemes result in rapid growth in blockchain volume.
Summary
- The authors design a smart-contract architecture based on the ABAC model that can effectively minimize storage requirements on the blockchain and restrict rapid growth. Below is an overview of an Attribute-Based Access Control (ABAC) model:
(Attribute-Based Access Control (ABAC) example. Adapted from V.C. Hu et al., Guide to Attribute-Based Access Control (ABAC) Definition and Considerations, NIST Special Publication 800-162, Nat’l Institute of Standards and Technology, Jan. 2014.)
- The authors incorporate a design for a reputation assessment mechanism that helps to prevent malicious behavior during the access control process and favors well-behaved nodes.
- They use a modified prototype of the Quorum blockchain to validate the proposed scheme and assess its performance.
- Using the results, they conduct a case study of a simple supply chain that moves bananas on pallets by truck from a farm to a supermarket.
- The paper considers a three-layer system architecture:
- This paper presents two categories of functions. The first category is basic access control functions such as attribute management, policy management, or access request processing. These are accommodated by Action Control Contracts (ACCs) and a Management Contract (MC). The second category is malicious behavior detection, which is supported by the Reputation Contract (RC).
- The aforementioned smart contracts are detailed below in the Method section.
Method
Access Control Contract (ACC)
- An ACC is created and deployed for each device in the system. The ACC manages environmental attributes, resources, and policies. Processes access requests related to the device and make decisions about accepting or rejecting them.
- An account is auto-created and receives ether (ETH) from a gateway when a new device is connected. Afterward, the gateway creates an ACC for the device and deploys it on the blockchain using the device’s account. The contract addresses of MC and RC are passed along using a constructor when the ACC is deployed.
- Functions are provided for adding new policy items and updating or deleting existing policies. The device manager alone may delete the ACC.
- Top-layer miners do not involve specific access operations; this mitigates their influence on the timestamp to reduce security risks.
Management Contract (MC)
- The MC deploys upon blockchain creation.
- After deployment, the ACC must be registered in MC.
- The MC is responsible for managing information from the RC and device attributes (as a requestor).
- When a device joins the blockchain network, the MC deploys the ACC associated with it and registers its attributes.
- The management of RC includes three operations: Register, Get, and Update.
- The management of device attributes includes four basic operations: Register, Delete, Get, and Update.
- Deletion of the RC is not allowed.
Reputation Contract (RC)
- Following MC deployment, the RC is created, deployed, and registered in the MC.
- The RC uses “behavioral information” submitted by the ACC to calculate reputation level, rewarding or penalizing the devices accordingly.
Reputation Algorithm
- Reputations are calculated based on all current and previous behaviors.
- Credit of device i: C_i = \lambda_1 C_i^P - \lambda_2 C_i^N
- C_i^P: Positive part due to normal behaviors
- C_i^N: Negative part due to malicious behaviors
- \lambda_1 & \lambda_2: Weights
Penalty Function
- C_i^N = \sum_{k=0}^{m_i-1} \frac{\alpha_k}{m_i-k}
- m_i: This refers to the number of malicious behaviors to be considered for device i.
- k: This refers to the chronological index of malicious behavior in the past (begins at k=0).
- \alpha_k: This is the penalty coefficient of malicious behavior k that represents severity with range 1 to 10.
- \frac{1}{mi−k}: This functions as the weighing factor; it is variant depending on when malicious behavior appears. The impact of malicious behavior decreases gradually over time but never disappears.
- There are three types of malicious behavior: high-frequency request (behavior ID = 1), policy check failed (behavior ID = 2), and importance check failed (behavior ID = 3).
- Behavior cannot simultaneously belong to more than one type of malicious behavior. If there is ambiguity in categorization, then label with higher priority ID.
Reward function
- C_i^P = min(C_{i,max}^P, \sum_{k=k_1}^{l_i}\omega_k)
- C_{i,max}^P: This is the predefined upper limit on C_i^P and prevents unlimited reward accumulation.
- l_i: This is the number of normal behaviors considered for device i.
- k: This is the chronological index of past normal behaviors (k_1 is the index of the first normal behavior after the last penalty).
- Ω_k: This is the weight of normal behavior k. There is only one type of normal behavior currently with behavior ID = 0, but the list may be expanded with more normal types.
- Every behavior submitted automatically updates the behavior list. The penalty and reward values are recalculated to determine new credit values when updated.
- Upon C_i^P recalculation, normal behaviors before the index k_1 are not counted again.
- Malicious behavior records are never emptied; every penalty calculation counts all previous malicious behaviors.
- Penalties made by the system have the effect of blocking device access requests.
- The penalty attribute used in the MC and ACCs is the block number of the last forbid block (TLFB). This is calculated by adding forbid to the block number of the block containing the access transaction.
Other Issues
- A device’s credit should not be related to activity level.
- A device may not initiate a single request over a short period, but may not correspond to malicious behavior; thus, device credit value should be left unaffected.
- A library that provides Quad-precision floating-point operations is used to correct an issue with Solidity, which does not support floating-point in performing definitions and calculations.
- Access is requested before the last forbid block is reverted directly.
Behavior list
- There are four parts to the behavior list: LegalBehavior, which is the normal behavior list, Misbehaviors, which is the malicious behavior list, Begin, which is the beginning index of LegalBehaviors, and TLFB, which is the last forbid block.
- LegalBehaviors and Misbehaviors are the two most important parts. They have the same structure consisting of three parts: Behavior ID, Block number (corresponds to the moment when behavior appears), and Current weight value.
- The behavior list can be found using the subject address (as key).
- A reputation calculation algorithm was provided in the paper; it is designed to prevent interference made by outside users and can only be called by the ACC. There is no self-destruct operation.
Results
The Blockchain-Based Reputed Access Control (BBRAC) system shows the potential for suppressing the growth of blockchain storage in its reputation mechanisms.
Gas Consumption
- Accurately reflects the cost of each operation.
- In the BBRAC scheme, subject attribute management is managed by the MC, while in Wang’s scheme, it is managed by the SC.
- In the BBRAC scheme, resource attribute management, policy management, and access decisions are all managed by just one ACC.
- In Wang’s scheme, resource attribute management, policy management, and access decisions are managed by object contract, policy contract, and ACC, respectively.
- Fig. 5 shows the results based on transaction cost.
Access Time
- Access time is a key performance metric, especially for applications with high real-time requirements. Access time depends on many factors, e.g. hardware, network, consensus choice, and communication factor, and inter-calling between contracts
- Table IV shows the average access time of over 500 requests both with and without reputation subsystems, presenting a comparison with Wang’s scheme.
Storage Pressure
- With blockchain applied in IoT, large devices correspond to large contracts; this results in storage pressure on the blockchain.
- Storage pressure may be reduced by reducing contract size (selecting access model, design of contract architecture, function implementation, etc.).
- Comparison (n: number of devices)
- In Zhang’s scheme, an ACC is deployed by an object device that wants to control access requests initiated by a subject device. Subject-object pairs can agree on multiple access control methods; each method is implemented by one ACC. There are n object/subject devices and n(n-1) subject-object pairs generated (need to deploy n(n-1) \approx n^2 contracts).
- In Wang’s scheme, each policy contract is created by a user, in which one policy contract corresponds to one user. Each device belongs to a single user, and with n users, n contracts need to be deployed.
- Fig. 6: Blockchain volume versus number of devices (unit: KB)
- Both BBRAC and Wang’s scheme use the ABAC model, outperforming Zhang’s scheme in storage consumption. As the number of devices increases, storage occupancy of BBRAC increases faster than in Wang’s scheme. This is primarily caused by a reputation subsystem. However, it is a valuable tradeoff.
Reputation Subsystem
- The reputation subsystem has four mechanisms: reward, penalty, tolerance, and alarm. If a threshold is defined in advance, an alarm can be triggered by a Solidity event.
- Fig. 7 shows the Impact of reward, penalty, and tolerance mechanisms. The bars correspond to a cumulative count of malicious behaviors.
- Legitimate access accumulates reputation, while malicious behaviors decrease credit value.
- We may make the following observations.
- Frequent malicious behavior corresponds to a decrease in credit value.
- Repeatedly malicious acts correspond to an exponential growth in the number of forbid blocks; the time in which a device is forbidden continues growing (log of historical malicious behaviors).
- Malicious behavior that occurs may be tolerated if a device has accumulated high credit value.
- This assumes accidental harmful behavior is normally caused by operational error.
- Legitimate access accumulation may increase credit value but stays constant after reaching an upper limit.
- In conclusion, rewards and penalties can have a positive effect under two different situations.
- In situation 1, there are more requests to collect within a given duration (in block #) than the blockchain can manage. The Penalty mechanism may reduce the number of transactions generated by nodes with malicious behavior, resulting in more chances for well-behaved nodes.
- In situation 2, the blockchain can collect all requests generated within a given duration. This reduces transactions due to the penalty mechanism’s assistance in lowering the blockchain’s growth rate.
- In an experiment, the authors test the number of transactions (room) that can be saved for well-behaved nodes. The node sends access requests at fixed time intervals until there is an increase of 500 blocks. The initial credit value is set to 0, and the first 50 requests exhibit malicious behaviors that fail to pass important policy checks.
- Without using the reputation algorithm, the number of requests sent over 500 blocks is 169. All of these requests are collected successfully, regardless of their behavior types. While using the reputation algorithm, 168 requests were sent over the same period of 500 blocks; 130 were successfully collected (i.e. 38 were blocked). This shows an increase of 22.6%, and this rate increases further as malicious behavior increases.
Discussion & Key Takeaways
- This work provides a solution for improving access control in IoT systems and proposes an improved smart contract-based framework.
- The ABAC model implementation uses smart contracts and reduces the number of ACCs to minimize storage requirements.
- As shown in the experiments above, the execution times of functions such as attribute management are reduced and the growth rate of the blockchain’s volume is restricted.
- The reputation subsystem increases access security at the contract level and improves the probability of a successful collection of transactions from well-behaved nodes by curtailing malicious nodes’ access requirements.
- In the context of subject attribute management, this work dramatically reduces gas consumption. When compared to an ADAC, the amount of gas required for a transaction is reduced by 1,470,000 gas.
Applicability
- Storing data on the blockchain is expensive. One solution is to only store crucial data (e.g. attributes, policies) on-chain while storing the remaining data off-chain. Some researchers use cloud storage or distributed storage platforms such as IPFS and Swarm for off-chain storage. This may be implemented in the proposed system.
- Compared with traditional models, models based on smart contracts are still very new. Some examples include an automatic update of attributes, automatic discovery of attribute permission relationships, and improvement of smart contract implementation.