## 3 Related Work
### Limitation of Lightweight Encryption and the Need for Layered Security  
While lightweight encryption schemes have been widely recognized as effective solutions for securing resource-constrained IoT devices, their scope of applicability remains largely confined to local or edge-level communications. These cryptographic mechanisms, designed to minimize CPU cycles, memory usage, and energy consumption, are optimized to operate within the tight hardware limitations of IoT nodes such as wearables, sensors, and embedded devices. Algorithms like ChaCha20, TinyAES, SIMON, and SPECK demonstrateefficiency on such platforms by reducing computational complexity and supporting real-time data processing. However, as IoT ecosystems scale and data transmission extends beyond the local premises of edge environments toward remote cloud infrastructures, the security landscape changes considerably. Communication across public or semi-trusted networks introduces increased exposure to sophisticated attack vectors, including man-in-the-middle attacks, replay attacks, and key compromise risks. In such scenarios, the lightweight encryption schemes that prioritize performance over cryptographic strength may no longer offer sufficient resilience against these threats. This renders lightweight encryption alone inadequate for securing sensitive health data or critical IoT applications once data moves beyond the trusted local domain. Conversely, applying robust encryption schemes--such as AES-256 with GCM mode, RSA, or Elliptic Curve Cryptography (ECC) with large key sizes--provides stronger protection and compliance with regulatory standards like HIPAA and GDPR for data in transit across untrusted environments. These algorithms offer higher security margins, resistance to brute-force attacks, and support for advanced features like mutual authentication and key exchange. However, their computational requirements, larger memory footprint, and higher energy consumption make them impractical for direct deployment on constrained IoT devices, especially at the edge, where processing resources are limited. This performance-security dichotomy highlights a critical trade-off in IoT environments. Lightweight encryption satisfies performance demands at the device level but falls short when higher-grade security is required for wide-area or cloud communication. On the other hand, robust cryptographic protocols ensure stronger data protection but at the cost of rendering constrained devices inoperable due to resource exhaustion. To address this challenge, there is a need for a layered encryption approach that applies lightweight cryptography for local, edge-level communication while enforcing stronger encryption mechanisms at the boundary between edge systems and cloud services. Such a design allows for optimized resource utilization at the device level without compromising the overall security of the system when sensitive data exits the local trusted environment. This work embraces this layered security philosophy by integrating lightweight encryption at the edge and robust end-to-end encryption during data transmission to the cloud through a multi-broker MQTT architecture. This design ensures that security policies are adaptable to the context of data transmission, providing a balanced solution between cryptographic strength and resource efficiency. The main contributions of this study are the following:  
1. Designing and implementing a dual-layer encryption architecture that integrates lightweight encryption at the edge and strong encryption (AES-256 with TLS 1.3) when transmitting data to the cloud, ensuring confidentiality, integrity, and performance across the entire data pipeline. 2. Introducing a custom bridge application that operates at the boundary between trusted (hospital) and untrusted (cloud) environments. The bridge functions as both subscriber and publisher--decrypting edge-encrypted messages and re-encrypting them using cloud-grade protocols before forwarding--effectively decoupling transport-level and application-level encryption. 3.