# Challenge-Response Pair Mechanisms and Multi-Factor Authentication Schemes to Protect Private Keys
## 4 Experimental Section and Analysis  
### Generation of Reference Tables from PUF-Based Physical Tokens  
Physically Unclonable Functions (PUFs) are security primitives that extract unique information from a device to generate a distinctive signature [52]. This approach significantly enhances security by enabling the creation of device-specific signatures or true random numbers, which can be directly integrated into cryptographic protocols, thereby strengthening device security. Most existing research explores the use of PUFs for generating cryptographic keys or seeds by challenging various addresses of the device to obtain unique responses for key creation and verification [64]. In this work, the generation of the reference table is tailored differently for the server and client sides. Instead of using a conventional 256-bit address for the PUF, we construct a reference table of dimensions such as 256 \(\times\) 256. On the server side, the PUF is read multiple times to thoroughly characterize its behavior for enrollment purposes. Specifically, this research employs Static Random  
Figure 5: Block diagram showing the two-step operation that retrieves the secret key Sk and signs transaction T. During Step 1, the recovery of the reference table CT with RN\({}_{1}\) and three factors is the same as that described in Sections 2.2 and 2.3. In Step 2, the recovery of the ephemeral key K is based on the CRP mechanism using table CT and random number RN\({}_{3}\). The key K allows the decryption of the private key K, and the signing of transaction T.  
Access Memory (SRAM)-based PUFs to capture three possible states: \"0\", \"1\", and \"X\", thereby obtaining comprehensive information about all PUF cells. For experimentation, IS61 LV6416 1 Mb SRAM chips were utilized, providing 1,048,576 cells, each read hundreds of times. The server can retain this detailed information for the recovery process, safeguarding against token damage or loss. The physical token is then delivered to the user, where it generates the same reference table using a single read.  
Experimental section: We conducted an enrollment session comprising 1000 reads for 1970 token table generation cycles using an enrollment file i.e., the comparison of all those 1000 reads on the server side using challenges. Clients use the same challenges to produce the same table using one single read. On the server side, after 1000 reads, we obtain our enrollment file, and, during each cycle, we read states \"0\" or \"1\" of each cell of the IS61 LV6416 1M SRAM chip and store the binary read; we compare each read to calculate the average state of each cell. Cells consistently producing \"1\" or \"0\" were marked as stable \"1\"s and \"0\"s, respectively, while cells exhibiting bit flips were labeled as \"X\". This process resulted in a ternary mapping (\"0\", \"1\", \"X\") of the entire SRAM-based PUF on the server side. On the client side, a single read of the SRAM PUF yielded a binary state (\"0\" and \"1\") without comparisons to other reads. For the analysis, 65,536 random addresses were generated, shared between the client and the server, and used to create reference tables for both sides. As shown in Figure 6, the Kernel Density Estimation (KDE) highlights the proportions of \"0\" and \"1\" for both the client and the server, and the distribution of \"X\" on the server.