IIoT-RoboAuth: PUF-Based Command-Bound Authentication for Industrial Robotic Control Networks

Industry 4.0 has shifted industrial robotics from isolated motion cells toward software-defined production assets. Collaborative robots and multi-joint robotic arms now execute machining, assembly, inspection, transport, and materialhandling tasks under frequent product changes. Their controllers receive kinematic commands that encode target Cartesian coordinates, joint trajectories, torque ceilings, velocity limits, work modes, and safety-zone states. Forged or delayed control commands exhibit distinct risk profiles compared with conventional IT data packets because they can change the physical state of a machine while people, tools, and workpieces occupy the same environment. A syntactically valid command with a modified torque limit or stop-zone boundary can bypass a conventional login decision and still cause unsafe motion. Industrial authentication must therefore protect the command semantics executed after a user or device has been authenticated.

Conventional centralized authentication services are poorly matched to this setting. A cloud or plant-core authority can deliver strong identity management, but it can also become a latency bottleneck and a single point of failure when robots require rapid local decisions. Operational technology networks additionally differ from enterprise networks because a delayed rejection can be as harmful as an incorrect acceptance. In a coordinated robot cell, a safety controller may have only a few milliseconds to decide whether a control command belongs to the authorized session, whether its sequence number is fresh, and whether its parameters remain within an approved kinematic envelope. Time-Sensitive Networking, EtherCAT, and Profinet deployments make deterministic transport possible, yet they do not by themselves create authenticated and safety-bound command semantics. A lightweight distributed scheme is required to join cyber authentication with motion-safety reasoning at the edge.

Zhuang et al. [1] proposed a three-factor authentication and key agreement protocol for unmanned aerial vehicles assisting terrain exploration. The protocol combines elliptic-curve operations, passwords, biometric features, smart cards,

This work is open access and licensed under the Creative Commons CC BY 4.0 License.

physically unclonable functions, reconfigurable physically unclonable functions, fog nodes, Real-or-Random analysis, and ProVerif verification. Its design usefully avoids dependence on the ground-control station during every authentication session, uses hardware identity to resist physical capture, and refreshes reconfigurable responses to constrain machinelearning modelling attacks. These properties are attractive for industrial robot controllers, which are long-lived edge devices exposed to supply-chain, maintenance, and physical-access risks. However, the original protocol assumes terraindata exchange rather than a real-time control loop. It does not bind command payloads, torque bounds, collision parameters, or stop-zone hashes to the authenticated session.

This domain gap exposes additional attack paths. A man-in-the-middle can capture an otherwise valid session and inject a false coordinate or torque command. An attacker with temporary access to the robot-cell floor can collect challenge-response pairs and train a model to predict static physical responses. A fog node that receives an authentication flood can delay safe motion decisions even if the cryptography remains correct. A spoofed kinematic parameter can weaken collision detection, enlarge a prohibited zone, or disable an interlock without changing the user's password. Finally, a substituted firmware image can replace the authentication library or the limit-checking routine before any session starts. These attacks require a protocol that treats command integrity, physical identity, availability, and safety bounds as a single security problem rather than independent control layers.

This paper proposes IIoT-RoboAuth, a PUF-based command-bound authentication protocol for industrial robotic control networks. It retains the source scheme's elliptic-curve, PUF/RPUF, and three-factor foundations [1], but maps the participants to an HMI, two Edge Safety Gateways, a Robotic Arm Controller, and an independent Robot Cell Safety Plane. The protocol adds a command sequence chain, a 5-ms freshness rule, per-command HMAC, kinematic-limit verification, gateway diversity, controlled RPUF refresh, remote attestation, and an audit commitment.

The contributions are fourfold. First, a quantified domain-gap analysis identifies the command fields, latency path, and fault-tolerance properties absent from the source protocol. Second, the cryptographic contribution is a transcriptbound session and command-key schedule with editable equations, explicit parameters, four messages, and byte-level accounting. Third, the systems contribution is a stateful command-validation workflow combining sequence, freshness, kinematic, attestation, and dual-gateway checks with explicit rejection paths. Fourth, a fixed-seed message-driven simulator reports run-level latency, statistical uncertainty, and component ablations while distinguishing modeled behavior from hardware or certification evidence.

Recent benchmarks clarify the position of this work. Wan et al. combine PUF evidence, three-factor login, and continuous zero-trust verification in IIoT [2], while Yu et al. protect revocable biometric-PUF credentials for repeated access [3]. HCDA addresses cross-domain key management for embodied robots through domain servers and a blockchain consortium [4], and ASIDS detects robotic-arm trajectory tampering from an acoustic side channel after motion evidence is produced [5]. IIoT-RoboAuth differs by authenticating the command semantics before controller execution: the sequence, 5-ms age, role scope, and safety-profile hash are cryptographically bound and then rechecked at the controller. It does not claim cross-domain federation, continuous location assurance, or post-execution anomaly detection.

• 2.    Background and Related Work

• 3.    Source Protocol Analysis and Industrial Threat Model

  3.1.    Baseline Protocol Elements

Authentication and key agreement schemes for constrained cyber-physical systems attempt to balance three forces: the cost of cryptographic operations, the exposure of long-lived credentials, and the need for a decision before a time-critical action. Fog-assisted designs move trust decisions closer to endpoints, reducing dependence on distant data centers and allowing local policy enforcement. The source design [1] follows this direction by allowing unmanned aerial vehicles and data-transit fog nodes to establish sessions without repeated participation by a ground control station. Its U2D and U2U flows use pseudonyms, elliptic-curve scalar multiplication, hash commitments, random values, PUF responses, and RPUF updates. This architecture provides an important baseline for robot control environments because robotic arms also depend on edge mediation, constrained controllers, and local failure handling.

Three-factor authentication remains useful in industrial contexts when each factor is isolated. The knowledge factor is a protected operator credential, the possession factor is a secure token, and the inherence factor is a biometric template processed by a fuzzy extractor [6]. IIoT-RoboAuth keeps the factor reconstruction at the HMI and transmits only a rolebound pseudonym and verification value. The gateway therefore decides a requested work mode without receiving the raw password or biometric sample.

PUFs derive device evidence from manufacturing variation [7], but exposed challenge-response pairs can support predictive modeling. DC-PUF demonstrates that response dependency can reduce the correlation exploited by modern machine-learning attacks [8]. The proposed protocol consequently treats RPUF refresh as an engineering interface rather than assuming that reconfiguration alone provides a measured resistance percentage; physical reliability and modeling resistance require device-specific hardware tests.

Industrial networking adds operational constraints. IEC 62443-3-3:2013 defines system security requirements, and IEC 62443-4-2:2019 defines component requirements [9,10]. ISO 10218-1:2025, ISO 10218-2:2025, and ISO 138491:2023 provide robot, cell, and safety-related control contexts [11-13]. These documents do not prescribe this protocol; they motivate authenticated, auditable, and timely evidence that can be consumed by independent safety logic.

IEEE 802.1Qbv scheduled traffic, OPC UA PubSub, and IEEE 802.1AS time synchronization define the transport and clock context for bounded-age decisions [14-16]. EtherCAT and PROFINET provide common industrial communication profiles [17,18]. IIoT-RoboAuth does not replace these transports: it rejects a command whose sequence or timestamp is inconsistent with the configured slot, even when the cryptographic tag is otherwise valid.

The adversary model combines Dolev-Yao network control [19], adaptive session exposure in the Canetti-Krawczyk tradition [20], and ProVerif correspondence events [21]. The formal claim is deliberately limited to secrecy and authentication under idealized primitives; queueing, PUF noise, clock drift, and physical limits are evaluated or bounded separately.

The source scheme initializes an elliptic-curve group, a generator, a master secret, a public key, and a hash function. During registration, an unmanned aerial vehicle and a Data Transit Fog Node receive challenges, derive PUF responses, and store masked pseudonym and verification values. A user registers with an identifier, password, biometric feature, and smart card through a fuzzy-extractor process. In the U2D authentication flow, the user login proof, the fog-node parameters, the vehicle pseudonym, an elliptic-curve ephemeral value, and timestamps allow the parties to derive a shared session key. The U2U variant uses a related exchange between two aerial vehicles. RPUF output is refreshed during key agreement so that a previously collected set of challenge-response pairs is not assumed to represent the next session [1].

The source design has several strengths worth preserving. It limits recurrent control-station participation, uses pseudonyms rather than clear identifiers on the open link, combines a human proof with device-rooted evidence, and derives a session key from fresh values and an elliptic-curve shared secret. Its ROR argument aims to distinguish a real session key from a random string, and its ProVerif model checks secrecy and mutual-authentication correspondence. The protocol also treats physical attacks and learning attacks as distinct problems. These properties make it more suitable than a password-only or certificate-heavy approach for an edge device whose maintenance history and physical perimeter cannot be assumed perfect.

The limitation is that the authenticated object in the source scheme is principally a terrain-data session. Once a valid session key exists, the data semantics are handled outside the protocol. A robot controller cannot make the same separation. The command payload contains values whose permissible ranges depend on tooling, workpiece position, collaborative mode, current joint state, and safety-zone configuration. The protocol must therefore establish not only that a peer is legitimate but also that each command belongs to an authorized operating mode, advances the control sequence exactly once, and remains within a cryptographically committed safety profile. The baseline session-key proof alone is insufficient to guarantee those conditions.

3.2.    Entity and Data Remapping

Table 1 maps the entities and data objects from the terrain-exploration model to the Industry 4.0 robot-cell model. The mapping deliberately separates the high-level operator authorization path from the device-to-device safety path. The Human-Machine Interface establishes the three-factor proof and requests an approved work mode. The Robotic Arm Controller produces or executes motion instructions but must prove device state through PUF/RPUF evidence. The Edge Safety Gateway performs local mutual-authentication relay, command MAC verification, limit checking, and failover coordination. The Robot Cell Safety Plane is not a cryptographic participant; it receives only a validated control decision and retains an independent ability to stop motion.

Table 1. Entity and Control-Data Mapping from the Source Protocol to IIoT-RoboAuth

Source	IIoT-RoboAuth	Responsibility	Security binding
UAV	Robotic Arm Controller	Execute bounded motion; provide PUF/RPUF evidence	Controller pseudonym, boot digest, RPUF epoch
DTFN	Edge Safety Gateway	Relay mutual authentication; validate policy and command	Gateway identity, policy epoch, failover state
US	HMI / operator	Local three-factor proof; request work mode	Role token, operator pseudonym
Terrain data	Command and kinematic state	Coordinate, torque, speed, interlock, safety zone	Command hash, sequence, SafetyHash
GCS records	Audit service	Accountability and incident analysis	Event code and Merkle root

The expanded command record is denoted by Cmd = {X, Y, Z, tau, omega, mode, collision, zone, interlock, Seqc, Tc, epoch}. X, Y, and Z denote the requested target coordinate; tau is the torque threshold in newton metres; omega is the joint-speed limit in degrees per second; mode identifies automatic or manual operation; collision and zone represent the collision-detection threshold and stop-zone boundary hash; interlock represents a safety-interlock status code; Seqc is the monotonically increasing command sequence; Tc is the command timestamp; and epoch identifies the active policy and RPUF-refresh period. The gateway does not assume that all fields are equally mutable. The zone hash, limit profile, and work mode are policy fields; the target coordinate and torque request are dynamic command fields. This distinction allows the protocol to reject a command that uses a correct session key but attempts to change a safety profile without a new role-authorized policy epoch.

The role token has a similarly narrow purpose. It states that a particular HMI session may request a defined work mode and command scope; it does not grant unrestricted motion authority. For example, a maintenance engineer may request slow manual motion inside a service zone but may not raise a torque limit or disable a collision threshold. A safety officer may authorize a policy epoch after reviewing a risk assessment but cannot use the token as an operator password. The separation of roles supports least privilege and provides an audit path for accountability. It also reduces the impact of an insider who has a valid credential but attempts to repurpose it outside the approved task or time window.

3.3.    Threat Model and Attack Traces

IIoT-RoboAuth uses a combined Dolev-Yao and adaptive device-compromise model. The adversary can observe, replay, delay, reorder, modify, and inject messages on the network; compromise a low number of controllers or gateways; collect challenge-response pairs during temporary physical access; submit floods of syntactically valid authentication requests; and attempt to replace firmware or an authentication library. The adversary cannot defeat a correctly implemented elliptic-curve discrete-logarithm assumption, hash preimage resistance, HMAC unforgeability, or the physical non-clonability of a genuine PUF without collecting evidence or exploiting implementation defects. The model additionally recognizes that safety parameters are assets. A change to a stop-zone boundary or torque limit is treated as an integrity attack even if the robot controller remains authenticated.

The first attack is command injection through a man-in-the-middle. An attacker records a valid session establishment, delays the original command, and inserts Cmd* with a modified coordinate or torque field. If the protocol authenticates only the session and not the command, Cmd* can be accepted as application data. In a robot cell, the impact may be a product defect, a tool collision, or unsafe acceleration. The second attack is physical tampering and PUF modelling. An attacker entering a restricted area collects a large set of challenge-response pairs from a controller during servicing, trains a predictor, and later impersonates the controller. The third attack is a gateway single point of failure and denial-of-service flood. The attacker overwhelms one fog node with login requests, creating an authentication queue long enough to interrupt the safety control loop. The fourth attack is kinematic parameter spoofing, in which a valid-looking packet changes collision thresholds or a stop-zone hash. The fifth attack replaces firmware so that an apparently authentic controller computes a different command MAC or bypasses the limit checker.

Fig. 1. IIoT-RoboAuth security architecture for a robotic arm cell.

Table 2. Industrial Attack Paths and IIoT-RoboAuth Controls

Attack	Robot-cell impact	Unmodified weakness	IIoT-RoboAuth control
Command modification	Unsafe coordinate or torque	Session does not bind payload	Command HMAC and canonical hash
Replay / delay	Stale motion after state change	No per-command sequence or age	Monotonic sequence and 5-ms rule
Gateway flood	Safety-decision delay	Single fog-node queue	Dual gateways and priority queue
Kinematic spoofing	Unsafe limits or zone	Safety fields outside authentication	SafetyHash and controller range check
Firmware substitution	Bypassed MAC or limit check	Trusted implementation assumed	Measured boot and attestation

The threat model creates two design requirements that are not visible in an ordinary session-key comparison. First, the gateway must separate authentication priority from bulk telemetry. A safety-critical command confirmation or emergency-stop message cannot wait behind a flood of failed password attempts or a non-critical diagnostic upload. Second, each controller must retain a local safe-degrade behavior. If both gateways are unreachable, the controller may complete only the pre-authorized bounded motion already committed for the current short epoch, or it may transition to a safe stop. The protocol never asks an unavailable network service to approve an unconstrained new command.

3.4.    Quantified Protocol-Gap Analysis

Table 3 quantifies why the source data-session protocol cannot be transferred unchanged to robotic control. The values are protocol-level counts or explicitly labeled model inputs; they are not physical security scores. The central gap is that zero safety fields are authenticated after the baseline session, whereas the redesign commits twelve command and policy fields and retains a local rejection state.

Table 3. Quantified Gap between the Source Protocol and Robot-Control Requirements

Requirement	Source protocol	Robot-control target	Consequence / redesign
Command-semantic binding	0 command or safety fields	12 canonical fields	Bind CmdHash and SafetyHash to Tag_c
Freshness state	Session timestamp	Per-command 5 ms and Seq_c	Reject stale and duplicate motion
Fault tolerance	One active fog path	Two synchronized gateways	Mirror epoch, revocation digest, audit root
Execution boundary	Authenticated data session	Controller-local limit decision	MAC before kinematic and interlock checks
Reproducible evidence	No robot-specific ablation	30 fixed seeds; four ablations	Separate each control's contribution

• 4.    IIoT-RoboAuth Protocol Design

  4.1.    Design Objectives and Trust Anchors

4.2.    Authentication, Key Derivation, and Command Binding

The protocol has five objectives. O1 is mutual authentication among the HMI, an Edge Safety Gateway, and a Robotic Arm Controller without a per-command dependency on a central cloud service. O2 is command integrity: every executed motion command must be bound to the session key, sequence number, safety profile, and authorized work mode. O3 is bounded freshness: the command must arrive within a five-millisecond window and advance the sequence chain exactly once. O4 is resilience: a gateway loss or authentication flood must not create a single point of failure for safety-critical operations. O5 is physical-root continuity: a controller must demonstrate a current PUF/RPUF state and measured boot before it can use a command session. These objectives are intentionally stricter than user login because the target is a motion execution path.

System initialization follows the source protocol's elliptic-curve foundation. A plant registration authority selects an elliptic-curve group G with generator P and publishes the public parameters, hash function, HMAC suite, and policy identifiers. The registration authority is used only for enrollment, revocation, and planned policy updates; it is not a synchronous participant in each robot command. Each Robotic Arm Controller and Edge Safety Gateway has a PUF/RPUF-equipped root of trust. The HMI stores its three-factor data in a protected credential container. Device registration derives a pseudonym, a masked verification value, a challenge-response commitment, and a boot measurement reference. The safety profile is versioned separately from the session so that a new robot tool or cell layout requires an explicit policy epoch rather than an implicit command update. The instantiated suite uses NIST P-256, SHA-256, HKDF-SHA-256, and HMAC-SHA-256 [22-24].

Gateway diversity is implemented as a local pair rather than a global cluster. Gateway A handles the primary authentication path, while Gateway B maintains a synchronized policy epoch, revocation Bloom-filter digest, and audit root. Only compact state is replicated: no raw biometric, password, or long-term private key is transferred. A controller accepts command authorization from either gateway only when the gateway identity, policy epoch, and gateway quorum marker match the current cell configuration. This rule prevents a failed-over gateway from silently authorizing commands using stale safety limits. It also allows the cell to continue local operations after a gateway failure without assuming that the entire plant security infrastructure is available.

Figure 2 gives the four-message sequence. The HMI locally validates the three factors and sends M1. The primary gateway validates role and revocation state and sends M2 with its ephemeral point. The controller returns PUF/RPUF and measured-boot evidence plus its ephemeral point in M3. M4 confirms the transcript, safety profile, and short command epoch. The online exchange is two end-to-end round trips; Gateway B receives only mirrored failover state.

Fig. 2. IIoT-RoboAuth mutual-authentication and command-binding sequence.

Table 4. Cryptographic and Operational Parameter Profile

Parameter	Value in the reproducibility profile	Rationale / boundary
Elliptic curve	NIST P-256; 33-byte compressed point	128-bit classical security; hardware timing not measured
Hash / KDF	SHA-256 / HKDF-SHA-256; 32-byte output	Transcript and domain separation
MAC	HMAC-SHA-256; 32-byte tag	Command and confirmation integrity
Nonces / pseudonyms	16 bytes / 16 bytes	Freshness and unlinkable fast-path identifier
Clock requirement	IEEE 802.1AS; absolute error <= 1 ms	Required to interpret the 5-ms acceptance rule
RPUF refresh	10,000 sessions or 24 h; maintenance boundary	Design default, not measured hardware optimum
Replay cache	256 sequence/nonce entries	Bounded controller memory

Table 5. Authentication and Command-Binding Records

Phase	Serialized record	Bytes
M1: HMI proof	PID_u, N_u, RoleToken, ModeReq, T_u, Auth_u	105
M2: gateway challenge	PID_g, N_g, P_e, BF_rev, T_g, Q_g, Auth_g	141
M3: controller proof	PID_r, N_r, PUFproof, BootHash, RPUF_e, Q_r, Auth_r	165
M4: confirmation	ConfirmTag, SafetyHash, SessionSeq	72
Command envelope	Cmd(96), Seq_c, T_c, SafetyHash, RoleTokenID, AuditRoot, Tag_c	224

Let Z be the ephemeral P-256 shared secret; K_i and K_g are device-side masked values released only after valid root-of-trust checks. Nonces N_u, N_g, and N_r, session sequence S_e, policy epoch P_e, and RPUF epoch RPUF_e are transcript inputs. The 32-byte session key is derived as follows.

SK^_e = HKDF-SHA-256(Z || K_i || K^_g,N^_u || N_g || N_r || S^_e || P^_e || RPUF^_e, 32)                        (1)

The command key is domain-separated from the session key and bound to the controller, sequence, work mode, and active safety profile.

CK_c = HKDF - SHA- 256(SK_e, CellID || PID_r || Seq_c || SafetyHash || Mode || RPUF_e, 32)                   (2)

The sender authenticates the canonical command and audit context; the controller recomputes both CmdHash and Tag_c before any range check.

Tag_c = HMAC - SHA - 256(CK_c, CmdHash || Seq_c || T_c || SafetyHash || RoleToken || AuditRoot)

AuditRoot is the current Merkle commitment to accepted and rejected events [25]. Application-layer byte counts exclude Ethernet, IP, transport, OPC UA, and fieldbus headers.

Table 6. Computational Complexity and Communication Burden

Entity / path	Dominant operations	Asymptotic cost	Communication
HMI handshake	Local 3FA/fuzzy reconstruction; hashes; HMAC	O(1)	M1: 105 B
Gateway handshake	2 P-256 scalar multiplications; hashes; HMAC	O(1)	M2+M4: 213 B
Controller handshake	2 P-256 scalar multiplications; 1 PUF/RPUF; HMAC	O(1)	M3: 165 B
Online command	2 hashes; 1 HMAC; d field checks	O(d)	224 B per command
Replay state	256-entry bounded cache	O(1) lookup; O(w) memory	No extra message

Algorithm 1. Controller-side command validation and exception handling

01 INPUT envelope E, last accepted sequence s_last, active profile P_e

02 if attestation_epoch(E) != P_e then REJECT(ATTESTATION_MISMATCH)

03 derive CK_c from SK_e, controller ID, sequence, SafetyHash, mode, and RPUF epoch

04  if HMAC_verify(CK_c, E) = false then REJECT(INVALID_MAC)

05  if E.Seq_c != s_last + 1 then REJECT(REPLAY_OR_GAP)

06  if abs(T_now - E.T_c) > 5 ms then REJECT(STALE_COMMAND)

07  if E.SafetyHash != hash(active_profile) then REJECT(POLICY_MISMATCH)

08  if role_scope_allows(E.Mode, E.Cmd) = false then REJECT(ROLE_VIOLATION)

09  if kinematic_bounds(E.Cmd, active_profile) = false then REJECT(OUT_OF_RANGE)

• 10  if interlock_state != closed then REJECT(INTERLOCK_OPEN)

• 11  append event commitment; mirror watermark to available gateway

• 12    set s_last = E.Seq_c; ACCEPT command for motion-planner review

• 13  on gateway disagreement, freeze new sessions and enter bounded safe-degrade

• 14  hardware emergency stop remains independent of all protocol decisions

4.3.    Kinematic Limits, Freshness, and Safe Execution 4.4.    RPUF Refresh, Remote Attestation, and Resilience

Cryptographic validity is a necessary but not sufficient condition for robot motion. The Kinematic Limits Check compares the requested target, torque, joint speed, collision threshold, and stop-zone hash with the active safety profile. The check is evaluated after MAC verification but before the command is handed to the motion planner. A command passes only when all requested values remain inside the profile bounds, the selected work mode is authorized by the role token, the interlock state is compatible with motion, and the command has not skipped or duplicated a sequence number. The controller records a rejection code that distinguishes invalid cryptography, stale freshness, policy mismatch, out-ofrange kinematics, interlock violation, and attestation failure. This distinction is operationally important because a safety stop caused by a network delay should not be diagnosed as a PUF failure.

The immutable profile commitment is calculated by Eq. (4). A tool, payload, collaboration mode, or stop-zone change creates a new policy epoch rather than an ordinary motion command.

SafetyHash = SHA - 256(ProfileID || Bounds || tau_max || omega_max || Collision || StopZone || Interlock || P_e)          (4)

The controller accepts a command only when all predicates in Eq. (5) hold. The 5-ms rule assumes an IEEE 802.1AS clock error not exceeding 1 ms; deployments that cannot maintain this bound must configure and validate a larger window rather than reuse the reported model.

Accept = MAC_OK AND (Seq_c = Seq_last + 1) AND (abs(T_now - T_c) <= 5 ms) AND Limits_OK            (5)

Emergency stop is treated as a safety-plane command outside the ordinary movement queue. IIoT-RoboAuth supports authenticated emergency-stop logging, but it never requires the cryptographic protocol to succeed before a hardware or safety-controller stop is honored. The network protocol can report who initiated the event, which epoch was active, and whether a command was in flight; it cannot become a precondition for stopping a machine. This ordering respects the independence expected of functional-safety mechanisms and prevents an attacker from using authentication load to delay an emergency action.

RPUF refresh mitigates challenge-response modelling only when the refresh is controlled and auditable. The controller maintains a refresh counter Re and a current RPUF epoch. At an approved maintenance boundary, the gateway issues a refresh request that includes a fresh nonce, the next policy epoch, and the expected maintenance state. The controller creates a new response partition, updates its local masked verification value, and produces a refresh proof that the gateway records without storing raw response material. The registration authority receives only a protected update record or a threshold commitment, depending on the deployment model. A refresh is rejected if the cell is moving, if the stop-zone state is unknown, or if the controller attestation is stale. This approach prevents a security mechanism from changing hardware identity during an active motion operation.

Remote attestation addresses firmware substitution. At boot, the controller measures the bootloader, authentication library, command-MAC module, and kinematic-limit module into a BootHash. The hash is bound to the PUF/RPUF proof in M3. The Edge Safety Gateway compares the value to an authorized measurement set for the current controller model and policy epoch. A mismatch does not imply malicious code by itself; it may signal a maintenance update. However, the controller is not allowed to open a new motion session until the update has been approved, attested, and associated with an updated safety profile. This process keeps supply-chain and patch-management events visible to the authentication layer. The implementation boundary follows current industrial remote-attestation evidence [26].

Gateway resilience uses a safety-priority queue. Verification requests are classified into emergency stop, command confirmation, session continuation, new login, telemetry, and audit replication. Emergency and command-confirmation messages receive bounded local service; new login requests can be rate-limited and moved to a lower priority. Gateway B receives the compact audit root, accepted sequence watermark, policy epoch, and revocation digest through a protected local channel. If Gateway A fails, Gateway B can verify the next command only after confirming that it has the same cell state. If neither gateway is available, the controller uses local safe-degrade logic rather than granting a new unbounded command. The design therefore removes gateway centrality without converting the robot controller into an uncontrolled autonomous authority.

• 5.    Security Analysis and Formal-Verification Plan

  5.1.    Informal Security Analysis

5.2.    ROR-Style Argument and ProVerif Events

Mutual authentication follows from the fact that the HMI, gateway, and controller each contribute fresh evidence to the session-key derivation and verify a session-confirmation MAC. The HMI proves a valid three-factor-derived role token; the gateway proves knowledge of the current policy and revocation state; and the controller proves PUF/RPUF and boot-measurement state. A man-in-the-middle who replays M1 cannot create a valid M4 because the gateway nonce, controller nonce, and policy epoch differ. An attacker who substitutes a controller proof cannot derive the same session key without the controller's masked device material and current PUF/RPUF evidence. The use of pseudonyms reduces linkability, although the design does not claim absolute anonymity because an authorized plant audit service can resolve a pseudonym when an incident requires accountability.

Command injection resistance follows from the distinction between session authentication and command authentication. After a session has been established, an attacker may still see a valid command sequence number, timestamp, and transport slot. The attacker cannot substitute a different coordinate, torque, speed, work mode, collision threshold, or stop-zone hash without changing CmdHash. A changed hash invalidates Tagc because the tag is computed using CKc, which is tied to the current sequence, safety profile, role token, and RPUF epoch. A copied command also fails because the controller rejects a sequence that does not equal SeqLast + 1 or a timestamp outside the five-millisecond window. This defense is stronger than a simple encrypted channel because it gives the controller an explicit cryptographic assertion that the safety semantics are the ones authorized for this command.

Physical tampering resistance combines PUF evidence, reconfigurable response epochs, and attestation. A copied flash image cannot reproduce the original controller's physical response. A collected set of challenge-response pairs becomes less useful after a controlled RPUF refresh, because the response behavior and epoch commitment change. The attacker may still attempt a real-time relay from the original controller, so the gateway and controller bind freshness, topology, and cell identifier into the session. The model recognizes residual implementation risks such as side channels, weak challenge selection, insecure debug ports, and insufficient RPUF entropy. These are engineering requirements rather than properties that a symbolic proof can guarantee. The protocol therefore requires disabled debug interfaces, protected key paths, rate-limited challenge access, and incident response after a tamper event.

Denial-of-service resilience is partial by design. No authentication protocol can guarantee availability against an attacker who fully saturates a physical link or removes power. IIoT-RoboAuth reduces protocol-induced denial of service by distributing the gateway role, prioritizing safety traffic, maintaining compact failover state, and requiring local safe-degrade behavior. It also avoids a cloud round trip on every command. A flood of new HMI login attempts cannot consume the same queue budget as an in-flight command confirmation. If an attacker succeeds in delaying a valid command beyond five milliseconds, the controller rejects it rather than executing an unsafe stale instruction. This may reduce availability, but it preserves a conservative safety property: under uncertainty, motion is bounded or stopped instead of being continued with ambiguous authority.

Kinematic spoofing is resisted because the active safety profile is included in the command key and tag. A message that changes only an application-layer field cannot remain cryptographically valid. A controller also recomputes limit checks locally, so a compromised gateway cannot instruct the robot to execute a value outside its configured profile simply by forwarding a tagged message. The remaining assumption is that the safety profile and limit-check implementation are trustworthy. Remote attestation and measured boot address unauthorized code replacement, while the independent safety plane retains the ability to stop motion if the protocol layer misbehaves. This layered arrangement preserves the separation between security evidence and functional-safety actuation.

The ROR-style proof sketch follows the source protocol's separation between a real session key and a random test value [1]. The adversary is given Execute, Send, Reveal, Corrupt, Test, and challenge-query capabilities subject to the stated freshness restrictions. Game G0 represents the real protocol. G1 replaces hash outputs used in pseudonym and command-key derivation with random-oracle values, bounding the difference by hash collision probability. G2 replaces elliptic-curve shared secrets with random group elements under the elliptic-curve Diffie-Hellman assumption. G3 replaces the PUF/RPUF proof with an ideal unpredictable response except with the probability of a successful physical clone or predictor. G4 replaces the test session key with a random string. The adversary's distinguishing advantage is bounded by the sum of the hash, elliptic-curve, PUF/RPUF, HMAC, and freshness-window failure terms.

The addition of command binding introduces a second test property. Even if an adversary is unable to distinguish SKe from random, a protocol can fail if it permits a non-authorized command to reach the motion planner. The commandauthenticity event therefore requires accept_command(PIDr, Seqc, CmdHash, SafetyHash, Pe) to imply prior events authorize_role(PIDu, Mode, Pe), attest_controller(PIDr, BootHash, RPUFe), verify_gateway(PIDg, Pe), and issue_command(PIDu, Seqc, CmdHash, SafetyHash). A correspondence query asserts that every accepted command is associated with a unique authorized issuance event. A replay attempt violates the unique sequence requirement and is rejected before the accept event. A kinematic-spoofing attempt changes SafetyHash or CmdHash and cannot satisfy the correspondence unless the attacker can forge HMAC under CKc.

A ProVerif model can represent the HMI, two gateways, and the controller as replicated processes with public channels, private enrollment channels, abstract PUF functions, and event annotations. The model should query secrecy of SKe and CKc, injective correspondence for session confirmation, injective correspondence for command acceptance, and reachability of a reject event when a timestamp or sequence is invalid. The model should not overstate what symbolic analysis proves: PUF machine-learning resistance, timing behavior, queueing resilience, and physical limit enforcement require computational or empirical evaluation. ProVerif instead verifies that, under the idealized cryptographic assumptions, the message flow cannot yield an accepted command without the modeled prerequisites. This division of evidence keeps the formal claim precise and useful.

• 6.    Reproducible Evaluation and Standards Mapping

  6.1.    Evaluation Scope, Platform, and Parameters

  The previous manuscript inaccurately labeled the scenario evaluation as NS-3. The revision removes that claim. The evidence is generated by a Python 3.12 message-driven simulator running on Windows 11 with an Intel Core i9-13900HX and 15.7 GB RAM; no robot controller, PUF device, safety module, or NS-3 model was used. The topology identifiers rotate among 12 controllers, two gateways, and four HMIs, but the latency values are consequences of the explicit service and delay distributions in Table 7 rather than measurements of those devices.

6.2.    Modeled Latency, Communication, and State Costs

Thirty fixed seeds (20260801-20260830) generate 1,000 authentication sessions per seed. Correctness testing generates 1,000 trials per attack class and seed for command modification, replay, a 6-20 ms stale command, and an out-of-range command carrying a valid tag from an authorized origin. Each attack class therefore contains 30,000 trials. Seedlevel latency means are the unit of analysis; 95% t intervals and a paired t test compare modeled paths. Wilson intervals summarize binary rejection rates. Statistical significance describes simulator variability only, not production uncertainty.

Table 7. Message-Driven Simulation and Reproducibility Parameters

Item	Specification	Purpose
Software / host	Python 3.12; Windows 11; Core i9-13900HX; 15.7 GB RAM	Fully disclosed execution platform
Seeds / sessions	20260801-20260830; 1,000 sessions per seed	30 independent run summaries
Proposed local delay	4 one-way lognormal delays; mean 0.48 ms; CV 0.25	Local robot-cell network assumption
Baseline central delay	4 one-way lognormal delays; mean 3.85 ms; CV 0.30	Central-path comparison assumption
Queue delay	Exponential mean 0.35 ms proposed; 1.20 ms baseline	Scenario load variability
Attack corpus	4 balanced classes; 1,000/type/seed	Not an estimate of field attack frequency
Clock / stale injection	<=1 ms clock error; stale age uniformly 6-20 ms	Tests the 5-ms predicate
Statistics	Seed-level mean, SD, 95% t CI, paired t; Wilson CI	Avoids treating 30,000 events as independent latency runs
Artifacts	Python script, latency CSV, ablation CSV, summary JSON	Exact rerun and audit trail

Across the 30 seed-level means, the proposed local path was 7.903 ms (SD 0.017; 95% CI 7.896-7.909) and the centralized baseline was 22.735 ms (SD 0.100; 95% CI 22.698-22.773). The paired comparison yielded t(29) = 787.93, p < 0.001. This difference validates the encoded delay model, not a hardware speed claim. The controller state budget rises from 156 KB to 241 KB because the redesign reserves 85 KB for the replay cache, safety profile, measured-boot/RPUF metadata, priority queue, and audit frontier.

Modeled authentication latency

Application-layer footprint

Command-validation tests

7.903 ms

483 bytes

30,000/30,000

95% CI: 7.896-7.909 ms

four-message handshake

rejected per attack class

30 seeds x 1,000 sessions

224-bytc command envelope

Wilson 95% lower bound: 99.987%

Table 8. Modeled Latency and Analytical Resource Summary

Metric	Centralized baseline	IIoT-RoboAuth	Evidence boundary
Authentication latency	22.735 ms	7.903 ms	Modeled; 30 seed means
95% CI	22.698-22.773 ms	7.896-7.909 ms	t interval over seed means
Controller RAM budget	156 KB	241 KB	Analytical allocation, not measured peak
Handshake	Not byte-accounted	4 messages; 483 B	Application payload only
Command envelope	Not supported	224 B	Application payload only

The latency is generated by the stated message-delay model; no robot hardware or NS-3 result is claimed.

Fig. 3. Reproducible evaluation scope: modeled latency, protocol footprint, and command-validation tests.

6.3.    Ablation and Command-Validation Correctness

The complete configuration rejected every generated attack trial in each class (30,000/30,000; Wilson 95% CI, 99.987%-100%). The controlled removals isolate causality: command modifications passed without the command MAC, replays passed without the sequence chain, stale commands passed without the 5-ms check, and validly tagged but unsafe commands passed without the kinematic check. These deterministic logic outcomes establish module necessity inside the simulator; they do not estimate real-world attack prevalence or physical PUF behavior.

Table 9. Full-Border Ablation Results (Rejected / 30,000 Trials)

Configuration	Modified command	Replay	Stale >5 ms	Out of range
Full IIoT-RoboAuth	30,000	30,000	30,000	30,000
Without command MAC	0	30,000	30,000	30,000
Without sequence chain	30,000	0	30,000	30,000
Without 5-ms freshness	30,000	30,000	0	30,000
Without kinematic check	30,000	30,000	30,000	0

6.4.    Standards and Interoperability Mapping

The standards mapping is a design trace, not certification. IEC 62443-3-3:2013 requirements SR 1.1-1.13 (identification and authentication), SR 2.1-2.12 (use control), SR 3.1-3.9 (system integrity), and SR 7.1-7.8 (resource availability) are mapped to three-factor/PUF evidence, scoped roles, command HMAC, attestation, rate limiting, and gateway diversity [9]. IEC 62443-4-2:2019 component requirements CR 1.1, CR 2.1, CR 3.4, and CR 7.1 are mapped at the controller and gateway boundary [10]. NIST IR 8259 Rev. 1 supplies complementary device-cybersecurity activities [27].

ISO 10218-1:2025 and ISO 10218-2:2025 provide the robot and cell safety context, while ISO 13849-1:2023 governs safety-related control principles [11-13]. The protocol supplies provenance, SafetyHash, a bounded sequence, and rejection evidence; it does not replace safety-rated stop circuits, risk assessment, or performance-level determination.

OPC UA PubSub, IEEE 802.1Qbv scheduling, and IEEE 802.1AS synchronization can carry and time the authenticated envelope [14-16]. EtherCAT and PROFINET integrations may carry the envelope or a compact reference to it if they preserve sequence and time context [17,18]. PUF responses and long-term keys are never exported through the interoperability API.

Table 10. Technical Mapping to Security, Safety, and Interoperability Requirements

Reference	Relevant requirement	Protocol evidence	Boundary
IEC 62443-3-3:2013	SR 1, SR 2, SR 3, SR 7 families	3FA/PUF, scoped role, HMAC, attestation, dual gateway	No SL certification claim
IEC 62443-4-2:2019	CR 1.1, 2.1, 3.4, 7.1	Device identity, authorization, software integrity, availability	Component tailoring required
ISO 10218-1/-2:2025	Robot and cell safety	Mode scope, SafetyHash, conservative reject	Does not replace safety hardware
ISO 13849-1:2023	Safety-related control	Independent safety plane and stop precedence	No PL determination
NIST IR 8259 Rev. 1	Device identity and secure update	Attestation, revocation, state awareness	Plant risk tailoring required
OPC UA / TSN	Interoperability and bounded time	Sequence, timestamp, policy epoch	Schedule and clock must be engineered

• 7.    Discussion and Deployment Boundaries

• 8.    Conclusion

Multi-robot collaboration introduces another boundary. In a robot-to-robot task, each controller needs assurance not only that its peer is authentic but also that both controllers use compatible safety profiles, coordinate frames, and time epochs. IIoT-RoboAuth can extend the source protocol's U2U logic by deriving a collaboration key from two controller pseudonyms, two RPUF epochs, a shared cell identifier, and a task-sequence identifier. The collaboration key should authorize only the bounded coordination operation, such as a handoff or synchronized lift, not a general command channel. A gateway or safety supervisor should commit the shared task envelope before either controller begins the coordinated motion. This scoped approach prevents a compromise in one arm from becoming unlimited authority over the other arm.

Privacy follows a data-minimization rule: the fast path contains pseudonyms, role scope, and event commitments, while identity resolution remains in a protected audit service. Robot-cell logs can expose operators, timing, tooling, and process recipes, so retention, access, and purpose limits must be set by plant governance. The cryptographic audit root detects silent log rewriting but does not justify collecting unrelated personal data.

Deployment boundaries are explicit. The simulator does not emulate motor dynamics, physical collision, PUF noise, side channels, safety-PLC behavior, or fieldbus driver jitter. The 5-ms predicate is valid only when the measured clock error and network budget support it. RPUF refresh requires a controller that implements secure reconfiguration, and measured boots require protected reference measurements. A legacy controller that cannot reserve the additional state must use an external safety proxy or a reduced profile rather than silently disabling a control.

Future work should repeat the protocol on real P-256 and PUF/RPUF hardware with IEEE 802.1AS instrumentation, publish fieldbus packet captures, and perform hardware-in-the-loop fault injection across several robot vendors. Postquantum migration should evaluate ML-KEM, ML-DSA, and SLH-DSA under the same byte, memory, and timing budget rather than substituting algorithms without systems evidence [28-30].

IIoT-RoboAuth converts a three-factor fog-assisted data-session scheme into a command-bound protocol for industrial robotic control. The revision makes the contribution reproducible at protocol level: five editable equations specify key derivation, command authentication, safety-profile commitment, and acceptance; four messages total 483 application bytes; and controller pseudocode defines each rejection path. A quantified gap analysis separates the source protocol's identity strengths from the command, time, and failover properties required before motion execution.

Under the stated message-delay model, 30 seed-level means produced 7.903 ms authentication latency versus 22.735 ms for the centralized baseline, while the analytical controller state budget increased from 156 KB to 241 KB. The full validator rejected all 30,000 trials in each of four command-attack classes, and each ablation exposed the attack controlled by the removed module. These findings support command-binding correctness inside the supplied simulator, not physical tamper resistance, PUF modeling immunity, safety certification, or production readiness. Hardware-in-the-loop replication is the required next validation stage.

All the Declarations and StatementsAuthor Contributions Statement

Haewon Byeon: Conceptualization, protocol analysis, methodology, software, validation, formal analysis design, visualization, writing - original draft, and writing - review and editing.

Conflict of Interest Statement

The author declares no competing financial interests or personal relationships that could have appeared to influence the work reported in this manuscript.

Funding Declaration

N/A. This research received no specific grant from funding agencies in the public, commercial, or not-for-profit sectors.

Data Availability Statement

No external human-subject or proprietary production dataset was used. The Python reproducibility script, seed-level latency CSV, ablation CSV, and summary JSON are supplied with the revised submission.

Ethical Declarations

N/A. This study contains no experiments involving human participants or animals and uses simulated authentication and command messages only.

Acknowledgments

N/A.

Declaration of Generative AI in Scholarly Writing

Generative artificial intelligence assisted with language drafting and document formatting. The author reviewed, revised, and accepts responsibility for the protocol, software, results, citations, and final manuscript.

Abbreviations

The following abbreviations are used in this manuscript:

IIoT - Industrial Internet of Things

PUF - Physically Unclonable Function

RPUF - Reconfigurable PUF

HMI - Human-Machine Interface

TSN - Time-Sensitive Networking

HMAC - Hash-based Message Authentication Code

HKDF - HMAC-based Extract-and-Expand Key Derivation Function

ROR - Real-or-Random

CI - Confidence Interval

Appendix A/B/C…, with appendix title

N/A. All reproducibility parameters and results are reported in Tables 7-9; machine-readable artifacts are supplied separately.