{"id":"778f6e12-e995-4f03-adaf-7f985a2a40bd","arxiv_id":"2411.18027","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":2,"one_line_summary":"The paper describes a crypto-biometric multi-factor authentication protocol for robotic delivery and an audio-visual fusion transformer for adversarial defense, but the security proof, symbolic tool results, and baseline comparisons are missing.","lead":"This paper proposes a multi-factor authentication scheme for robot package delivery that combines cryptographic keys with face and voice verification, plus a transformer-based denoiser to resist adversarial machine learning attacks. The protocol's formal security proof and symbolic verification outputs are absent from the manuscript, and the defender is not compared to existing defenses, so the claims rest on incomplete evidence.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The promised formal security analysis and ProVerif/Scyther validation are absent from the manuscript, so the central claim of a rigorously verified privacy-preserving MFA scheme is unsupported; the protocol's security rests on an unmodeled secure-channel and robot-trust assumption.","rationale":"I read the paper in good faith as a draft proposing a robotic-delivery MFA system that combines ECDH/ECDSA with face/voice verification and a transformer-based audio-visual fusion defender. For the central claim to hold, the protocol must be demonstrably secure and the defender must demonstrably improve robustness. The most load-bearing gap is the total absence of the promised formal security analysis and ProVerif/Scyther validation. Without those, the security properties asserted in the abstract are not established by the manuscript itself. This is not merely a presentation issue: the protocol's only security argument is the message sequence in Fig. 4 and the informal text, and the physical-capture discussion explicitly limits its guarantee to past sessions, leaving the current session's subkey and index recoverable from the robot. The reader's weakest_assumption identified the secure-channel/robot-capture issue, which is closely related and partially overlaps with my concern, but the reader's designated weakest assumption was not the same as mine: I focus on the missing formal verification as the primary load-bearing defect, with the robot-trust assumption as the concrete reason why the absence matters. I do not see an internally inconsistent cryptographic step that would require a different verdict; rather, the central claims are unsupported by the provided evidence. The reader's REJECT verdict is therefore appropriate, and my analysis does not change it. The concrete test I propose would settle whether the protocol actually satisfies its security goals by reconstructing the formal model and checking the reachable attack states; in parallel, a simple inspection of the PDF and linked repository would confirm whether the promised ProVerif/Scyther artifacts exist at all.","tokens_in":21807,"tokens_out":6484,"duration_ms":63435,"concrete_test":"Independently reconstruct the protocol's Dolev-Yao model from Fig. 4 and Section IV in ProVerif or Scyther, including the robot as a party that receives (key, index, embeddings) over the 'Security Channel' and then checks the subkey locally. Query for authentication, secrecy of the subkey, and unlinkability; if the tool finds an attack when the security channel is modeled as public, or when the robot's stored state is readable after physical capture, the central security claim fails. Also inspect the Google Drive link for ProVerif/Scyther scripts and formal proofs; if none exist, the claim of symbolic verification is unsupported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The abstract's central claim includes a 'rigorous formal analysis' and ProVerif/Scyther symbolic verification. No such analysis appears in the manuscript: Section III.C.3 promises unlinkability 'details are provided in Section ??', and Section VI says 'Lastly, we validate the security ... through ProVerif and Scyther' but then presents only implementation cost, power consumption, and AI-defender accuracy/EER. There is no security-analysis subsection, no ProVerif/Scyther model, no trace output, no reduction proof, and no appendix containing the missing material. The protocol's claimed security properties (mutual authentication, PFS, unlinkability, replay/MITM resistance) therefore rest on an unverified message sequence. In particular, the authentication phase (Fig. 4) sends the session key and chosen index to the robot over an assumed 'Security Channel' and stores them on the robot; the paper's own physical-capture discussion (Section VI.B.4) only claims protection of past sessions, leaving the current session's subkey recoverable from robot memory. The multi-factor and privacy claims are thus load-bearing on a trusted-robot/secure-channel assumption that is neither formally modeled nor experimentally challenged, and the promised formal verification that would support the central claim is absent.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a privacy-preserving multi-factor authentication scheme for robotic delivery systems, combining ECC-based cryptographic key exchange and digital signatures with face and voice biometric verification. It also introduces a transformer-based audio-visual fusion 'defender' intended to reconstruct inputs before verification, thereby mitigating adversarial examples, and reports a real-world implementation on a Turtlebot3 with Raspberry Pi 3, including computational cost and power consumption measurements. The abstract and introduction claim a rigorous formal security analysis using ProVerif and Scyther, along with resistance to impersonation, replay, man-in-the-middle, and linkability attacks.","tokens_in":22001,"tokens_out":3238,"duration_ms":32736,"significance":"If fully substantiated, the proposed system would address a real gap: robotic last-mile delivery currently lacks an integrated multi-factor authentication protocol that combines cryptographic security with biometric verification and defends against ML-based adversarial inputs. The paper gives credit for a concrete hardware implementation, energy consumption measurements, and a defender architecture that is evaluated against five attack types. However, the central verification claims are not supported by the manuscript: the promised formal analysis and symbolic verification results are absent, the protocol description contains garbled and duplicated text, and the security argument depends on unmodeled assumptions about a secure channel and robot trustworthiness. The defender evaluation also lacks baselines and statistical detail, so the claim of being the 'first' effective audio-visual fusion defender is not established.","major_comments":[{"comment":"The abstract and Section VI explicitly promise validation using ProVerif and Scyther, and Section I.B promises a 'comprehensive security analysis (Using Reduction Proof and Symbolic Tool)'. The manuscript contains no reduction proof, no ProVerif or Scyther model, no trace output, and no security-analysis subsection or appendix. Section III.C.3 even leaves the unlinkability proof as 'details are provided in Section ??'. The claimed properties of key indistinguishability, unlinkability, perfect forward secrecy, and resistance to impersonation/replay/MITM therefore rest entirely on an unverified message sequence, directly contradicting the paper's central claim of rigorous formal analysis.","section":"Abstract and Section VI, first paragraph"},{"comment":"In the authentication phase, the server sends the session key, the chosen index, and the user's biometric embeddings to the robot over a 'Security Channel', and the robot stores them for later verification. The adversary model in Section III.B does not include physical robot capture or compromise of this channel, yet Section VI.B.4 concedes that if the one-time key is broken, only previous sessions are protected, leaving the current session's subkey and embeddings recoverable from the robot. The multi-factor and privacy claims are thus load-bearing on a trusted-robot/secure-channel assumption that is neither formally modeled nor experimentally challenged; this must be addressed or explicitly scoped out.","section":"Figure 4 (Step C^Crypto_5 / MAU4) and Section VI.B.4"},{"comment":"The protocol description is internally inconsistent and partially duplicated, making it impossible to verify the message flow. Section IV.B repeats the 'Registration Phase' and 'Robot Registration' text nearly verbatim on pages 6-7, and Figure 3 contains duplicated flow fragments. More seriously, Step B2 in Section IV.B states 'key = dc ∗ QS' while Figure 3 and the preceding text require key = KDF(ds * Qc), and the MC1 construction in Step C^Crypto_2 (text: Enc{KEY[UID], UID||µ}) differs from Figure 4 (MC1 = {Qc || Enc{key, UID||µ} || TID}). These discrepancies preclude a reader from verifying even the basic cryptographic operations, let alone the claimed security properties.","section":"Section IV.B and Figure 4"},{"comment":"The defender evaluation compares the defended model only against the undefended model. There are no comparisons with existing defense mechanisms such as adversarial training baselines, autoencoder-based defenders, or other transformer/denoising methods, and no confidence intervals, standard deviations, or number of runs are reported. Given the paper's claim of introducing the 'first' transformer-based audio-visual fusion defender, the results as presented do not establish superiority over prior art, and the EER improvements alone are insufficient to support the resilience claim.","section":"Section VI.B, Table II and Figures 8-9"}],"minor_comments":[{"comment":"The manuscript contains numerous typos and unresolved cross-references, including 'Tradiaional' (Section I.B), 'Cilp' in Equation (5), 'Hign-level' (Section IV.A), and 'Section ??' in Section III.C.3.","section":"Throughout"},{"comment":"The computational cost text reports '0.1.419 s' for ECDSA, which appears to be a typo, and the caption text in Figure 3 contains garbled fragments such as 'Dif f ieHellman'. These should be corrected.","section":"Section VI.A and Figure 3"},{"comment":"The text refers to 'Following Algorithm 16' when the actual algorithm is labeled 'Algorithm 1: Verification Process with Defender'; the reference should be updated.","section":"Section IV.D.2"},{"comment":"The AAM-Softmax loss formula is typeset with an unclear summation index ('ΣN j=i,j̸=yi'), and the variables s and m are not fully defined; the notation should be cleaned up for reproducibility.","section":"Equation (2)"}],"recommendation":"reject","confidential_remarks":"The manuscript appears to be an incomplete draft: promised security proofs and tool outputs are missing, the protocol description is duplicated and internally inconsistent, and the physical-capture discussion acknowledges a limitation that undermines the multi-factor claim. These are not minor presentation issues; they affect the core contributions. The paper is not ready for review in its current form, and a revision would require adding the full formal analysis, correcting the protocol specification, and substantially reworking the defender evaluation."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nYou should know two things about arXiv:2411.18027. First, the claimed core result—a rigorously analyzed privacy-preserving MFA scheme for robot delivery—is not in the manuscript. The abstract promises formal analysis plus ProVerif and Scyther validation; the body contains none of it. Section VI says the security is validated with ProVerif and Scyther, then reports power consumption and defender accuracy. The unlinkability discussion literally says 'details are provided in Section ??'. So the central claim is unsupported as written.\n\nWhat is actually new: the combination of ECDH/ECDSA-based MFA with face/voice embedding verification and a transformer-based audio-visual denoiser for delivery robots. That is a plausible niche. The defender idea—reconstructing both modalities before verification—is worth trying, and the EER numbers (PGD from 35.42 to 13.45) suggest it helps, though only against an undefended baseline without error bars or adaptive attacks. The Turtlebot3 implementation with cost/energy measurements is concrete.\n\nThe soft spots are large. The protocol description is garbled: duplicated registration sections, Figures 1 and 4 repeat with different labels, and the authentication phase sends the session key and chosen index to the robot over an assumed 'Security Channel' that is never modeled. If an attacker can read the robot's memory or that channel, the multi-factor claim collapses. The physical-capture discussion only claims forward/backward secrecy for past sessions, not the current one. The defender evaluation also lacks adaptive attacks, which is the standard bar for adversarial robustness claims. Placeholder citations and a missing appendix make this look like an unfinished draft.\n\nThe crypto primitives are standard ECDH/ECDSA; nothing is circular. The problem is absence of evidence, not cooked evidence.\n\nWho this is for: someone interested in robotic delivery authentication or audio-visual defense might find the system concept and preliminary numbers worth a skim. As a rigorous contribution, it is not there yet.\n\nRecommendation: desk reject, with an invitation to resubmit once the formal analysis, ProVerif/Scyther models, unlinkability proof, and a proper adversarial evaluation are actually included. The core idea deserves a serious look, but this manuscript does not yet merit referee time.","headline":"An unfinished draft: the promised ProVerif/Scyther validation and formal analysis are absent, so the central claim is unsupported, though the audio-visual fusion defender idea is reasonable and the implementation is real.","tokens_in":22584,"tokens_out":3044,"would_cite":false,"duration_ms":25376,"reading_group":"no","serious_thinker":"unclear","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper proposes a privacy-preserving multi-factor authentication protocol for robotic delivery in which a user is verified by a secret subkey plus face and voice embeddings, backed by a transformer-based audio-visual fusion defender…","keywords":["robotic delivery authentication","multi-factor authentication","privacy-preserving biometrics","face and voice embedding","transformer fusion defender","adversarial samples","elliptic curve cryptography"],"falsifier":"Capture a deployed robot and read its flash storage, or eavesdrop on the security-channel transmission during the MAU4 step, to extract the one-time key, chosen-index subkey, and stored face and voice embeddings; then present those values to a fresh robot at a delivery point. If that robot accepts the package, the three-factor authentication guarantee is false.","tokens_in":21561,"feed_emoji":"🤖","tokens_out":6771,"duration_ms":59515,"temperature":0.7,"pith_summary":"This paper seeks to make robotic last-mile delivery authentication secure and private by asking the robot to check three things at once: a subkey derived from a server-issued secret key, the user's face, and the user's voice. It argues that combining elliptic-curve cryptography with deep-learning biometric verification closes impersonation, replay, man-in-the-middle, unlinkability, and identity-theft risks, while protecting biometric data by storing only encrypted embeddings rather than raw face or voice recordings. To harden the biometric factor against machine-learning attacks such as FGSM and PGD, the authors introduce a fusion transformer that reconstructs denoised face and audio inputs before verification. If the protocol and the defender work as described, a robot could authenticate a package recipient offline and privately in a single interaction, even in noisy real-world settings.","feed_headline":"Robot delivery check merges face, voice, and a secret code","feed_subtitle":"New protocol keeps biometrics encrypted and adds a transformer defense against adversarial samples.","key_machinery":"The carrying mechanism is a three-factor verification pipeline. The crypto factor uses ECDH key agreement and ECDSA-signed messages to exchange a one-time key, a random index, and rotating UID/KEY values updated by XOR with fresh random values, letting client and server establish a shared secret and a chosen subkey. The biometric factor captures a face image and a voice sample, passes both through the fusion defender, a transformer encoder operating on flattened image patches and mel-spectrogram patches with separate linear projections and two MSE reconstruction losses, then extracts embeddings with ResNet for the face and ECAPA-TDNN for the voice under an AAM-Softmax loss, and compares them against the server-provided encrypted embeddings. The fusion defender is load-bearing for the AI-resilience claim because it reconstructs cleaned inputs before any verification model sees them.","core_discovery":"The central claim is that a robotic delivery system can authenticate a receiving user with three independent factors in a single interaction: something the user knows (a six-character subkey selected from a server-generated key via a random index), something the user is (a face embedding), and something the user says (a voice embedding), with all biometrics stored only as encrypted embeddings. The protocol uses ECDH-derived shared keys and ECDSA signatures for mutual authentication between client and server, while the robot receives the key, index, and embeddings over a security channel and runs the biometric checks locally. The paper further claims that its transformer-based audio-visual fusion denoise defender, trained with face and audio reconstruction losses, reduces the effectiveness of adversarial perturbations on both face and voice verification, reporting lower equal error rates under FGSM, PGD, BIM, FFGSM, and Jitter attacks.","pith_inferences":["An unstated consequence is that the same three-factor template could migrate to other unattended delivery contexts, such as medicine, documents, or keys, where the recipient must be verified without a human courier.","A testable extension is to evaluate the fusion defender against adaptive attackers who know its weights or against physical-domain attacks such as printed glasses and replayed recordings, since the reported evaluations use a fixed set of gradient-based perturbations.","Editorial observation: the abstract and introduction promise a formal reduction proof and ProVerif/Scyther symbolic verification, but the visible full text contains no theorem statement, proof, or tool transcript, so the formal-security claims are asserted rather than demonstrated in this version.","Another consequence not developed in the paper is that the security-channel assumption between server and robot means real-world security depends on physical and network protection of the robot during provisioning, not only on cryptography."],"forward_implications":["If the protocol is secure, a delivery robot can authenticate a recipient with one interaction, without requiring the user to remember a long password or carry a separate token.","If the defender generalizes as reported, face and voice verification on the robot would withstand common white-box adversarial perturbations, with the paper's numbers showing EER falling from 35.42% to 13.45% under PGD and from 20.16% to 12.86% under FGSM.","If the biometric storage design is sound, raw face images and voice recordings never reside on the robot; only encrypted, server-derived embeddings do, so a physical robot capture does not directly leak biometrics.","If the channel assumptions hold, the scheme's offline verification capability means authentication can proceed after a single secure provisioning step, which is useful where internet connectivity is unreliable."],"supporting_citations":[{"why":"Supplies the elliptic-curve group operations used by the cryptographic key exchange and signatures in the protocol.","marker":"[23]"},{"why":"The ECDH protocol is the mechanism by which client and server derive the shared key used to encrypt credentials and embeddings.","marker":"[25]"},{"why":"ECDSA provides the digital signatures that let client and server authenticate each other's registration and authentication messages.","marker":"[26]"},{"why":"ArcFace/AAM-Softmax loss is the method the paper uses to train face and voice embedding extractors for the biometric factor.","marker":"[27]"},{"why":"Establishes that deep networks are vulnerable to adversarial perturbations, the threat the proposed fusion defender is designed to counter.","marker":"[28]"},{"why":"Defines the FGSM attack, one of the five adversarial methods used to evaluate the defender.","marker":"[29]"},{"why":"Defines the PGD attack, the benchmark under which the paper reports its largest EER improvement from 35.42% to 13.45%.","marker":"[30]"},{"why":"The transformer encoder architecture that the fusion defender adapts for joint face and audio denoising.","marker":"[36]"},{"why":"VoxCeleb supplies the face and voice data used to train and test the verification models and the defender.","marker":"[39]"},{"why":"ECAPA-TDNN is the voice embedding model used in the biometric verification pipeline.","marker":"[40]"}],"fun_headline_variants":["Robot delivery auth uses face, voice, and a secret code","Encrypted biometrics for secure robot package delivery","Transformer defender blocks adversarial face-voice attacks","Three-factor robot authentication with privacy protection","New robot delivery scheme thwarts AI attacks on biometrics"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol assumes the channel between server and robot is secure and that the robot's stored key, index, and embeddings cannot be read or altered by an attacker; if an attacker can learn or modify those values, the multi-factor authentication can be bypassed.","fun_headline_variants_meta":{"raw":{"variants":["Robot delivery auth uses face, voice, and a secret code","Encrypted biometrics for secure robot package delivery","Transformer defender blocks adversarial face-voice attacks","Three-factor robot authentication with privacy protection","New robot delivery scheme thwarts AI attacks on biometrics"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000176,"raw_usage":{"total_tokens":1296,"prompt_tokens":962,"completion_tokens":334,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":578,"completion_tokens_details":{"reasoning_tokens":275}},"tokens_in":578,"tokens_out":334,"duration_ms":3663,"temperature":1.0,"reasoning_tokens":275,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T11:35:56.822311+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Capture a deployed robot and read its flash storage, or eavesdrop on the security-channel transmission during the MAU4 step, to extract the one-time key, chosen-index subkey, and stored face and voice embeddings; then present those values to a fresh robot at a delivery point. If that robot accepts the package, the three-factor authentication guarantee is false.","supporting_citations":[{"cited_title":"Elliptic curve cryptosystems,","cited_arxiv_id":null,"evidence_quote":"Supplies the elliptic-curve group operations used by the cryptographic key exchange and signatures in the protocol."},{"cited_title":"” new directions in cryptography","cited_arxiv_id":null,"evidence_quote":"The ECDH protocol is the mechanism by which client and server derive the shared key used to encrypt credentials and embeddings."},{"cited_title":"The elliptic curve digital sig- nature algorithm (ecdsa),","cited_arxiv_id":null,"evidence_quote":"ECDSA provides the digital signatures that let client and server authenticate each other's registration and authentication messages."},{"cited_title":"V oxceleb: Large- scale speaker verification in the wild,","cited_arxiv_id":null,"evidence_quote":"VoxCeleb supplies the face and voice data used to train and test the verification models and the defender."}],"review_version":1}