## 3 The Proposed Fog-Based MQTT Architecture with an Authentication Scheme
### Authentication System
#### 3.2.2 Lightweight Authentication Scheme  
The authentication scheme comprises two main phases: registration and authentication. The complete steps of the authentication scheme are illustrated in Figure 8, and all notations used in the scheme are listed in Table 3. In the registration phase in which the channel is assumed to be secure, the identity of C (ID\({}_{\text{C}}\)) and the identity of [PERSON] (ID\({}_{\text{B}}\)) are sent to the AM with which [PERSON] is associated. Then, the AM generates the authentication parameters for both C and B. These parameters contribute to initializing the mutual authentication process between C and B. In the authentication phase, since the connection in the traditional MQTT must be directly established from the client to the broker by sending the client ID, the authentication in our proposed architecture starts by sending the CONNECT message. Thus, C is required to send some authentication parameters to B, including its ID\({}_{\text{C}}\), which is wrapped with ID\({}_{\text{B}}\) in the XOR operation. [PERSON], in turn, extracts ID\({}_{\text{C}}\) and passes the parameters to the AM to authenticate C. The AM then generates and sends other authentication parameters to C and B, which should acknowledge the authenticity of these parameters. After this, a mutual authentication is conducted between C and B. At the end, a session key is generated by C to secure the communication between C and B. \begin{table}
\begin{tabular}{c c} \hline \hline
**Symbol** & **Description** \\ \hline C & Client (publisher, subscriber, or broker acting as a client) \\ \hline B & Broker \\ \hline AM & Authentication manager \\ \hline ID\({}_{\text{C}}\) & Identity of client \\ \hline ID\({}_{\text{B}}\) & Identity of broker \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Notation used in the authentication scheme. Figure 7: General interaction of the authentication scheme. Figure 8: Authentication scheme’s steps. \begin{table}
\begin{tabular}{c c} \hline \hline
**Symbol** & **Description** \\ \hline \(\text{AID}_{\text{C}}\) & Alias ID of client \\ \hline \(\text{AID}_{\text{B}}\) & Alias ID of broker \\ \hline SN & Secret number \\ \hline Na & Nonce \\ \hline R1, R2, R3, R4 & Random number \\ \hline MK1 & Master key 1 \\ \hline MK2 & Master key 2 \\ \hline MID\({}_{\text{C}}\) & Master identity of client \\ \hline MID\({}_{\text{B}}\) & Master identity of broker \\ \hline SK\({}_{\text{AM}\_\text{C}}\) & Secret key between AM and C \\ \hline SK\({}_{\text{AM}\_\text{B}}\) & Secret key between AM and B \\ \hline K-Sc\({}_{\text{C}\_\text{B}}\) & Session key between C and B \\ \hline H(.) & One-way hash function \\ \hline \(\oplus\) & XOR operator \\ \hline \(\|\) & Concatenation \\ \hline Ci, Verifier & Ciphers \\ \hline \hline \end{tabular}
\end{table} 
Table 3: _Cont._* Registration Phase In the registration phase, C and the corresponding B share their IDs with the AM. After receiving both IDs, the AM generates and sends authentication parameters for C and B independently. It is assumed that all messages in the registration phase are exchanged through a secure channel. Upon receiving ID\({}_{\text{C}}\) and ID\({}_{\text{B}}\), the AM creates the following parameters for both C and B: alias identities (AID\({}_{\text{C}}\) and AID\({}_{\text{B}}\)) using SN, master identities (MID\({}_{\text{C}}\) and MID\({}_{\text{B}}\)) using MK1, and secret keys (SK\({}_{\text{AM}\_{C}}\) and SK\({}_{\text{AM}\_{B}}\)) using MK2.