# Key Recovery for Content Protection Using Ternary PUFs Designed with Pre-Formed ReRAM
## 6 Characterizing the Key Recovery from ReRAM PUFs  
### Rates of Erratic Keys Recovered from ReRAM PUFs  
One of the explanations for the low BERs reported in Section 5 is the enrollment cycles which populated the look-up tables with quality information on the PUFs. The PUFs were subjected to 80 successive reads in order to identify, then minimize, the impact of the noisy reading cycles. This resulted in a reduction of the differences between the responses generated from the PUFs and the original responses that were stored in the look-up tables. The key recovery protocols are much more challenging. They can face higher BERs as the initial responses are the result of a single read, which could be noisy. Therefore, we conducted a new analysis to quantify the BERs relevant to the key recovery protocols. See Figure 14, in which the PUFs are used twice. This figure shows examples of 44 key recovery cycles; the left column displays the keys generated during the first read from the PUFs and the right column shows the keys generated from the same PUFs during the recovery cycles. The numbers of errors between the two are shown in the last column. As was performed in Section 5, two pre \begin{table}
\begin{tabular}{c c c} \hline \hline
**Factor** & **256 Kb SRAM** & **2 \(\times\) 4 Kb ReRAM** \\ \hline Commercial availability & Broad & Limited \\ \hline Entropy: number of & 256 k cells & 128 M pairs \\ cells/pairs & 2\(\times\) 10\({}^{-6}\) & 1\(\times\) 10\({}^{-8}\) \\ \hline \hline Latencies: enrollment cycle & 7 h & 15 min \\ \hline Latencies: responses/256 bits & 10 \(\mu\)s & 10 ms \\ \hline Crypto-analysis & 5 min & 4.4 h \\ \hline Sense attack & No & Yes \\ \hline Self-destroy & No & With 1.5 V \\ \hline Radiation hardness & Limited & Yes \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Comparison between SRAM and pre-formed ReRAM based key generation protocols. The enrollment cycles of the SRAM are very slow. The cell pairing scheme driving the ReRAMs at different currents increases entropy and enhances tamper resistance. formed ReRAM chips were used to generate 256-bit long keys using the differential pairing protocol. The resultant BERs are higher than those reported in Section 5; however, they are still relatively low, and are well within the RBC-light capabilities. To quantify the BERs, we performed 5000 successive cycles similar to that presented in Figure 14. The results are summarized in Figure 15, which shows on a log scale the probability of the occurrence of erratic keys as a function of the numbers of errors for 256-bit long responses. The average BERs observed in this experiment were \(6.148\,10^{-4}\). These BERs created 787 bit-errors out of the 5000 pairs of 256-bit long keys. Such error rates are even lower than those given as examples in Section 3.3, in which the use of the RBC-light is suggested. The distribution of erratic keys observed here is well described by a Poisson distribution having a parameter \(\lambda\) equal to the average number of erratic bits per 256-bit long key:  
\[\lambda=256\times\text{BER}=256\times 6.148\times 10^{-4}=0.1574 \tag{5}\]  
* 4290/5002 keys (85.8%) have zero errors versus a Poisson distribution at 85.4%
* 643/5000 keys (12.9%) have one error versus a Poisson distribution at 13.4%
* 58/5000 keys (1.2%) have two errors versus a Poisson distribution at 1.06%
* 8/5000 keys (0.16%) have three errors versus a Poisson distribution at 0.06%
* 1/5000 keys (0.02%) have four errors versus a Poisson distribution at 0.002%  
The RBC-light that searches for erratic keys with a Hamming distance of no more than one is expected to find the matching keys in 98.5% of cases. The need to generate a second response occurs in only 1.5% of the cases, and a third response in 0.02% of cases. False reject rates (FRR) of the key recovery will occur if the latencies of the RBC are too long due to an excessive number of iterations, and lengthy PUF response generation cycles. Figure 14: Forty-four 256-bit long key generation cycles.