Design and Hardware Implementation of a Simpliﬁed DAG-Based Blockchain and New AES-CBC Algorithm for IoT Security

: Recently, to enhance the security of the Internet of Things (IoT), research on blockchain-based encryption algorithms has been actively conducted. However, because blockchains have complex structures and process large amounts of data, there are still many difﬁculties in using the conventional blockchain-based encryption algorithms in an IoT system that must have low power consumption and be ultra-lightweight. In this study, to address these problems (1) we simpliﬁed the conventional Directed Acyclic Graph (DAG)-based blockchain structure, and (2) we proposed a new Advanced Encryption Standard (AES)-Cipher Block Chaining (CBC) algorithm with enhanced security by periodically changing the secret key and initialization vector (IV) in the conventional AES-CBC encryption algorithm. Because the DAG, which is the conventional blockchain structure, randomly transmits data to multiple blocks, there may be overlapping blocks, and the quantity of transmitted data is not limited; thus, the time and power consumption for encryption and decryption increase. In this study, a simpliﬁed DAG was designed to address these problems so that packets can be transmitted only to three blocks, without overlapping. Finally, to verify the effectiveness of the algorithm proposed in this paper, an IoT system consisting of 10 clients and one server was implemented in hardware, and an experiment was conducted. Through the experiment, it was conﬁrmed that when the proposed AES-CBC algorithm was used, the time taken and the amount of power consumed for encryption and decryption were reduced by about 20% compared to the conventional AES-CBC algorithm.


Introduction
Recently, technologies such as artificial intelligence, big data, cloud computing, the Internet of Things (IoT), and network performance have improved with the advent of the hyper-connected era. Due to advances in these technologies, resources are increasingly virtualized for sharing. Networks are virtualized to share network resources or build a cloud environment. Although the number of applications using networks is increasing, network security remains inadequate. The IoT is a technology used to connect and control sensors through networks. This technology is used not only in industries but also in homes. When the IoT is used at home to connect and control home devices, such as consumer devices, security systems, and home appliances, it is known as a smart home system. However, individual devices connected to home systems can create security problems. The IoT is controlled through a network, and connected devices with weak security may suffer various types of damage by hackers. Vulnerabilities such as simple patterns of encryption, non-periodic password changes, old platforms, a lack of encryption algorithms, and a lack of security in network connections can be revealed. Using these vulnerabilities, personal information can be stolen to cause financial damage, and secondary damage Functionally, the nodes were divided into two categories: light and full nodes. Light nodes are IoT devices that are connected to the full nodes to interact, and the collected sensor data are subject to data authority management with AES block encryption. The full nodes have two roles, as an administrator and a gateway, and a secure blockchain system was implemented using AES block ciphers [18].

Struture of DAG
The structure of DAG is attracting attention as a core technology in the era of blockchain 3.0 [19][20][21][22][23]. Figure 1 shows a structure of the DAG. As a non-circulating directed graph, it has multi-directionality without any fixed order and continues in only one direction, as seen in the figure.
Electronics 2021, 10, x FOR PEER REVIEW 3 of 21 Huang et al. proposed a credit-based proof of work (PoW). Power was limited through PoW to fit IoT devices, and a blockchain infrastructure with a DAG structure was built. Functionally, the nodes were divided into two categories: light and full nodes. Light nodes are IoT devices that are connected to the full nodes to interact, and the collected sensor data are subject to data authority management with AES block encryption. The full nodes have two roles, as an administrator and a gateway, and a secure blockchain system was implemented using AES block ciphers [18].

Struture of DAG
The structure of DAG is attracting attention as a core technology in the era of blockchain 3.0 [19][20][21][22][23]. Figure 1 shows a structure of the DAG. As a non-circulating directed graph, it has multi-directionality without any fixed order and continues in only one direction, as seen in the figure.

AES Algorithm
The AES algorithm was established by the National Institute of Standards and Technology and was the first algorithm that was approved for Top Secret use by the US National Security Agency [24]. The AES algorithm is a symmetric key algorithm that uses the same key in encryption and decryption processes. A symmetric key algorithm refers to an algorithm that uses the same cipher key for encryption and decryption. The encryption structure is composed of a Substitution-Permutation Network (SPN) structure and a Feistel structure. The AES algorithm uses the SPN structure, which is shown in Figure 2. In Figure 2, S represents the substitution box (S-box), and P represents the permutation box (P-box). Regarding the encryption process of the AES algorithm, ciphertexts are generated through many rounds of processes in the S-box and P-box. The S-box is a basic packet used for encryption, and its function realizes the non-linear substitution of data. The function of the P-box is changing the location of data. The SPN structure has the disadvantage that it must be designed to require an inverse function in the encryption and decryption processes, but has the advantage that it can be designed more efficiently than the Feistel structure because encryption and decryption are possible simultaneously without moving bits during the encryption process.

AES Algorithm
The AES algorithm was established by the National Institute of Standards and Technology and was the first algorithm that was approved for Top Secret use by the US National Security Agency [24]. The AES algorithm is a symmetric key algorithm that uses the same key in encryption and decryption processes. A symmetric key algorithm refers to an algorithm that uses the same cipher key for encryption and decryption. The encryption structure is composed of a Substitution-Permutation Network (SPN) structure and a Feistel structure. The AES algorithm uses the SPN structure, which is shown in Figure 2. In Figure 2, S represents the substitution box (S-box), and P represents the permutation box (P-box). Regarding the encryption process of the AES algorithm, ciphertexts are generated through many rounds of processes in the S-box and P-box. The S-box is a basic packet used for encryption, and its function realizes the non-linear substitution of data. The function of the P-box is changing the location of data. The SPN structure has the disadvantage that it must be designed to require an inverse function in the encryption and decryption processes, but has the advantage that it can be designed more efficiently than the Feistel structure because encryption and decryption are possible simultaneously without moving bits during the encryption process.

CBC Operating Mode
The block encryption technology has five operating modes: Electronic CodeBook (ECB) mode, Cipher Block Chaining (CBC) mode, Cipher FeedBack (CFB) mode, Output FeedBack (OFB) mode, and Counter (CTR) mode. The CBC mode is the most secure encryption method among block encryption operating modes and is the most commonly used. Figure 3 is a block diagram that shows the encryption and decryption processes in CBC mode [25]. In the CBC operating mode encryption process, as shown in Figure 3a, each block performs an XOR operation with the encryption result of the previous block before being encrypted, and in the case of the first block, the initialization vector (IV) is used. The decryption process in the CBC operating mode proceeds in the reverse order of the encryption process, as shown in Figure 3b. However, because the first block does not have the encryption result of the previous block, the ciphertext and the initialization vector (IV) are XOR operated [26,27].

CBC Operating Mode
The block encryption technology has five operating modes: Electronic CodeBook (ECB) mode, Cipher Block Chaining (CBC) mode, Cipher FeedBack (CFB) mode, Output FeedBack (OFB) mode, and Counter (CTR) mode. The CBC mode is the most secure encryption method among block encryption operating modes and is the most commonly used. Figure 3 is a block diagram that shows the encryption and decryption processes in CBC mode [25]. In the CBC operating mode encryption process, as shown in Figure 3a, each block performs an XOR operation with the encryption result of the previous block before being encrypted, and in the case of the first block, the initialization vector (IV) is used. The decryption process in the CBC operating mode proceeds in the reverse order of the encryption process, as shown in Figure 3b. However, because the first block does not have the encryption result of the previous block, the ciphertext and the initialization vector (IV) are XOR operated [26,27].

Proposed Simplified DAG-Based Blockchain Structure
This paper proposes a structure suitable for the new IoT using simplified DAG-based blockchain. Figure 4 shows the structure of the simplified DAG-based blockchain. Unlike the DAG structure, the proposed simplified DAG-based blockchain structure generates paths randomly without any overlapping blocks. If memory usage increases, system resources may become insufficient and process efficiency may be degraded. In the case of the IoT, as the number of processes increases, the memory usage increases, leading to greater power usage, so that the efficiency may be reduced, and phase alignment is not performed. In this study, to address these problems, a new algorithm was constructed in which the same paths do not overlap in any node. That is, the final target point is reached without going to any node that has already been passed once. Regardless of which node it is, when an event has occurred in a node, paths are created to three nodes. A path is thus created to reach the destination through three paths between the nodes, and when an event has occurred, the paths between nodes are changed in no particular order.

Proposed Simplified DAG-Based Blockchain Structure
This paper proposes a structure suitable for the new IoT using simplified DAG-based blockchain. Figure 4 shows the structure of the simplified DAG-based blockchain. Unlike the DAG structure, the proposed simplified DAG-based blockchain structure generates paths randomly without any overlapping blocks. If memory usage increases, system resources may become insufficient and process efficiency may be degraded. In the case of the IoT, as the number of processes increases, the memory usage increases, leading to greater power usage, so that the efficiency may be reduced, and phase alignment is not performed. In this study, to address these problems, a new algorithm was constructed in which the same paths do not overlap in any node. That is, the final target point is reached without going to any node that has already been passed once. Regardless of which node it is, when an event has occurred in a node, paths are created to three nodes. A path is thus created to reach the destination through three paths between the nodes, and when an event has occurred, the paths between nodes are changed in no particular order.  The simplified DAG-based blockchain randomly transmits the ciphertext to three clients. Therefore, it is difficult to apply the algorithm to fewer clients. To solve this problem, clients are registered to the server to determine how to transmit the ciphertext to clients. In cases where the number of clients connected to the server is less than four, when an event occurs, the client determines the number of clients to which the ciphertext is to be transmitted as "zero". Here, "zero" has no special meaning and was used to indicate that events that occurred in a random client are transmitted directly to the server without passing through other clients. Subsequently, the ciphertext is sent directly to the server without sending it to any client, and the decision is made without the procedure to check the number of clients from which data are received. When at least four clients are connected to the server, the client where the event has occurred transmits the ciphertext to other clients. The clients that receive the ciphertext decrypt the ciphertext, encrypt it again, include a message indicating that the current client has verified the data, and transmit it to the server. When clients are extended in this way, the transmission method is defined according to the number of clients. In this manner, the client where an event has occurred randomly transmits a message to three clients, and the transmission process can be carried out up to three times for each data packet. In our proposed simplified DAG-based blockchain structure, even if the number of clients increases, the number of clients for which the packets are verified is limited to nine at the maximum. This is because increasing the amount of data generated by the client can overload the system and cause network delays. The value of nine was verified as the optimal value through many experiments. Table 1 shows the packet structure generated when an event occurs in a client. The packet structure is as follows. In the packet, Number "n" is the cumulative sum of the values of octet 4, which is the 4th digit of the IP address of the clients where the events occurred; Event Client Address "a" is the value of the octet 4, which is the 4th digit of the IP address of the client where the event occurred; and Random Address 1 "b", Random Address 2 "c", and Random Address 3 "d" represent the values of the octet 4, which is the 4th digit of the IP addresses of three random clients where events occurred. In addition, Server Address "e" is the value of octet 4, which is the 4th digit of the server's IP address, and Sensor data "f" is the output value of the client (e.g., sensor) where the event occurred. Here, the IP address of the client where the event occurs at random is generated by referring to the addresses in the lookup table already registered in each client. For example, if a = 5, b = 1, c = 4, d = 2, e = 6, f = 11, the initially generated packet structure becomes "5, E5, A (1, 4, 2), S6, D11". Then, this packet is transmitted to the client whose IP address' octet 4 value equals 1. The client that received this packet adds 1, which is the value of octet 4 of the client IP, to the "n" position of the packet to create a new packet "6, E5, A (1, 4, 2), S6, D11", and transmits the new packet to the client of which the IP address' octet 4 value equals 4. The client that received this packet adds 4, which is the value of octet 4 of the client IP, to the "n" position of the packet to create a new packet "10, E5, A (1, 4, 2), S6, D11", and transmits the new packet to the client of which the IP address' octet 4 value is 2. The client that received this packet adds 2, which is the value of octet 4 The simplified DAG-based blockchain randomly transmits the ciphertext to three clients. Therefore, it is difficult to apply the algorithm to fewer clients. To solve this problem, clients are registered to the server to determine how to transmit the ciphertext to clients. In cases where the number of clients connected to the server is less than four, when an event occurs, the client determines the number of clients to which the ciphertext is to be transmitted as "zero". Here, "zero" has no special meaning and was used to indicate that events that occurred in a random client are transmitted directly to the server without passing through other clients. Subsequently, the ciphertext is sent directly to the server without sending it to any client, and the decision is made without the procedure to check the number of clients from which data are received. When at least four clients are connected to the server, the client where the event has occurred transmits the ciphertext to other clients. The clients that receive the ciphertext decrypt the ciphertext, encrypt it again, include a message indicating that the current client has verified the data, and transmit it to the server. When clients are extended in this way, the transmission method is defined according to the number of clients. In this manner, the client where an event has occurred randomly transmits a message to three clients, and the transmission process can be carried out up to three times for each data packet. In our proposed simplified DAGbased blockchain structure, even if the number of clients increases, the number of clients for which the packets are verified is limited to nine at the maximum. This is because increasing the amount of data generated by the client can overload the system and cause network delays. The value of nine was verified as the optimal value through many experiments. Table 1 shows the packet structure generated when an event occurs in a client. The packet structure is as follows. In the packet, Number "n" is the cumulative sum of the values of octet 4, which is the 4th digit of the IP address of the clients where the events occurred; Event Client Address "a" is the value of the octet 4, which is the 4th digit of the IP address of the client where the event occurred; and Random Address 1 "b", Random Randomly generated client addresses are re-encrypted so that the order of the next client's address cannot be known. The randomly generated client addresses, including the event client's address, are encrypted as shown in Table 1. The address encryption is defined as in (1).
The encryption was carried out by moving 2 bits of the current address and performing an XOR operation with a randomly defined number "2".

Data Verification Method
The server verifies the three packets received from the clients. There are two methods to verify the data. The first one is to check n = a + b + c + d in Table 1, and the second one is to compare the Sensor Data "f" in Table 1 in the packets generated by individual clients (for example, sensor) where the event occurred, with each other. Figure 5 shows an example of how a client where an event occurred transmits a packet to the server. This figure shows a case in which an event occurred in Client 5. Let us assume that the three packets, which this client will transmit to other clients, are as follows: packet 1: "5, E5, A (7, 2, 1), S15, D1" -packet 2: "5, E5, A (9, 4, 8), S15, D1" -packet 3: "5, E5, A (10, 6, 3), S15, D1" These packets were generated because an event occurred in Client 5 (a = 5 in this case). Client 5 transmits packet 1 to a client of which the IP address' octet 4 value is 7, packet 2 to a client of which the IP address' octet 4 value is 9, and packet 3 to a client the IP address' octet 4 value is 10.
Packet 1 passes through b = 7, c = 2, d = 1, which correspond to the value of octet 4 of the randomly generated client IP so that the Number of the packet transmitted to the server becomes n = a + b + c + d = 5 + 7 + 2 + 1 = 15 and the packet received by the server becomes "15, E5, A (7, 2, 1), S15, D1". Packet 2 passes through b = 9, c = 4, d = 8, which correspond to the value of octet 4 of the randomly generated client IP so that the Number of the packet transmitted to the server becomes n = a + b + c + d = 5 + 9 + 4 + 8 = 26 and the packet received by the server becomes "26, E5, A (9, 4, 8), S15, D1". Packet 3 passes through b = 10, c = 6, d = 3, which corresponds to the value of octet 4 of the randomly generated client IP so that the Number of the packet transmitted to the server becomes "24, E5, A (10, 6, 3), S15, D1". Because each of the three packets mentioned above have the same front part n = a + b + c + d and have the same sensor data, f = D1, it can be seen that they were transmitted normally.
If n = a + b + c + d is not valid in a packet due to hacking or other reasons, or sensor data "f" does not coincide, the packet is discarded. In addition, if the data in the packet other than octet 4 of the client IP do not match the packet received by the server, it will mean that the data have not been accurately transmitted. Therefore, this packet is also discarded.  Figure 6 shows the timeout for the client data to be received by the server. The server waits up to 5000 ms (measured from the time the first data were received) for the data to arrive. This is to prevent the system from going down due to overload on the server or the client when the network is delayed or the amount of data to be transmitted is momentarily increased. This value of 5000 ms was determined to be the most suitable response delay time from the server through many experiments. Then, the data received are discarded, and the data received before the timeout are adopted after verification.

Proposed New AES-CBC Algorithm
This paper proposes a new AES-CBC algorithm suitable for the new IoT. The conventional AES-CBC algorithm was set such that the cipher key was changed at regular intervals. In the process through which clients transmit data, encryption and decryption are sequentially performed while the data are transmitted to the server. That is, the data can be transmitted only when the cipher keys of all clients are identical, and the cipher keys are synchronized with the system time. When a new client has been registered, the cipher key used when a client has been added is configured to synchronize the cipher key. Figure 7 shows the overall structure of the encryption algorithm.  Figure 6 shows the timeout for the client data to be received by the server. The server waits up to 5000 ms (measured from the time the first data were received) for the data to arrive. This is to prevent the system from going down due to overload on the server or the client when the network is delayed or the amount of data to be transmitted is momentarily increased. This value of 5000 ms was determined to be the most suitable response delay time from the server through many experiments. Then, the data received are discarded, and the data received before the timeout are adopted after verification.  Figure 6 shows the timeout for the client data to be received by the server. The server waits up to 5000 ms (measured from the time the first data were received) for the data to arrive. This is to prevent the system from going down due to overload on the server or the client when the network is delayed or the amount of data to be transmitted is momentarily increased. This value of 5000 ms was determined to be the most suitable response delay time from the server through many experiments. Then, the data received are discarded, and the data received before the timeout are adopted after verification.

Proposed New AES-CBC Algorithm
This paper proposes a new AES-CBC algorithm suitable for the new IoT. The conventional AES-CBC algorithm was set such that the cipher key was changed at regular intervals. In the process through which clients transmit data, encryption and decryption are sequentially performed while the data are transmitted to the server. That is, the data can be transmitted only when the cipher keys of all clients are identical, and the cipher keys are synchronized with the system time. When a new client has been registered, the cipher key used when a client has been added is configured to synchronize the cipher key. Figure 7 shows the overall structure of the encryption algorithm.

Proposed New AES-CBC Algorithm
This paper proposes a new AES-CBC algorithm suitable for the new IoT. The conventional AES-CBC algorithm was set such that the cipher key was changed at regular intervals. In the process through which clients transmit data, encryption and decryption are sequentially performed while the data are transmitted to the server. That is, the data can be transmitted only when the cipher keys of all clients are identical, and the cipher keys are synchronized with the system time. When a new client has been registered, the cipher key used when a client has been added is configured to synchronize the cipher key. Figure 7 shows the overall structure of the encryption algorithm. Two cipher keys should be used for encryption and decryption of the proposed algorithm: (the current cipher key) and (the cipher key in the immediately previous block). These cipher keys were identically set to 192 bits (24 bytes), and the initialization vector IV was set to 128 bits (16 bytes). Figure 8 shows the process through which the cipher keys are changed. The cipher keys are changed at different time intervals. If the defined time is the same as the current time, the cipher key will not be changed and is used as it is; if the time is different, the cipher key will be changed. If the defined time and the current time are different, the cipher key is calculated by the time function and is output again.  Two cipher keys should be used for encryption and decryption of the proposed algorithm: K e n (the current cipher key) and K T n (the cipher key in the immediately previous block). These cipher keys were identically set to 192 bits (24 bytes), and the initialization vector IV was set to 128 bits (16 bytes). Figure 8 shows the process through which the cipher keys are changed. The cipher keys are changed at different time intervals. If the defined time is the same as the current time, the cipher key will not be changed and is used as it is; if the time is different, the cipher key will be changed. If the defined time and the current time are different, the cipher key is calculated by the time function and is output again. Two cipher keys should be used for encryption and decryption of the proposed algorithm: (the current cipher key) and (the cipher key in the immediately previous block). These cipher keys were identically set to 192 bits (24 bytes), and the initialization vector IV was set to 128 bits (16 bytes). Figure 8 shows the process through which the cipher keys are changed. The cipher keys are changed at different time intervals. If the defined time is the same as the current time, the cipher key will not be changed and is used as it is; if the time is different, the cipher key will be changed. If the defined time and the current time are different, the cipher key is calculated by the time function and is output again.  In Figure 8, the process of changing the ciphertext is as follows. [ Step 1] Carry out shift operation of K e n (1) to output K e n (2), which is colored orange.
Step 1 can be expressed as Equation (2).
Step 2] Carry out XOR operations of K e n (2) output in Step 1 with the value obtained by shifting K e n (1) to the left bit by bit to output K e n (3) which is colored blue.
Step 2 can be expressed as Equation (3).
K e n = K e n (1) ⊕ K e n (2) [ Step 3] Change the new cipher key every minute using K e n (3) and Time Zone for changing encryption.
"IV Refresh" in Figure 8 is a sort of initialization vector (IV) used in "CBC Operating mode." Using "IV Refresh" is in the sense that the value of IV is changed every minute to enhance security further.

Time Zone
The cipher key changes when the defined time is not identical to the current time. Figure 9 shows the process through which cipher keys are generated. The month of the system's current date and the minute of the current time are added. In this paper, months and minutes are used to generate cipher keys. If we use months, days, hours, and minutes simultaneously, cipher keys can become too complex and take a long time to decrypt. Using minutes instead of hours changes the cipher key every minute to enhance security.
Electronics 2021, 10, x FOR PEER REVIEW 10 of 21 In Figure 8, the process of changing the ciphertext is as follows. [ Step 1] Carry out shift operation of (1) to output (2), which is colored orange.
Step 1 can be expressed as Equation (2).
Step 2] Carry out XOR operations of (2) output in Step 1 with the value obtained by shifting (1) to the left bit by bit to output ′ (3) which is colored blue.
Step 2 can be expressed as Equation (3). [ Step 3] Change the new cipher key every minute using ′ (3) and Time Zone for changing encryption.
"IV Refresh" in Figure 8 is a sort of initialization vector (IV) used in "CBC Operating mode." Using "IV Refresh" is in the sense that the value of IV is changed every minute to enhance security further.

Time Zone
The cipher key changes when the defined time is not identical to the current time. Figure 9 shows the process through which cipher keys are generated. The month of the system's current date and the minute of the current time are added. In this paper, months and minutes are used to generate cipher keys. If we use months, days, hours, and minutes simultaneously, cipher keys can become too complex and take a long time to decrypt. Using minutes instead of hours changes the cipher key every minute to enhance security. The XOR operation is carried out for one byte of the 24 bytes of the input per time interval, in order, and the resultant values are fed to . Equation (4) describes the operation process: In Equation (4), is the current cipher key, which is 192 bits, and (MM+mm) represents the month and minute, which is 8 bits. These two values are XOR operated to generate a new cipher key, ′ .
The used here is copied to and stored there. is used as a temporary cipher key. It is used as the cipher key when decryption is not performed during network The XOR operation is carried out for one byte of the 24 bytes of the input K e n per time interval, in order, and the resultant values are fed to K e n . Equation (4) describes the operation process: In Equation (4), K e n is the current cipher key, which is 192 bits, and (MM+mm) represents the month and minute, which is 8 bits. These two values are XOR operated to generate a new cipher key, K e n .
The K e n used here is copied to K T n and stored there. K T n is used as a temporary cipher key. It is used as the cipher key when decryption is not performed during network timeout or normal encryption/decryption. This cipher key is discarded when the next cipher key has been changed.
In Figure 9, K i is the current cipher key and represents the input, and K o is the new changed cipher key and represents the output. Figure 10 shows a diagram showing the process of changing IV. Of the 192 bits (24 bytes) of the cipher key K e n the last eight bytes are discarded and only the first 16 bytes are used to carry out the XOR operation of K e n and IV. The calculated IV is used again to generate the cipher key.

Initialization Vector (IV) Change
Electronics 2021, 10, x FOR PEER REVIEW 11 of 21 timeout or normal encryption/decryption. This cipher key is discarded when the next cipher key has been changed. In Figure 9, is the current cipher key and represents the input, and is the new changed cipher key and represents the output.   Figure 11 shows the hardware that makes up the system used for experimental testing of the algorithm. The left side of the picture shows the central server configured with one Raspberry Pi 3 B+ board, and the right side shows clients to which sensors were connected and configured using ten Raspberry Pi ZERO boards. The sensors consisted of speaker sensors and human-body-sensing sensors. The server and clients could communicate through a router. The clients encrypted the data generated by the sensors and transmitted the ciphertext to the central server through the other clients. The Raspberry Pi board used in the experiment was an experimental embedded board developed by the UK's Raspberry Pi Foundation for basic computer science education. The specifications of the 3 B+ model used as a server are as follows: CPU ARM11 700 MHz, RAM 512 MB SDRAM, and GPU 250 MHz VideoCore IV. The specifications of the ZERO model are as follows: ARM11 1 GHz, RAM 512 MB SDRAM, and GPU 250 MHz video core IV.  Figure 11 shows the hardware that makes up the system used for experimental testing of the algorithm. The left side of the picture shows the central server configured with one Raspberry Pi 3 B+ board, and the right side shows clients to which sensors were connected and configured using ten Raspberry Pi ZERO boards. The sensors consisted of speaker sensors and human-body-sensing sensors. The server and clients could communicate through a router. The clients encrypted the data generated by the sensors and transmitted the ciphertext to the central server through the other clients. The Raspberry Pi board used in the experiment was an experimental embedded board developed by the UK's Raspberry Pi Foundation for basic computer science education. The specifications of the 3 B+ model used as a server are as follows: CPU ARM11 700 MHz, RAM 512 MB SDRAM, and GPU 250 MHz VideoCore IV. The specifications of the ZERO model are as follows: ARM11 1 GHz, RAM 512 MB SDRAM, and GPU 250 MHz video core IV. Figure 12 shows the overall structure of the system. The server stores suspicious clients and new clients in the lookup table, and each client has a lookup table that stores the addresses of newly entered clients. When a new client is registered through the server, the server transmits the newly entered client's address to the connected clients through a broadcast. Each client stores the address received from the server in the lookup table.

System Configuration
When an event occurs in the connected sensor, it creates the addresses of the clients to which it will transmit the data by referring to the lookup table. Electronics 2021, 10, x FOR PEER REVIEW 12 of 21 Figure 11. Hardware equipment that composes the system. Figure 12 shows the overall structure of the system. The server stores suspicious clients and new clients in the lookup table, and each client has a lookup table that stores the addresses of newly entered clients. When a new client is registered through the server, the server transmits the newly entered client's address to the connected clients through a broadcast. Each client stores the address received from the server in the lookup table.
When an event occurs in the connected sensor, it creates the addresses of the clients to which it will transmit the data by referring to the lookup

Client Extension
When each new node (client) is created, the algorithm is not modified, but the internet protocol (IP) address of the new client is registered with the server, and the time is synchronized. When the client is added, the IP address of the newly added client is registered in the lookup table composed of text files subordinate to the server. When the client is registered, the server transmits information regarding the new client's addition   Figure 12 shows the overall structure of the system. The server stores suspicious clients and new clients in the lookup table, and each client has a lookup table that stores the addresses of newly entered clients. When a new client is registered through the server, the server transmits the newly entered client's address to the connected clients through a broadcast. Each client stores the address received from the server in the lookup table.
When an event occurs in the connected sensor, it creates the addresses of the clients to which it will transmit the data by referring to the lookup

Client Extension
When each new node (client) is created, the algorithm is not modified, but the internet protocol (IP) address of the new client is registered with the server, and the time is synchronized. When the client is added, the IP address of the newly added client is registered in the lookup table composed of text files subordinate to the server. When the client is registered, the server transmits information regarding the new client's addition

Client Extension
When each new node (client) is created, the algorithm is not modified, but the internet protocol (IP) address of the new client is registered with the server, and the time is synchronized. When the client is added, the IP address of the newly added client is registered in the lookup table composed of text files subordinate to the server. When the client is registered, the server transmits information regarding the new client's addition to other clients via broadcasting. Synchronized clients transmit data, including the client added, during the data transmission process. In the algorithm, the method of transmission between the server and the client is as shown below. The proposed algorithm is not optimized if there are fewer than 10 clients. Therefore, the transmission process is defined according to the number of clients, as shown in Algorithm 1.
When there are three or fewer clients, the data are sent directly to the server; when six or fewer clients are connected, the client where an event occurs transmits the data to three other clients, and the three clients transmit the data to the server for verification. In addition, when there are nine or fewer clients, the client transmits the data to two sets of three clients so that the data are verified twice, and when more than nine clients are connected, the data are sent to three sets of three clients so that the data are verified three times.

Registration of Cases of Suspicious Clients
To enhance security, a method for disregarding suspicious clients was established. A lookup table was constructed on the server to determine whether the clients were problematic. The server determines the number of clients from which the data arrive at the server according to the total number of clients. The number of messages received by the server from a client when the number of clients is greater than six is determined, and when insufficient or incorrect data have been received, the relevant client is recorded in the lookup table. In this way, clients that could be problematic are determined using the accumulated data.

Experiment and Results
The tests were conducted to investigate the following cases.

1.
Handling of data by the data processing server when the client's secret key is different.

2.
Handling of data transmitted from a wrong client.

3.
Dealing with several kinds of processing, such as the substitution of incorrect values into the data. Figure 13 shows the experimental setup implemented for encryption and decryption. Two out of ten Raspberry Pi zero boards were used to configure the sensors. The sensors were a passive infrared sensor (PIR) sensor and a sound sensor. The PIR sensor was used to transmit signals when a human body was detected, and the sound sensor was used to send signals when a certain sound level (decibels) was reached. Electronics 2021, 10, x FOR PEER REVIEW 14 of 21 Figure 13. Experimental setup implemented for encryption and decryption.

Encryption and Decryption Analysis
Several experiments were conducted to observe whether encryption and decryption were carried out.
To proceed with the experiments, the equipment was configured as shown in Figure 13. Here, because there were 10 clients, the client where the event occurred sent encrypted data to three clients for data verification, which was repeated three times when the data were transmitted to the server. The IP addresses of the 10 clients became "192.168.0.N," where N was the value of octet 4 for client, "5-14." In the server address, the digit corresponding to the value of octet 4 for client was set as "15." A client with "192.168.0.5" was connected to a PIR sensor, and a client with "192.168.0.6" was connected to a speaker sensor.
In the system, the cipher key was changed once per minute. When changed, the old cipher key was valid for 1 min. That is, the created cipher key could be used for 2 min, after which the cipher key was changed, and the old cipher key was discarded. The first experiment checked whether encryption/decryption was carried out properly.
The experiment was conducted by generating an event in the client connected to the PIR sensor. The client where the event occurred randomly generated IP addresses. The generated packet including the random data A (4, 2, 8) is "5, E5, A (4, 2, 8), S15, D1". To enhance security, first, the random data of "A (4, 2, 8)" was encrypted by performing a left shift operation. Then, the entire packet "5, E5, A (4, 2, 8), S15, D1" was encrypted once more. The packet was encrypted because the data contained in the packet may be hacked due to a hacker, and the packet should be encrypted once more to enhance security. In this case, the keys used for the two encryptions are different. Using the same cipher key has the disadvantages that the structure of encryption and decryption is complex, encryption and decryption takes a long time, and energy consumption increases.
In this way, the client also generated two more packets such that the encrypted data were "5, E5, A (9, 7, 1), S15, D1" and "5, E5, A (3, 6, 10), S15, D1". The three encrypted data packets were transmitted to the individual clients. The clients, corresponding to hosts 4, 9, and 3, decrypted the packet. In the decrypted packets, the part corresponding to the client address was decrypted again and added to the digit of "N," which was the first digit

Encryption and Decryption Analysis
Several experiments were conducted to observe whether encryption and decryption were carried out.
To proceed with the experiments, the equipment was configured as shown in Figure 13. Here, because there were 10 clients, the client where the event occurred sent encrypted data to three clients for data verification, which was repeated three times when the data were transmitted to the server. The IP addresses of the 10 clients became "192.168.0.N," where N was the value of octet 4 for client, "5-14." In the server address, the digit corresponding to the value of octet 4 for client was set as "15." A client with "192.168.0.5" was connected to a PIR sensor, and a client with "192.168.0.6" was connected to a speaker sensor.
In the system, the cipher key was changed once per minute. When changed, the old cipher key was valid for 1 min. That is, the created cipher key could be used for 2 min, after which the cipher key was changed, and the old cipher key was discarded. The first experiment checked whether encryption/decryption was carried out properly.
The experiment was conducted by generating an event in the client connected to the PIR sensor. The client where the event occurred randomly generated IP addresses. The generated packet including the random data A (4, 2, 8) is "5, E5, A (4, 2, 8), S15, D1". To enhance security, first, the random data of "A (4, 2, 8)" was encrypted by performing a left shift operation. Then, the entire packet "5, E5, A (4, 2, 8), S15, D1" was encrypted once more. The packet was encrypted because the data contained in the packet may be hacked due to a hacker, and the packet should be encrypted once more to enhance security. In this case, the keys used for the two encryptions are different. Using the same cipher key has the disadvantages that the structure of encryption and decryption is complex, encryption and decryption takes a long time, and energy consumption increases.
In this way, the client also generated two more packets such that the encrypted data were "5, E5, A (9, 7, 1), S15, D1" and "5, E5, A (3, 6, 10), S15, D1". The three encrypted data packets were transmitted to the individual clients. The clients, corresponding to hosts 4, 9, and 3, decrypted the packet. In the decrypted packets, the part corresponding to the client address was decrypted again and added to the digit of "N," which was the first digit of the packet, to accumulate the value of octet 4 for client. Host packets were added in the same way such that the digits became "9, E5, A (4, 2, 8), S15, D1", "14, E5, A (9, 7, 1), S15, D1", and "8, E5, A (3, 6, 10), S15, D1", respectively, in the three clients. Finally, the received packets were decrypted in the server, and the data were adopted. Table 2 shows the results of encryption and decryption through experiment. From the upper left of the table, the host addresses "192.168.0.5-14" were defined. It can be seen that the ciphertexts were transmitted to the relevant clients and sequentially transmitted to the server. Table 3 shows the ciphertext received at the server. The client addresses and the received ciphertexts were checked. If there was no problem, the data received from the clients were gathered to determine the data. Consequently, it can be seen that the data "1" was transmitted.  The second experiment checked whether encryption/decryption was carried out properly when an incorrect secret key or other value was entered during the transmission process. The system was constructed identically to the first experiment. Three tests were conducted as part of the second experiment: changing the secret key, changing the data, and receiving data from an irrelevant client.

Changing the Secret Key
The secret key value of the client corresponding to "192.168.0.6" was changed, and the encryption/decryption and transmission of data were checked. During data transmission, the client corresponding to "192.168.0.6" could not decrypt the received data and could not transmit the data to the next client. The server waited for a packet from the client for 5 s and processed only the previously received data if it did not receive the packet.

Changing the Data
This experiment was conducted by randomly changing the data in the packets and transmitting them. The client corresponding to "192.168.0.5" decrypted the data received from the client where the event occurred, or another client changed "D1" in the packet data "5, E5, A (4, 2, 8), S15, D1" to a different value and transmitted the data to other clients or the server. While the data were transmitted, encryption and decryption were carried out without any problems. The server decrypted the data received from each client, and compared and analyzed the data. The server determined that the packet corresponding to the randomly generated client "192.168.0.6" was wrong, discarded this data, and recorded the client in the lookup table as a suspicious client.

Receiving Data from an Irrelevant Client
This experiment was conducted using the same method as described above. The difference was that, although the server should have received packets such as "5, E5, A (3, 6, 10), S15, D1" from the client "192.168.0.10", the packet was transmitted from an address in which the host address was not 10. In this way, the event of the client connected to the speaker sensor was generated approximately 100 times, and the condition of the server was checked. Table 4 shows the number of data received from clients. In Table 4, c5 is the client to which the sensor was connected, and c14 is the client for experimentation. The client address was changed and transmission was performed. Three packets were generated by the client where the event occurred, and these were transmitted to other clients. One packet contained three client addresses. In the normal condition, if an event occurs 100 times, each client transmits and receives 100 times, resulting in a total of 900 transmissions and receptions for all clients. However, because the original address of the client corresponding to c14 was not used in this experiment, the total number of transmissions and receptions for each client was 600. Accordingly, it can be confirmed that the server did not process the packets corresponding to client c14. Figure 14 shows a graph of three measurements of the transmission speeds from the clients to the server. The first communications are marked with squares, the second with triangles, and the third with circles. The delays were generally 50 ms, and a cumulative average delay of approximately 200 ms was measured. The round-trip time (RTT) of the wirelessly connected router network had a minimum delay of 43 ms, a maximum delay of 632 ms, and an average of 75 ms. When the averages of the encryption/decryption times were added, the average delay was found to be approximately 80 ms.

Analysis of the Proposed Aes-Cbc Algorithm for Time and Power Consumption
Overhead refers to the additional memory required to process an instruction. The causes of overhead include high-priority processing first, the use of a stack frame of an external function, and increases in signal data to ensure network communication.

Analysis of the Proposed Aes-Cbc Algorithm for Time and Power Consumption
Overhead refers to the additional memory required to process an instruction. The causes of overhead include high-priority processing first, the use of a stack frame of an external function, and increases in signal data to ensure network communication.
To calculate the overhead, in this study, 100 events were generated in the client and the quantity of resources (time, power, and packet) of each node were measured. This enabled the identification of the quantities of resources generated by encryption and decryption excluding network delays. Table 5 shows the minimum, average, and maximum values (overhead) of the time taken and power consumed by each node during encryption and decryption when an event occurred in the client. To calculate the power, an oscilloscope and ammeter were used. We measured the voltage using the oscilloscope's trigger function because the voltage rises instantaneously when sending data. The current was measured with an ammeter, and power was calculated by multiplying the measured voltage by the current flowing through the client. At this time, the measured voltage and current were effective values. In our experimental system, one Raspberry Pi board was implemented as a client.
When the AES-CBC algorithm proposed in this paper was used, the packet size increased from 27 bytes on average (maximum 31 bytes) before encryption to 49 bytes on average (maximum 57 bytes) after encryption. If a TCP/IP protocol packet was included here, the size of the packet increased to 89 bytes (maximum 97 bytes). However, given the maximum transmission unit (MTU) of IPv4, the increase in size of a packet due to encryption and the TCP/IP protocol does not affect network reliability. In general, protocol packets are referred to as network packet overhead.

Comparison with Conventional AES-CBC Algorithm
The time taken and the amount of power consumed for encryption and decryption by the conventional AES-CBC algorithm [20] and those by the proposed AES-CBC were compared. In the experiment, 100 events were generated in the client, and the average values of packet size, time taken, and amount of power consumed for encryption and decryption were compared.
The average size of packets encrypted in the conventional AES-CBC algorithm was 51 bytes, and 91 bytes including the protocol packet. By comparison, the average size of packets encrypted in the proposed AES-CBC algorithm was 49 bytes, and 89 bytes including the protocol packet. Figure 15 shows the comparison of the times taken for encryption and decryption by the conventional AES-CBC algorithm and by the proposed AES-CBC algorithm. Table 6 shows the mean value, minimum value, maximum value, and standard deviation of the time spent for encryption and decryption as numerical values. In the case of the conventional AES-CBC algorithm, the average time taken for encryption was 1.56 ms, and the average time taken for decryption was 3.02 ms. By comparison, in the case of the proposed AES-CBC algorithm, the average time taken for encryption time 1.2 ms and the average time taken for decryption time 2.41 ms, a decrease of about 20-23%.
shows the mean value, minimum value, maximum value, and standard deviation of the time spent for encryption and decryption as numerical values. In the case of the conventional AES-CBC algorithm, the average time taken for encryption was 1.56 ms, and the average time taken for decryption was 3.02 ms. By comparison, in the case of the proposed AES-CBC algorithm, the average time taken for encryption time 1.2 ms and the average time taken for decryption time 2.41 ms, a decrease of about 20-23%.   Figure 16 shows the amount of power consumed for encryption and decryption by the conventional AES-CBC algorithm and the proposed AES-CBC algorithm. Table 7 shows the mean value, minimum value, maximum value, and standard deviation of the power consumed for encryption and decryption as numerical values. In the case of the conventional AES-CBC algorithm, the average amount of power consumed for encryption   Figure 16 shows the amount of power consumed for encryption and decryption by the conventional AES-CBC algorithm and the proposed AES-CBC algorithm. Table 7 shows the mean value, minimum value, maximum value, and standard deviation of the power consumed for encryption and decryption as numerical values. In the case of the conventional AES-CBC algorithm, the average amount of power consumed for encryption was 0.231 mW, and that for decryption was 0.311 mW. By comparison, in the case of the proposed AES-CBC algorithm, the average amount of power consumed for encryption was 0.193 mW and that for decryption was 0.247 mW, representing a decrease of approximately 17-21%. was 0.231 mW, and that for decryption was 0.311 mW. By comparison, in the case of the proposed AES-CBC algorithm, the average amount of power consumed for encryption was 0.193 mW and that for decryption was 0.247 mW, representing a decrease of approximately 17-21%.

Conclusions
In this paper, we simplified the conventional DAG-based blockchain structure and proposed a new AES-CBC algorithm with enhanced security by periodically changing the secret key and initialization vector (IV) in the conventional AES-CBC encryption algorithm. In the proposed new algorithm, the key is renewed every minute, and when a client event has occurred, the host addresses of the clients connected to the network are randomly set to create three ciphertexts, and the ciphertexts are transmitted to the clients. The transmission process depends on the number of clients, and the transmitted ciphertexts are transmitted to the server through other clients. Regarding server and client information, new client host addresses were created by referring to individual lookup tables, and a database for storing problematic clients was configured in the server's lookup table. Clients were identified as suspicious in cases when the server did not receive messages from the clients, and in cases in which the client address corresponding to the encrypted packet was not identical to the address of the client that transmitted the packet. When a new client was registered, the server provided information about the new client through a broadcast. In this way, the proposed new algorithm was improved to apply to the IoT because its security is better than that of conventional algorithms.

Conclusions
In this paper, we simplified the conventional DAG-based blockchain structure and proposed a new AES-CBC algorithm with enhanced security by periodically changing the secret key and initialization vector (IV) in the conventional AES-CBC encryption algorithm. In the proposed new algorithm, the key is renewed every minute, and when a client event has occurred, the host addresses of the clients connected to the network are randomly set to create three ciphertexts, and the ciphertexts are transmitted to the clients. The transmission process depends on the number of clients, and the transmitted ciphertexts are transmitted to the server through other clients. Regarding server and client information, new client host addresses were created by referring to individual lookup tables, and a database for storing problematic clients was configured in the server's lookup table. Clients were identified as suspicious in cases when the server did not receive messages from the clients, and in cases in which the client address corresponding to the encrypted packet was not identical to the address of the client that transmitted the packet. When a new client was registered, the server provided information about the new client through a broadcast. In this way, the proposed new algorithm was improved to apply to the IoT because its security is better than that of conventional algorithms.
Through experiments, it was found that the new AES-CBC algorithm proposed in this paper reduces the time taken and the amount of power consumed for encryption and decryption by approximately 20% compared to the conventional AES-CBC algorithm.
In the future, we plan to build a database with an algorithm that can be practically used and build a system to improve communication and security. Funding: This research received no external funding.