Mutual V2I Multifactor Authentication Using PUFs in an Unsecure Multi-Hop Wi-Fi Environment
Round 1
Reviewer 1 Report
Comments and Suggestions for AuthorsAuthors proposed a secure multifactor authentication protocols for vehicle-area networks enabled by physically unclonable functions. It is based on entities mutual authentication and secret cryptographic key generation.
The Introduction is clear and well structured.
It is not necessary that used notations will be separate section. It only points out to the table and it can be done in Introduction.
Related Work describes relevant challenges and opportunities in the area of multi-hop Wi-Fi environment and compares proposed solution with existing ones, but it will be better to add short description instead reference number in the column Work in Table 2.
In my opinion, description of the PUF in section 4 Background: physically unclonable functions (PUFs) in for most of potential readers relatively far from the real V2X environments and need to be simply incorporated in the context.
The title of section 5 „Proposed scheme“ must be improved and need to incorporate all considered entities, phases and proposed ideas. Pre-deployment, registration, authentication and communication phases are proposed and explained, but additional comparison with related work must be added. The importance of the cloud must also be deeply explained. In addition, proposed contributions must be elaborated through the whole section 5.
At the beginning of Security analysis (section 6), authors must add explanation about the reasons of selection of inductive proof and game based proof and cite appropriate references in which similar proofs are used for similar security analysis. The same thing is with the BAN Logic. Additionally, it is necessary to suggest main directions for implementation of the proposed approach and to sketch possible verification scenario which is closer to real V2I environment as well as to consider appropriate evaluation metrics and methods.
Finally, Conclusion should be adjusted with the changes in the submission based on suggestions of the review.
Author Response
Reviewer #1
Rev. #1, Comment 1:
It is not necessary that used notations will be separate section. It only points out to the table and it can be done in Introduction.
Response 1: We moved the notations table to be part of the Introduction section.
Rev. #1, Comment 2:
Related Work describes relevant challenges and opportunities in the area of multi-hop Wi-Fi environment and compares proposed solution with existing ones, but it will be better to add short description instead reference number in the column Work in Table 2.
Response 2: We added first author’s name in addition to the citation.
Rev. #1, Comment 3:
In my opinion, description of the PUF in section 4 Background: physically unclonable functions (PUFs) in for most of potential readers relatively far from the real V2X environments and need to be simply incorporated in the context.
Response 3: We merged Section 3 ”Background” with Section 2 ”Related Work” and adjusted the text accordingly.
Rev. #1, Comment 4:
The title of section 5 “Proposed scheme” must be improved and need to incorporate all considered entities, phases and proposed ideas. Pre-deployment, registration, authentication and communication phases are proposed and explained, but additional comparison with related work must be added. The importance of the cloud must also be deeply explained. In addition, proposed contributions must be elaborated through the whole section 5.
Response 4: We explained at the start of Section 3 ”Proposed Multihop Wi-Fi Authentication Scheme” the phases of the protocol then explained the deployment scenario and main players in the protocol. We also provide Table 2 that compares our work with two others that relied on PUFs for security and authentication.
Rev. #1, Comment 5:
At the beginning of Security analysis (section 6), authors must add explanation about the reasons of selection of inductive proof and game based proof and cite appropriate references in which similar proofs are used for similar security analysis. The same thing is with the BAN Logic. Additionally, it is necessary to suggest main directions for implementation of the proposed approach and to sketch possible verification scenario which is closer to real V2l environment as well as to consider appropriate evaluation metrics and methods.
Response 5: We added introductory sentences and cited several works that dealt with similar problems using gamebased proof and BAN logic proof.
Rev. #1, Comment 6:
Finally, Conclusion should be adjusted with the changes in the submission based on suggestions of the review.
Response 6: We adjusted the conclusions section accordingly.
Author Response File: 
Author Response.pdf
Reviewer 2 Report
Comments and Suggestions for AuthorsThe manuscript is written on a timely and important topic - secure authentication in VANETs using PUFs over multi-hop Wi-Fi environments. While the intention to address privacy and mutual authentication in dynamic vehicular networks is appreciated, the current version of the paper has several major weaknesses that require thorough addressing. Please consider the following detailed comments and recommendations:
1) Avoid the textual repetitions (description of attacks, conclusions, etc.) with exact same wording, as it has already been published at a significant cost: Gebali, F.; Elhadad, M.K. PUFGuard: Vehicle-to-Everything Authentication Protocol for Secure Multihop Mobile Communication. Computers 2023, 12, 233. https://doi.org/10.3390/computers12110233
2) The manuscript does not clearly articulate how the proposed protocols significantly improve upon or differ from existing PUF-based authentication schemes in vehicular environments. There is no detailed comparison with state-of-the-art protocols or standards such as those based on ECC, blockchain, or fog-based V2X security models;
3) No simulations, prototype implementation, or performance benchmarks are included. Without empirical results (e.g., latency, key generation time, communication overhead), it is difficult to assess the real-world feasibility or efficiency of the proposed protocols;
4) The "informal analysis" merely lists attacks and claims resistance without step-by-step logic or adversary modeling. The absence of a defined threat model, adversary capabilities, or formally modeled step-by-step attack vectors weakens the credibility of the security claims;
5) PUFs are central to the paper, yet their instability, error tolerance, and environmental sensitivity are not discussed. No mechanisms, such as fuzzy extractors or helper data schemes, are described. There’s also no reference to real-world deployments or challenges in embedding PUFs in vehicles;
6) Provide a comparative table summarizing the features and security capabilities of your protocol versus existing schemes;
7) Improve the clarity and consistency of notation in the protocol diagrams.
Author Response
Reviewer #2
Rev. #2, Comment 1:
Avoid the textual repetitions (description of attacks, conclusions, etc.) with exact same wording, as it has already been published at a significant cost: Gebali, F.; Elhadad, M.K. PUFGuard: Vehicle-to-Everything Authentication Protocol for Secure Multihop Mobile Communication. Computers 2023, 12, 233. https://doi.org/10.3390/computers12110233
Response 1: We provided citation for the paper your are referring to and confined ourselves to a very brief discussion.
Rev. #2, Comment 2:
The manuscript does not clearly articulate how the proposed protocols significantly improve upon or differ from existing PUF-based authentication schemes in vehicular environments. There is no detailed comparison with state-of-the-art protocols or standards such as those based on ECC, blockchain, or fog-based V2X security models;
Response 2: Lines 20–23 provide a comparison between public key protocols such as ECC and RSA.
Lines 42–48 provide a comparison between PUF-based authentication protocol proposed here is compared with how PUFs are used in literature.
Rev. #2, Comment 3:
No simulations, prototype implementation, or performance benchmarks are included. Without empirical results (e.g., latency, key generation time, communication overhead), it is difficult to assess the real-world feasibility or efficiency of the proposed protocols;
Response 3: The main purpose of this work is to propose a new multifactor annoynmous mutual authentication protocol for VANETs. Later publications could be concerned with implementation and performance details.
Rev. #2, Comment 4:
The ”informal analvsis” merely lists attacks and claims resistance without step-by-step logic or adversary modeling.
The absence of a defined threat model, adversary capabilities, or formally modeled step-by-step attack vectors weakens the credibility of the security claims;
Response 4: We added Section 4.1 ”Threat Model” to identify the capabilities of the attacker.
Rev. #2, Comment 5:
PUFs are central to the paper, yet their instability, error tolerance, and environmental sensitivity are not discussed. No mechanisms, such as fuzzy extractors or helper data schemes, are described. There’s also no reference to real-world deployments or challenges in embedding PUFs in vehicles;
Response 5: We provided more details and citations on noise in PUFs and means of removing this noise.
Rev. #2, Comment 6:
Provide a comparative table summarizing the features and security capabilities of your protocol versus existing schemes;
Response 6: Table 2 compares our proposed protocol with two other similar works.
Rev. #2, Comment 7:
Improve the clarity and consistency of notation in the protocol diagrams.
Response 7: Table 1 summarizes the notations used and we double checked that we used this notation in our algorithms.
Author Response File: Author Response.pdf
Reviewer 3 Report
Comments and Suggestions for AuthorsAlthough the suggested application of PUFs for mutual authentication is helpful, the methodology does not have specific algorithmic descriptions, formal definitions, and system parameters for reproducibility. A formal pseudocode or protocol flow chart will improve clarity.
The background research is comprehensive but has excessive background that dilutes the paper's focus. Over reviewing cutting essential prior investigations to summarize and incorporating comparative critique to show how your protocol advances beyond them in practical terms.
The formal security proof is impressive, but in the current form (blending BAN logic, inductive proofs, and game-based models) they are unnecessary. Maybe include a high-level table listing a summary of what threat each proof addresses, with cross-references to subsections.
There is no correspondence between the sensational claim in the abstract (e.g., "the first time in literature") and the evidence shown. Ensure that any such novelty claims are substantiated with literature analysis and explanation.
The paper does not contain simulation or experimental results. Given the protocol's usage of wireless hops and real-time security exchanges, empirical experiments or performance simulation (e.g., latency, generation time for keys, packet overhead) would be needed to confirm feasibility.
The limitations section is concise and mentions lightly only non-PUF vehicles. More elaboration on interoperability, integration with non-PUF legacy environments, or hardware constraints (e.g., cost, entropy range) would confer the paper's applicability.
Author Response
Reviewer #3
Rev. #3, Comment 1:
Although the suggested application of PUFs for mutual authentication is helpful, the methodology does not have specific algorithmic descriptions, formal definitions, and system parameters for reproducibility. A formal pseudocode or protocol flow chart will improve clarity.
Response 1: We did the following changes:
• Added a notation table (Table 1, p. 3)
• A step-by-step pseudocode (Algorithm 1, p. 10)
• A protocol flowchart (Figure 3, p. 11)
• Section 4.2 we provide the steps necessary for using a PUF for authentication and secure key exchange
Rev. #3, Comment 2:
The background research is comprehensive but has excessive background that dilutes the paper’s focus. Over reviewing cutting essential prior investigations to summarize and incorporating comparative critique to show how your protocol advances beyond them in practical terms.
Response 2: Section 3 has been completely rewritten to focus on critical comparative analysis. The revised Related Works now categorizes existing approaches into cryptography, blockchain, fog/edge, and PUF-based protocols, highlights their strengths and weaknesses, and concludes with a research gap.
We also included two figures for clarity.
Manuscript Updates:
• Section 2 Related Works: fully replaced with enriched comparative review.
• Figure 1 (Taxonomy of Authentication Approaches)
• Table 2 (Comparative Feature Matrix)
Rev. #3, Comment 3:
The formal security proof is impressive, but in the current form (blending BAN logic, inductive proofs, and gamebased models) they are unnecessary. Maybe include a high-level table listing a summary of what threat each proof addresses, with cross-references to subsections.
Response 3: While we retained detailed proofs, we added a summary table (Table 4) that maps each proof method to the security property it validates, with cross-references to subsections.
Rev. #3, Comment 4:
There is no correspondence between the sensational claim in the abstract (e.g., ”the first time in literature”) and the evidence shown. Ensure that any such novelty claims are substantiated with literature analysis and explanation.
Response 4: We acknowledge this important point. We tempered the novelty claim in the abstract and introduction and supported it with comparative evidence. The revised text specifies that our framework is the first to combine PUF-based authentication with bi-directional trust, cooperative multi-hop Wi-Fi forwarding, and cloud-assisted scalability, unlike prior works that addressed these dimensions only in isolation.
Manuscript Updates: Abstract: fully rewritten with revised novelty claim.
Rev. #3, Comment 5:
The paper does not contain simulation or experimental results. Given the protocol’s usage of wireless hops and realtime security exchanges, empirical experiments or performance simulation (e.g., latency, generation time for keys, packet overhead) would be needed to confirm feasibility.
Response 5: We thank the reviewer for highlighting this. While full implementation is ongoing, we added a new Section 6.6 Implementation Roadmap, describing the planned testbed using Mininet-WiFi and SUMO, the metrics to be evaluated, and preliminary latency expectations (¡10 ms per hop). This roadmap provides a clear plan for empirical validation.
Manuscript Updates:
• New Section 4.7 Implementation Roadmap added
• New references included:
[30] Fontes, R. R., et al. (2015). Mininet-WiFi: Emulating software-defined wireless networks. ICCCN.
[31] Krajzewicz, D., et al. (2012). Recent development and applications of SUMO. IJASM.
Rev. #3, Comment 6:
The limitations section is concise and mentions lightly only non-PUF vehicles. More elaboration on interoperability, integration with non-PUF legacy environments, or hardware constraints (e.g., cost, entropy range) would confer the paper’s applicability.
Response 6: We thank the reviewer for this insightful remark. We completely rewrote Section 5 (Limitations & Future Work). The revised section discusses legacy interoperability, hybrid deployment, vendor heterogeneity, hardware integration costs, and environmental sensitivity of PUFs.
Manuscript Updates:
• Section 5 Limitations & Future Work replaced with expanded text.
• New references added:
[24] Delvaux, J., et al. (2014). Helper data algorithms for PUF-based key generation. IEEE TCAD, 34(6),
889–902.
[32] Maes, R. (2016). Physically Unclonable Functions: Constructions, Properties and Applications. Springer.
Author Response File: Author Response.pdf
Round 2
Reviewer 2 Report
Comments and Suggestions for AuthorsMost of the comments have been addressed by the authors.
Despite being eager to see the experimental part of the paper, I recommend publishing the current manuscript, considering that the authors have clearly provided a roadmap, future work, and limitations.
Together with that, I'd ask authors to implement the following minor changes before submittinga camera-ready version of the paper:
1) The revised paper includes a new “Comparative Analysis and Research Gap” section and Table 2, listing several paradigms. Comparison exists but remains conceptual, it lacks quantitative or technical depth to prove real improvement. At least, please describe what are the meaning of the words "High", "Poor", "Moderate", "Partial", "High" in the table to strengthen the positioning of the manuscript;
2) Ground your choice of Mininet-WiFi for the simulation;
3) Why did you omit the "Discussion" (or "Conclusions") section? It's worth adding it to summarise the results. Please review the paper template.
No issues.
Author Response
Our response is in the attached PDF file.
Author Response File: Author Response.pdf
Reviewer 3 Report
Comments and Suggestions for AuthorsNo further comments
Author Response
We thank the reviewer for his efforts to improve the manuscript.
