# FeRHA: Fuzzy-Extractor-Based RF and Hardware Fingerprinting Two-Factor Authentication
## 5 Combined PUF- and RFF-Based Authentication
### Operation Phase  
After enrollment, a node can apply the FeRHA protocol to authenticate other IoT devices in the system. For such authentication, FeRHA utilizes a two-factor approach, which leverages the unique characteristics of the transmitted waveform to identify the device. This identification mechanism enables FeRHA to obfuscate the PUF response, circumventing the need for the incorporation of cryptographic primitives. Assume that \(\delta_{x}\) (prover) and \(\delta_{y}\) (verifier) need to authenticate each other. The main steps of FeRHA are covered in Algorithm 1. The verifier, \(\delta_{y}\), will extract the RFF, \(\widehat{RFF_{x}}\), of the prover, \(\delta_{x}\), and send it along with of the challenges, \(C_{x,i}\), that is included in \(\gamma_{x\to y}\). Therefore, the received signal of node \(\delta_{x}\) can be written as:  
\[\Omega_{\delta_{x}}(t)=[W_{\delta_{x}\delta_{y}}(t)*D(A)]C_{x,i}+n(t) \tag{6}\]  
where \(W(t)\) is the wireless channel and \(*\) denotes the conventional operation. \(D(. )\) is the overall effect of hardware distortion on the transmitted analog signal, \(A\), and \(n(t)\) is the noise. By extracting \(C_{x,i}\), \(\delta_{x}\) will input \(C_{x,i}\) to its PUF, \(PUF_{x}\), to generate the corresponding response bit-string as follows:  
\[\widehat{R_{x,i}}=PUF_{x}(C_{x,i}) \tag{7}\]  
where \(\widehat{R_{x,i}}\) is the noise-affected response. FeRHA mitigates the noise in the generated biometric, \(RFF\), and the PUF response, \(R\), as discussed in Sections 3 and 4. Hence, \(\delta_{x}\) will  
Figure 4: An illustrative example for constructing \(\gamma_{x}\). apply the fuzzy extractor to the generated response bit-string \(\widehat{R_{x,i}}\) and \(\widehat{RF_{x}}\) while utilizing the helper string extracted during the enrollment phase, as follows:  
\[R_{x,i}=\Pi(\widehat{R_{x,i}},\mathcal{H}_{R_{x,i}}) \tag{8}\] \[RFF_{x}=\Pi(\widehat{RF_{x}},\mathcal{H}_{RFF_{x}}) \tag{9}\]  
where \(\mathcal{H}_{R_{x,i}}\) and \(\mathcal{H}_{RFF_{x}}\) are the helper bit-strings generated during the enrollment process for \(R_{x,i}\) and \(RFF_{x}\), respectively. \(R_{x,i}\) and \(RFF_{x}\) denote the noise-mitigated versions of \(\widehat{R_{x,i}^{y}}\) and \(\widehat{RF_{x}}\), respectively. In the context of FeRHA, the storage of the actual list of CRPs is not required. Instead, FeRHA has introduced a token list, \(\gamma\), which comprises a series of challenge bits that are associated with an authentication token, _Token_, as illustrated in Figure 3. The use of a token list, \(\gamma\), in FeRHA provides a secure mechanism for verifying the authenticity of a device while eliminating the exposure of the actual CRPs list. Thus, in the event of an eavesdropper gaining access to the token list, the ability to model \(\delta_{x}\)'s PUF will be hindered. This is because the eavesdropper will erroneously associate \(C\) with the authentication _Token_, rather than with the PUF response, \(R\), ultimately leading to a thawed model of \(PUF_{x}\). The authentication token corresponding to \(C_{x,i}\), denoted as \(\widehat{\mathit{Token}_{x,i}^{y}}\), is specific for verifier \(\delta_{y}\) and is in essence a bit-string that is mapped based on \(RFF_{x}\) and \(R_{x}\). This mapping process is performed by utilizing an obfuscation function, represented by \(\Phi\), as shown in Algorithm 1. In order for node \(\delta_{x}\) to construct \(\widehat{\mathit{Token}_{x,i}^{y}}\), it will generate a factor, \(\mathcal{L}_{xy}\), that is dependant on the communication link with \(\delta_{y}\) using its PUF, as follows:  
\[\mathcal{L}_{xy}=PUF_{x}(\mathcal{H}_{RFF_{x}},\mathcal{H}_{RFF_{y}}) \tag{10}\]  
where \(\mathcal{H}_{RFF_{x}}\)and\(\mathcal{H}_{RFF_{y}}\) are the helper strings for \(RFF_{x}\) and \(RFF_{y}\), respectively, which are generated using the fuzzy extractor during the enrollment phase.