## 5 The Proposed Fortified-Edge 2.0 Framework
After collecting all k-mers, the list is converted into a text string representation. A CountVectorizer is then applied, treating each k-mer as a word and counting the frequency of each unique pattern to generate a fixed-length numerical feature vector \(V\). ```
0: Binary Sequence \(B\) of length \(m\), K-mer size \(k\)
0: Feature Vector \(V\)
1: Step 1: Initialize
2: Define an empty list \(K\leftarrow\{\}\) to store k-mers. 3: Step 2: Extract K-Mers
4:for\(i\gets 0\) to \(m-k\)do
5: Extract substring \(K_{i}=B[i:i+k]\)
6: Append \(K_{i}\) to list \(K\)
7:endfor
8:Step 3: Vectorization
9: Convert \(K\) into a text string representation. 10: Apply CountVectorizer to transform \(K\) into vector \(V\). 11:Step 4: Return Feature Vector
12: Output \(V\) as the final feature representation. ```
**Algorithm 2** Feature Extraction Using K-Mers

Algorithm 3 shows the steps involved in the evaluation on the server side. The process begins by loading the CRP dataset \(\mathcal{CRP}\) from a local file. A challenge \(C\) is selected from the dataset, and feature extraction techniques are applied to generate a vectorized representation \(V_{C}\). To ensure data authenticity and integrity, the server computes a digital signature \(S_{C}=\text{Sign}(V_{C},sk_{S})\) using its private key \(sk_{S}\), and transmits the signed challenge tuple \((V_{C},S_{C})\) to the client. Upon receiving the client's signed response \((V_{R},S_{R})\), the server performs signature verification by validating \(S_{R}\) against \(V_{R}\) using the client's public key \(pk_{C}\). If the verification succeeds and the received vectorized response \(V_{R}\) matches the expected response \(V_{E}\) stored in the dataset, the server ends the authentication process with a success message. Otherwise, an authentication failure message is generated. To facilitate performance evaluation, the server records critical metrics, including execution time, CPU utilization, and memory usage, before terminating the session. ```
0: Challenge-Response Dataset \(\mathcal{CRP}\)
0: Authentication Result
1:Step 1: Initialize
2: Load dataset \(\mathcal{CRP}\) from CSV. 3:Step 2: Challenge Selection
4: Select a challenge \(C\in\mathcal{CRP}\). 5: Generate vectorized challenge \(V_{C}\) using feature extraction. 6:Step 3: Challenge Signing
7: Compute digital signature \(S_{C}=\text{Sign}(V_{C},sk_{S})\). 8: Send tuple \((V_{C},S_{C})\) to client. 9:Step 4: Receive and Verify Response
10: Receive signed response \((V_{R},S_{R})\) from client. 11: Verify signature: Verify\((S_{R},V_{R},pk_{C})\). 12:if Signature \(S_{R}\) is valid then
13:if\(V_{R}=V_{E}\) (expected response) then
14: Send authentication success message. 15:else
16: Send authentication failure message. 17:endif
18:else
19: Send authentication failure message (invalid signature). 20:endif
21:Step 5: Log and Close
22: Log execution time, CPU, and memory usage. 23: Close connection. ```
**Algorithm 3** Server Authentication Process

Algorithm 4 shows the steps involved in the evaluation on the client side. The client authentication process begins with the client establishing a connection to the server and sending an authentication request. Upon receiving a tuple consisting of the encrypted vectorized challenge \(V_{C}^{enc}\) and the corresponding server-generated signature \(S_{C}\), the client decrypts \(V_{C}^{enc}\) to recover the original vectorized challenge \(V_{C}\). The authenticity of the challenge is then verified by validating the server's signature \(S_{C}\) against \(V_{C}\) using the server's public key \(pk_{S}\). If the signature verification succeeds, the client reconstructs the original binary challenge \(C\) from \(V_{C}\), applies it to its embedded PUF to generate the binary response \(R\), and vectorizes the response to produce \(V_{R}\). Subsequently, the client signs \(V_{R}\) using its private key \(sk_{C}\) to produce a signature \(S_{R}\). The client then transmits the signed tuple \((V_{R},S_{R})\) back to the server.