Blockchain in internet of things: Challenges and Solutions

Introduction

• IoT’s dense collection of personal data and lack of safeguards create privacy and security risks, compounded by decentralized control, heterogeneous device resources, multiple attack surfaces, situational risks, and scale.The data can support personalized services but can also reveal private behavior and lifestyle patterns.Source: Introduction · p. 1
• Prior approaches have not comprehensively addressed IoT security and privacy, while some impose excessive delays or overhead, may compromise privacy, or are too computationally expensive for constrained devices.The paper argues for privacy-aware data sharing without sacrificing user privacy.Source: Introduction · pp. 1–2
• Blockchain offers decentralization, anonymity, and security over untrusted parties, but its resource-intensive mining, latency, poor scalability, and traffic overhead challenge IoT adoption.Multiple miners process transactions to support robustness, at the cost of additional resource use and delay.Source: Introduction · p. 2
• The proposed IoT architecture aims to retain blockchain’s security and privacy benefits while reducing its integration challenges through a lightweight, decentralized design.A smart home illustrates the approach, which the paper describes as suitable for diverse IoT use cases.Source: Introduction · pp. 2–3

Block-based IoT Architecture

• The three-tier architecture connects smart homes, an overlay network, and cloud storage for remote home-data access and third-party use of stored device data.The example use cases include Alice remotely checking her bedroom temperature and a thermostat provider using device data to provide services.Source: Block-based IoT Architecture · p. 3
• A resource-capable, always-online home device mines and stores the centrally owner-managed local BC, chaining each device’s transactions and supporting device addition or removal.The owner creates a starting transaction for each new device and can remove a device by deleting its ledger.Source: Block-based IoT Architecture · pp. 3–4
• Local BC policy headers implement owner-controlled access, while devices share keys based on generalized Diffie-Hellman [9]; blocks are appended without proof-of-work, and transactions count as true even before mining.The latest policy is in the last block’s header; the miner links each new block to its predecessor and copies the prior policy.Source: Block-based IoT Architecture · p. 4
• Homes may use optional local storage, and each home miner maintains public keys for granting others permission to access home data.Source: Block-based IoT Architecture · p. 4

Overlay Network

• Overlay nodes use Tor for IP-layer anonymity and form clusters with elected cluster heads to reduce network overhead and delay.Nodes may change clusters when delays are excessive, and clusters can elect a new head at any time.Source: Overlay Network · p. 4
• Each cluster head keeps requester-key and requestee-key access lists plus a forward list of transactions sent for other cluster heads.Source: Overlay Network · p. 4
• Cluster heads independently keep or discard overlay BC blocks based on participant communications, allowing divergent copies without synchronization but sometimes delaying block or transaction discovery.For example, the passage describes different block sets at CH1 and CH4; the BC contains cloud-storage multisig transactions and access transactions.Source: Overlay Network · p. 4
• For multiple homes, a shared overlay selects a common miner and storage; device starting transactions chain to their home’s, creating forks, while devices track the last transaction’s block number and data hash.This forking differs from Bitcoin, where forking is not permitted due to its double-spending effect.Source: Overlay Network · pp. 4–5

Cloud Storage

• A user is authenticated by a matching block-number and stored-data hash; new block numbers are encrypted with a shared key derived using generalized Diffie-Hellman.Data packets are stored FIFO in blocks with their hashes; the passage states that collision-resistant hashes and secret block numbers prevent others from accessing data or chaining fresh data to the ledger.Source: Cloud Storage · p. 5
• Users may maintain a separate data ledger for each device or one shared ledger; separate ledgers allow a service provider access to a particular device’s data.Source: Cloud Storage · p. 5

• The section focuses on how transactions are handled after introducing the architecture’s general topology.Source: Transaction Handling · p. 5

Storing

• For cloud storage, the miner checks permissions, assigns a random ID, and sends data for validation; matching hashes and available space allow storage, followed by an encrypted block number returned to the miner.The storage signs the data hash and sends it to the overlay network for mining, making changes to user data visible to all.Source: Storing · p. 5
• Trusted shared storage omits accounting, the miner’s current-data hash transmission, and sending the data hash to the overlay network; other steps follow the cloud process.Shared storage is local storage managed by the home owners and is trusted.Source: Storing · p. 5
• Local storage follows similar steps, but uses no IDs because communications occur within the smart home.Devices may store data in local, shared, or cloud storage according to the defined policy.Source: Storing · p. 5

Accessing

• An SP signs a multisig request with the smart-home miner; CHs route it using PK lists, and the miner checks local-BC permission before encrypting requested packets to the requester.The miner sets the transaction output to “1” or “0” to indicate whether access is granted.Source: Accessing · p. 6
• The miner records completed requests locally and may send them to random CHs as evidence or misbehavior alerts, but can omit overlay storage to reduce identity-linking risk.Stored multisig transactions can serve as proof that data was sent and make nodes aware of unauthorized access requests.Source: Accessing · p. 6
• Authorized users or SPs seeking the entire chain receive block numbers and data hashes; other requesters receive minimum query-satisfying data, potentially with noise or safe answer.The miner may use noise or safe-answer methods to provide additional privacy before sending data.Source: Accessing · p. 6
• Forwarding CHs and requester and requestee CHs retain transactions; other nodes store them when involved in intermediate communication.CHs that forward a transaction must keep it in their BC, as do the requester’s and requestee’s CHs.Source: Accessing · p. 6

• A monitor transaction addresses owners’ need to access device information in real time, such as a smart thermostat’s current configuration.Source: Monitoring · p. 6
• In a monitor transaction, the miner requests real-time data from the specified device and sends it to the requester.Source: Monitoring · p. 6, Figure 2 · p. 8
• Data can be sent continuously, for example while the user watches a live camera feed.Source: Monitoring · p. 6

Distributed Trust

• CHs rate one another using the Beta Reputation System, treating a verified block from a miner as direct evidence and a block relayed by another CH as indirect evidence.Source: Distributed Trust · p. 8
• A CH generating a block sends it with a multisignature transaction to neighboring CHs, which validate that transaction when the block arrives.Source: Distributed Trust · p. 8
• CHs with direct evidence randomly verify block-transaction signatures, checking fewer transactions when evidence is more trustworthy; without direct evidence, they check every transaction.The number of random checks depends on the CH’s direct evidence about the miner and its trust assessment of CHs providing indirect evidence.Source: Distributed Trust · p. 8

Evaluation

• Requester and requestee public-key lists reduce denial-of-service effects, while repeated failed requests can be blocked; cluster-wide dropping is detected and prompts election of a new cluster head.A denial-of-service attack can still succeed using different public keys.Source: Evaluation · p. 10
• Users can detect altered or deleted cloud data by comparing its hash with the locally stored blockchain hash, and cluster heads can expose inconsistent hashes, but the user cannot recover the data.Source: Evaluation · p. 10
• Cooperating cluster heads may evade fake-block detection when trust permits sampling, but any cluster head that detects a fake block can alert the others.Source: Evaluation · p. 10
• Users can send arbitrary transactions to the overlay network and change IDs and public keys for each transaction to hinder linking transactions to real-world identities.Source: Evaluation · p. 11
• Local-BC mining makes compromised home devices detectable, predefined devices and a starting transaction prevent unauthorized additions, and pre-chained storage blocks impede service-provider impersonation.Source: Evaluation · p. 11
• The architecture enforces security and privacy properties in each network tier through appropriate methods.Source: Evaluation · p. 11
• Except for new-miner joining, actions scale at worst with cluster count, which grows more slowly than node count; same-cluster access packet overhead and delay depend on home-storage hops.For same-cluster access, computation and memory overhead remain constant.Source: Evaluation · p. 11, Table 3 · p. 12

• The architecture handles most IoT security and privacy threats while considering device constraints, with overhead constant at best and most transactions scaling with network clusters rather than nodes at worst.Presented in a smart-home context, it is broadly applicable to most multi-tiered IoT network topologies.Source: Conclusion · p. 12
• Further reducing vulnerability to denial-of-service, modification, and 51% attacks in distributed trust remains an open question.IoT's broadcast medium, decentralization, and resource constraints complicate addressing these challenges; the architecture lays groundwork for research with a lightweight, secure, and private framework retaining most blockchain benefits.Source: Conclusion · p. 12

Biographies

• Ali Dorri researches IoT, wireless sensor, and vehicular network security and privacy, including blockchain applications to IoT.He is a Ph.D. candidate at the University of New South Wales; his earlier studies focused on computer engineering and mobile ad hoc network security.Source: Biographies · p. 13
• Salil S. Kanhere is an UNSW associate professor whose research interests include IoT, pervasive computing, mobile networking, and privacy and security.He has published over 150 peer-reviewed articles and received a Humboldt Research Fellowship in 2014.Source: Biographies · p. 13
• Raja Jurdak leads CSIRO’s Distributed Sensing Systems Group and focuses his research on energy efficiency and mobility in networks.He has over 100 peer-reviewed publications and holds adjunct appointments at several Australian universities.Source: Biographies · p. 13