## 5 Implementation of Secure IoT-Based Communication System
### Publisher Implementation at the IoT Node
```
Input: Encrypted MQTT messages from edge devices Output: Re-encrypted messages published to cloud broker Begin  Connect to Cloud MQTT Broker  Subscribe to Topic
```

**Algorithm 4**Pseudocode For Subscriber ComponentAll cryptographic schemes were implemented using well-established, open-source cryptographic libraries--primarily PyCryptodome, a widely-used and actively maintained Python library that supports a broad range of symmetric encryption algorithms, AEAD modes, and secure random number generation. Here are some sample imports taken from the source code:

from Crypto.Cipher import AES, ChaCha20,ChaCha20_Poly1305,Salsa20

from Crypto.Util.Padding import pad,unpad

from Crypto.Random import get_random_bytes

## 6 Performance and Security Analysis

Table 1 summarizes the metrics used to evaluate the proposed layered encryption framework. The metrics are divided into two categories: security-related metrics, which assess how well the system protects sensitive healthcare data, and performance metrics, which assess the efficiency of the encryption techniques when applied to resource-constrained IoT devices. Each metric is listed alongside the tools or methods used to measure it, the specific layer of the architecture where the evaluation was applied (either edge or cloud), and the expected outcome based on the design goals. ### Testbed

To evaluate the proposed multi-layer encryption framework under realistic IoT healthcare conditions, we extended our original testbed in this study [4] to include a local MQTT broker deployed within the hospital (edge) environment. This modification allows us \begin{table}
\begin{tabular}{l l l l} \hline \hline
\begin{tabular}{l} Salsa20\(\backslash\)Blake2b is better \\ compared to other protocols \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Security and performance metrics. to simulate the layered security model: lightweight encryption at the edge and robust encryption when data leaves the hospital premises toward the cloud. The revised testbed is illustrated in Figure 4. A similar testbed using the Ubuntu operating system has been adopted in several research studies. For example, [PERSON] et al. (2019) proposed a data protection protocol for MQTT based on hierarchical ID-based encryption and evaluated its performance using Python libraries on an Ubuntu 18.04.4 LTS system with an Intel Core i9-9940X 3.30 GHz processor. The testbed consists of three main roles: the MQTT Publisher, the Local MQTT Broker, and the MQTT Subscriber, all deployed on laptops running Ubuntu 22.04 LTS. Each device is equipped with an Intel Core i5 CPU, 8 GB of RAM, and utilizes the Paho MQTT library version 1.5.1. The publisher encrypts image data using lightweight ciphers (e.g., Salsa20-Blake2b) and sends it to the local MQTT broker. The Local Broker, hosted on an identical laptop, receives and decrypts the incoming messages. A bridge component re-encrypts them using AES-256 and publishes them over a TLS 1.3 channel to the Cloud MQTT Broker, which is hosted on an AWS instance running Ubuntu 24.04 LTS and Mosquito version 2.0.18. The MQTT Subscriber, located on a fourth laptop with the same hardware and software stack as the publisher, subscribes to the cloud broker and receives the re-encrypted data for further validation and performance analysis. ### Security Evaluation

In the context of encrypted IoT traffic, particularly for privacy-sensitive domains such as healthcare, the preservation of statistical unpredictability in ciphertext is essential. To assess this, we applied the Approximate Entropy (ApEn) test from the NIST Statistical Test Suite (STS) ([PERSON], 2019), which measures the frequency and predictability of overlapping patterns in a binary sequence. A high entropy score indicates that the ciphertext lacks detectable regularity--an essential criterion for resisting ciphertext-only attacks and for maintaining the indistinguishability of encrypted data.