## 5 Implementation of Secure IoT-Based Communication System
### Publisher Implementation at the IoT Node
The broker configuration includes a listener on port 1883 for local (non-TLS) connections and defines the topic structure (e.g., image/test) used to separate and organize published image data. The same MQTT local broker is running a custom bridge application that was developed to securely transfer encrypted IoT data from the local MQTT broker, hosted within the hospital network, to a cloud-based broker. The bridge acts as a middleware layer with dual MQTT roles. It subscribes to encrypted messages published to the local broker by edge IoT devices--typically resource-constrained nodes that encrypt their payloads using lightweight symmetric encryption algorithms such as Salsa20, in conjunction with the Blake2b hashing function for message integrity. Upon receiving these messages, the bridge decrypts the payload locally using a pre-shared symmetric key and nonce structure. Following successful decryption, the bridge performs re-encryption of the payload using AES-256. This transformation ensures that sensitive healthcare data is protected with stronger cryptographic guarantees before being transmitted across untrusted networks. The re-encrypted data is then published to the cloud MQTT broker over a secure TLS 1.3 channel, leveraging a self-signed X.509 certificate for broker authentication. Functionally, the bridge application encapsulates the following operations:

1. MQTT Subscriber: subscribes to a designated topic on the local Mosquito broker to retrieve incoming encrypted messages. 2. Decryption Module: applies the Salsa20 cipher to extract the original message content. 3. Re-encryption Module: uses AES in GCM mode with a 256-bit key to ensure confidentiality and integrity. 4. MQTT Publisher: publishes the transformed message to the cloud broker on a mirrored topic, using UTF-8 encoding and base64 to preserve structure. Algorithm 3 outlines the core functionality of the local broker component. Each hospital can deploy an identical bridge that independently manages encryption, translation and secure routing, by incorporating both application-layer and transport-layer encryption. This design decouples resource-efficient encryption at the edge from the computationally heavier encryption required for cloud integration, allowing edge devices to remain lightweight and energy-efficient while maintaining compliance with cloud security standards and providing architectural scalability. ### Cloud MQTT Broker and Subscriber

The cloud broker is hosted in a secure environment (e.g., AWS) and configured to accept TLS connections from external clients such as the bridge. It functions identically to the local broker in terms of topic management but enforces additional security policies. The subscriber connects to this cloud broker, receives the forwarded encrypted messages, and is responsible for:

* Verifying the authenticity of the payload using the MAC. * Decrypting the ciphertext using the shared symmetric key. * Measuring latency and decryption time. The subscriber reconstructs the original binary image from the decrypted payload and stores it locally for further analysis. Decryption operations mirror the encryption protocol used by the publisher and require proper nonce extraction and HMAC validation. Only if the integrity check passes is the decryption process executed. The subscriber also logs message arrival time, processing delays, and total messages received. These metrics help evaluate end-to-end system performance and protocol efficiency in realistic deployment scenarios. Algorithm 4 outlines the core functionality of the subscriber component.