# A Lightweight and Practical Anonymous Authentication Protocol Based on Bit-Self-Test PUF
## 5 Implementation and Analysis
### Implementation and Analysis of the Protocol
We use SPONGENT-128/256/128 to hash the robust response \(r_{c}\) to generate a 128-bit key \(k\). The generated keys are tested by NIST and the results show that after 15 sets of tests, the \(p\)-value is greater than 0.01, which indicates that the keys have passed all experiments in the NIST Statistical Test Suite. We control the operation of \(TRNG\) by generating true  
Figure 8: \(KEY.Ext/KEY.Rec\) model. random numbers in the PL part of the Zynq-7000 SoC XC7Z010 FPGA using the method described in the reference [40], which enforces a sub-stable state on the flip-flop through closed-loop feedback control. While having good randomness, the \(TRNG\) has a very low hardware overhead, making it ideal for generating random numbers in a lightweight authentication protocol. The \(PRF\) and \(PRF^{\prime}\) are based on the pseudorandom number function designed by the SIMON block cipher in [32]. According to the requirements of the proposed protocol authentication process, we selected SIMON128/128 for the \(PRF\) and encryption operations. Table 1 shows the execution overhead required for each module of the protocol execution once and the total execution overhead on the device for the whole authentication process. Tables 2 and 3, respectively, show the comparison between the proposed protocol and past schemes in terms of various security properties and hardware overhead. Although the overhead of [6] has a small advantage over the proposed protocol, it lacks the very important feature of mutual authentication. Furthermore, the protocol in [6] is resistant to modeling attacks, but the protocol has weak forward security and the protocol is also less resistant to DoS attacks. As analyzed in Section 4, our proposed scheme satisfies all the important security features required, achieves mutual authentication, and performs the protocol process as it uses the temporary IDs in every round, which can be used as antitracking, while having good forward secrecy and backward security as well; furthermore, the proposed protocol has the ability to handle the problem of desynchronization, providing the ability to resist DoS attacks while ensuring the session security. Moreover, the resource overhead on the device of this protocol is 870 LUTs and 547 registers, which is a great advantage in terms of security and overhead compared to the recent PUF-based lightweight authentication protocols. As shown in Table 4, when we implement the protocol using the Zynq-7000 SoC XC7Z010 FPGA (Xilinx, San Jose, CA, USA) board with a 6-core 3.4 GHz AMD 2600 (AMD, \begin{table}
\begin{tabular}{c c c} \hline \hline
**Module** & **LUTs** & **Registers** \\ \hline PUF & 150 & 47 \\ KEY.E/R & 241 & 165 \\ TRNG & 128 & 12 \\ PRF & 267 & 154 \\ Controller & 84 & 169 \\
**Total** & **870** & **547** \\ \hline \hline \end{tabular}
\end{table} 
Table 1: The proposed protocol’s execution costs. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Protocols** & **SP1** & **SP2** & **SP3** & **SP4** & **SP5** & **SP6** & **SP7** \\ \hline [PERSON] [6] & ✗ & ✓ & ✗ & ✓ & ✓ & ✗ & ✓ \\ [PERSON] [14] & ✓ & ✗ & ✓ & ✓ & ✓ & ✓ & ✗ \\ [PERSON] [41] & ✓ & ✓ & ✓ & ✓ & ✓ & ✓ & ✓ \\
**Proposed work** & ✓ & ✓ & ✓ & ✓ & ✓ & ✓ & ✓ \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Performance comparison based on required security. Santa Clara, CA, USA) desktop computer, the total execution time measured at a clock frequency of 2.5 MHz averaged 509,913 clock cycles, and the actual execution time on the device side averaged 16.65 ms. The execution time in [41] containing the instruction transfer between token and verifier is around 1.25 s, and the protocol has a high level of security. However, compared to [41], our proposed scheme has significant advantages in terms of execution time and hardware overhead. The protocol in [14] is implemented on the Edison platform and its end-to-end execution time is measured to be around 480.11 ms, but [14] uses BCH codes on the device side to correct the noisy response, which leads to a higher hardware overhead.