## 5 Implementation of Secure IoT-Based Communication System
### Publisher Implementation at the IoT Node
Furthermore, the integration of TLS 1.3 with X.509 certificates issued by trusted Certificate Authorities (CAs) at the local broker, cloud broker and subscriber mitigates threats associated with unauthorized access or spoofed brokers (e.g., T1557--Man-in-the-Middle). This is reinforced by mutual certificate validation and strict topic-based access control at MQTT brokers, reducing the risk of command-and-control misuse via the application layer (e.g., T1071.001--MQTT protocol abuse). The framework also mitigates risks related to credential brute-forcing and password compromise (T1110--Brute Force) through the use of pre-provisioned symmetric keys at the edge and planned integration with AWS Key Management Service (KMS) at the bridge and cloud layers. ### Performance Evaluation

Performance evaluation is undertaken with six encryption protocols--Salsa20, ChaCha20-Poly1305, AES-GCM, CCM8, EAX, and TinyAES--across three payload sizes (1 KB, 5 KB, and 10 KB). The evaluation considers average throughput, CPU cycles, and encryption time, offering a granular view of how each protocol scales with data volume. The experimental results illustrated in this section provide a comprehensive overview of the performance of the proposed HECS4 MQTT framework across its core components: publisher, local broker bridge, and subscriber. Figures 6 and 7 capture the behavior of the publisher. Figure 6 presents the execution of a test cycle where the publisher transmits encrypted image payloads using a selected protocol (ChaCha20-Poly1305 in this run). The system iterates through multiple encryption protocols, and for each run, 100 images are published. Figure 7 reports detailed performance metrics such as CPU cycles, encryption time, throughput, and memory usage (RSS). These measurements are essential for evaluating the computational overhead of each encryption protocol on constrained devices. Figure 8 shows the terminal output of the local broker bridge. It confirms successful connection to the local MQTT broker and logs the message transformation and forwarding activity to the cloud broker. Each message is decrypted (Salsa20), re-encrypted (AES256), and securely forwarded over TLS 1.3, highlighting the bridge's role in ensuring layered encryption and secure transition beyond the edge network. Figure 9 presents the subscriber's behavior. It logs the receipt of published messages, indicating correct end-to-end delivery. Together, these figures validate the operational integrity and performance of the multi-layer

Figure 6: Publisher testing. Average CPU cycles reveal how demanding each protocol is on device processors, a key constraint in IoT environments. Salsa20 again proves efficient, requiring the fewest cycles across all payloads. Figure 12 displays the average CPU cycles consumed by each protocol. [PERSON] et al. [28] studied the performance evaluation of e-health applications, noting the limitations of existing studies and the lack of realistic measurements in the context of IoT communications. Importantly, they state that a latency below 500 milliseconds is required for emergency and rapid response e-health applications, particularly in scenarios involving event-driven alarms where immediate action is critical. In contrast, less time-sensitive applications, such as those involved in electrocardiogram (ECG) monitoring, can typically tolerate latency of up to 1 s without compromising clinical utility. All latency measurements obtained during our experimental evaluation were consistently below 500 milliseconds, thereby demonstrating the effectiveness of the HEC54 MQTT framework. Figure 11: Average encryption by protocol and image size. Figure 10: Average throughput by protocol and image size. ## 7 Conclusions and Discussion

This study has presented a secure and scalable MQTT-based communication framework tailored for healthcare IoT environments.