A Post-Quantum Secure RFID Authentication Protocol Based on NTRU Encryption Algorithm

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper addresses the security degradation of traditional RFID authentication protocols in the context of quantum computing and proposes a post-quantum secure bidirectional RFID authentication protocol based on the NTRU encryption algorithm. The topic is well aligned with current research hotspots in post-quantum cryptography and Internet of Things security, with a clear problem definition and a well-structured technical approach. Starting from the limitations of existing NTRU-based authentication protocols, the authors systematically design a complete authentication framework involving a KGC, readers, tags, and a backend server. By combining BAN-logic formal analysis, AVISPA-based verification, and performance comparison experiments, the paper provides a relatively comprehensive validation of the security and feasibility of the proposed protocol.

1. The paper presents multiple instances where the order or numerical values of the parameters (N, p, q) are inconsistent; these should be unified and their corresponding security level sources should be clearly specified.
2. It is recommended to discuss the impact on protocol security in the event that the KGC is compromised or partially fails.
3. The authors are encouraged to supplement the related work and application background with a discussion on recent advances in chaos-based encryption for multimedia and IoT security.
4. A quantitative analysis of the scalability issue arising from storing multiple reader public keys on the tag side is suggested, particularly regarding the feasibility of this design in large-scale RFID systems.
5. “Chaos-Based Video Encryption Techniques: A Review” systematically summarize and propose multi-layer and multi-directional chaos-based encryption concepts, which may help interpret high-security encryption mechanisms from a broader information security perspective and offer useful insights for the high-security RFID authentication protocol studied in this paper.
6. It is recommended to include comparisons with additional post-quantum schemes, such as Kyber, FrodoKEM, and Dilithium, even if only at a qualitative level.

Author Response

1. The paper presents multiple instances where the order or numerical values of the parameters (N, p, q) are inconsistent; these should be unified and their corresponding security level sources should be clearly specified.

Thank you for pointing out the inconsistencies in the order or numerical values of the parameters (N, p, q) presented in the paper. This was indeed an oversight on my part. I have now systematically reviewed and corrected the entire text, unifying all relevant expressions as (N, p, q) = (443, 3, 2048). Additionally, in Section 5, I have clearly specified the security-level sources and corresponding references for this parameter selection. Your meticulous review has helped improve the accuracy and rigor of the paper. Once again, thank you for your correction and effort.

 

2. It is recommended to discuss the impact on protocol security in the event that the KGC is compromised or partially fails.

Thank you for raising this crucial issue. We fully recognize that the security of the Key Generation Center (KGC) is vital to the entire protocol framework. Your concern regarding the impact of a compromised or partially failed KGC indeed touches upon the core security assumptions of trust-based third-party authentication protocols in practical deployment.

Similar to most security protocols based on Public Key Infrastructure (PKI)—such as TLS/SSL, which typically assumes Certificate Authorities (CAs) are trusted during analysis—our protocol reasonably assumes during the design and analysis phase that the KGC is a physically and logically secure and trusted entity. This assumption serves as the foundational premise for the protocol to achieve its security objectives within the current model, allowing us to focus our research on the construction and analysis of the authentication protocol layer.

We understand that the failure of the KGC belongs to a higher-level system security engineering issue, involving multiple dimensions such as physical protection, operational procedures, and disaster recovery mechanisms, which fall outside the direct scope of this authentication protocol’s logical design. If the KGC is fully compromised, an attacker could forge credentials for any legitimate entity, exposing all protocols relying on that KGC to systemic risks. This is a common challenge inherent to centralized key management systems and not a design limitation unique to this protocol.

To more clearly define this security boundary, we have added a standalone paragraph in Section 4, "Protocol Design," of the revised manuscript, formally explaining the KGC Security as a Foundational Assumption and explicitly outlining the protocol’s security dependencies.

Furthermore, we fully agree with your perspective: enhancing the robustness of the KGC itself through mechanisms such as threshold cryptography, hardware security modules (HSM), and regular key updates is a critical aspect of future system deployment. We will briefly mention this direction in the "Future Work" section to demonstrate our ongoing attention to this issue.

Once again, we sincerely thank you for your profound and insightful review comments, which have significantly contributed to improving the rigor and completeness of the paper. We will continue to refine the related content and eagerly await your further guidance.

 

3. The authors are encouraged to supplement the related work and application background with a discussion on recent advances in chaos-based encryption for multimedia and IoT security.

Thank you for your encouraging suggestion to supplement the related work with a discussion on recent advances in chaos-based encryption for multimedia and IoT security. We greatly appreciate your guidance and have accordingly added a dedicated subsection in the revised manuscript, which has significantly enriched the background and completeness of our work.

 

4. A quantitative analysis of the scalability issue arising from storing multiple reader public keys on the tag side is suggested, particularly regarding the feasibility of this design in large-scale RFID systems.

Thank you for raising the important concern regarding scalability due to storing multiple reader public keys on tags. In response, we have added a dedicated quantitative analysis in Section 6 (Spatial Overhead). This analysis is presented in tabular form to clearly illustrate the storage requirements under different scenarios.

Furthermore, we have optimized the tag’s storage design by implementing a lightweight credential mechanism, in which tags store only a fixed-length hash digest per authorized reader instead of full public keys. This approach significantly reduces per-reader storage overhead while maintaining security.

Our updated analysis demonstrates that even in large-scale deployments involving dozens of readers, the total storage remains well within the typical 1–2 KB user memory of low-cost passive RFID tags (e.g., EPC Class 1 Gen 2). Thus, the protocol remains both feasible and scalable for practical RFID systems.

We believe these revisions directly address your valuable feedback, and we thank you again for helping strengthen the practical relevance of our work.

 

5. “Chaos-Based Video Encryption Techniques: A Review” systematically summarize and propose multi-layer and multi-directional chaos-based encryption concepts, which may help interpret high-security encryption mechanisms from a broader information security perspective and offer useful insights for the high-security RFID authentication protocol studied in this paper.

Thank you for recommending the important review article "Chaos-Based Video Encryption Techniques: A Review." We have carefully studied this paper, and its systematically proposed multi-layer, multi-directional chaos-based encryption framework has indeed provided valuable theoretical references for understanding high-security encryption mechanisms from a broader information security perspective. The in-depth analysis of the "confusion-diffusion" collaborative mechanism of chaotic systems in real-time multimedia data protection has also offered enlightening insights for the design paradigm of the high-security RFID authentication protocol studied in this paper. We have supplemented the discussion and citation of the core viewpoints from this literature, which has made the background review of this research more comprehensive and the perspective broader.

Once again, we appreciate the academic guidance you provided, as it has significantly contributed to enhancing the depth and breadth of our study.

 

6. It is recommended to include comparisons with additional post-quantum schemes, such as Kyber, FrodoKEM, and Dilithium, even if only at a qualitative level.

Thank you for recommending the inclusion of comparisons with other post-quantum schemes such as Kyber, FrodoKEM, and Dilithium. Post-quantum cryptography is an important background for this study, and we acknowledge that we overlooked such performance comparisons in the initial draft. We sincerely appreciate your reminder.

We have carefully examined the post-quantum mechanisms you suggested and have added a dedicated subsection in the revised manuscript. In this subsection, we provide a qualitative analysis comparing NTRU with Kyber, FrodoKEM, Dilithium, and classical ECC in terms of security foundations, core operations, and suitability for lightweight authentication scenarios. This addition helps to better position our protocol within the broader landscape of post-quantum cryptography and enhances the completeness of our discussion.

Thank you again for your valuable suggestion, which has strengthened the relevance and rigor of our work.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

This submission presents a mutual authentication protocol for RFID systems leveraging the NTRU encryption algorithm to achieve post-quantum security. The authors motivate their work by highlighting vulnerabilities in existing RFID protocols and the advantages of NTRU over alternatives, such as ECC, particularly in terms of quantum resistance, computational efficiency, and key management flexibility. The protocol is described in detail, including initialization and authentication phases, and is evaluated through informal security analysis, BAN-logic formal verification, AVISPA simulation, and performance comparisons with ECC. The submission is well-structured, with clear sections on related work, security requirements, protocol design, security analysis, and performance evaluation. It contributes a practical application of NTRU to RFID, addressing a gap in post-quantum protocols for resource-constrained environments. The use of multiple verification methods (BAN, AVISPA) strengthens the security claims, and the performance analysis demonstrates NTRU's efficiency advantages.

However, there are notable logical inconsistencies, factual inaccuracies, and areas for methodological improvement that undermine some claims. Overall, the submission is a solid effort but requires revisions for rigor and accuracy before publication:

1. The tag verifies the reader by checking if the received h(rR || h(idR)) matches a pre-stored h(idRi). However, this assumes the tag stores hashes for all authorized readers, which could lead to scalability issues in large systems. Logically, an attacker could replay a valid h(rR || h(idR)) from a previous session if nonces are not properly bound or if the tag does not enforce freshness checks early. The submission claims resistance to replay attacks; however, this step relies solely on a hash without a timestamp or counter, making it vulnerable if the random number (rR) is predictable or reused.
2. While the protocol achieves mutual authentication via decryption proofs (e.g., tag decrypts E_PKT to verify rT), it lacks explicit key agreement or session key derivation. The submission claims forward and backward secrecy; however, since no session keys are generated for data encryption (only authentication), this claim is misleading. Forward secrecy typically requires ephemeral keys to protect past sessions if long-term keys are compromised; here, compromising SKT would allow decryption of past ciphertexts containing nonces and hashes, potentially linking sessions.
3. The protocol claims DoS mitigation via early freshness checks and secure channels, but the backend server must decrypt E_PKS(h(idT)) for every query, which is computationally expensive. An attacker flooding with malformed E_PKS could still exhaust resources before checks, especially since NTRU decryption is not instantaneous.
4. The abstract and Section 5 state (N, p, q) = (443, 3, 2048) for 128-bit post-quantum security, citing [21]. This matches standard NTRU recommendations, but the submission inconsistently refers to " (443, 2048, 128) " in some places (likely a typo). Additionally, the decryption failure probability (<5×10^{-5}) is accurate for these params, but the submission does not discuss handling failures in the protocol (e.g., retry mechanisms), which is a practical oversight.
5. NTRU encryption ~601,800 cycles (25.1 ms at 24 MHz), ECC ~23 million cycles (958 ms). This is factually based on [27], but ECC can be optimized further (e.g., with Montgomery multiplication), and NTRU's NTT assumes hardware support that is not always available in inexpensive RFID tags.
6. Energy consumption from [9] (2005) uses outdated 0.13μm CMOS; modern processes (e.g., 22nm) would reduce values significantly for both algorithms. Claiming NTRU's energy is "one three-hundredth" of ECC is exaggerated without updated data—recent studies show closer ratios.
7. NTRU public key 610 bytes vs. ECC 128 bytes is correct, but the submission downplays this as a "price for quantum resistance" without quantifying the impact on low-cost tags (e.g., EPC Class 1 tags have ~1-2 KB storage).
8. It is better to use a tabular presentation instead of Figure 3. It is better to use a text presentation instead of Figure 5. Also, the conclusions do not fully reveal the results presented in the submission.

Comments for author File: Comments.pdf

Author Response

Dear Reviewer,

Thank you very much for your thorough and insightful review of our manuscript. We

sincerely appreciate the time and expertise you have dedicated to evaluating our work

and for providing such constructive and detailed comments. Your feedback has been

invaluable in helping us improve the clarity, rigor, and completeness of the paper. We

have carefully addressed each of the points raised, and the corresponding revisions have

been incorporated into the manuscript. Below, we provide a point-by-point response to

your comments.

Comment 1: The tag verifies the reader by checking if the received h(rR || h(idR))

matches a pre-stored h(idRi). However, this assumes the tag stores hashes for all

authorized readers, which could lead to scalability issues in large systems. Logically, an

attacker could replay a valid h(rR || h(idR)) from a previous session if nonces are not

properly bound or if the tag does not enforce freshness checks early. The submission

claims resistance to replay attacks; however, this step relies solely on a hash without a

timestamp or counter, making it vulnerable if the random number (rR) is predictable or

reused.

Response: We thank you for raising this important concern regarding both

scalability and replay attack resistance. We have substantially revised the protocol

design and its explanation to address these points.

1. Scalability optimization: In the revised protocol (Section 4.3), the tag no longer

needs to store a separate hash for each authorized reader. Instead, it stores a 32-byte

combined hash credential `H(PK_R)` for each reader, which is generated by the trusted

KGC during system initialization. This credential simultaneously authenticates the

reader's identity and the legitimacy of its public key. The scalability impact is now

quantitatively analyzed in Section 6.1, where we demonstrate that even with 30

authorized readers, the total storage overhead (≈1.77 KB) remains within the 1–2 KB

user memory of typical low-cost passive tags (e.g., EPC Class 1 Gen 2).

2. Replay attack resistance: We have clarified and strengthened the freshness

mechanism. The initial random number `r_R` is generated by a Hash_DRBG

(Deterministic Random Bit Generator based on a hash function), ensuring its uniqueness

and unpredictability. More importantly, session freshness is not guaranteed by `r_R`

alone but by a multi-stage challenge-response mechanism involving `r_T` and `r_S`. The

tag's response (`E_PK_R(r_R || r_T || E_PK_S(h(id_T)))`) is encrypted with the legitimate

reader's public key. Even if an attacker replays the initial request, they cannot decrypt the

tag's subsequent encrypted response and therefore cannot pass the later, more critical

verification stages (`r_T` and `r_S` decryption proofs). This layered approach

fundamentally prevents replay attacks without relying on stateful components like

counters. We have expanded the security analysis in Section 5.1 to explicitly explain this

defense.

Comment 2: While the protocol achieves mutual authentication via decryption proofs(e.g., tag decrypts E_PKT to verify rT), it lacks explicit key agreement or session key

derivation. The submission claims forward and backward secrecy; however, since no

session keys are generated for data encryption (only authentication), this claim is

misleading. Forward secrecy typically requires ephemeral keys to protect past sessions if

long-term keys are compromised; here, compromising SKT would allow decryption of

past ciphertexts containing nonces and hashes, potentially linking sessions.

Response: We thank you for this critical observation, which prompted us to refine

and clarify our security claims.

1. Clarification of protocol objectives: As highlighted in the revised Section 5.1, the

core objective of this protocol is secure mutual authentication and entity privacy

protection, not the establishment of a session key for subsequent data encryption. This

design aligns with the typical operational model of many RFID systems, where after

successful authentication, the tag's identity is recognized, and all associated data is

retrieved from the secure backend server. Therefore, no continuous data stream

requiring encryption is established post-authentication.

2. Refined definition of forward/backward secrecy in our context: We have redefined

the claimed forward secrecy property more precisely as session unlinkability and forward

security of authentication credentials. Even if an adversary compromises the tag's

long-term private key `SK_T` in the future and decrypts previously captured ciphertexts,

they would only recover session-specific, one-time random numbers (`r_T`, `r_S`, `c`) and

a hash value `h(id_T)`. These components are cryptographically independent per session

and cannot be used to (a) derive valid authentication credentials for other sessions or (b)

link multiple sessions to the same tag. This effectively protects tag identity privacy and

ensures session isolation, which is the intended forward security goal for an

authentication-centric system.

3. Inherent backward secrecy: Correspondingly, since no session keys are ever

derived, there is no key material whose compromise could jeopardize future sessions.

Therefore, the protocol inherently provides backward secrecy within its defined security

model.

We have revised the relevant passages in Sections 5 to present these claims with

greater precision and to avoid potential misunderstanding.

Comment 3: The protocol claims DoS mitigation via early freshness checks and

secure channels, but the backend server must decrypt E_PKS(h(idT)) for every query,

which is computationally expensive. An attacker flooding with malformed E_PKS could

still exhaust resources before checks, especially since NTRU decryption is not

instantaneous.

Response: Thank you for highlighting this aspect of DoS vulnerability. We have

enhanced the description of our layered defense strategy in Section 5.1.

1. First line of defense – lightweight source authentication: Before the backend

server performs any NTRU decryption, it first performs a lightweight legitimacy

verification of the incoming request. This is feasible because a secure authenticated

channel (as assumed in our model, Section 4.1) is established between the reader and

the server. This channel establishment includes the negotiation of authenticationcredentials (e.g., a shared key or certificates). The server can therefore verify a Message

Authentication Code (MAC) attached to the request with minimal computational cost,

effectively filtering out flooding requests from unauthenticated sources.

2. Second layer – controlled resource expenditure: Only requests that pass this

initial authentication are forwarded to the more computationally expensive NTRU

decryption stage. This two-tiered approach makes it significantly harder for an attacker

to directly exhaust the server's decryption resources by flooding with random or

malformed ciphertexts.

We acknowledge that absolute DoS resistance is challenging, but our design aims to

raise the cost of attack substantially by leveraging the pre-existing secure channel

assumption, which is reasonable in many practical RFID deployments.

Comment 4: The abstract and Section 5 state (N, p, q) = (443, 3, 2048) for 128-bit

post-quantum security, citing [24]. This matches standard NTRU recommendations, but

the submission inconsistently refers to " (443, 2048, 128) " in some places (likely a typo).

Additionally, the decryption failure probability (<5×10⁻⁵) is accurate for these params,

but the submission does not discuss handling failures in the protocol (e.g., retry

mechanisms), which is a practical oversight.

Response: We sincerely apologize for the inconsistency and omission.

1. Parameter notation unified: We have corrected all instances and unified the

parameter notation throughout the manuscript as (N, p, q) = (443, 3, 2048).

2. Decryption failure tolerance mechanism added: We have added a new subsection,

Section 4.4: "Decryption Failure Tolerance Mechanism". This section describes a

concise fault-tolerance strategy: after a critical decryption step fails validation, the

current session is terminated, and the original initiator (reader or server) is allowed one

automatic retry. With one retry, the combined decryption failure probability drops to

approximately 25 × 10⁻¹⁰, which is negligible. If the retry also fails, the session is

terminated and flagged as abnormal. This lightweight mechanism enhances protocol

robustness without introducing complex state management on resource-constrained

devices.

Comment 5: NTRU encryption ~601,800 cycles (25.1 ms at 24 MHz), ECC ~23

million cycles (958 ms). This is factually based on [30], but ECC can be optimized further

(e.g., with Montgomery multiplication), and NTRU's NTT assumes hardware support that

is not always available in inexpensive RFID tags.

Response: We appreciate this note on contextualizing performance data.

1. Citation corrected and context clarified: We have corrected the citation to the

benchmarking source [30] (`pqm4` project). In Section 6.2, we have added a clarifying

note stating that these comparative figures exist within a specific benchmarking context

and that the performance of concrete implementations can be influenced by the degree

of optimization and available hardware support.

2. Emphasis on algorithmic efficiency trend: We maintain that the cited data reflectsa well-established trend: the core polynomial convolution operation of NTRU is

structurally more efficient and amenable to optimization (both in software and, where

available, with NTT acceleration) than the sequence of finite field operations required for

ECC scalar multiplication. Even considering potential optimizations for both, NTRU

retains a significant efficiency advantage, which is crucial for energy-constrained RFID

tags. We have tempered the language to present this as a consistent performance trend

rather than an absolute, implementation-independent fact.

Comment 6: Energy consumption from [9] (2005) uses outdated 0.13 μ m CMOS;

modern processes (e.g., 22nm) would reduce values significantly for both algorithms.

Claiming NTRU's energy is "one three-hundredth" of ECC is exaggerated without

updated data—recent studies show closer ratios.

Response: Thank you for this valid criticism. We have completely revised the energy

consumption analysis in Section 6.3.

1. Updated references and qualitative analysis: We have removed the specific

quantitative comparison based on the outdated [9] and instead conducted a qualitative

analysis based on trends observed in recent independent studies targeting modern

embedded platforms (e.g., ARM Cortex-M4). We cite recent works [31, 32] which

indicate that optimized NTRU implementations achieve energy consumption in the

microjoule ( μ J) range per operation, while classical ECC, even with optimizations,

typically remains in the millijoule (mJ) range.

2. Revised claim: We now state that NTRU operates at an order of magnitude lower

in energy consumption compared to classical ECC, which is consistent with its superior

computational efficiency. We have removed the precise "one three-hundredth" claim

from the abstract and Section 6.3 to ensure accuracy and focus on the fundamental

efficiency advantage.

Comment 7: NTRU public key 610 bytes vs. ECC 128 bytes is correct, but the

submission downplays this as a "price for quantum resistance" without quantifying the

impact on low-cost tags (e.g., EPC Class 1 tags have ~1 - 2 KB storage).

Response: We have significantly expanded the storage analysis in Section 6.1 to

directly address this concern.

1. Quantified impact analysis: We now provide a detailed breakdown of the tag's

storage overhead, introducing the formula: Total Storage = 854 + 32n bytes, where `n` is

the number of authorized readers.

2. Feasibility demonstration: Using this formula, Table 8 shows concrete examples:

for 10, 15, and 30 readers, the total storage is 1.17 KB, 1.33 KB, and 1.77 KB,

respectively. This clearly demonstrates that even with a substantial number of readers,

the storage requirement remains within the 1–2 KB user memory of low-cost passive

tags (EPC Class 1 Gen 2).

3. Conclusion strengthened: We conclude that through careful lightweight storage

optimization (storing compact hash credentials instead of full keys), the protocol

achieves a post-quantum security upgrade with minimal and feasible storage cost,

effectively addressing the scalability concern for large-scale deployments.

Comment 8: It is better to use a tabular presentation instead of Figure 3. It is better

to use a text presentation instead of Figure 5. Also, the conclusions do not fully reveal the

results presented in the submission.

Response: Thank you for these presentation and concluding remarks.

1. Figure 3 replaced: As suggested, the generic bundle diagram (original Figure 3)

has been removed. The strand space analysis in Section 5.1 now relies solely on clear

textual and mathematical descriptions, improving readability and saving space.

2. Figure 5 replaced: The original simulation report figure (Figure 5) has been

replaced with a concise textual summary of the AVISPA verification results in Section 5.3,

stating that the protocol was found to be "SAFE" under the OFMC and CL-AtSe

backends, satisfying authentication and secrecy goals.

3. Conclusions rewritten: We have thoroughly rewritten Section 7 (Conclusion). The

new conclusion is structured into three clear points that directly correspond to and

summarize the paper's core contributions: (1) High Security & Quantum Resistance, (2)

Optimized Performance & Feasibility, and (3) Systematic Protocol Design & Analysis. This

new presentation more effectively reveals and synthesizes the key results of the work.

Additional minor corrections: We have also performed a thorough proofreading to

correct typographical errors, improve language fluency, and ensure consistency in

terminology and citation formatting throughout the manuscript.

Once again, we are deeply grateful for your expert review and constructive guidance.

We believe that the revisions made in response to your comments have significantly

strengthened the manuscript's validity, clarity, and impact. We hope the revised version

now meets the journal's standards for publication.

Sincerely,

The Authors

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

I really appreciate the authors' revisions, which effectively address the issues that were raised.