# FeRHA: Fuzzy-Extractor-Based RF and Hardware Fingerprinting Two-Factor Authentication
## 5 Combined PUF- and RFF-Based Authentication
### Operation Phase
Thereafter, \(\delta_{x}\) will need to form the authentication token, \(\widehat{\mathit{Token}_{x,i}^{y}}\), as illustrated in Figure 5, by applying the obfuscation function, \(\Phi\), as follows:  
\[\widehat{\mathit{Token}_{x,i}^{y}}=\Phi(\mathcal{L}_{xy},R_{x,i},RFF_{x}) \tag{11}\]  
The FeRHA protocol incorporates an obfuscated counter, denoted as \(count\), into the sending packet to provide protection against replay attacks. This mechanism restricts access to \(count\) and prevents unauthorized interception of the transmitted packets between \(\delta_{x}\) and \(\delta_{y}\), as detailed in the following subsection. Additionally, \(\widehat{\mathit{Token}_{x,i}^{y}}\) is masked using a pre-selected key, designated as \(\mathit{Key}\), which is chosen from \(\gamma_{x\to y}\). It is important to note that this token and its accompanying challenge cannot be utilized for authentication and are assigned solely as a key. Therefore, the transmitted packet can be constructed as follows:  
\[\{\mathit{Key}\oplus count,\mathit{Key}\oplus\widehat{\mathit{Token}_{x,i} ^{y}}\} \tag{12}\]  
Then, \(\delta_{x}\) will send the above packet to \(\delta_{y}\). The mapping of the authentication token, _Token_, is not uniform across different nodes. This lack of uniformity means that an attacker attempting to eavesdrop on communication between node \(\delta_{x}\) and various verifiers, \(\delta_{y}\), \(\delta_{z}\), and \(\delta_{w}\), will not succeed in discovering \(\mathit{Token}\). This is because the mapping is not exact, and \(\Phi\) does not yield an identical mapping across different verifiers. Therefore, such an attempt is futile. Lastly, \(\delta_{y}\) will compare \(\widehat{\mathit{Token}_{x,i}^{y}}\) that is received during the enrollment phase, with \(\widehat{\mathit{Token}_{x,i}^{y}}\). If \(\widehat{\mathit{Token}_{x,i}^{y}}\) matches \(\widehat{\mathit{Token}_{x,i}^{y}}\), then the authentication succeeds; otherwise, the received authentication token, \(\widehat{\mathit{Token}_{x,i}^{y}}\), will be rejected. ```
0: Let \(\gamma_{x\to y}\) be the token list of \(\delta_{x}\) that shared with \(\delta_{y}\). \(\Phi\) is the response obfuscation function, where \(\mathcal{H}_{RFF}\) and \(\mathcal{H}_{R_{x},1}\) are the helper string for \(RFF\) and \(R_{x,1}\), respectively. 1:\(\delta_{y}\) extracts \(\widehat{RFF_{x}}\)
2:\(\delta_{y}\) sends \((C_{x,i},\widehat{RFF_{x}})\) to \(\delta_{x}\), where \((C_{x,i},Token_{x,i}^{y})\in\gamma_{x\to y}\)
3:\(\delta_{x}\) applies \(C_{x,i}\) to its PUF, i.e., \(PUF_{x}(C_{x,i})=\widehat{R}_{x,i}\)
4:\(\delta_{x}\) applies FE to \(\widehat{R}_{x,i}\) and \(\widehat{RFF_{x}}\), s.t. \(R_{x,i}=\Pi(\widehat{R}_{x,i},\mathcal{H}_{R_{x,j}})\), and \(RFF_{x}=\Pi(\widehat{RFF_{x}},\mathcal{H}_{RFF_{x}})\)
5:\(\delta_{x}\) determines \(\mathcal{L}_{xy}\) using its PUF, where \(\mathcal{L}_{xy}=PUF_{X}(\mathcal{H}_{RFF_{x}},\mathcal{H}_{RFF_{y}})\)
6:\(\delta_{x}\) calculate \(\widehat{Token_{x,i}^{y}}=\Phi(\mathcal{L}_{xy},R_{x,i},RFF_{x})\)
7:\(\delta_{x}\) masks \(\widehat{Token_{x,i}^{y}}\) as \(\{Key\oplus count,Key\oplus\widehat{Token_{x,i}^{y}}\}\) and send it to \(\delta_{y}\)
8: Using \(Key\), \(\delta_{y}\) extracts \(count\) and \(\widehat{Token_{x,i}^{y}}\), and performs \(count\) value check. 9:if\(count\) is new then
10:\(continue\). 11:else
12:\(disconnect\). 13:endif
14:\(\delta_{y}\) compare \(\widehat{Token_{x,i}^{y}}\) and \(\widehat{Token_{x,i}^{y}}\): If equals, \(\delta_{x}\) is \(authenticated\), otherwise \(\delta_{x}\) is \( rejected\)
```  
**Algorithm 1** FeRHA(\(\delta_{x}\),\(\delta_{y}\))