## 3 Our Construction
### The Proposed Scheme
#### 3.1.4 Authentication  
1. First, the manager sends \(t_{i}\in\mathbb{Z}_{q}^{n}\) to \(\textit{user}_{i}\). 2. After receiving \(t_{i}\), \(\textit{user}_{i}\) computes \(\mathbf{d_{B_{i}}}=\text{SampleD}\big{(}\mathbf{\omega_{B_{i}}},\ s,\ 0,\ t_{i}\big{)}\), and then chooses a number \(r_{i}\) randomly, and computes \(k_{i}=H\big{(}\mathbf{\omega_{B_{i}}}\big{)}\), \(a_{i}=E_{k_{i}}\big{(}\mathbf{d_{B_{i}}},\ r_{i}\big{)}\). 3. The \(\textit{user}_{i}\) sends \(a_{i}\) to the manager. 4. After receiving \(a_{i}\) from each user, the manager performs the following: for \(i=1\) to \(Q^{\prime}\), the manager computes \(\big{(}\mathbf{d_{B_{i}}},\ r_{i}\big{)}=D_{H(\mathbf{\omega_{B_{i}}})}(a_{i})\) and \(\mathbf{F_{B_{i}}}=[A||(Acc_{x}-\mathbf{B_{i}})]\in\mathbb{Z}^{n\times(m+m^{\prime})}\), then checks if \(\mathbf{F_{B_{i}}}\mathbf{d_{B_{i}}}=t_{i}\ \text{mod}\ q\). If the check passes, the user is authenticated; otherwise, the manager aborts the session. 5. Next, the manager performs as follows according to \(Q^{\prime}\). **Case 1** (\(Q^{\prime}>1\)):  
1. First, the manager computes \(R_{i}=r_{1}\oplus r_{2}\oplus\ldots\oplus r_{i-1}\oplus r_{i+1}\ldots\oplus r _{Q^{\prime}}\) for \(i=1\) to \(Q^{\prime}\), \(\textit{sk}=r_{1}\oplus r_{2}\oplus\ldots\oplus r_{Q^{\prime}}\), \(k_{i}=H\big{(}\mathbf{\omega_{B_{i}}}\big{)}\), and \(b_{i}=E_{k_{i}}(\textit{sk}\,\ R_{i})\). 2. The manager sends \(b_{i}\) to each \(\textit{user}_{i}\). 3. After receiving \(b_{i}\), \(\textit{user}_{i}\) computes \(\big{(}\textit{sk}^{\prime}\,\ R_{i}^{\prime}\big{)}=D_{ki}(b_{i})\), and then checks if \(\textit{sk}^{\prime}=R_{i}^{\prime}\oplus r_{i}\). If it is true, the manager is authenticated. Then, \(\textit{user}_{i}\) sets the session key \(\textit{sk}=\ \textit{sk}^{\prime}\). **Case 2** (\(Q^{\prime}=1\)):  
1. First, the manager chooses a number \(r^{\prime}\) randomly. 2. Then, the manager computes \(k_{i}=H\big{(}\mathbf{\omega_{B_{i}}}\big{)}\), \(b=E_{k_{i}}(r^{\prime}\,\ H(r_{i}))\) and the manager sends \(b\) to \(\textit{user}_{i}\). 3. After receiving \(b\), \(\textit{user}_{i}\) computes \((r^{\prime},\ h)=D_{ki}(b)\). The \(\textit{user}_{i}\) checks if \(h=\ H(r_{i})\). If it is true, the manager is authenticated. Then, \(\textit{user}_{i}\) sets the session key \(\textit{sk}=r^{\prime\prime}\oplus r_{i}\). **4. Security Analysis**  
* In this section, we provide the security analyses, which include the analyses on the replay attacks, the man-in-the-middle attacks, and the secure mutual authentication, where the detailed security proofs are shown in Appendix A. Replay Attacks: In the proposed scheme, each user chooses a number \(r_{i}\) randomly and sends \(r_{i}\) to the manager. The random number \(r_{i}\) is different in every authentication round. Hence, there is no chance that an attacker can succeed in replay attacks in the proposed scheme. * Man-in-the-Middle Attacks: In the proposed scheme, we use a secure symmetric encryption algorithm to encrypt data in every data flow of the authentication phase. If there is an attacker wanting to intercept messages \(a_{i}\) or \(b\), there is no chance that the attacker can obtain the plaintext without the symmetric key. In Steps 1-4 of the authentication phase, \(d_{B_{i}}\) and \(r_{i}\) are protected by the secret key \(k_{i}\), and in Step 5 of the authentication phase, \(\textit{sk}\), \(R_{i}\), \(r^{\prime}\), and \(H(r_{i})\) are protected by the secret key \(k_{i}\), too. The comparisons of features and security between the proposed scheme and [3; 4] are summarized in Table 2. \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Moustaine et al.’s Scheme** & **Park et al.’s Scheme** & **Our Scheme** \\ \hline Mutual Authentication & Yes & Yes & Yes \\ Group Authentication & No & No & Yes \\ No Replay Attack & Yes & Yes & Yes \\ No Man-in-the-Middle Attack & Yes & Yes & Yes \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Feature and security comparisons.