{"id":"1ec576d9-f0cf-4a8f-abff-e2250b78480f","arxiv_id":"2509.06112","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"The paper introduces LP2-CASKU, a drone-cluster authentication protocol combining batch joining, private cross-cluster moves, and session-key updates, but the protocol's signature computation and security proofs do not work as written.","lead":"This paper proposes a security protocol for drone swarms that lets new drones join a group and lets drones move between groups without leaking their identity or the group's secret key. It claims large speed and energy gains in simulation, but the central cryptographic step appears impossible for a drone to compute as described.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Join-phase 'signature' sig_k uses no NUAV secret: any party knowing the shared H(CJT) can forge it, so the batch authentication does not authenticate NUAVs.","rationale":"The reader's verdict REJECT remains appropriate, but the specific weakest assumption they named is false. The protocol is not non-executable; it is executable but does not do what the paper claims. The load-bearing problem is that sig_k is a function of public/known values and the shared token H(CJT), not of the NUAV's private key. A formal or simulated test of Eq. (25) under an attacker-chosen (sk*, PID*, v*) settles the point. Because this flaw undermines the first of the three contributions, and the performance evaluation is built on the MAm join flow, the rejection stands even though the stated reason differs. I set agreement_with_reader to partial rather than agree because the reader and I locate the failure in the same equations but with opposite technical mechanisms: they say the NUAV cannot compute the value; I say it can, and that is precisely why the value does not authenticate it.","tokens_in":25519,"tokens_out":10746,"duration_ms":97325,"concrete_test":"Implement a simulated impersonation in the Join Phase: take H(CJT_{i,j}) as the only secret, choose attacker-controlled (sk*, r*, v*) with sk* unrelated to any registered NUAV, set pk* = g^{sk*}, PID* = H(sk*, r*), V* = g^{v*}, and compute sig* via Eqs. (22)-(23). Run the CH aggregation of Step 3 and the CM verification Eq. (25). If the verification succeeds, the Join Phase authenticates no NUAV secret and the impersonation concern is confirmed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The reader's pinpointed non-computability is not correct: D_k = pk_GBS^{H(CJT)} * pk_CH = g^{sk_CH}, so D_k^{v_k w_k} can be computed from H(CJT) and public keys without sk_CH. The real flaw is worse. In Section 4.2.3, Eqs. (22)-(25), the NUAV's private key sk_NUAV never appears in the join token: sig_k uses only D_k, the random v_k, and public values in w_k = H(PID_NUAV, PID_CH, pk_NUAV). Any party that knows H(CJT_{i,j}) - which is sent to every NUAV in Step 1 and is cluster-wide, not per-UAV - can choose an arbitrary PID_NUAV and pk_NUAV = g^{sk'}, compute a fresh V_k = g^{v_k}, and form a valid sig_k that passes the CH's aggregation and the CM verification Eq. (25). Moreover, the NUAV join message carries no timestamp or session challenge, so a recorded {PID_NUAV, pk_NUAV, V_k, sig_k} can be replayed unchanged. Thus the batch authentication does not establish that the sender possesses any GBS-issued per-UAV secret; it only tests knowledge of a shared cluster token. Since Challenge 1 and security goal S1 rest on NUAV authenticity, the central claim of reliable dynamic join authentication - and the latency/energy numbers measured for it - collapses.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes LP2-CASKU, a suite of mechanisms for authenticating UAVs that join or move between clusters in a hierarchical low-altitude economy network. The design has three parts: a message aggregation mechanism for batch authentication of new UAVs (NUAVs) by a cluster head and its members, a lightweight cross-cluster authentication mechanism for existing UAVs (EUAVs) based on a shared cross-cluster token, and a polynomial-based cluster session key update mechanism to provide forward and backward secrecy. The authors claim security goals S1–S7, provide a formal analysis for S6 and S7 (deferred to a supplementary file), and evaluate latency and energy with OMNeT++ simulations, reporting large reductions relative to a version of the scheme without aggregation.","tokens_in":25869,"tokens_out":10201,"duration_ms":84358,"significance":"If the protocol were correct, LP2-CASKU would be a useful contribution: dynamic UAV cluster authentication with batch aggregation, privacy-preserving cross-cluster handover, and key-update secrecy is genuinely important, and the paper's system model, threat model, and performance-evaluation framework are carefully constructed. The overhead tables and the parameter sweeps over NUAV/CM/CH counts and network bitrate are strengths. However, the central authentication mechanism does not actually authenticate NUAVs, the main verification equation does not balance even for honest parties, and the formal security analysis is circular. These are load-bearing defects, so the paper's central claims and performance numbers cannot be accepted as demonstrating reliable service provisioning.","major_comments":[{"comment":"The join token sig_k does not involve the NUAV's private key sk_NUAV. Since D_k = pk_GBS^{H(CJT)} * pk_CH = g^{sk_CH}, the value sig_k = D_k^{v_k w_k} is computable from public keys, the hash H(CJT), and the chosen v_k. The value H(CJT) is sent to every NUAV in Step 1 and is cluster-wide, not a per-UAV secret. Consequently, any party knowing H(CJT) can choose arbitrary PID_NUAV and pk_NUAV, pick v_k, and produce a valid tuple {PID_NUAV, pk_NUAV, V_k, sig_k} that passes the CM verification in Eq. (25). The batch authentication therefore does not establish possession of any GBS-issued per-UAV secret; it only tests knowledge of a shared cluster token. In addition, the join message contains no timestamp or nonce, so a recorded tuple can be replayed. This invalidates S1 and S6 for NUAV authentication, which is the central claim of the paper.","section":"Section 4.2.3, Eqs. (22)-(25)"},{"comment":"The CH's aggregate-verification equation does not balance. With sig_{CM} = g^{(N*H(result) - sk_{CM}*M) / s}, where N = N_{i,j,CM}, and with sig_CMs = ∏ sig_{CM_l}^{s_l} and pk_CMs = (∏ pk_{CM_l})^M as displayed in Eq. (34), the right-hand side of Eq. (33) evaluates to g^{N^2 * H(result)} rather than g^{H(result)}. For N > 1 the equality cannot hold. Therefore an honest set of CMs will fail the Step 5 verification, and the neighboring CHs' verification in Eq. (38), which uses the same aggregate, will also fail. The join protocol is not executable even in the absence of an adversary.","section":"Section 4.2.3, Eq. (33) with Eqs. (30), (34)"},{"comment":"The mutual-authentication step cannot succeed as written. Eq. (41) defines res_k = H(H(CJT), PID_NUAV_k, pk_CH_{i,j}), while Eq. (42) defines res'_k = H(H(CJT), PID_NUAV_k). The two arguments differ by the inclusion of pk_CH_{i,j}, so for a collision-resistant hash the claimed equality res'_k = res_k will never hold. Thus the NUAV cannot verify the CH in Step 8, contradicting the claimed mutual authentication.","section":"Section 4.2.3, Steps 7-8, Eqs. (41)-(42)"},{"comment":"The formal security analysis is circular. Theorem 1 assumes that the adversary's advantage in DUG is negligible (Eq. (53)) and then concludes that S6 holds; that is the definition of the security goal, not a derivation. No reduction to DLP or DHP is shown in the main text, and the proof is deferred to a supplementary file. Theorem 2 has the same structure for S7. As presented, the formal analysis provides no evidence for S6 or S7, and the illustrative argument for S1 in Section 5.2 relies on the false premise that knowledge of H(CJT) is a per-NUAV credential, which is contradicted by Major Comment 1.","section":"Section 5.1, Theorems 1-2 and Eq. (53)/(55)"}],"minor_comments":[{"comment":"There are repeated typos, including 'computationly' (Sections 1 and 3.1), 'Vechiles' (Section 7), 'by across' (Abstract), and 'The minor latency introduce' (Section 6.3.2).","section":"Throughout"},{"comment":"After defining the Data Confidentiality Game, the text says 'DUG is detailed as follows' where DCG is meant. Also, Eq. (14) uses f(x_n) before x_n has been defined in the surrounding text.","section":"Section 3.2.4, DCG definition"},{"comment":"The reference to 'Sections 4.2.1 and 2' should presumably be 'Sections 4.2.1 and 4.2.2'.","section":"Section 6.1, computation overhead"},{"comment":"The claim that 'generating a valid sig_k requires knowledge of H(CJT)' should be stated as 'any party knowing the cluster-wide H(CJT)' because H(CJT) is not a per-UAV secret; this wording obscures the fact that the token is shared.","section":"Section 5.2, S1"}],"recommendation":"reject","confidential_remarks":"The most serious issue is in the Join Phase: the 'signature' sig_k is forgeable by anyone who knows H(CJT), a value distributed to all NUAVs of the cluster, and the aggregate verification in Eq. (33) does not hold for honest parties. These are design-level defects, not presentation issues; fixing them would require replacing the join-authentication mechanism, reworking the verification equations, and re-running the security analysis and performance evaluation. I would note for the editor that the specific concern about non-computability of Eq. (22) is not the strongest basis for rejection: D_k = g^{sk_CH} is in fact computable from public values, but that computability is precisely what makes the token forgeable without any NUAV secret."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper's central authentication mechanism doesn't authenticate anyone. In Join Phase Step 2, the NUAV computes sig_k = D_k^{v_k w_k} with D_k = pk_GBS^{H(CJT)} * pk_CH = g^{sk_CH}. That value is computable from public keys plus H(CJT), which is sent to every NUAV in the cluster. The NUAV's private key never appears. Any party knowing H(CJT) can pick an arbitrary PID and public key, choose its own v_k, and produce a valid join token that passes the CM and CH verification equations. There is also no timestamp or challenge, so recorded tokens replay. The stress-test note is right, and it is worse than the reader's original pinpoint: the reader said the NUAV cannot compute sig_k because sk_CH is missing, but actually the computation is possible; the real problem is that it proves nothing about the NUAV. Same story in the Cross-cluster Phase: C_{i,j} = H(PID, T3, CT) XOR CT, and CT is known to all CHs, so the destination CH learns nothing about whether the EUAV possesses any secret. The formal security analysis is circular (Theorem 1 assumes the advantage is negligible and then concludes the scheme is secure), and the actual proofs are deferred to a missing supplementary file. The performance numbers are also against the paper's own baseline without MAm, not against any comparable scheme, so the reported 82.8%-90.8% latency reduction is not evidence of advantage over prior work. What the paper does well is organize the problem space: Table 1 gives a reasonable comparison of which prior schemes cover batch join, cross-cluster authentication, key update, and privacy. The system model and design goals are clearly stated. But a protocol whose batch authentication can be forged by anyone holding a shared token, and whose cross-cluster authentication likewise proves no secret knowledge, does not deserve referee time as a secure scheme. It could potentially be revised into something real, but the current text is not sound enough to serve as a baseline for others. I would not cite it, and I would not bring it to reading group except as a cautionary example of a signature that does not bind to the intended party's secret.","headline":"The join-phase signature in LP2-CASKU uses no NUAV secret, so any party knowing the shared H(CJT) can forge it; the paper's central authentication claim collapses.","tokens_in":26415,"tokens_out":2660,"would_cite":false,"duration_ms":24858,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims a single protocol—batch drone onboarding, unlinkable cross-cluster authentication, and polynomial session-key updates—cuts join latency by 82.8–90.8% and energy by 37.6–72.6% in simulation versus its non-aggregated…","keywords":["Entity authenticity","Low-altitude economy","Privacy preservation","Service reliability","UAV cluster","Batch authentication","Forward secrecy","Unlinkability"],"falsifier":"Re-implement the Join Phase exactly as specified in Section 4.2.3 and have a would-be new drone compute its signature from the public parameters distributed by the ground station; if the cluster head cannot verify the aggregated batch through the single hash check (Eq. (25) in the paper), the central mechanism is not implementable. Separately, capture two cross-cluster authentication sessions of the same existing drone and try to link the two pseudonyms using the public token; any such link defeats the unlinkability claim.","tokens_in":25332,"feed_emoji":"🛰️","tokens_out":12301,"duration_ms":99541,"temperature":0.7,"pith_summary":"The paper proposes LP2-CASKU, a lightweight and privacy-preserving protocol for authenticating drones that join a cluster or move between clusters in a low-altitude economy network. It claims to solve three problems at once: authenticating several new drones in one batch, authenticating a migrating drone without revealing or linking its identity, and updating the cluster session key so that joining drones cannot read past traffic and departing drones cannot read future traffic. If the claims hold, the batch mechanism alone cuts join-phase latency by roughly 82.8–90.8% and energy consumption by 37.6–72.6% compared with the same protocol without aggregation, while the cross-cluster step costs only a few hashes and XORs. The case is made by formal game-based security analysis, a theoretical cost breakdown, and a discrete-event simulation of a small swarm.","feed_headline":"Batch authentication cuts drone-cluster join latency by up to 90.8%","feed_subtitle":"If right, the scheme also anonymizes cross-cluster drone moves and keeps cluster keys secret as members join or leave.","key_machinery":"The central machinery is a message-aggregation layer on top of exponentiation-based signatures in $\\mathbb{Z}_p^*$: an aggregated signature $\\mathit{sig}_{\\mathrm{NUAVs}} = H((\\prod_k \\mathit{sig}_k)^{sk_{\\mathrm{CH}}^{-1}}) \\oplus key$, an aggregated verification $g^{H(\\mathit{result})} \\stackrel{?}{=} \\mathit{sig}_{\\mathrm{CMs}} \\cdot pk_{\\mathrm{CMs}}$, and a polynomial secret-sharing scheme for session-key update. The aggregation does the heavy lifting: it makes authentication cost nearly independent of the number of new drones and cluster members, and it is what converts $N$ individual join flows into one broadcast. The cross-cluster sub-mechanism rides on the shared communication token $CT$ and a one-way hash that produces fresh pseudonyms, while the key-update sub-mechanism uses polynomial interpolation at points $x_l = H(\\mathit{PID}_{\\mathrm{CM},l})$ to reconstruct $key_{\\mathrm{new}}$ only among current members.","core_discovery":"The paper's central discovery is that the three requirements—cheap batch onboarding, anonymous and unlinkable cross-cluster migration, and session-key secrecy under joins and departures—can be combined in a single protocol built only on a multiplicative group $\\mathbb{Z}_p^*$, hash functions, exponentiation, and XOR, with no bilinear pairings and no blockchain. The load-bearing trick is the signature relation: each new drone $k$ produces $\\mathit{sig}_k = D_k^{v_k w_k}$, where $D_k = pk_{\\mathrm{GBS}}^{H(\\mathrm{CJT})}\\cdot pk_{\\mathrm{CH}}$ equals $g^{sk_{\\mathrm{CH}}}$; because the cluster head knows $sk_{\\mathrm{CH}}$, it raises the product of all incoming signatures to $sk_{\\mathrm{CH}}^{-1}$, turning the batch into one group element that all cluster members verify with a single hash equation. For cross-cluster moves, a shared token $CT$ lets a destination head check an EUAV's pseudonym and immediately mint a fresh pseudonym $\\mathit{PID}_{\\mathrm{new}} = H(\\mathit{PID}_{\\mathrm{old}}, T_3, CT)$, so sessions cannot be linked. For key updates, a degree-$(N_{CM}-1)$ polynomial distributes the new session key to current members, which the paper argues gives forward and backward secrecy.","pith_inferences":["Beyond the paper, the reported 82–90% figures measure aggregation gain against a non-aggregated version of the same protocol, not a head-to-head win against the blockchain-based schemes the paper cites; a direct cross-protocol comparison remains untested.","Beyond the paper, the anonymity and unlinkability guarantees are only as strong as the shared token $CT$; if any ground base station leaks it, an adversary could recompute $\\mathit{PID}_{\\mathrm{new}} = H(\\mathit{PID}_{\\mathrm{old}},T_3,CT)$ and link a drone's sessions, concentrating the privacy claim in trust of the base stations.","Beyond the paper, the formal security theorems are deferred to a supplementary file, so a reader relying on forward and backward secrecy should check that the games cover the departing-member and joining-member cases explicitly rather than by illustrative argument.","A testable extension would be to replace the fixed polynomial key update with a proactive, verifiable variant so that a single corrupted cluster member cannot inject bogus shares during reconstruction."],"forward_implications":["New-drone onboarding scales almost flat: with 3 to 7 new UAVs and fixed cluster size, join latency moves from 9.86 ms to 14.15 ms with aggregation, versus 57.43 ms to 132.98 ms without it.","The benefits are largest on weak links: at a 1 Mbps network bitrate, aggregation brings join latency from 566.51 ms to 59.72 ms, an 89.5% cut.","A migrating existing UAV can be authenticated at a cost of roughly 3 hash operations, 2 XORs, 3 group elements, and a timestamp, which is far cheaper than onboarding a new UAV.","Every join triggers a session-key update that excludes the newcomer from past keys, and every departure triggers an update that excludes the leaver from future keys, via polynomial shares that only current members can reconstruct.","Message aggregation also lowers energy use: the cluster head's consumption drops by about 72.6% as the number of new UAVs grows, and other cluster heads drop by about 62.9%.","Beyond the paper, the reported 82–90% figures measure aggregation gain against a non-aggregated version of the same protocol, not a head-to-head win against the blockchain-based schemes the paper cites; a direct cross-protocol comparison remains untested.","Beyond the paper, the anonymity and unlinkability guarantees are only as strong as the shared token $CT$; if any ground base station leaks it, an adversary could recompute $\\mathit{PID}_{\\mathrm{new}} = H(\\mathit{PID}_{\\mathrm{old}},T_3,CT)$ and link a drone's sessions, concentrating the privacy claim in trust of the base stations.","Beyond the paper, the formal security theorems are deferred to a supplementary file, so a reader relying on forward and backward secrecy should check that the games cover the departing-member and joining-member cases explicitly rather than by illustrative argument."],"supporting_citations":[{"why":"Supplies the discrete-logarithm hardness assumption that underlies the unforgeability of the aggregated signatures.","marker":"[29]"},{"why":"Supplies the Diffie-Hellman hardness assumption used in the session-key and signature security arguments.","marker":"[30]"},{"why":"Defines the Dolev-Yao adversarial model of full channel control that the scheme claims to resist.","marker":"[31]"},{"why":"Provides the cryptographic-game definitions used to formulate the data unforgeability and confidentiality games.","marker":"[32]"},{"why":"Provides the game-sequences proof technique used for the formal security theorems.","marker":"[33]"},{"why":"Network simulator used to produce the reported latency and energy numbers.","marker":"[28]"},{"why":"Supplies the single-sign-on principle on which the lightweight cross-cluster authentication is modeled.","marker":"[34]"},{"why":"Provides the hierarchical GBS-CH-CM swarm architecture that the system model assumes.","marker":"[14]"}],"fun_headline_variants":["Drone-cluster joins 90% faster with batch auth and key secrecy","Privacy-preserving UAV cluster auth cuts latency 90.8%","Batch auth slashes drone join latency by up to 90.8%","Anonymous cross-cluster drone migration with lower latency","UAV cluster onboarding 90% faster while keeping keys secret"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol assumes every ground base station is fully trusted, each cluster head is trusted by its members, and all registration messages travel over secure channels; if any of these premises fails, the authentication and privacy guarantees collapse.","fun_headline_variants_meta":{"raw":{"variants":["Drone-cluster joins 90% faster with batch auth and key secrecy","Privacy-preserving UAV cluster auth cuts latency 90.8%","Batch auth slashes drone join latency by up to 90.8%","Anonymous cross-cluster drone migration with lower latency","UAV cluster onboarding 90% faster while keeping keys secret"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00058,"raw_usage":{"total_tokens":2832,"prompt_tokens":1143,"completion_tokens":1689,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":759,"completion_tokens_details":{"reasoning_tokens":1599}},"tokens_in":759,"tokens_out":1689,"duration_ms":10883,"temperature":1.0,"reasoning_tokens":1599,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T16:19:12.958143+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-implement the Join Phase exactly as specified in Section 4.2.3 and have a would-be new drone compute its signature from the public parameters distributed by the ground station; if the cluster head cannot verify the aggregated batch through the single hash check (Eq. (25) in the paper), the central mechanism is not implementable. Separately, capture two cross-cluster authentication sessions of the same existing drone and try to link the two pseudonyms using the public token; any such link defeats the unlinkability claim.","supporting_citations":[{"cited_title":"The discrete logarithm problem,","cited_arxiv_id":null,"evidence_quote":"Supplies the discrete-logarithm hardness assumption that underlies the unforgeability of the aggregated signatures."},{"cited_title":"The Static Diffie-Hellman Problem,","cited_arxiv_id":null,"evidence_quote":"Supplies the Diffie-Hellman hardness assumption used in the session-key and signature security arguments."},{"cited_title":"On the Security of Public Key Protocols,","cited_arxiv_id":null,"evidence_quote":"Defines the Dolev-Yao adversarial model of full channel control that the scheme claims to resist."},{"cited_title":"An Introduction to Provable Security,","cited_arxiv_id":null,"evidence_quote":"Provides the cryptographic-game definitions used to formulate the data unforgeability and confidentiality games."},{"cited_title":"Sequences of Games: A Tool for Taming Complexity in Security Proofs,","cited_arxiv_id":null,"evidence_quote":"Provides the game-sequences proof technique used for the formal security theorems."},{"cited_title":"OMNeT++ 6.0.3,","cited_arxiv_id":null,"evidence_quote":"Network simulator used to produce the reported latency and energy numbers."},{"cited_title":"Single Sign-On Architectures,","cited_arxiv_id":null,"evidence_quote":"Supplies the single-sign-on principle on which the lightweight cross-cluster authentication is modeled."},{"cited_title":"Intelligent UAV Swarm Cooperation for Multiple Targets Tracking,","cited_arxiv_id":null,"evidence_quote":"Provides the hierarchical GBS-CH-CM swarm architecture that the system model assumes."}],"review_version":1}