1 Introduction

The device density per network is increasing rapidly. Many wireless protocols are used to create an IoT environment via protocols such as RFID, GPS, IEEE 802.11, Bluetooth, and zigbee. This is also accomplished through a variety of IT technologies. The number of devices used in 2009 is estimated to be approximately 900 million IoT, while in 2020 this number is projected at approximately 250 million devices [1–3]. As IoT technology grows, so does the possibility of information leakage, as most IoT devices are exposed to information leak and hacking. Numerous suggestions have been proposed in this regard, such as a security protocol in the IoT environment, Datagram Transport Layer Security (DTLS); or embedded Security Socket Layer (SSL), WolfSSL. DTLS is a protocol that provides security through datagram protocol communication, and requires six message packet exchanges. If a packet is lost, message packets must be transmitted from the beginning again, which may result in poor device performance in the limited IoT environment [4, 5]. WolfSSL is an embedded protocol based on SSL/TLS. This lightweight library can be used with resources of limited size and mobility; however, it is not easily applied in the case of small devices with few resources because it is not lightweight enough [6].

IETF has been categorized by a device resource that configures the IoT environment and is shown in Table 1. Currently, many IoT products have applied the IoT platforms. These platforms can benefit both the developer and the company, and offer a platform that brings many benefits, including:

  • reduced development cycle of a project

  • reduced development mistakes

  • reduced cost

The platforms enable the developer to make new IoT devices easily and quickly. Platforms can make various devices in the areas of consumer and smart home, smart infrastructure, security and surveillance, healthcare, retail, industry, and transportation. The IoT device, Network, Security, and Service constitute the IoT platform. In the IoT platform, the IoT device collects various data and consists of a processor, wireless media, memory, and special sensors that sense row data. The processors used in the IoT devices that are included in Embedded Systems range from 8 to 32 bit. The M2M device generally uses the 8 bit microprocessor; however, the IoT device uses not only an 8 bit microprocessor but also a 32 bit microprocessor. The microprocessor makes it possible for an IoT device to connect to a variety of smart devices such as Smartphones and Tablets using wireless communication.

Table 1 Specification for each class
Full size table

To support communication, the IoT device utilizes wireless media such as Wi-Fi and BLE. It is important for the IoT device to have a protocol stack software for each wireless media. The software is held within the IoT device memory using either ROM or Flash. Wireless media came into widespread use in IoT devices for its high-performance and ample memory. The IoT software is divided into five parts within memory, as shown in Fig. 1. Each SW must be included in the memory except the Security SW, as shown in Table 2.

Table 2 IoT software category
Full size table
Fig. 1
figure 1

IoT platform

Full size image

The IoT device requires sufficient memory to gather, send, and receive sensor data from a smart device. IoT device platforms have been designed by four companies, ARM mbed, ATMEL Arduino, Raspberry Pi, and Intel Edision, which all offer the required 32 bit high microprocessor. ARM Mbed specifically has a 100 MHz and 32 bit Cortex-M processor. NXP, Freescale, TI, STMicro, and Nordic are based on Mbed, and the Arduino offers microprocessors ranging from 8 to 32 bit. The Raspberry Pi has an ARM1176JZF 700 MHz, 32 bit microprocessor. The Intel Edison has a 400 MHz and 32 bit Quark processor, as shown in Table 3.

Table 3 IoT device speed for each processor
Full size table

Also, ARM, ATMEL, Raspberry Pi, and INTEL have large memory such as RAM and Flash, as shown in Table 4.

Table 4 IoT device memory size for each platform
Full size table

Mbed and Arduino are used in various applications, such as in wearable devices with low performance applications, while Raspberry Pi and Edison can be used in high speed devices such as gateway with high applications. As mentioned above, the classes suggested by IETF are simple and can be applied in a limited environment. This study targets devices that have core roles; Table 5 presents three classes categorized by the size of their resources.

Table 5 Specification for each weight
Full size table

This study is focused on the middleweight among the three classes and suggests a sporadic authentication protocol using the Hash Tree if authentication among devices is difficult, due to the absence of a central control server. The flash memory size required for the suggested protocol is approximately 5000 KB and the testing device has stm32 cortex m4, which is a middleweight resource.

This paper is configured as follows: Sect. 2 demonstrates the relevant studies, Sect. 3 demonstrates working principles of the suggested protocol, and the conclusion is presented in Sect. 4.

2 Related Works

2.1 Merkle Tree

The Hash Tree first suggested by Merkle is configured, as shown in Fig. 2. Each attribute was hashed to form a binary tree and the message is verified using a Root Hash.

$$P[i, j]= f(P[i, (i+j-1)/2] \parallel P[(i+j+ 1)/2, j])$$
(1)

Equation (1) calculates P(1) and shows the process of assigning a space for mapping the nodes with an attribute value or hash value, respectively. Equation (2) shows a computation that requires two child trees to derive the Root Hash.

$$P^{n_{parent}} = f(P^{n_{left}} \parallel P^{n_{right}})$$
(2)

This is called a Tree Authentication [7]. The most important attribute at this point is the authentication of the Root Hash and the Merkle Tree proof that the correct Root Hash value is with the authenticator. To apply this in an IoT environment, the central control server must have all the Root Hash values of every user that causes issues with memory space and verification. Even when configured this way, the system is still exposed to hacking and information leaks [8, 9].

Fig. 2
figure 2

Merkle Hash Tree

Full size image

2.2 Specification of CoAP

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10 s of KB/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy, and building automation CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP or for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.

In this case, the sender and receiver share a secret key K, which they will use to authenticate their transmissions. We describe the message authentication goal and various methods of achieving it. Issues which are still being resolved will be explicitly noted in this text, as shown in Table 6.

Table 6 Definition authenticity of an encryption scheme
Full size table

Let us examine some example message authentication codes and use the definition to assess their strengths and weaknesses. We fix a PRF, as shown in Table 7.

Table 7 Definition authenticity of an encryption scheme
Full size table

2.3 C.Message Authentication Code (MAC)

For many people, privacy is the goal most strongly associated with cryptography; but message authentication is arguably even more important. Indeed you may or may not care if some particular message you send remains private, but you almost certainly want to be sure of the originator of each message that you act on. Message authentication is what buys you that guarantee. Message authentication allows one party, the sender, to send a message to another party, the receiver, in such a way that the receiver will almost certainly know if the message is modified a route. Message authentication is also called data-origin authentication, and is said to protect the integrity of a message, ensuring that each message that is received and deemed acceptable is arriving in the same condition that it was sent out with no bits inserted, missing, or modified. Here we will be looking at the shared-key setting for message authentication (remember that message authentication in the public-key setting is the problem addressed by digital signatures). The AES and SHA algorithm is widely used in MAC or an authentication [6, 8, 9].

Authentication protocol in current IoT environments is shown in Fig. 3.

  1. (1)

    Initial U (user or sensor node) tries to request authentication with the Cipher Suite options, at which time the Cipher Suite as a set of encryptions of RSA, SHA, or AES occasionally selects and uses an arbitrary encryption scheme.

  2. (2)

    V (server or sensor node) notifies that it is ready to authenticate when a request is received.

  3. (3)

    U with a reply from V forms a message tag with a private key shared with random seeds presented with N. U forms a MAC and transmits to V using the authentication, private key, and message tag.

  4. (4)

    V verifies the validity of the MAC and tests the validity of the authentication and private key shared by U and V, then forms a MAC in the same process and transmits.

  5. (5)

    U verifies the validity of the MAC received from V and the authentication is finalized if there is no problem [10].

As shown in the abovementioned processes, authentication through MAC is simple and has relatively fewer hand-shakes; however, it requires devices with heavyweight resources in forming MACs and validation verification [11].

Fig. 3
figure 3

Flow diagram of authentication phase

Full size image

3 Proposed Authentication Protocol

As discussed in the previous section, classes suggested by IETF are lightweight in this paper, as shown in Table 5. The lightweight class is small enough to include the IoT software in memory as shown in Table 2. The middleweight class in this paper is suitable for devices in applications, such as wearables for SmartHome and Healthcare applications, because the middleweight class has enough memory to embed in ash memory. The middleweight class makes it possible for the device to contain the IoT software in memory, as shown in Table 4. Although middleweight devices are low in price, the class exhibits high-performance and meets the requirements suggested by IETF. Here is a purposed Keyed Hash algorithm, which is required from lightweight to middleweight classes because the IoT device should support the 32 bit microprocessor and have a memory size of at least 512 KB. The suggested protocol uses a sporadic authentication at the time that an authentication is required in order to address specific issues. It is able to authenticate between devices with limited recourses in the absence of central control.

  1. (1)

    The Device (device that requires the authentication) transmits either a MAC address or a Serial number to the Target Device (device that performs the authentication). A MAC address and Serial number is encryption using AES as show in Fig. 4 in first step.

  2. (2)

    The Target Device uses the leftmost node value as a MAC or serial and reflects a Hash value to the parent node through four encryption rounds (a set of encryptions of RSA, SHA, or AES occasionally selects). The right node is a Time Stamp that is used to form a Hash Tree. After the Hash Tree is formed, the Target Device sends the Time Stamp on the rightmost node to the device via four encryption rounds. It can be seen below that less calculations are required than for those shown in Fig. 3. The flow is as follows:

    $$\begin{aligned} F(X,Y,Z)= & {} (X \wedge Y) \vee (\lnot X\wedge Z) \\ G(X,Y,Z)= & {} (X \wedge Z) \vee (\lnot X\wedge Z) \\ H(X,Y,Z)= & {} X\oplus Y\oplus Z \\ I(X,Y,Z)= & {} Y\oplus (X\wedge \lnot Z) \\ \end{aligned}$$
Fig. 4
figure 4

Flow diagram of proposed protocol

Full size image

F and G are functions (X, a logical product of Y) and (logical AND of NOT X and Z) to logical sum operation, the H function shows the XOR operation for all arguments, and the I function (X-OR and NOT Z) indicates the XOR operation in the Y operation.

  1. (3)

    The Device from the Hash Tree is formed at the Device in the same way that the Hash Tree is formed at the Target Device. The device and target device has the same Hash Tree algorithm and four encryption rounds. Then two device has each TDH3 and DH3.

  2. (4)

    The Root Hash is transmitted for authentication of its validity at the Device, the Target Device authenticates, and the Hash shake is completed. (Device: D, Target Device: TD, DH3: Root Hash)

In Table 8, the message transmission was encrypted by AES128 bit, (3) encrypts the key information via DH3 AES. This has the advantage of double encryption (DH1-3: Device Hash 1–3, TDH1-3: Target Device Hash 1–3 as shown in Fig. 2).

Table 8 Message transport sequence
Full size table

When the Root Hash for authentication is formed, DH1 and DH2, the left and right Hash values, respectively, take up only 64 bits to form the Root Hash, enabling high security. This security results from one of the tMac Address, Serial number, or Time Stamp being snipped while the message is being transmitted. Figure 5 is a graphic of the formula shown in Tables 8 and 9 and shows the differences apparent to the conventional Merkle Hash Tree, This is used for authentication of attribute 1–2, consisting of a MAC address and Serial number unique identification tag device, so that each forms a 128 bit empty bit padding. Values used in padding are derived via a function of the time seed and argument. In this way, the padding has 128 bits of Message generating a Hash value with the SHA128 algorithm, L1H1 is a Hash generated using the MAC address (LeftHash), and a Hash produced using the Serial number is R1H2 (RightHash). The Hash values of both the generated 128 bit top of the L1H1 64 bit, and R1H2 in the sub 64 bit Nomitori, the padding without 128 bit after setting, is Hashing to again SHA128 algorithm. This is used as the generated Hash value to authenticate as Keyed Hash.

Fig. 5
figure 5

Root Hash procedure flow

Full size image
Table 9 Create a Root Hash procedure
Full size table

We use the definition of the tagging algorithm to see that

$$\begin{aligned} T1 = F_{k} (SD_{p}\text { and } ME_{p}) \oplus F_{K} (k\_SHA2)\\ T2 = G_{k} (TD_{leaf}) \oplus F_{K} (SD_{p}\text { and } ME_{p}) \oplus F_{K} (k\_SHA2)\\ T3 = G_{K} (DH1 \parallel DH2) \oplus F_{K} (k\_SHA2) \\ \end{aligned}$$

T1, T2, and T3 are computed for each sequence in Fig. 4. T1, SDp, and Mep are used in the argument of the F function, and the last argument is Fig. 4. Padding values as described in X are used. The Hash values derived as a function F are calculated again to transmit the sequence SHA128. T2 is the leaf node of the Target Device as an argument of G functions, that is, using the time stamp and SDp and Mep, and then transmits the double-encrypted message with SHA128, as with T1. T3, the target device to authenticate the device seeking transmission, indicates whether the sequences of each Keyed Hash match and SHA128 are set to double encrypt by all processes in order to transmit a sequence of strengthened security. The SHA128 encrypted sequence is set to the value obtained by decoding, even if the sniffing is a Hash value, and the security is a difficult surface to analogize so that the original data is strong.

4 Performance Evaluation

There are three performance evaluations. First, the authentication delay time of each platform is compared with the initial authentication and re-authentication. Second, the code size of each platform is compared with the code size before compiling the codes. Last, CoAP and the keyed hash are compared with the amount of power consumption required using the Wi-Fi module in to authenticate through a significant number of cycles.

4.1 Authentication Delay Time of Each Platform

Performance was compared to the code size of each of the platforms by measuring the speed and the effectiveness of the Keyed Hash, as confirmed through verification. Figure 4 shows the time of the initial authentication and the time required to perform the re-authentication. WolfSSL, CoAP, and MQTT exhibited a performance speed between 150,000 and 230,000 ms in Fig. 6. Further, the value stored in the certificate for re-authentication when performing according to all three protocols was reduced to a width of 50,000 m, whereas the proposed algorithm is required because it uses the Keyed Hash one-off and disposes of the authentication and re-authentication at the same time.

Fig. 6
figure 6

Authentication delay time of each platform

Full size image

4.2 Code Size of Each Platform

Table 10 shows the code size to be used only for authentication on each protocol. This has decreased to approximately 1/5 to 1/3 the size of the existing protocols code, making it lightweight.

Table 10 Code size of each platform
Full size table

4.3 Power Consumption

For calculating the power consumption of the keyed hash, we used Wireless 802.11n with the wireless LAN module for the device and the target device as shown in Table 10. We compute the TX and RX power consumption for only send and receive times, except when executing the keyed hash algorithm.

Equations (3) and (4) are that Txp and Rxp are typical values and Message/BurstTx is transmission time, N is number of messages.

TX power consumption can be given as,

$$P_{Total Tx} = Tx{p} \cdot {\frac{Message}{Burst Tx}} \cdot N$$
(3)

Let us assume that there is Tp TX power and Message authentication data and N number of messages.

The RX power consumption can be given as

$$P_{Total Rx} = Rx{p} \cdot {\frac{Message}{Continuous Rx}} \cdot N$$
(4)

A key hash is needed with two times TX and RX, as shown in Fig. 3; however, CoAP has three times TX and RX, as shown in Table 11. Here, we compare the Keyed Hash and CoAP.

Table 11 RX and TX power consumption using Wi-Fi
Full size table

4.4 Quantative Analysis

The proposed keyed hash scheme protocol, even without the presence of a Certificate Authority (CA), has the conspicuous advantage of being able to perform authentication. This is a complex procedure where the performance and power consumption are more efficient than the existing system; this occurs when you place a large specific gravity on the role of the CA. This system also has the advantage of solving some of the security problems, as shown in Fig. 7.

Fig. 7
figure 7

Compare with power consumption

Full size image

For example, if the server with the CA role is set to save all of the information about the certificate and the server is hacked, you might have a significant leak of information. If the protocol that provides this and subsequent authentication uses the quick discard method, security is enhanced. Moreover, when using an encryption algorithm in duplicate for every sequence operation, it is difficult to analogize the original data; by modifying the conventional keyed hash method for use, it is possible to provide enhanced security against hackers.

5 Conclusion

This paper suggests a new authentication protocol that enables authentication between devices in the absence of a central control server based on a keyed hash. The commonly used Hash-Tree authentication has been analyzed from various angles and applied, lending the advantages of being able to authenticate with less resources, fewer hand-shakes, and reduced information leaks in sporadic authentications. The proposed keyed hash scheme protocol without the need for the presence of a Certificate Authority (CA), has the advantage of being able to stand out an authentication. This is a complex process in which the performance and power consumption are more efficient than the conventional method in terms of the number of parts, and solves the security problems that occur when a significant amount of the weight is assigned to the role of the left CA. If the server that serves the CA and stores all of the information about the certificate is hacked, information leakage may occur, as shown in Table 12.

Table 12 Comparison of CoAP and proposed protocol
Full size table

In this protocol, the proposed method of using the waste immediately after authentication was added as additional security. In addition, it is difficult to infer the original because of the use of a Data Encryption Algorithm in every action sequence with a double, and because the existing keyed hash method is more secure from invaders. Further study is needed so that this method can be applied in diverse environments such as BLE or zigbee, which are continuously evolving. Another area of focus for future research will be the Key generator and Key distribution for the security platform.