## 3 Materials and Methods
### Authentication Phase  
In this phase, a user \(C\) as a registered entity becomes eligible to utilize the facilities within that organization/university, where \(C\) is physically present. As shown in Figure 3a, the tree structure presents accessibility branches and sub-branches for solving the problem of ZKP for the authentication process. The challenge model contains 16 \(\times\) 4 tree nodes, generated by a pseudo-random number generator _PRNG_. Each grey/child node contains a  
Figure 2: System model for the hash-chain fog/edge protocol. unique 2 \(\times\) 2 matrix that can be accessed in a tree form starting from the root node. The tree traversal simplifies the ease of access to all the parts of the balanced tree. Each child node has a 2 \(\times\) 2 matrix given by Figure 3b, which are the transition vales w, x, y, z in the graph. These transition values are the process elements for completing the hash-chain protocol, which is simultaneously registered in the hash-chain flow for the record logs of every client \(C\)'s authentication. In other words, completing the graph transition of a particular matrix represented as a node within the challenge model tree helps to achieve the authentication successfully between _FS_ and \(C\). Furthermore, every block has a set of a matrices that is reset every time for a new authentication phase. Figure 3c shows the hash-chain flow, which is created as a part of every hash-chain protocol used for authentication. The hash-chain flow is used to store the transition record logs between the authenticating entities, which can be later referred to for the log auditing process. The root node is created in Step 4 of the hash-chain protocol, consisting of the hash of a unique transition value with its timestamp. The root node's hash value is then combined (XOR) with the next transition value and a timestamp for generating the second hash (\(K_{c,s}\)) in Step 5 Similarly, the third hash combines the successive transition value with a timestamp with the previous second hash in Step 6, indicating the completion of the authentication protocol. In that case, the client \(C\) does not succeed in the first challenge, then \(C\) has to complete a new challenge in Mode 1 and later, if un-successful, in Mode 2. \[\textbf{Mode 1}:D=(A\times B)^{-1}\times C^{T} \tag{1}\]  
In Equation (1), _FS_ sets one of the blocks as in Mode 1. User \(C\) has to find the block exactly D by calculating the Mode 1 challenge and respond with the values according to the hash-chain protocol. \[\textbf{Mode 2}:D=A^{T}\times(B\times C)^{-1} \tag{2}\]  
Similarly, for Equation (2), _FS_ sets one of the blocks as Mode 2. Therefore, the respective user \(C\) has to find block D and respond to the values according to the hash-chain protocol. In Figure 3, we can see that for every authentication of the corresponding user \(C\), a hash-chain is created that helps to maintain the validity of ZKP. This hash-chain process is kept private on the fog server _FS_, and hence, it will not be possible for the user \(C\) to independently generate it. The first hash1 is taken by the _FS_ by including its hash timestamp \(t_{s}\) XOR with the transition edge of the selected block matrix \(\lambda_{s}\). The previous hash1 value is then XORed with the new set of users \(C\) (\(t_{\varepsilon}\)_XOR_\(\lambda_{c}\)) for whom hash2 is generated. hash2, in the same way, is XORed with _FS_ (\(t_{s+1}\) XOR \(\lambda_{s+1}\)), for whom hash3 is generated. The following protocol steps are explained in detail in Figure 2[38] with the notations:  
1. Each client \(C\) before setting up an authentication first needs to confirm its identity with the authentication server _AS_ by sending its identity \(I_{c}\) and public key _PK\({}_{c}\)  
Figure 3: Challenge model. (**a**) Balanced tree with a superfluous sub-branch having 4 \(\times\) 4 nodes. (**b**) Directed graph transition matrix in each node. (**c**) Hash-chain flow. \[C\to AS:I_{c}||PK_{c};\]
2.