# Key Recovery for Content Protection Using Ternary PUFs Designed with Pre-Formed ReRAM
## 2 One Way Unclonable Functions with Ternary States
### Error-Correcting Methods Versus Search Engines
#### 2.4.2 Response-Based Cryptography (RBC)  
RBC enhances the protection of the key generation process by eliminating the need to operate a fuzzy extractor at the client device level, see Figure 2. In lieu of generating a data helper from **K**, the client device hashes **K'** to generate the message digest **H(K')**, which is transmitted to the server. The RBC is a search engine that is able to recover **K'** from **K** and the message digest **H(K')**[30; 31; 32]. Through an iterative process, the RBC search engine hashes the initial response **K = K0** and compares the message digest **H(K0)** and **H(K')**. If these two do not match, the RBC tests all data streams **K1k** from a Hamming distance of 1 of **K0**. If these do not match, the RBC iterates and tests all data streams **K2k** from a Hamming distance of 2. Such an iterative process can handle Hamming distances up to 3, and 256-bit long responses. Beyond this, the latencies become prohibitive. A scheme fragmenting the data streams with nonces has been documented as effective with BERs as high as 20%. For example, if 256-bit long responses are impacted by 7% BERs, a fragmentation of 4 is applied; with SHA-128, **H(K')** as a 4 \(\times\) 128-bit long stream. Each fragment is filled with nonces and is hashed. The RBC does not necessarily consume less power than a mainstream ECC,and it is not faster; however, the burden is moved to the server, thereby reducing both the vulnerability and the power consumption at the client device level. The hashing of \(\mathbf{K}^{\prime}\) is a light operation. Hashing methods such as SHA-128 or SHA-256 are extremely fast, and commercial implementation in hardware embedded in cryptographic processors is available. The RBC can also benefit from high-performance computing (HPC), graphic processor units (GPU), and associative processor units (APU), all of which leverage the possibility of distributing the search through parallel computations [33; 34]. This approach can also leverage noise injection schemes relying on HPC solutions, which reduce the risk of exposure to certain attacks. The opponents need access to similar computing power in order to participate. The use of HPC is not recommended for the \"RBC-light\" version needed for key recovery, see Section 3.3.  
Figure 1: Block diagram of an ECC scheme. The challenges (\(\mathbf{T}\), _IDAccess_) generate the responses \(\mathbf{K}\) from the image of the PUF stored by the server, and the response \(\mathbf{K}^{\prime}\) from the PUF. The helper transmitted by the server allows the ECC fuzzy extractor of the client device to recover \(\mathbf{K}\) from \(\mathbf{K}^{\prime}\).  
Figure 2: Block diagram of RBC search engine scheme. The challenges (\(\mathbf{T}\), _IDAccess_) generate the responses \(\mathbf{K_{0}}\) from the image of the PUF, and the responses \(\mathbf{K}^{\prime}\) from the PUF. The RBC finds \(\mathbf{K}^{\prime}\) through an iterative process from \(\mathbf{K}\) and \(\mathbf{H}(\mathbf{K}^{\prime})\).