## 5 Implementation of Secure IoT-Based Communication System
### Publisher Implementation at the IoT Node  
The publisher emulates a typical IoT edge node, such as a wearable medical device, that collects and transmits patient-related data. In this implementation, a static image file is used to represent sensed data for evaluation purposes. The image data is loaded in binary format and encrypted using one of several available cryptographic schemes prior to transmission. The supported encryption algorithms include ChaCha20-Poly1305, AES in EAX, GCM, and CCM8 modes, TinyAES in CTR mode, Salsa20 with Blake2b, Ascon, and lightweight ciphers such as SIMON and SPECK. Each encryption routine uses either a fixed 128-bit or 256-bit key, defined in advance. For authenticated encryption schemes, nonce and tag management are handled within the function, and the encrypted payload is base64 encoded for safe transmission via MQTT. The publisher component connects to the local MQTT broker over a non-TLS channel (port 1883), reflecting real-world scenarios where IoT devices operate in trusted local  
Figure 3: Traffic flow. environments with limited TLS capability. TLS support is included for both OpenSSL and WolfSSL, although this is deactivated by default. The publisher constructs a JSON message containing the encrypted image and a timestamp indicating the moment of publication. Messages are sent to the MQTT broker on a predefined topic, simulating real-time data flow from an IoT health sensor. To assess the performance of each encryption scheme under constrained conditions, the implementation integrates system-level monitoring. The Linux perf tool is executed as a subprocess to capture hardware-level statistics, including task clock, CPU cycles, instructions, cache references, and cache misses. In parallel, a separate thread utilizes the psutil library to track memory usage, measuring real-time resident set size (RSS) and peak memory allocation during the transmission phase. The publisher is designed to run for a fixed number of iterations, transmitting a defined number of encrypted messages at regular intervals. Upon completion, the system calculates throughput based on the total size of encrypted data sent over the elapsed time. All metrics--timing, CPU usage, cache behavior, memory usage, and throughput--are aggregated and logged in a structured CSV format for subsequent analysis. Algorithm 1 outlines the core functionality of the publisher module within the proposed framework. ```
Input: Image directory path, number of images x, encryption method Output: Encrypted messages published to MQTT topic, log performance Begin  Connect to Local MQTT Broker with TLS  For x number of images do  Load image data from file  Generate timestamp  EncryptedPayload = Encrypt_Payload(image_data, Encryption_Method)  Construct JSON message with 'timestamp' and 'content'  Publish message to topic  Wait fixed interval before next message  Log performance metrics (latency, throughput, CPU stats)  End For  Save performance data in cvs file  Disconnect from Broker End
```  
Algorithm 2 outlines the core functionality of the encryption function. ```
Input: Image directory path, number of images x, encryption method Output: Encrypted messages published to MQTT topic, log Begin  function Encrypt_Payload(data, method)  If method =AES-GCM:  Generate nonce Other methods, such as ChaCha20-Poly1305 and CCM8, follow similar encryption and tagging generation patterns. ### Local MQTT Broker and Bridge Application

The local broker, implemented using Mosquito, serves as a lightweight, internal MQTT hub that receives encrypted messages from the publisher. It provides basic message queuing and forwarding capabilities without any transformation or decryption of the payload. This broker acts as an intermediary that simplifies edge communication and enables local scalability by allowing multiple publishers to offload encryption tasks while forwarding to a common cloud path via the bridge.