**3.2 IoT devices**

Most IoT systems are managed through firmware so ensuring the integrity and authenticity of the firmware update of the devices is a complex and critical task that must be carefully addressed. In addition, it may happen that multiple devices

with their various subsystems need to be updated urgently and simultaneously, for example, to apply a critical fix. Therefore, the high availability of updates is a requirement.

Most existing solutions for firmware upgrades depend on the client-server model in which the manufacturer delegates the firmware distribution process to the suppliers of its products. The central client-server architecture has the drawback to be a Single Point of Failure (SPoF), and in case the server is not available IoT devices cannot access resources (updates). There are two approaches: manual and automatic.

On the one hand, in the manual update process, the device owner must start the firmware update process. In general, this type of update is adopted by devices that have limited bandwidth or directly it is the owner who decides to do it this way. However, the manual firmware update mechanism is not as efficient as the owner of the device must perform all operations manually. In addition, there is a high probability that human error may occur during the firmware update process or that devices are outdated due to lack of resources for updating.

On the other hand, the automatic updating seems more tempting to be adopted today. This way, the manufacturer of the IoT device could initiate the firmware update without the active participation of the device owner. The current automatic firmware update process uses the client-server architecture, where the repository of the provider is the server and the IoT device becomes the client-side. In general, there are two ways to deliver the firmware from the server to the client: PUSH and PULL methods. The differences between these two methods are in the initiator of the project firmware upgrade process. In the PUSH method, the device manufacturer starts the firmware update process by distributing the firmware binary file. In the PULL method, on the other hand, it is the IoT device that starts the firmware update process by sending a binary request to download the firmware to the server.

In Ref. [11], a blockchain-based firmware check and firmware update was proposed for IoT device systems. In the Lee and Lee scheme, the blockchain technology is used in your firmware proposal to verify the firmware version and the firmware authenticity file, as well as to distribute the firmware binary to the nodes connected to the network. Each IoT device is a network node, so each node must store all or part of the chain in its local storage, which means that only a few IoT devices are able to adopt this solution. So, the Lee and Lee proposition is not suitable for a heterogeneous IoT ecosystem.

In Ref. [12] the application of blockchain technology was proposed to update the firmware of IoT devices from different vendors. In this solution, each IoT device must periodically probe any random node in the network to check the firmware version. When a device vendor publishes a new version of the firmware upgrade to the block network, the newly created firmware upgrade needs to be verified first by the network through a consensus protocol. When one of the IoT devices of the associated device vendor wants to perform the firmware upgrade process, the device must create a transaction for the firmware upgrade request. In this scheme, IoT devices would not be able to download the firmware from their corresponding vendor unless all nodes in the network have verified the associated firmware. In this solution, all network nodes must store all firmware that has been published on the network.

#### **3.3 Distributed file system (DFS)**

When we find use cases such as the previous ones that require a distributed storage it is necessary to resolve where to store the files and who can access them. Blockchain technology does not offer storage solutions and it is not a recommended

**79**

*Blockchain Applications in Cybersecurity DOI: http://dx.doi.org/10.5772/intechopen.90061*

practice to store files in the blockchain. A possible solution is the use of distributed storage systems, like the decentralized P2P file storage systems. When using this kind of storage, files are divided into pieces that are replicated in different peers. A peer requiring access to an archive collects pieces of this archive, which is partially located in several peers at a time. The performance is similar to that of the P2P

As the main solution for implementing this kind of storage is to use IPFS [13]. IPFS is a decentralized hypermedia P2P protocol that allows the storage of distributed files dividing the files in chunks and replicating them in the peers that require them. When a file is downloaded, chunks are collected from different sources at the same time. Each file is identified and accessed through its hash or fingerprint. IPFS is the basis of Filecoin, a distributed storage network based on Blockchain. This network basically integrates IPFS in a specific Blockchain network for data storage in which the nodes get tokens as payment for the storage service provided (and the customers pay them). As for privacy and access control, the IPFS protocol does not include any encryption mechanism or access control. It is up to the client or DApp to encrypt each file prior to sharing the archive to prevent its disclosure to third

In short, IPFS provides distributed and decentralized storage of large files with a certain degree of resilience, integrity, and very high availability. By storing in the Blockchain the hash of the files, which occupies only a few bytes, both systems are

Another interesting use case, maybe not so known as the previous one, is the application of blockchain strategies to content delivery networks. These networks are widely used nowadays, so we have considered that they are a good example of how we can use blockchain to add value to existent processes or technologies.

A Content Delivery Network (CDN) consists of an overlapped network of computers containing different copies of the same set of data. The objective of its creation is to maximize the bandwidth available in a service to improve, as far as

Prior to the emergence of Blockchain and the definition of the Distributed Ledger Technologies, it was already possible to find collaborative networks that allowed greater resistance to targeted attacks [15], such as DDoS. But it was difficult to incentivize a participant to offer their computing power to these networks. This lack of ability to attract new collaborators made the network growth very difficult

A client accesses one of the copies of the data. By providing information replicas and bringing closer the node that provides the service, the response time should be improved, and service outages avoided. But, how does that affect the information a customer can see? The Byzantine Generals Problem enunciated by [14] establishes that the components of a distributed computing system may fail, reaching a condition of imperfect information. In this situation, an observer could have different information depending on unnoticed facts, like the server consulted or the client's location. A different observer could have different information for the same service consulted if an inconsistent CDN state is making the network to fail in its responses. A consensus regarding which component has failed in the first place and which

BitTorrent network and files are indexed by their hash or fingerprint.

parties, which is not a very versatile and interoperable solution either.

linked and the integrity of the file is guaranteed.

**4.1 Introducing the content delivery networks**

possible, the availability and access to data.

information is trustworthy would make things easier.

**4. Blockchain and content delivery networks (CDN)**

#### *Blockchain Applications in Cybersecurity DOI: http://dx.doi.org/10.5772/intechopen.90061*

*Computer Security Threats*

requirement.

automatic.

heterogeneous IoT ecosystem.

published on the network.

**3.3 Distributed file system (DFS)**

with their various subsystems need to be updated urgently and simultaneously, for example, to apply a critical fix. Therefore, the high availability of updates is a

Most existing solutions for firmware upgrades depend on the client-server model in which the manufacturer delegates the firmware distribution process to the suppliers of its products. The central client-server architecture has the drawback to be a Single Point of Failure (SPoF), and in case the server is not available IoT devices cannot access resources (updates). There are two approaches: manual and

On the one hand, in the manual update process, the device owner must start the firmware update process. In general, this type of update is adopted by devices that have limited bandwidth or directly it is the owner who decides to do it this way. However, the manual firmware update mechanism is not as efficient as the owner of the device must perform all operations manually. In addition, there is a high probability that human error may occur during the firmware update process or that

On the other hand, the automatic updating seems more tempting to be adopted today. This way, the manufacturer of the IoT device could initiate the firmware update without the active participation of the device owner. The current automatic firmware update process uses the client-server architecture, where the repository of the provider is the server and the IoT device becomes the client-side. In general, there are two ways to deliver the firmware from the server to the client: PUSH and PULL methods. The differences between these two methods are in the initiator of the project firmware upgrade process. In the PUSH method, the device manufacturer starts the firmware update process by distributing the firmware binary file. In the PULL method, on the other hand, it is the IoT device that starts the firmware update process by sending a binary request to download the firmware to the server. In Ref. [11], a blockchain-based firmware check and firmware update was proposed for IoT device systems. In the Lee and Lee scheme, the blockchain technology is used in your firmware proposal to verify the firmware version and the firmware authenticity file, as well as to distribute the firmware binary to the nodes connected to the network. Each IoT device is a network node, so each node must store all or part of the chain in its local storage, which means that only a few IoT devices are able to adopt this solution. So, the Lee and Lee proposition is not suitable for a

In Ref. [12] the application of blockchain technology was proposed to update the firmware of IoT devices from different vendors. In this solution, each IoT device must periodically probe any random node in the network to check the firmware version. When a device vendor publishes a new version of the firmware upgrade to the block network, the newly created firmware upgrade needs to be verified first by the network through a consensus protocol. When one of the IoT devices of the associated device vendor wants to perform the firmware upgrade process, the device must create a transaction for the firmware upgrade request. In this scheme, IoT devices would not be able to download the firmware from their corresponding vendor unless all nodes in the network have verified the associated firmware. In this solution, all network nodes must store all firmware that has been

When we find use cases such as the previous ones that require a distributed storage it is necessary to resolve where to store the files and who can access them. Blockchain technology does not offer storage solutions and it is not a recommended

devices are outdated due to lack of resources for updating.

**78**

practice to store files in the blockchain. A possible solution is the use of distributed storage systems, like the decentralized P2P file storage systems. When using this kind of storage, files are divided into pieces that are replicated in different peers. A peer requiring access to an archive collects pieces of this archive, which is partially located in several peers at a time. The performance is similar to that of the P2P BitTorrent network and files are indexed by their hash or fingerprint.

As the main solution for implementing this kind of storage is to use IPFS [13]. IPFS is a decentralized hypermedia P2P protocol that allows the storage of distributed files dividing the files in chunks and replicating them in the peers that require them. When a file is downloaded, chunks are collected from different sources at the same time. Each file is identified and accessed through its hash or fingerprint. IPFS is the basis of Filecoin, a distributed storage network based on Blockchain. This network basically integrates IPFS in a specific Blockchain network for data storage in which the nodes get tokens as payment for the storage service provided (and the customers pay them). As for privacy and access control, the IPFS protocol does not include any encryption mechanism or access control. It is up to the client or DApp to encrypt each file prior to sharing the archive to prevent its disclosure to third parties, which is not a very versatile and interoperable solution either.

In short, IPFS provides distributed and decentralized storage of large files with a certain degree of resilience, integrity, and very high availability. By storing in the Blockchain the hash of the files, which occupies only a few bytes, both systems are linked and the integrity of the file is guaranteed.
