## 5 Implementation of Secure IoT-Based Communication System
### Publisher Implementation at the IoT Node
The proposed system leverages a multi-broker layered encryption model, combining lightweight encryption at the edge (using Salsa20 and Blake2b) with robust cryptographic protections (AES-256 and TLS 1.3) as data moves toward the cloud. A key architectural advancement is the introduction of a custom bridge application, which performs in-place cryptographic translation, decoupling edge-layer encryption from transport-layer security without imposing computational burdens on resource-constrained devices. A comparison with traditional TLS-only architectures highlights the security and operational benefits of the proposed approach. As shown in Table 3, TLS-only models rely on a centralized broker to handle all client traffic, which, while offering basic confidentiality and metadata protection, exposes decrypted payloads at the broker layer. In contrast, the multi-broker architecture preserves end-to-end confidentiality by maintaining encryption throughout the data lifecycle. Furthermore, this model reduces the impact of broker compromise, avoids TLS-related overhead on IoT endpoints, and introduces cryptographic adaptability suited for varied operational environments, particularly in healthcare, where privacy, performance, and reliability are paramount. The modular separation of trust zones--from edge nodes within hospital networks to cloud infrastructures--also enhances auditability and security governance. Each broker operates independently, which promotes scalability across multiple hospitals or clinics while retaining a consistent security posture. This makes the proposed design not only technically feasible but also strategically aligned with large-scale health data systems that must comply with privacy regulations. While the current architecture demonstrates strong performance and security guarantees, several areas offer opportunities for future enhancement:

1. Dynamic Key Management: future research could explore the integration of lightweight key exchange protocols or identity-based encryption to reduce the reliance on pre-shared keys at the edge. 2. Mutual TLS Authentication: enforcing client authentication via mutual TLS in the cloud broker could further enhance access control and mitigate impersonation risks. Figure 12: CPU cycles by protocol and image size. 3. Intrusion Detection Integration: the bridge application can be extended with lightweight anomaly detection modules to monitor traffic patterns and detect signs of compromise or data leakage. 4. Interoperability Testing: extending the framework to support additional brokers, such as HiveMQ or EMQX, and testing interoperability in hybrid deployments would validate its practical adaptability. With the rise of quantum computing, existing cryptographic schemes--especially RSA and ECC--face potential vulnerabilities. Further extension of this work could incorporate post-quantum algorithms, such as lattice-based key exchange, particularly at the cloud layer, where resources are more flexible. Additionally, 6G+ networks will enable ultra-low latency and edge intelligence, making the proposed multi-broker architecture well-suited for integration with 6G features like network slicing and secure edge processing. Future work could include investigating the integration of quantum-resilient cryptography and assessing the framework's adaptability to 6G-enabled healthcare IoT systems.