# FeRHA: Fuzzy-Extractor-Based RF and Hardware Fingerprinting Two-Factor Authentication
## 5 Combined PUF- and RFF-Based Authentication
### Enrollment Phase  
IoT has a vast conceptual coverage, encompassing both spatial and temporal dimensions. However, in practical terms, the interaction between devices is more localized. As a result, a node, \(\delta_{y}\), does not need to authenticate numerous IoT devices. The practicality of FeRHA is evident in its ability to facilitate mutual authentication between nodes without the need for an intermediary trusted server. However, it is important to note that a server is indispensable during the device enrollment process to effectively manage the sharing of token list \(\gamma\). During the enrollment of a device, it is necessary to establish connectivity with a local server that maintains an index of active IoT devices. For instance, in the domain of IoV (Internet of Vehicles), the department of motor vehicles is a viable candidate for serving as the server. In an IoV setting, if a vehicle intends to participate in peer-to-peer data sharing on the road, it should retrieve some CRPs for other affiliated vehicles. Throughout the enrollment process, each IoT node is required to provide specific information in order to be integrated into the network. We assume that the enrollment phase is conducted through a secure channel. In our proposed protocol, the CRP list of a node will not be explicitly stored at any other IoT node. This feature is designed to enhance the security of the protocol by preventing an eavesdropper from capturing the CRPs of a node and model its PUF. Upon enrollment, an IoT device, \(\delta_{x}\), will send to the server a CRP list, \(\Gamma_{x}\), which reflects a small subset of all possible challenge-response combinations. Recall that FeRHA assumes that strong PUFs are employed. For each CRP in \(\Gamma_{x}\), node \(\delta_{x}\) generates helper data and stores them in its memory. We note that this does not introduce any notable vulnerability since it is impossible to infer the response of a challenge using the corresponding helper data. In addition, the size of \(\Gamma_{x}\) is limited and would not constitute much of a burden for the IoT node. For example, storing helper data of 8 bits for 1024 CRPs would take only 8K bits. The server assigns each potential verifier (i.e., IoT nodes other than \(\delta_{x}\)) a distinct subset of \(\Gamma_{x}\). To clarify, let us assume that the network consists of four IoT nodes, namely \(\delta_{x},\delta_{y},\delta_{z},\) and \(\delta_{w}\). As shown in the example in Figure 4, each node will obtain a subset of \(\Gamma_{x}\), such that \(\gamma_{x\to z}\
eq\gamma_{x\to w}\), and \(\gamma_{x\to z}\cup\gamma_{x\to w}\
eq\Gamma_{x},\forall z\
eq w\). For each of these subsets, the response of the challenge is obfuscated in a manner that depends on the verifier. In essence, the obfuscated response becomes an authentication _Token_. Using the case of \(\delta_{x}\) and \(\delta_{y}\) as an example, the associated token, \(\textit{Token}_{x,i}^{y}\), in \(\gamma_{x\to y}\) is formed as follows:  
\[\textit{Token}_{x,i}^{y}=\Phi(\mathcal{L}_{xy},R_{x,i},\textit{RF}_{x}), \quad\forall(C_{x,i},R_{x,i})\in\gamma_{x\to y} \tag{3}\]  
where \(R_{x,i}\) is the corresponding response of \(C_{x,i}\) using \(\textit{PUF}_{x}\), while \(\textit{RF}_{x}\) is the RF fingerprint for \(\delta_{x}\). \(\Phi(. )\) is a function to obfuscate the PUF response, \(R_{x,i}\), using \(\textit{RF}_{x}\); yet such obfuscation is made to depend on the verifier, \(\delta_{y}\), by factoring in \(\mathcal{L}_{xy}\). For example, \(\Phi(. )\) could be a Boolean function where \(\mathcal{L}_{xy}\) is used as an operator, or could be a bit-shuffling (rotate) function that uses \(\mathcal{L}_{xy}\) to determine the shuffling pattern or rotation count. The principal objective of performing this operation is to enable the receiver node to deduce the response bit-string since the actual response is not included in the authentication packet. Therefore, an interceptor of authentication packets will be prevented from knowing the response.