## 2 System Model and Security Requirements  
As shown in Figure 1, the system model suggested in this study has three discrete entities: (1) a Trusted Authority (_TA_); (2) a User (\(C_{i}\)); and (3) Industrial IoT devices (\(I1 oT_{j}\)). Both Internet of Things (IoT) devices and users/controllers are presumed to have tamper-resistant memory, which ensures that data, including shared authentication keys, stored within this memory cannot be illegally accessed [25]. 1. The Trusted Authority (_TA_) is responsible for generating system parameters and facilitating online registration. Building upon prior assumptions [26], it is postulated that _TA_ possesses robust storage capacities, hence ensuring the protection of its computational operations against potential external vulnerabilities. As a result, _TA_ has the capability to securely retain the identities of entities, in addition to their related authentication master keys. Figure 1: System model. Users (\(C_{i}\)): Users representing PLC/SCADA (Programmable Logic Controller/ Supervisory Control and Data Acquisition) employ the aid of a \(TA\) to verify Industrial Internet of Things (IIoT) devices during the process of registration. Afterward, they perform computations to derive a key and update their authentication keys. * Industrial Internet of Things (\(IIoT_{j}\)) Devices: are widely used in numerous domains and are typically described as devices with few resources that are capable of connecting to the Internet. These devices commonly rely on the delegation of their storage and computing functions to centralized servers over wireless connections for the purpose of data analysis and administration. Within our proposed system model, users/controllers and IIoT devices initially engage in an online registration process with a TA, followed by an offline registration process with one another. When adding a new IIoT or a new user/controller (a new communication path is allowed in the system), the new device sends a message to \(TA\) for the purpose of validation. The \(TA\) sends a message to the IIoT device and the User (the communication partners). After the reception of these messages, both the User and the IIoT device proceed to generate and confirm the authentication key for future messages. The \(TA\) and \(IIoT\) device selection methods ensure the soundness of the suggested strategy. In order to establish robust security measures and safeguard privacy from potential risks, we have developed a lightweight message authentication protocol utilizing a symmetric key and incorporating forward secrecy (FS) capabilities. This approach has been meticulously designed to accommodate the unique requirements of an IIoT environment. The latest research shows that the proposed scheme must meet the following security and privacy requirements [27; 28; 29; 30]:  
* Mutual authentication: The purpose of mutual authentication is to facilitate the verification of communication reliability between entities. This measure guarantees that parties can have a high level of assurance regarding the authenticity of the communicating entity's identity while also preventing hostile parties from assuming the identities of legitimate entities. * Ensuring authenticated message integrity: It is imperative that messages utilized for authentication purposes between entities have the capability to be identified if any unauthorized alterations or tampering have occurred. * Key agreement: The proposed scheme aims to establish a mutually shared session key solely between the user and the Industrial Internet of Things (IIoT) device. This key will be utilized for the authentication of messages exchanged between the user and the IoT device. * Soundness: Following the completion of a legitimate session, it is expected that the shared keys will achieve a state of synchronization. In essence, it is vital to periodically update shared authentication keys, which are used to authenticate entities and are employed to compute session keys. This practice guarantees the accuracy and uniformity of the session key.