## 5 Implementation of Secure IoT-Based Communication System
### Publisher Implementation at the IoT Node
\begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Aspect** & **TLS Only (Single Broker)** & **Multi-Broker Layered Encryption** \\ \hline Architecture & Single MQTT broker with TLS connection from all clients & Local broker (in hospital) + cloud broker, with edge and cloud layers using different encryption schemes \\ \hline Encryption at Edge & TLS (standard AES, handshake overhead) & Lightweight encryption (e.g., Salsa20-Blake2b) optimized for resource-constrained devices \\ \hline Data Security Beyond the Broker & Not preserved—broker decrypts payload & Preserved—data re-encrypted (e.g., AES-256 + TLS 1.3) before leaving trusted environment \\ \hline Metadata Protection & Protected (TLS encrypts topics, headers, etc.) & Fully protected via TLS on outer layer; internal encryption protects payload end-to-end \\ \hline End-to-End Confidentiality & Broken at broker level—broker sees plaintext payload & Maintained from publisher to subscriber through layered encryption \\ \hline Broker Compromise Risk & High—one compromised broker exposes all client data & Reduced—layered encryption limits exposure even if a broker is compromised \\ \hline TLS Overhead on IoT Devices & Significant (handshake, certificate validation) & Avoided—edge uses lightweight symmetric encryption tailored to constrained devices \\ \hline Key Management Complexity & Centralized certificate-based authentication & Multi-key architecture (light at edge, stronger in cloud) with symmetric/shared keys \\ \hline Adaptability for Healthcare & Less suitable for edge devices (wearables, implants) & Highly adaptable—tailored crypto for edge, strong security when data moves to public/cloud infrastructure \\ \hline Compliance and Auditability & Requires TLS logs and endpoint audit trails & Clear separation of trust domains (edge, hospital, cloud) allows enhanced security controls and logging \\ \hline Scalability Across Hospitals & Single point of failure & Multi-broker allows local independence and central management in cloud \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Comparison of traditional TLS-MQTT with multi-broker layered encryption. ### Positioning Within Current Research

Recent studies in IoT security have explored various lightweight encryption methods [4; 5; 6; 7; 8; 9; 10; 11; 12; 13; 14; 15; 16; 17; 18; 19; 20]. However, most existing works either focus solely on lightweight schemes at the device level or employ TLS in monolithic, single-broker architectures that do not preserve end-to-end confidentiality. This research builds on prior findings by integrating both dimensions--efficient edge-layer encryption and robust cloud-layer protection--through a modular, multi-broker MQTT framework. ### Limitations of This Work

While the proposed system demonstrates strong performance and security under standard operating conditions, several limitations must be acknowledged to inform future research and practical deployments. We acknowledge the following: (1) static key management--the current implementation uses pre-shared symmetric keys at the edge, which may present management and scalability challenges in large-scale deployments; (2) limited broker interoperability--the system was primarily tested using a specific MQTT broker implementation, and broader compatibility with other brokers (e.g., HiveMQ, EMQX) has not yet been fully validated; and (3) no real-time attack simulation--the system was evaluated under normal operation scenarios, and future evaluations should include adversarial testing for various attack surfaces. ### Future Research Directions

Building on the proposed design, future research could explore the following:

1. Integration of post-quantum cryptographic algorithms, especially lattice-based key exchanges, to ensure long-term cryptographic resilience. 2. Adapting the framework to 6G-enabled infrastructures, leveraging edge intelligence, ultra-low latency, and secure slicing for healthcare-specific use cases. 3.