# An Enhanced Lightweight IoT-based Authentication Scheme in Cloud Computing Circumstances
## 4 Security Analysis and Performance Evaluation
### Computational-cost Comparison  
This sub-section presents the performance evaluation of the proposed scheme with [PERSON] et al. 's scheme, [PERSON] et al. 's scheme and [PERSON] et al. 's scheme in terms of execution-time. The evaluation of each scheme was based on the following considerations: \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Security Property** & **[PERSON] et al.** & **[PERSON] et al.** & **[PERSON] et al.** & **Our Scheme** \\ \hline Provide evidence of connection attempt & fails & fails & fails & success \\ Provide mutual authentication & fails & fails & fails & success \\ Provide user anonymity & fails & & success \\ Resist impersonation attack & fails & fails & fails & success \\ Resist off-line user identity/password attack & fails & & success \\ Resist privileged-insider attack & fails & fails & success \\ Resist replay attack & & & fails & success \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Security comparison. * \(T_{h}\) represents a hash function. * \(T_{S}\) represents an encryption/decryption operation using AES algorithm. * The execution time for \(T_{h}\) is case 1: 0.00517 ms [30] and case 2: 0.0000328 ms [32]. * The execution time for \(T_{S}\) is case1: 0.02148 ms [30] and case2: 0.0214385 ms [32]. Table 3 summarizes the operations carried out by \(U_{i},~{}S_{j}\) and \(CS\) during the registration, login and authentication phases. The execution time required by \(U_{i},~{}S_{j}\) and \(CS\) during each phase is shown in Table 4.  
From Table 3, it is easy to see that our scheme requires more computational operations than previous works. However, it is necessary to compute the execution-time in a real scenario. For that reason, we used the execution-time described in [30] and [32] to compare the performance of each scheme. The execution-time results are shown in Table 4, and it is clear that the execution time depends on: (a) the characteristics of each device, (b) the cryptography libraries and (c) the computational load. In our scheme, \(CS\) is the participant which computes more computational operations because we assume that has more resources than \(U_{i}\) and \(S_{j}\). Moreover, \(U_{i}\) computes more computational operations than \(S_{j}\) because we assume that \(U_{i}\) will request few connections per day; however, \(S_{j}\) will receive many request for connection, considering a high volume of users it is necessary that \(S_{j}\) computes few computational operations. According with the results summarized in Table 4, the scheme with les computational operations was proposed by [PERSON] et al. [1]. In fact, the execution time of each device must be considered as show in Table 4. The computational operations evaluated using case 2 gives better results than case 1. Under this situation, our scheme requires 40% less time which represents an acceptable performance, less than 0.1862 ms [30]. Figure 7 shows the computational-cost comparison by participant and scheme. In this case, we used the execution-time of the case 1. The main difference between our scheme and previous works is the inclusion of symmetric operations during the authentication phase. The symmetric operations are used to provide mutual authentication between \(U_{i}\) and \(S_{j}\), increasing the security of the proposed scheme.