Two secure authentication protocols for mitigating vulnerabilities in IoD

When developing authentication protocols for the Internet of Drones (IoD) environment, it is essential to take into account the efficient utilization of resources. In this section, we will first compare the computational costs of the proposed protocols with those of protocols^{9,10,11,22,23,24,26,27}, followed by a comparison of their communication costs and storage costs.

Table of Contents

Computational cost comparison

Table 5 shows the execution time of each operation based on the execution time used in³⁴. Smart metering in³⁴ can be used as a reference to help us compare the computational cost of the proposed schemes with other schemes. The calculations were performed on a device equipped with a 798MHz processor and 256MB of RAM, and the server was simulated on an Ubuntu 12.04 virtual machine with a 2.6GHz i5-4300 processor. To consider PUF performance evaluation,³⁴ uses a 128-bit arbiter PUF circuit on an MSP430 micro controller device with a 798 MHz processor. The timing of cryptographic operations can vary significantly due to several factors related to the hardware and software environments. Key influences include hardware specifications, such as processing power and memory speed, which directly affect execution times; software implementation efficiency, where optimized or hardware-accelerated algorithms can enhance performance; environmental factors like network latency and bandwidth, impacting operations that rely on server communication; concurrent processes that may cause resource contention; and configuration settings, including buffer sizes and algorithm parameters. Understanding these factors helps clarify the variability in operation times across different environments, facilitating a better interpretation of results.

Table 5 Execution time of different operations used in this paper (in ms)³⁴.

In²⁴, the communication cost at the drone is \(2T_{PUF} + 13T_h\) and at the user side is \(12T_h\), and at the server side, is \(17T_h\). The total execution time for the authentication phase in this scheme approximately is 1.077 milliseconds.

In²⁶, the communication cost at the drone \(T_{PUF} + 7T_h\) and at the user side is \(8T_h\) , and at the server side, is \(2T_{PUF} +11T_h\). The total execution time for the authentication phase in this scheme approximately is 0.631 milliseconds.

In²⁷, the communication cost at the drone is \(T_{PUF} +4T_{mp}+4T_h+2T_{pa}\) and and at the server side, they amount to \(5T_{mp}+5T_h+T_{pa}\). The total execution time for the authentication phase in this scheme approximately is 24.424 milliseconds.

In the scheme⁹, the drone executes six hash operations and two PUF operations. Therefore, the execution time on the drone is \(2T_{PUF}+6T_h \approx 0.396 ~ms\). The user executes eight hash operations. Therefore, the execution time on the user side is \(8T_h \approx 0.208\) ms. Similarly, the server performs six hash operations, with a time of \(6T_h \approx 0.066\)ms. Thus, the total execution time of the scheme⁹ approximately is 0.67 ms.

In the proposed protocol (a), the drone executes eight hash operations and two PUF operations. Therefore, the execution time on the drone is \(2T_{PUF}+8T_h \approx 0.448\) ms. The user also executes 12 hash operations, resulting in an execution time of \(12T_h \approx 0.312\) ms on the user side. Similarly, the server performs eight hash operations, with a time of \(8T_h \approx 0.088\) ms. Thus, the total execution time required for the computations in the proposed protocol (a) approximately is 0.848 ms.

In the proposed protocol (b), the drone executes eleven hash operations and two PUF operations. Therefore, the execution time on the drone is \(2T_{PUF}+11T_h \approx 0.526\) ms. The user also executes 15 hash operations, resulting in an execution time of \(15T_h \approx 0.39\) ms on the user side. Similarly, the server performs twelve hash operations in a time of \(12T_h \approx 0.132\) ms. Thus, the total execution time required for the computations in the proposed scheme (b) approximately is 1.048 ms.

The execution time for the schemes^{9,10,11,22,23} is calculated in a similar way, with the results presented in Table 6.

Table 6 Comparison of computation cost (in ms) of proposed schemes with similar recent schemes.

Figure 14 shows the computational cost comparison of the proposed schemes with recent similar schemes.

Communication cost comparison

First, we give the basic definition of communication cost, which is equal to the number of bits sent on the communication channels by entities present in each session. The lower the number of these bits, the lower the network traffic and the higher the transfer speed.

A comprehensive evaluation of communication costs of proposed protocols is conducted based on key metrics, namely the quantity and size of exchanged messages.

The number of exchanged messages for the proposed scheme and schemes^{9,10,11,22,23,24,26,27} was counted as described below. In the Tahavor et al. protocol³⁵, we assumed \(32-\text {bit}\) timestamp \(B_t\), \(128-\text {bit}\) Pseudonymous identity \(B_{id}\), \(128-\text {bit}\) random numbers \(B_r\), \(160-\text {bit}\) SHA-1 hash function \(B_h\), \(160-\text {bit}\) PUF challenge-response pair \(B_p\), and \(128-\text {bit}\) fuzzy extractor output \(B_f\), and \(320 ~\text {bits}\) for the elliptic curve point \(B_e\). We also used conventional values for further calculations, including \(256-\text {bit}\) chaotic map \(B_{cmap}\), \(160-\text {bit}\) private key \(B_{pr}\), and \(320-\text {bit}\) public key \(B_{pu}\). Additionally, based on calculations in¹⁰, two values were uniquely used: \(128-\text {bit}\) ciphertext \(B_{ct}\) and a variable-length \(T_{R_a} (SP_{11})\) that could be either \(288 ~\text {bits}\) or \(416 ~\text {bits}\), depending on its content. The bit lengths of the parameters used in the communication cost comparison are shown in the Table 7.

Table 7 The bit lengths of the parameters used in the communication cost comparison.

Tanveer et al.¹⁰’s scheme involves three message exchanges for authentication and access to the drone. These messages have sizes of \(576~ \text {bits}\), \(608 ~\text {bits}\), and \(320~ \text {bits}\), resulting in a total message size of \(1504 ~\text {bits}\). Irshad et al.¹¹’s scheme involves three message exchanges as \(\langle W_{u_i},Cert_{u_i}^+,R_1^ \prime ,SID_{u_i}^*,Q_{u_i},TS_1\rangle\), \(\langle W_{u_i}^*,X_i,Cert_{CN_j}^ \prime ,R_1^\prime ,D_{u_i}, TS_1,TS_2\rangle\) and \(\langle Cert_{SD_k}^+,N_{SD_k},R_2^ \prime ,SKV,W_{u_i}^*,TS_2,TS_3\rangle\). The first message, comprising a \(128-\text {bit}\) ciphertext \((W_{u_i })\), \(Cert_{u_i}^+\) comprises various components: a private key, two elliptic curve multiplications contributing 1120 bits in total, \(R_1^ \prime\) is an elliptic curve multiplication which occupying \(320 ~\text {bits}\), \(SID_{u_i}^*\) is a pseudonymous identity with \(160 ~\text {bits}\), \(Q_{u_i}\) is the output of a hash function and is equivalent to \(160 ~\text {bits}\) and finally \(TS_1\) is a \(32-\text {bit}\) timestamp, resulting in a total message size of \(992~ \text {bits}\). The second and third messages, respectively, require \(1024~ \text {bits}\) and \(1184 ~\text {bits}\). Thus, the overall size of all messages in¹¹’s scheme is \(3200 ~\text {bits}\). In²⁴, the transmitted messages are \(Msg1 = \{{PID}_i, M_1, M_2, V_1, T_1\}\), \(Msg2 = \{M_3, M_4, V_2, T_2\}\), \(Msg3 = \{M_5, M_6, V_3, T_3\}\), and \(Msg4 = \{M7, V4, T4\}\). Therefore, the communication cost for this scheme equal with \({Msg1} =\)\(160 + 160 + 160 + 160 + 32\)\(= 672~\text {bits}\), \({Msg2} =\)\((160 + 160) + 160 + 160 + 32\)\(= 672 ~\text {bits}\), \({Msg3} =\)\((160 + 160) + 160 + 160 + 32 = 672\) bits, and \({Msg4} = 160 + 160 + 32 = 352\) bits. Thus, the total communication overhead during authentication is \(672 + 672 + 672 + 352 = 2368\) bits as shown in Table 8.

In²⁶, the transmitted messages are \({M_1} =\)\(\{\text {PID}_u, C_g, X_1,\)\(X_2, T_1, I_1\}\), \({M_2} =\)\(\{\text {PID}_d, \text {PID}_u,\)\(C_d, X_3, X_4, T_2, I_2\}\), and \({M_3} =\)\(\{\text {PID}_d, X_5, T_3, I_3\}\). Therefore, the communication cost for this scheme equal with \({M_1} =\)\(160 + 160 + 160\)\(+ 160 + 32 + 160\)\(= 832\) bits, \({M_2} =\)\(160 + 160 + 160 + 160\)\(+ 160 + 32 + 160 = 992\) bits, and \({M_3} =\)\(160 + 32 + 32 + 160\)\(= 384\) bits. Thus, the total communication overhead during authentication is \(832 + 992 + 384\)\(= 2208\) bits, as shown in Table 8.

In²⁷, the transmitted messages are \({D_{req}} =\)\(\{{PID}_i, D_1, D_2, D_3\}\), \(G_{Res} =\)\(\{G_2, G_4,\)\(G_5, G_6, T_1\}\), and \({D_{Auth1}} =\)\(\{{PID}_j, D_5, D_6, T_3\}\). So, the communication cost for this scheme is \({D_{req}} =\)\(160 + 320 + 320 + 320\)\(= 1120~\text {bits}\), \({G_{Res}} =\)\(160 + 320 + 160 + 160 + 32\)\(= 832~\text {bits}\), and \({D_{Auth1}}\)\(= 160 + 320 + 160 + 32 = 672 ~\text {bits}\). Thus, the total communication overhead during authentication is \(1120 + 832 + 672 = 2624~\text {bits}\).

In⁹’s scheme, the drone sends one message and receives two messages, the user sends three messages and receives two messages, and the server sends one message and receives one message. These five messages are \(\langle A_1^*,C_j^{new},T_1\rangle\), \(\langle M_1,M_2,T_2\rangle\), \(\langle M_3,M_4,HDID_j,T_2,T_3\rangle\), \(\langle M_5,M_6,M_7,T_4\rangle\), and \(\langle M_7,M_8,T_4,T_5\rangle\), which include ten hash functions, an identity, seven time stamps, and a PUF function challenge. Therefore, the total size of these messages is \((10\times 160)+(1\times 160)+(7\times 32)+(1\times 160)=2144 ~\text {bits}\).

In the proposed scheme (a), the messages are \(\langle A_1^*,C_j^{new},T_1\rangle\), \(\langle M_1,M_2,Z_1,T_2\rangle\), \(\langle M_3,M_4,HID_i,Z_2,T_2,T_3\rangle\), \(\langle M_5,M_6,M_7,Z_3,T_4\rangle\), and \(\langle M_7,M_8,Z_4,T_4,T_5\rangle\). Notably, by including the values of \(Z_1, Z_2, Z_3\) and \(Z_4\), four additional hash functions have been incorporated into the transmitted items. The remaining values consist of an identity, seven timestamps, and a challenge for the PUF function. In total, the size of all messages exchanged in the proposed scheme (a) equals to \((14 \times 160) + (1 \times 160) + (7 \times 32) + (1 \times 160) = 2784 ~\text {bits}\).

In scheme (b), the messages exchanged include \(\langle A_1^*,\)\(C_j^{new},T_1\rangle\), \(\langle M_1,\)\(M_2,Z_1,T_2\rangle\), \(\langle M_1,M_2,M_3,M_4,\)\(Z_1,Z_2, HID_i,T_2,T_3\rangle\), \(\langle M_5,M_6,\)\(M_7,Z_3,T_4\rangle\) and \(\langle M_7,M_8,M_9,\)\(Z_4,T_4,T_5\rangle\). The total communication cost is calculated based on the transmission of 18 hash functions, one identity, seven timestamps, and one challenge for the PUF function. This results in a total of \((18\times 160)+(1\times 160)+(7\times 32)+(1\times 160)=3424~ \text {bits}\). The communication cost for schemes^22,23 is similarly computed, and the findings are presented in Table 8.

Table 8 Communication cost comparison (in bits) of proposed schemes with similar recent schemes.

Figure 15 shows communication cost comparison (in bits) of proposed schemes with recent similar schemes.

After conducting security evaluations and comparing the proposed schemes with similar ones, we found that the schemes (a) and (b) incur higher communication and computational costs. Nevertheless, considering their robustness against various known attacks and the partial vulnerability of the other schemes to these threats, the rise in costs can be regarded as minimal.

Storage cost comparison

This section compares the memory requirements for storing essential parameters in the devices (for the schemes^{9,10,22,24,26,27} drone and IoT devices for schemes^11,23) and the drone for our proposed schemes. Table 9 summarizes the results.

In¹⁰’s scheme, the data elements \(\langle SID_j,DSK_j,GID_k\rangle\) are stored in the drone’s memory where \(SID_j\) is a pseudonymous identity of \(160~\text {bits}\), \(DSK_j\) is a private key of \(160~\text {bits}\), and \(GID_k\) is another identity of \(160~ \text {bits}\). Consequently, the total storage requirement for¹⁰’s scheme is also \(480~\text {bits}\).

Irshad et al.¹¹’s scheme stores the following values in IoT device memory: \(SID_{SD_k}\) and \(ID_{CN_j}\) are two \(160-\text {bit}\) pseudonyms for identification and authentication, \(N_{CN_j}\) is a \(320-\text {bit}\) elliptic curve point multiplication result, \(Pr_{SD_k}\) is a \(160-\text {bit}\) private key and \(Pub_{SD_k}\)is a \(320-\text {bit}\) public key, \(N_{SD_k}\) is another \(320-\text {bit}\) elliptic curve point multiplication result, \(Cert_{SD_k}\) is a \(160-\text {bit}\) and \(K_{{SD_k},CN_j}\) is a \(160-\text {bit}\) hash function output respectively. Based on these values, the total required storage is \(1760~\text {bits}\).

In²²’s scheme, the \(\langle \alpha _j,PID_j\rangle\) are stored in the drone’s memory, which \(\alpha _j\) is a \(160-\text {bit}\) hash function output and \(PID_j\) is a pseudonymous identity of a drone that is equal to \(160~\text {bits}\). Based on the specified values, the total required storage is \((2 \times 160)=320~\text {bits}\).

Gupta et al.²³’s scheme stores the values in the wearable device as \(\langle e_j,x_j,f_j,MI_u,MGID_i\rangle\) where \(e_j\), \(x_j\) and \(f_j\) are three \(160-\text {bit}\) hash function outputs. \(160-\text {bit}\) pseudonymous identities of user and gateway are denoted as \(MI_u\) and \(MGID_i\), respectively. So, based on the specified values, the total required storage is \((5 \times 160)=800~\text {bits}\).

In²⁴, the drone stores only \(\{PDID_j, b_j\}\), which is equal to \(\{160 + 160 = 320~\text {bits}\}\). The drone in²⁶, stores \(ID_g\), \(ID_d\), and MK, along with an emergency list of essential secrets, which is equal to: \(\{2 \times (160 + 160 + 160) = 960~\text {bits}\}\). In²⁷, the drone stores the values \(\{PUF(.), ID_i, Ch_i, D_1, D_2, D_3, D_4\}\) in its memory, which is equal to \(\{160 + 160 + 320 + 320 + 320 + 160 = 1440 ~\text {bits}\}\).

In the scheme presented in⁹, the data \(\langle B_1,HDID_j,GID_i\rangle\) are kept in the drone’s memory, where \(B_1\) is a hash function output of \(160~\text {bits}\), \(HDID_j\) represents the drone’s pseudonymous identity of \(160~\text {bits}\), and \(GID_i\) denotes a gateway node identity of \(160~\text {bits}\). This results in a total memory requirement of \((3 \times 160)=480~\text {bits}\). Even with the enhanced security features of the improved protocol (a), the storage requirement for the drone remains the same as in⁹’s scheme. Likewise, the proposed protocol (b) also necessitates an equivalent amount of memory as both⁹’s scheme and improved protocol (a).