## 5 Analyses
### Security and Privacy-Preservation Analyses
The recipients, RSUs or vehicles will have to check the freshness of the message, and once the timestamp is invalid the message is discarded. As such the proposed scheme, ECLAS, could resist against replay attack. * Modification Attack Resilience: In the scheme a valid message \((ID_{i},Q_{ID_{i}},\mathit{vpk}_{i},M_{i},t_{i},\sigma_{i})\) has a valid digital conditional anonymous signature \((ID_{i},\sigma_{i})\). Any modification to the message \((ID_{i},Q_{ID_{i}},\mathit{vpk}_{i},M_{i},t_{i},\sigma_{i})\) can be detected during verification \(S_{i}.P=h_{i}.R_{i}+\mathit{vpk}_{i}+Q_{ID_{i}}+h_{i,0}.P_{\mathit{vpb}}\) which simultaneously authenticates the sender, \(V_{i}\), and the TA side of TRA and KGC. Therefore, the proposed ECLAS scheme stands against modification attack. * Impersonation Attack Resilience: It is not feasible for an attacker to launch a successful impersonation on the message \((ID_{i},Q_{ID_{i}},\mathit{vpk}_{i},M_{i},t_{i},\sigma_{i})\) of which can pass verification as if it was generated by a legal user \(V_{i}\). However, it is impossible for an attacker to obtain the KGC's master key \(\alpha\) and the users private key \(x_{i}\) from the publicly accessible parameters as it will involve solving the intractable problems of ECDLP and ECCDHP from \(\mathit{vpk}_{i}=x_{i}P\) and \(P_{pub}=\alpha P\). * Stolen Verifier Table Attack Resilience: In the proposed ECLAS scheme, both the TA side, which comprises of TRA and KGC and the user side, which comprises of RSUs and OBUs on the vehicle do not require a check list. This implies resistance against stolen verification table attack as it means the table can not be stolen. * Key-Escrow Resilience: Although the TAs side has access to the master keys used for generating the user's partial private key, still more neither TRA nor KGC can generate a valid signature \(\sigma_{i}=(R_{i},Si)\) for a valid message \((ID_{i},Q_{ID_{i}},\mathit{vpk}_{i},M_{i},t_{i},\sigma_{i})\). This is due to the fact that, the vehicle adds a secret value \(x_{i}\) to the partial private key \(\mathit{psk}_{i}\) when computing its full private key \(\mathit{sk}_{i}=x_{i}+d_{i}+H_{2}(ID_{i}||Q_{ID_{i}})\alpha\), which is used for signing messages. To this effect although TRA knows the master key \(\beta\) and KGC knows the master key \(\alpha\) for the systems, they cannot forge messages to masquerade as \(V_{i}\) illegally. Thus, the proposed ECLAS scheme withstands the key escrow attacks. Now we will present a comparison analysis of ECLAS with recent related works in terms of security features satisfied. In Table 2 the results of the comparison is provided with the features coded as, SF-1, SF-2, SF-3, SF-4, SF-5, SF-6 to denote, integrity and authentication, anonymity, traceability and revocability, unlinkability, key escrow problem and resistance to common attacks respectively. In the Table 2 the symbol \(\checkmark\) denotes the satisfaction whereas \(\checkmark\) denotes not satisfaction of the security feature. As shown by the comparison table, the schemes in [47; 53; 54] fall short from fulfilling some of the features. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Security** & **Alazzawi** & **Bayat** & **[PERSON]** & **ECLAS** \\
**Feature** & **et al.**[47] & **et al.**[53] & **et al**[54] & \\ \hline
**SF-1** & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) \\
**SF-2** & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) \\
**SF-3** & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) \\
**SF-4** & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) \\
**SF-5** & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) \\
**SF-6** & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) & \(\checkmark\) \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Comparison Analysis of Security Features Satisfied.