# Enhancing Resilience in Digital Twins: ASCON-Based Security Solutions for Industry 4.0
## 3 Proposed Solution
### MQTT Broker  
We chose to utilize the MQTT protocol for three reasons. Firstly, MQTT is a commonly used communication protocol in IoT applications. Secondly, it is a lightweight messaging protocol, that can be configured and programmed to support payload encryption using any encryption algorithm, like the algorithms we chose for comparison, namely ASCON and AES-GCM (family of AEAD based on AES). Thirdly, Eclipse Ditto [20] supports MQTT protocol, i.e., through Eclipse Mosquitto [22], as a connection.  
The MQTT broker, designed for IoT communication, is crucial in our project. We opted for Eclipse Ditto's MQTT implementation, i.e., Mosquitto ([22]). Initially, we aimed to customize and control the MQTT implementation by building it from the source on our Linux server. This approach allowed us to directly incorporate a lightweight encryption algorithm into the code. However, we chose to implement these algorithms by extending the Ditto source code itself, using the provided connectivity extension. We utilized the connectivity extensions provided by Ditto, which we further extended to utilize our AEAD encryption algorithms. However, an external MQTT broker can also be used by installing it on the same machine as Ditto (Digital Twin) or on a separate, remotely accessible machine. Our scheme ensures secure IoT device communication with the cloud-hosted Ditto service.  
The MQTT broker plays a pivotal role in our IoT communication project. We chose Eclipse Ditto's MQTT implementation, specifically Mosquitto. Leveraging Ditto's connectivity extensions, we extended them to incorporate our AEAD encryption algorithms. Alternatively, an external MQTT broker can be utilized on the same machine as Ditto (Digital Twin) or a separate remote machine. Our approach guarantees secure communication between IoT devices and the cloud-hosted Ditto service. Despite MQTT not inherently being a secure protocol, our MQTT broker functions as a proxy, forwarding encrypted payload messages without access to IoT devices' encryption keys. Consequently, only the involved parties can decrypt and authenticate the payload. This entire process is visualized in Figure 2. The MQTT broker's limited access means it can only interact with the encrypted payload, preventing any malicious broker from compromising communication security. Our lightweight authentication and encryption algorithm, integrated into the solution, guarantees the confidentiality and integrity of the exchanged data.  
Even though MQTT is not a secure protocol, in our case, the MQTT broker acts merely as a proxy forwarding encrypted payload messages and does not have the shared encryption keys of IoT devices. Hence, only the communication parties can decrypt and authenticate the payload. The whole process is illustrated in Figure 2.  
The communication process between devices and Ditto involves several key steps. Firstly, each device connected to Ditto is assigned a unique device ID, crucial for ASCON's associative input. Secondly, a shared symmetric key exists between the device and its corresponding Digital Twin. When a message needs to be sent, the sender encrypts the payload and publishes it using MQTT under a topic that includes the device's unique ID. Similarly, the device uses its ID to publish messages for Ditto, creating a connection between the sender and receiver. Upon reception, the receiver decrypts and authenticates the MQTT message payload using the preshared symmetric key, ensuring the message's integrity and origin. In cases with multiple IoT devices, the receiver retrieves the appropriate shared key using the device ID, thereby ensuring secure and authenticated communication.