## 7 Results
### Performance Analysis  
Table 4 shows the performance analysis of various session keys generated during the hash-chain fog/edge protocol experiments. These keys present the independent time analysis for each key time required to be generated in the protocol message. It can thus be predicted that millions of keys can be generated in several fogs using a parallel working environment to authenticate several devices within the university/organization. Figure 4 presents the time generation analysis of session keys \(K_{s,c}\), \(K_{c,s}\), and updated \(K_{s,c}\). It shows the detailed time generation of every key separately. These keys are calculated based on \(K_{s,c}=H(T_{s}\oplus\lambda_{s}),K_{c,s}=H(T_{c}\oplus\lambda_{c})\), and updated \(K_{s,c}=H(T_{s}\oplus\lambda_{s})\). Figure 4 shows the performance comparison of session keys \(K_{s,c}\), \(K_{c,s}\), and updated \(K_{s,c}\). No major difference was observed within the session key time generation comparison, and it was also found to be effective for several operations on the workstation. Figure 5 shows the session key generation time on the workstation, AWS Cloud, and Raspberry Pi each for Session Key 1, Session Key 2, and Session Key 3 in detail. These keys are presented to be compared in detail for the three different platforms. The cloud session key generation time was slightly faster as compared to the workstation, whereas the Raspberry Pi had a much lower rate of performance due to the limited amount of configurations compared to the other platforms. Even though the cloud performed faster, still the communication time of the keys with the edge devices may suffer. Thus, a workstation can be recommended for better authentication performance as a fog server _FS_. A similar performance can still be achieved with the Raspberry Pi when the fog network consists of only IoT devices. \begin{table}
\begin{tabular}{l l l l} \hline \hline
**System Environment** & **Server, Workstation** & **AWS Cloud** & **Raspberry Pi (SB+)** \\ \hline System Hardware & Intel Core i5 @ 3.10 GHz & T2 micro @ 2.5 GHz & Arm v8 @ 1.4 GHz \\ \hline Primary Memory & 16 GB & 1 GiB & 1 GB SDRAM \\ \hline Operating System & Ubuntu 16.04 & Amazon Linux 2 AMI & Ubuntu Server 19 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Experimental setup. \begin{table}
\begin{tabular}{l l} \hline \hline
**System** & **Library** \\ \hline AWS Cloud / Workstation (Server) & Random, hashlib, datetime and numpy. \\ \hline Raspberry Pi & Random, hashlib, datetime, socket and JSON. \\ \hline Contiki Cooja Simulator &
\begin{tabular}{l} \textless{}stdio.h\textgreater{}, \textless{}stdlib.h\textgreater{}, \textless{}string.h\textgreater{}, \textless{}tontik.h\textasci{}, \textasci{}net/rime.h\textasci{}, \\ “lib/list.h\textasci{}”, “lib/memb.h\textasci{}”, “dev/button-sensor.h\textasci{} and “dev/led.h\textasci{}. \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Libraries used in the different systems. Figure 6 presents the independent protocol performance times. As discussed earlier, the behavior across the architecture varies, and we can notice from the figure that, in the case of the workstation and Raspberry Pi, the total protocol time was quite similar and was seen to be adapting as the number of authenticating nodes increased. In the case of the cloud, the protocol authenticating time was seen to be quite balanced, as the execution was reinitialized across the infrastructure. In Figure 7, we checked the hash-chain \begin{table}
\begin{tabular}{l l} \hline \hline
**Session Key** & **Generation Time in s (100 Keys Each)** \\ \hline \(K_{s,c}\) & 0.0080812 \\ \(K_{s,s}\) & 0.00739694 \\ Updated \(K_{s,c}\) & 0.00851083 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Session key performance analysis. Figure 4: Time generation analysis of session keys.