Secure PUF-ASCON-Based Gateway-Assisted D2D Authentication for Resource-Constrained Smart-Manufacturing IIoT Devices
TL;DR
PASMAP is proposed, a lightweight PUF-ASCON mutual authentication protocol for gateway-assisted D2D communication in smart-manufacturing IIoT and is evaluated against physical, protocol-level, and insider threats, including cloning, tampering, replay, man-in-the-middle, CRP disclosure, PUF modeling, stolen-verifier, and known-key attacks.
Abstract
Smart-manufacturing Industrial Internet of Things (IIoT) deployments increasingly depend on low-latency device-to-device (D2D) communication among resource-constrained, physically exposed field devices. This setting makes mutual authentication and session-key establishment difficult: public-key-intensive or cloud-dependent schemes add overhead, availability dependence, and single points of failure, while weak PUF-based designs may expose challenge-response pairs (CRPs) to replay, disclosure, and modeling attacks. This paper proposes PASMAP, a lightweight PUF-ASCON mutual authentication protocol for gateway-assisted D2D communication in smart-manufacturing IIoT. PASMAP combines SRAM-PUF key reconstruction, fuzzy-extractor helper data, hash- and XOR-based obfuscation, and ASCON authenticated encryption with associated data (AEAD) to protect hardware-rooted identities, hide raw PUF responses, and establish fresh session keys for post-authentication data exchange under an explicitly trusted local-gateway model. The protocol is evaluated against physical, protocol-level, and insider threats, including cloning, tampering, replay, man-in-the-middle, CRP disclosure, PUF modeling, stolen-verifier, and known-key attacks. A real-or-random (ROR) analysis bounds the adversary’s session-key advantage using hash collisions, PUF-response prediction, online guessing, and ASCON AEAD security. A mixed-platform evaluation based on ESP32 primitive timings for the edge devices and desktop timings for the resource-rich gateway yields an estimated total computation cost of 4.762 ms. The initiator and responder require 2.006 ms/264.79 μJ and 2.679 ms/353.63 μJ of computational energy, respectively, while the five-message exchange carries 4704 bits. These results indicate low computational overhead under the stated benchmark and power-model assumptions. However, the protocol totals are operation-count-based estimates, the PUF and fuzzy-extractor operations are simulated, and the energy model excludes several platform- and communication-dependent costs. A complete embedded implementation is therefore required to validate end-to-end latency, memory use, energy consumption, communication-stack overhead, SRAM-PUF reliability, and fuzzy-extractor performance.