# Secure and Efficient Authentication Scheme in IoT Environments
## 5 Evaluation
### Comparison by Performance  
In this section, we implemented the PBC library on embedded devices to calculate the primitive timing needed to measure the operational cost of the proposed scheme. In the PBC library, we implemented a pairing operation on a curve \(y^{2}=+x^{3}+x\) over the field \(F_{q}\) for some prime \(q=3\) mod 4, where both \(G_{1}\) and \(G_{1}\) are the group of points belonging to the \(E(F_{q})\). Note that SHA-256 is much more secure than other hashing algorithms and provides 2256 possible hash values, which makes it nearly impossible for two different attackers to have the exact same hash value coincidentally [45]. Therefore, we used the standard SHA-256 function to compute the cost of the general hash operation. Our experimental setup consisted of an Ubuntu 12.04 virtual machine installed on an Intel Core i5-8500 computer, with a 6-core 3.10 GHz CPU and a Windows 10 OS, provided by a service provider. In the Oracle virtual environment, we stimulated IoT devices and set RAM to 256 MB and execution cap to 26 percent (i.e., it reflects a single-core 798 MHz CPU), which is not very far from a real IoT system configuration [46]. To calculate the primitive timing of different cryptography operations used in the proposed scheme, our simulation used the pbc-0.5.14 library [10] and the GMP library [47]. Finally, we calculated and compared the operational cost of the proposed scheme and existing schemes using the PBC library to testify to the performance of the proposed scheme over existing schemes. Note that existing schemes use heavy operations such as bilinear pairings, modular exponentiation, and symmetric encryption + decryption, which are generally the most computationally expensive cryptographic operations. Therefore, we computed only such heavy operations on IoT devices and noted their respective execution times for the existing schemes. Then, we implemented the proposed scheme's code and recorded the execution time for hash and ECC operation. Table 3 summarizes the outcome of the simulation performance analysis of the PBC code, which we executed, along with the terms used to describe different cryptographic operations. The cost of detail computation is as follows:  
* Computational cost: Notice that the computing costs of lightweight operations (i.e., XOR, concatenation, and comparison) are overlooked due to their inexpensive computation. At the authentication phase, a considerable computing process is conducted. Hence, we measure the cost of the computation at the authentication phase. As depicted in Table 4, we compute some recent schemes' computation cost along with that of the proposed scheme. To compute cost, we count the number of \(T_{h}\), \(T_{cm}\), \(T_{expo}\), \(T_{pair}\), and \(T_{s}\) operations involved in the login phase, where communication happens on a public open channel. Then, for each cryptography operation, we assign the value we obtained in our PBC implementation. We evaluated all computation costs in \(ms\); however, this \(ms\) is the considerable maximum period when processing a high number of authentication requests (i.e., millions and zillions) in a real-time scenario. We also computed the computation cost of some recent schemes. Compared to the computation costs of the existing schemes, the proposed scheme is more productive by virtue of its lightweight computation power. * Communication cost: We used the parameter <q, r> of each of the size < 256, 224 > bits during the PBC-library-based primitive timing calculation; we chose this parameter since the suggested elliptic curve key length is 256 bit for NIST 2016-2030 and ECRYPR II 2031-2040. An ECC point \(X,Y=(x_{p},y_{p})\in E_{p}(a,b)\) therefore, requires (128 + 128)