9
Blockchain-Based Security Solutions for IoT Systems

Göran Pulkkis, Jonny Karlsson, and Magnus Westerlund

Department of Business Management and Analytics, Arcada University of Applied Sciences, Helsinki, Finland

9.1 Introduction

IoT security issues have many commonalities with IT security in general. However, much more sensitivity and confidentiality are required for IoT systems when these systems enter and digitalize the private lives of individuals. Some of the identified key privacy concerns for IoT related to the collection of individuals' data are unauthorized surveillance, uncontrolled data generation and use, inadequate authentication, and information security risks (Caron et al., 2016). The sensitivity of IoT technologies stems from security requirements such as confidentiality, integrity, authenticity, privacy, availability, and regulation. IoT security has physical and logical issues. The physical issues entail the limited capabilities of IoT devices in terms of computational power and memory and usually also in terms of energy, since most IoT devices are battery powered. The logical issues include authentication, privacy, protection against malware, the standardization of policies, and monitoring (Madakam and Date, 2016).

IoT deployment raises many security issues related to the characteristics of IoT devices, such as the need for lightweight cryptographic algorithms in terms of processing and memory capabilities, and the use of standard protocols, such as the necessity to minimize the size of data exchanged between nodes (Cirani et al., 2013). IoT devices are more vulnerable to security threats than Internet-connected computers, because of the limited processing capabilities and memory resources aggravating the implementation of protection. The current Internet networking protocol transition from IPv4 to IPv6 means that a growing number of IoT devices have global IP addresses, which facilitates the identification of these devices as targets of security attacks. Security attacks are also facilitated by the autonomous operation and communication of IoT devices. Thus, there is an urgent need for new and more robust security solutions for IoT systems.

The Internet and its technology stack have been in development for roughly four decades. During that time, the centralized client–server architecture has been fundamental in building current platforms and services. From an IoT point of view, this may also be troublesome, for example, when a myriad of wireless sensors need to submit their data back to a centralized service or when a monolithic service should be able to distribute security updates to a decentralized or distributed sensor network. These sensor networks would often benefit from a decentralized communication architecture being self-governing to a large extent. One issue that traditionally has been a hindrance in creating a decentralized architecture is the trust of other actors. The introduction of the cryptocurrency Bitcoin assumed that no trust is needed between two parties. This was achieved by integrating a distributed consensus mechanism as proof of the validation of new transactions while honoring the earlier transaction history. This was consequently extended to the design of generalized transactions outside the realm of cryptocurrencies. Today, this generalized mechanism often goes under the name of blockchain or decentralized ledger technology.

This chapter surveys blockchain-based security solutions for IoT and provides an insight into current research trends. Blockchain technology is briefly discussed, and its use in IoT environments is presented. Additionally, some current efforts to make blockchain technology suitable for IoT are described.

9.2 Regulatory Requirements

Recent attention from the regulator, particularly in the EU, has prompted an increased focus on security and privacy in the IoT sector. The adoption of blockchain technology as a viable solution for future IoT systems in fulfilling regulatory demands offers great potential. Concerning regulatory requirements regarding the design of IoT devices, new directives and regulations have recently been adopted by the EU Parliament. These requirements can be considered among the most stringent in the world and apply to the manufacturers of devices as well as service and platform providers anywhere if they deliver to the European Union and/or handle the personal data of EU residents. In addition, EU member states also provide some sector-specific regulation for areas handling sensitive information, such as health care and financial services. The United States lacks a general data protection or privacy law and instead relies mainly on a rather minimal sector-specific privacy-related legislation. The US approach makes drawing common conclusions more difficult for upholding a certain privacy level when designing information systems. For example, although the same IoT system may be used in different areas, the lack of a common privacy requirement or definition suggests that the manufacturer must at least, to a certain degree, anticipate the intended use of the design and maybe limit the areas of acceptable use when entering the US market. On the other hand, one can treat the EU regulatory requirements as the baseline for obligations that need to be fulfilled when dealing with either personal data or dealing with certain essential infrastructure operators. The two EU legal acts guiding the development and maintenance of information systems1 are the General Data Protection Regulation (GDPR)2 and the Directive on Security of Network and Information Systems (the NIS directive)3. The GDPR may have certain minor differences between the member states but lays the foundation for a unified digital single market within the European Union. As a directive, the NIS will likely be adopted differently by member states, although it defines what can be considered a minimum level of security responsibilities for information systems.

9.2.1 General Data Protection Regulation

The intention of the GDPR is to strengthen and clarify rights in regard to the personal data of natural persons—that is, individuals residing in the European Union. The GDPR affects organizations globally if their intended users are originating from the European Union and personal data are processed. A company found in violation of the regulation may face considerable fines and compensation fees to data subjects (GDPR Articles 82 and 83). The legislation separates the role of the controller and processor as different legal entities. The controller collects the initial consent or contract and cannot defer responsibilities in regard to the data subject to a third party. Even if the processor resides in a country outside the European Union, the processor is still bound by the GDPR while processing any personal data on an individual within EU borders. This is a measure ensuring that transnational data transfers do not violate the fundamental rights of the individual. Provided a processor is determined by the controller to follow the GDPR and that sovereign laws do not conflict with the EU laws, personal data can be transported and processed outside the EU.

The GDPR defines two types of data: personal and special category (sensitive) data. An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or one or more special category factors. Special categories in Article 4(1) of the GDPR are specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person. This separation between data classification may at times result in difficult design choices. For example, an image is considered under special categories when used for identification and/or authorization, while in documenting a care story the same image may be considered as personal data. Assuming the data subject has manifestly made the image public outside the immediate family, the system may in some cases be allowed to process the image at its own discretion.

Two important concepts in the legislation are, according to Article 5(1) A of the GDPR, that personal data shall be processed fairly and in a transparent manner in relation to the data subject. For the adoption of IoT, this may add additional system challenges compared to today's environment. The GDPR stipulates the following three main considerations on how to achieve compliance:

  • Design Requirements. Requiring freely given consent or; by contract or for the performance of a contract; data minimization; data protection by design and default.
  • Handling of Personal Data. Access; rectification; portability; transparency of usage; erasure.
  • Limitations on Processing. Notification; restriction; security.

Let us consider the method for integrating IoT hardware and services/platforms as a traditional data analytics process. Data quality from data generators, such as sensors, must, in light of the GDPR, be accurate and reliable. Meta information describing, for example, data source, access rights, and justification for lawful processing should be recorded along with the data when it becomes associated with a natural person. During feature engineering, efforts must be made such that descriptive statistics do not infringe on the data subject's integrity or introduce new features that can be considered sensitive. An example of new feature is clustering based on location and additional information such as place of worship that can be considered to infer either religion and/or race. If such statistics are needed for determining factors and/or causes in ascertaining a hypothesis, then these efforts need to be disclosed to the data subject beforehand.

The need for transparent processing and transparent data transfers/manipulations/removals may be best met by an immutable data storage solution, such as a ledger-based technology like blockchain. Treating each corresponding operation as a transaction and defining a smart contract for that operation offers an auditable record for forensic purposes and an approach for showing compliance to potential users and the regulator.

9.2.2 Directive on Security of Network and Information Systems

The NIS directive is somewhat more restrictive in its application than the GDPR. The intention of NIS is that it should not place additional burden on small and medium-sized enterprises but rather be a recommendation for dealing with security and security incidents. It should be noted that the handling of security incidents involving personal data or sector-specific data may be further specified in the GDPR or other relevant sector-specific acts. Incidents are defined as any event having an actual adverse effect on the security of network and information systems. Enterprises that fall within the definition of the directive and thus must fulfill its obligations are operators of essential services, such as energy, water, transport, banking, financial market infrastructures, health care, and digital infrastructure. The requirements of these enterprises in terms of security measures are as follows4:

  • Preventing Risks. Technical and organizational measures that are appropriate and proportionate to the risk.
  • Ensuring IT Security. Ensure a level of security of the network and information systems appropriate to the risks.
  • Handling Incidents. Prevent and minimize the impact of incidents on the IT systems used to provide the services.

The other category defined by NIS, in addition to the essential operators, comprises digital service providers such as online marketplaces, cloud computing services, and search engines. The obligations for companies belonging to this category are somewhat enlarged, and in addition to the requirements presented above for essential operators, these additional measures apply business continuity management; monitoring, auditing, and testing; and compliance with international standards.

9.3 Blockchain Technology

Blockchain technology was introduced in Nakamoto (2008) as a platform for the Bitcoin cryptocurrency. A blockchain is a distributed database for storing a continuously growing list of records called blocks. A blockchain is replicated in a peer-to-peer network of nodes, where each node stores a copy of the entire database. The topology of a blockchain is a chain of blocks since each block except the first block, the so-called Genesis Block, contains a link to the preceding block implemented as a hash of the preceding block. Each block in a blockchain is also time stamped. The basic structure of a blockchain is depicted in Figure 9.1.

Figure depicts basic blockchain structure.

Figure 9.1 Basic blockchain structure.

A blockchain user is the owner of a node in the blockchain network for operations on the blockchain and must also own a unique key pair in public key cryptography. The public key identifies a blockchain user. A blockchain user operates on a blockchain from a node in a blockchain network. An operation on a blockchain is a transaction initiated by a blockchain user. A transaction creates a record, for example, about the transfer of Bitcoins, data, physical property, or some other asset from a blockchain user to another user of the same blockchain. The transaction record is signed by the blockchain user who initiated the transaction, and is sent to all blockchain network nodes. Each blockchain network node tries to validate the received transaction record with the public key of the initiator of the related transaction. Transaction records that cannot be validated by all the blockchain network nodes are considered invalid and get discarded. Special blockchain network nodes called mining nodes collect validated transaction records and store them as lists in time-stamped candidate blocks. A mining node performs a distributed computational review process, called mining, on its candidate block before it can be linked to the blockchain.

There are several implementations of mining for blockchains. In the Bitcoin blockchain, mining is based on proof-of-work (PoW). This means that each mining node repeatedly creates a hash of the concatenation of the last blockchain block and a new nonce (a randomly chosen value) until a hash of required difficulty is created. Created hashes are different because the nonce is different in each one of them. The mining node, which first creates a hash of required difficulty, can link its candidate block to the blockchain. The required difficulty is defined by the number of leading zero bits in a created hash. For example, if the difficulty is 10 zero bits, then on the average 210 attempts are needed until a hash of the required difficulty is created. Thus, the mining node with the highest processing power will link its candidate block to the blockchain with the highest probability. In the Bitcoin blockchain, the PoW difficulty is increased after 2 weeks to control the blockchain growth rate.

A blockchain can be public, permissioned, or private. All software of a public blockchain is open source. Anyone can use a public blockchain, for example, the Bitcoin blockchain, by joining the blockchain network. A user joins a blockchain network by copying the entire blockchain and installing the blockchain software on the own node. Any blockchain user can also own a mining node, for example, by installing the mining software on the own node in a blockchain network.

More recent blockchain implementations that extend the functionality offered by the Bitcoin blockchain are denoted as Blockchain 2.0. One of the interesting features in Blockchain 2.0 is the support for smart contract, which was introduced as a concept by Szabo (1997). A smart contract is a computer program that encompasses contractual terms and conditions that enable the verification, negotiation, or enforcement of a contract. An example of a blockchain platform focused on smart contracts is Ethereum5, whose cryptocurrency is called Ether. A smart contract in Ethereum is called DApp (Decentralized App), which can be executed on a server or directly on an Ethereum node. See, for example, Tapscott and Tapscott (2016) for a detailed description of blockchain technology and blockchain applications.

The security of a blockchain is based on the hash-interdependence between successive blocks in combination with the distribution of copies of the entire blockchain to all nodes in a blockchain network. A blockchain is in practice tamperproof—that is, resistant to modification attempts—since a block cannot be altered without alteration of all the subsequent blocks and participation of the entire network to verify and log the change. Moreover, a blockchain is not controlled by any single centralized authority, which could be an attack target, since complete blockchain copies are stored in all nodes of a peer-to-peer network. However, if an attacker can achieve control of a sufficient number of nodes in a peer-to-peer blockchain network, including some mining nodes, then there can be data losses and/or the insertion of corrupted data in the attacked blockchain. (Conoscenti et al., 2016)

Examples of security attacks against blockchains are the selfish mining attack (Eyal and Sirer, 2013), the history-revision attack (Barber et al., 2012), the eclipse attack (Heilman et al., 2015), and the stubborn mining attack (Nayak et al., 2016). Malicious mining nodes do not transmit all mined new blocks for validation in the blockchain network in a selfish mining attack. A malicious miner having more than twice as much computational power than all honest mining nodes have together can insert corrupted blocks in a blockchain in a history-revision attack. All incoming and outgoing connections of a target node in a blockchain network are controlled in an eclipse attack. A stubborn mining attack combines selfish mining with an eclipse attack.

9.4 Blockchains and IoT Systems

IoT devices generate enormous amounts of data, which must be stored and processed. Each CRUD (Create, Read, Update, or Delete) operation on IoT data can be registered as a transaction record in a blockchain block. Unauthorized operations on stored IoT data can, therefore, be detected. An identity credential for an IoT device can be registered as a transaction record in a blockchain block when the device is manufactured and retrieved later when the device is being used. Access rules for IoT devices can be specified and enforced by smart contracts. Unauthorized operations on stored IoT data can, therefore, also be detected. No centralized authority, such as a cloud storage provider, is needed for the protection of IoT data, which can be safely stored in different network nodes, when a blockchain guarantees data authenticity and prevents unauthorized access. The deployment history of an IoT device can be stored as transaction records in a blockchain. Transaction records can be stored in blockchain blocks when the IoT device is produced, delivered to an owner, installed, updated, and delivered to another owner, and so on. A blockchain can also enable secure messaging between IoT devices. Message exchanges between IoT devices can be treated similar to financial transactions in a Bitcoin network. Message exchanges between IoT devices can be enabled with smart contracts, which implement agreements between two parties. A fundamental capability of a blockchain is that a duly decentralized, trusted ledger of all transactions in a network is maintained. This capability can enable the many compliances and regulatory requirements for IoT systems, for example, in the GDPR. (Banafa, 2016; Conoscenti et al., 2016)

9.5 Examples of Blockchain-Based Security Solutions for IoT Systems

The decentralized and autonomous features of a blockchain make it a nearly ideal component in IoT security solutions. Blockchain use can enable an IoT security level, which otherwise would be difficult or even impossible to achieve. This section presents some of the recently proposed IoT security solutions that are based on blockchain technology.

9.5.1 Secure Management of IoT Devices

The management of an IoT device includes the control of configuration settings and operation modes as well as ensuring uninterrupted operation. Blockchain-based control of configuration settings and operation modes can prevent unauthorized access attempts and also provide protection against denial-of-service attacks.

In Huh et al. (2017), the authors proposed control and configuration of IoT devices using Ethereum as a blockchain platform. An identification credential for an IoT device can be implemented by a unique key pair (i.e., a private key and a public key) in public key cryptography. The private key is stored in the IoT device while the public key is registered as a transaction record in an Ethereum block. An IoT device can then be addressed on Ethernet via its public key. Ethereum was chosen as the blockchain platform because its smart contracts enable the execution of programs on the blockchain. IoT device behavior can, therefore, be programmed in smart contracts. For a proof of the proposed concept, a simulation took place on a system composed of three IoT devices: an electricity meter, a LED light bulb, and an air conditioner. A policy requiring the air conditioner and the light bulb to switch to an energy-saving mode if the meter measurement exceeds 150 kW was set up by a smartphone. For the meter, a smart contract was programmed for sending measurement values and identity credentials (i.e., its public key and signature) to Ethereum. Smart contracts were also programmed for the air conditioner and the light bulb. These contracts retrieved measurement values with associated identity credentials from Ethereum. The identity credentials verified that the retrieved measurement value was a meter value and a transition to the energy-saving mode occurred when the threshold of 150 kW of the retrieved value was exceeded.

9.5.2 Secure Firmware Updates in IoT Devices

IoT device vendors remotely update the firmware of delivered devices in order to install new functionality and to patch discovered vulnerabilities. These updates are usually downloaded based on client requests from a repository server containing precompiled firmware binaries secured by public key infrastructure (PKI)-signed message digests. The signed message digest and the public signing key are attached to a downloaded firmware file. The firmware update on an IoT device starts only if a security check with the downloaded public key succeeds. However, this client–server firmware update protocol creates too much network traffic if millions of IoT devices simultaneously request updates.

A solution utilizing blockchains has been proposed for secure firmware updates in IoT devices where the global network traffic to a server is replaced by mostly local peer-to-peer communication between blockchain network nodes (Lee and Lee, 2016). In this solution, an IoT device manufacturer stores the hashes of released firmware versions on a blockchain that is accessible to all delivered IoT devices. Christidis and Devetsikiotis (2016) suggested that using a preinstalled smart contract with a condition to repeatedly check after a preset time interval has elapsed if a new firmware release is available, then an IoT device can autonomously find out about new firmware releases. The IoT device can retrieve the hash of the released firmware from the blockchain6 and use it to securely download the new firmware version from a distributed peer-to-peer file system consisting of the manufacturer's node and IoT devices with firmware versions installed. The firmware hashes stored on the blockchain can also be used to verify that firmware installed on IoT devices is untampered.

In the aforementioned solution, all IoT devices delivered by the same vendor are normal blockchain nodes. Other blockchain nodes are verification nodes, which are operated by the firmware vendor through a secure network connection to maintain updated firmware and firmware metadata. An IoT device broadcasts firmware update requests to the blockchain nodes. If a response is first received from a verification node, and the firmware on the IoT device is up-to-date, then the firmware is verified. Otherwise, the latest firmware is downloaded from the responding verification node. If a response is first received from a normal blockchain node that has the same firmware version as the IoT device requesting a firmware update, then the firmware version is verified by a lightweight PoW mining procedure in which six verification log responses suffice. Otherwise, the up-to-date firmware is downloaded from a verification node to the IoT device—a normal blockchain node—whose firmware version is older. Each blockchain block consists of a header and a verification field, which consists of a verification counter, hashes of all stored transactions, a verification log, the name of the blockchain network node, the current firmware version, and a hash of the firmware file. The verification log contains time-stamps representing verification times and IDs of network nodes that request firmware updates, and IDs of network nodes that respond to such requests.

9.5.3 Trust Evaluation of a Trusted Computing Base in IoT Devices

A Trusted Computing Base (TCB) is the set of hardware, firmware, and/or software components that ensure the security of a computer system. This means that to break the security, an attacker must subvert one or more of these components. A TCB can, therefore, be a part of an IoT device, which is a tiny computer system. A TCB is trustworthy if all TCB components are unchanged by faults and untampered by adversaries. A TCB measurement, which creates hashes of all TCB components, is carried out to evaluate the trustworthiness of a TCB. If these hashes are securely stored then they can be later used to verify the TCB. TCB measurements are carried out when an IoT device is connected to the Internet and each time its TCB is updated. Trustworthiness has been compromised if a TCB measurement cannot be verified. A verifier performs remote attestation by issuing a cryptographic nonce and signing the concatenation of a verified TCB measurement and the nonce to assure that the TCB of an IoT device is trustworthy.

In Park and Kim (2017), a protocol called TM-Coin (TCB Measurement-Coin) has been designed for the trustworthy management of TCB measurements in IoT devices. TM-Coin creates transaction records of verified TCB measurements and stores these records in blockchain blocks. TM-Coin uses the Trusted Execution Environment (TEE) provided by ARM TrustZone7 as the TCB in IoT devices for the secure generation of transaction records for the blockchain. The TM-Coin protocol consists of two blockchain transaction types: registration and update. A registration transaction stores a record of the verification of TCB measurement in a blockchain block when an IoT device is connected. After a code update of at least one TCB component in an IoT device, an update transaction also stores a record of the verification of TCB measurement in a blockchain block. The miner nodes in the blockchain perform remote attestation of the TCB in an IoT device during a transaction. Data sensed by an IoT device are assured to be trustworthy after remote attestation by an external verifier. The attestation function is

equation

where TCB_M is the latest TCB measurement of the IoT device obtained from the blockchain, D is the data sensed by the device, and N is a nonce issued by the verifier.

9.5.4 IoT Device Identity Validation

A secure identity of an IoT device can be implemented as a private key in an embedded public key cryptography chip. The corresponding public key is stored in a blockchain block by the IoT device manufacturer (Lombardo, 2016). A network node starts accessing an IoT device with a random challenge message, which is returned by the IoT device with a signature. The accessing network node can thereafter validate the IoT device identity with the public key that can be retrieved from the blockchain. An IoT device identity that is validated using a blockchain enables an almost perfectly secure authentication of an IoT, makes identity spoofing nearly impossible, and ensures the integrity of data captured from IoT devices because of the tamper-resilience of a blockchain.

An IoT device identity that is validated using a blockchain has been proposed to be used to create a blockchain based identity log capturing the device ID, its manufacturer, lists of available firmware updates, and known security issues (Manning, 2017). The history of a device with a securely validated identity can also be tracked by a blockchain. The history starts when the manufacturer stores the identity—the public key—of a manufactured IoT device in a blockchain block. Identities that are validated using a blockchain are being developed for IoT devices such as surveillance cameras.

9.5.5 Secure Data Store System for Access Control Information

Current standard solutions for access control to network-connected devices are based on access control lists (ACLs). However, it would be impossible to maintain an ACL for each and every IoT device and rely on centralized access control servers when IoT scales to billions of devices and millions of device owners. To put these IoT device owners in control of the data generated by their devices, blockchain deployment is a possible solution that excludes dependence on centralized third parties.

A blockchain-based secure data store system for access control information has been introduced as a component in a proposed solution for the protection of IoT device owners' access control to data generated by their IoT devices (Hashemi et al., 2016). The other components are a data management protocol and a messaging service. The proposed solution implements role and capability-based access control. When a party with a defined role sends an access control message to another party also with a defined role, then the message is delivered to the messaging service. The messaging service sends the message to the data store system, where it is stored as a transaction record in a blockchain block. After that, the receiving party fetches the message from the blockchain block in the data store system through the messaging service. An overview of the proposed solution is illustrated in Figure 9.2.

Figure depicts an overview of the proposed solution for secure access control messaging.

Figure 9.2 An overview of the proposed solution for secure access control messaging.

Four roles are defined, as is shown in Figure 9.2: data owner, data source, data requester, and endorser. A data owner owns and grants access to the data generated by their IoT devices (i.e., data sources). A data requester (e.g., an IoT device) requests access to IoT data and an endorser validates such requests. The data management protocol is a message exchange protocol for capability-based access control. A capability permits a data requester to access a data owner's data object on a data source. The data management protocol consists of five access control message types: data source ticket generation message, data request message, ticket exchange message, data access message, and access announcement message. The data store system is a blockchain similar to the Bitcoin blockchain. The messaging service stores messages received from a sender as transaction records in blockchain blocks in the data store system and implements a publisher–subscriber protocol—as shown in Figure 9.2—for the delivery of messages stored as transaction records in blockchain blocks in the data store system.

9.5.6 Blockchain-Based Security Architecture for IoT Devices in Smart Homes

A blockchain-based architecture has been proposed for local networks in smart homes (or some other local environments) with a number of connected IoT devices like smart thermostats, smart bulbs, and IP cameras (Dorri et al., 2016, 2017a, 2017b). The architecture has three tiers, namely, the local networks in smart homes, an overlay network, and cloud storage. In each tier, entities use blockchain transactions for communication with each other. The transaction types include genesis transactions, store transactions, access transactions, and monitor transactions. The architecture, which is illustrated in Figure 9.3, has strong protection against denial-of-service attacks, modification attacks, dropping attacks, mining attacks, appending attacks, and linking attacks.

Figure depicts an overview of the proposed blockchain-based architecture for smart homes.

Figure 9.3 An overview of the proposed blockchain-based architecture for smart homes.

In the local network, there is a private local blockchain, which is stored, mined, and managed by at least one device. When a new IoT device is connected to the local network, a genesis transaction record is stored in a local blockchain block. When an existing IoT device is removed, its ledger is deleted from the local blockchain. This local blockchain has a policy header containing an access control list, which enables a local network owner's control of all blockchain transactions in the local network. Communication between IoT devices is encrypted by preshared Diffie-Hellman8 keys. The local network can have local storage for data. The miner device maintains a list of public keys representing the digital identities of entities, which can be given permissions to access local network data from outside.

The overlay network resembles the peer-to-peer Bitcoin network (Nakamoto, 2008) and is composed of local network miner devices, other local network devices, and/or local network owners' smartphones or personal computers. Overlay network nodes communicate through the Tor network9 to achieve communication anonymity and are grouped into clusters, where a cluster head (CH) is elected for each cluster. Each CH maintains an overlay blockchain and three lists: public keys of requesters that are permitted to access data for the smart homes connected to the cluster, public keys of such local networks connected to the cluster that can be accessed from outside, and transactions sent to other CHs (Dorri et al., 2016). Transaction records with more than one signature and access transaction records are stored in overlay blockchain blocks. Several local networks having the same owner can be managed together as a shared overlay consisting of a shared blockchain with a common miner and shared storage.

IoT devices in a local network can store their data locally or in cloud storage. Cloud storages are blockchains, where IoT data is stored in identical blocks with unique block numbers. A local network device is authenticated in cloud storage by the given block number and a hash of the stored data. A store transaction, illustrated in Figure 9.4, is initiated by an IoT device in a local network to store generated data, for example, by a thermostat to store temperature measurements in cloud storage. An access transaction, illustrated in Figure 9.5, can be initiated by a local network owner or a service provider to retrieve stored IoT data. A monitor transaction, which can be initiated by a local network owner, retrieves the status of a connected IoT device, such as the current temperature value of a thermostat.

Figure depicts handling a store transaction.

Figure 9.4 Handling a store transaction.

Figure depicts handling an access transaction.

Figure 9.5 Handling an access transaction.

9.5.7 Improved Reliability of Medical IoT Devices

Medical IoT devices are subject to the same security concerns of other IoT devices. User safety in medical IoT-based systems is a top priority. A user must be protected from any system malfunction caused by a device fault or security incident. A medical IoT device must function reliably and resist security attacks. Also, the integrity and user privacy of data generated by medical IoT systems must be granted. Blockchain use in the management of medical IoT devices can provide protection against malicious tampering of device settings and modes of operation. An immutable blockchain ledger of records from management events can mitigate the risk of device malfunction.

Nichol and Brandt (2016) proposed the use of blockchain technology for device management to improve the reliability of medical IoT devices. When a medical IoT device is manufactured, a hash of a unique device identifier together with other relevant information, such as company name, is stored in a blockchain block. Later, this data can be updated with patient data, hospital, doctor, emergency contacts, and patient care directives. The patient and the caregivers can be automatically notified about device service needs, approaching battery expiration, and detected patient health irregularities through a set of smart contracts. The risk of a catastrophic device failure is, therefore, reduced by smart contracts sending preventive maintenance information to the patient and caregiver.

9.6 Challenges and Future Research

The implementation of proposed blockchain-based security solutions in IoT is a highly relevant topic for future research. First, IoT applications potentially benefiting from blockchain security features should be rigorously surveyed. An example of a relevant domain is health care IoT applications, where the tampering of health-related measurement data could be disastrous. When the applications and their security requirements have been established, the next step is to evaluate how blockchain technology could be implemented. Critical simulations and experimental evaluations of the security and performance of blockchain-based security solutions are needed before these solutions can be implemented in real applications. At the same time, new tamper-resistant blockchain-based security solutions providing detailed forensics about security attacks are required. Much work is also needed in the development of standards for the design of IoT hardware, IoT firmware, and other IoT software supporting implemented and verified blockchain-based security solutions.

A significant issue with using blockchain solutions in IoT systems is the limited processing capabilities of most of the used devices. As blockchain technology uses cryptography extensively for hashing, digital signing, and encryption, more research on lightweight cryptographic algorithms is needed for the practical implementation of blockchain-based security solutions.

9.7 Conclusions

Although IoT systems have existed in various forms for a long time, security challenges are emerging and will continue to emerge in the foreseeable future. General IT security methods and tools do not fulfill all specific requirements for secure IoT deployment. Therefore, the identification of emergent methods suitable for IoT security solutions is important. Blockchain technology may improve the ability of automatic response to a security incident. This is especially important for IoT systems, since decentralized IoT networks are expected to function reliably and securely without human supervision.

A relevant security risk for all IT systems, and therefore also for IoT systems, is the possibility of attackers tampering with the software and/or data of a security solution. Blockchain-based IoT security solutions mitigate this risk because they are “virtually” tamper resistant and because of their ability to perform real-time audits on transactions. However, there are also disadvantages and shortcomings of blockchain use in security solutions for IoT systems. The major disadvantages for resource-constrained IoT devices are the increasing processing power requirements of PoW mining and the increasing storage requirements in blockchain nodes when the size of a blockchain ledger grows. To mitigate these disadvantages, some other mining techniques should be deployed and only a device-dependent transaction ledger should be maintained when a device is too resource constrained (Banafa, 2016; Kolias et al., 2016).

It should be noted that none of the presented examples of blockchain-based IoT security solution proposals gives full protection against all possible security threats and attacks. Moreover, the practical deployment of these security solutions is still a future issue. A practical security solution for an IoT system can, therefore, combine a choice of blockchain-based security solutions with a set of other security solutions. The current rapid increase of IoT implementations and the IoT security incidents that have hitherto occurred emphasize the necessity of continued research on improving decentralized security measures and reliability of IoT systems.

Notes

References

  1. Banafa, A. (2016) A Secure Model of IoT with Blockchain. OpenMind. https://www.bbvaopenmind.com/en/a-secure-model-of-iot-with-blockchain/ (accessed May 16, 2017)
  2. Barber, S., Boyen, X., Shi, E., and Uzun, E. (2012) Bitter to better – how to make Bitcoin a better currency, in Lecture Notes in Computer Science, vol. 7397, Springer, Switzerland, 399–414.
  3. Caron, X., Bosua, R., Maynard, S. B., and Ahmad, A. (2016) The Internet of Things (IoT) and its impact on individual privacy: an Australian perspective. Computer Law & Security Review, 32(1), 4–15.
  4. Christidis, K. and Devetsikiotis, M. (2016) Blockchains and smart contracts for the Internet of Things. IEEE Access, 4, 2292–2303. doi: 10.1109/ACCESS.2016.2566339
  5. Cirani, S., Ferrari, G., and Veltri, L. (2013) Enforcing security mechanisms in the IP-based Internet of Things: an algorithmic overview. Algorithms, 6, 197–226. doi: 10.3390/a6020197
  6. Conoscenti, M., Vetro, A., and De Martin, J. C. (2016) Blockchain for the Internet of Things: a systematic literature review. Proceedings of the 13th International Conference of Computer Systems and Applications (AICCSA), IEEE, 1–6.
  7. Dorri, A., Kanhere, S. S., and Jurdak, R. (2016) Blockchain in Internet of Things: Challenges and Solutions. Available at https://arxiv.org/ftp/arxiv/papers/1608/1608.05187.pdf (accessed November 13, 2016).
  8. Dorri, A., Kanhere, S. S., Jurdak, R., and Gauravaram, P. (2017) Blockchain for IoT security and privacy: the case study of a smart home. Proceedings of the International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops), IEEE, 618–623.
  9. Dorri, A., Kanhere, S. S., and Jurdak, R. (2017) Towards an optimized BlockChain for IoT. Proceedings of the 2017IEE/ACM Second International Conference on Internet-of-Things Design and Implementation IoTDI'17, IEEE, 173–178.
  10. Eyal, I. and Sirer, E. G. (2013) Majority is not Enough: Bitcoin Mining is Vulnerable. Available at https://arxiv.org/pdf/1311.0243v5.pdf (accessed January 14, 2017).
  11. Hashemi, S. H., Faghri, F., Rausch, P., and Campbell, R. H. (2016) World of empowered IoT users. Proceedings of the First International Conference on Internet-of-Things Design and Implementation (IoTDI), IEEE, 13–24.
  12. Heilman, E., Kendler, A., Zohar, A., and Goldberg, S. (2015) Eclipse attacks on Bitcoin's peer-to-peer network. Proceedings of the 24th USENIX Security Symposium, Washington: Usenix, 129–144.
  13. Huh, S., Cho, S., and Kim, S. (2017) Managing IoT devices using Blockchain platform. Proceedings of the 19th International Conference on Advanced Communication Technology (ICACT), IEEE, 464–467.
  14. Kolias, K., Stavrou, A., Bojanova, I., Voas, J., and Grance, T. (2016) Leveraging Blockchain-based protocols in IoT systems. NIST National Institute of Standards and Technology. Available at http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2016-06/1_iot_stavrous.pdf (accessed December 27, 2016)
  15. Lee, B. and Lee, J.-H. (2016) Blockchain-based secure firmware update for embedded devices in an Internet of Things environment. The Journal of Supercomputing, 1–6. doi: 10.1007/s11227-016-1870-0
  16. Lombardo, H. (2016) Blockchain serves as tool for human, product and IoT device identity validation. Available at https://inform.tmforum.org/nfv-it-transformation/2016/11/blockchain-serves-tool-human-product-iot-device-identity-validation/ (accessed December 26, 2016).
  17. Madakam, S. and Date, H. (2016) Security mechanisms for connectivity of smart devices in the Internet of Things, in Mahmood, Z. (ed.), Connectivity Frameworks for Smart Devices, Series: Computer Communications and Networks, Springer International Publishing, Switzerland, 23–41. doi: 10.1007/978-3-319-33124-9_2
  18. Manning, J. (2017) Factom Receives Second DHS Grant For Blockchain IoT Project. ETHNews. Available at https://www.ethnews.com/factom-receives-second-dhs-grant-for-blockchain-iot-project (accessed June 27, 2017).
  19. Nakamoto, S. (2008) Bitcoin: A Peer-to-Peer Electronic Cash System. Available at https://bitcoin.org/bitcoin.pdf (accessed December 27, 2016).
  20. Nayak, K., Kumar, S., Miller, A., and Shi, E. (2016) Stubborn mining: generalizing selfish mining and combining with an eclipse attack. 2016 IEEE European Symposium on Security and Privacy (EuroS&P), 305–320.
  21. Nichol, P. B. and Brandt, J. (2016) Co-Creation of Trust for Healthcare: The Cryptocitizen Framework for Interoperability with Blockchain. doi: 10.13140/RG.2.1.1545.4963
  22. Park, J. and Kim, K. (2017) TM-Coin: trustworthy management of TCB measurements in IoT. Proceedings of the International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops), IEEE, 654–659.
  23. Szabo, N. (1997) The Idea of Smart Contracts. Available at http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html (accessed June 24, 2017).
  24. Tapscott, D. and Tapscott, A. (2016) Blockchain Revolution: How the Technology Behind Bitcoin Is Changing Money, Business, and the World, Penguin Publishing Group, USA.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.137.171.121