The proposed system comprises four main components: medical IoT devices for data collection; an AI-based sensitivity classifier; an adaptive cryptography module for dynamic algorithm selection; and a contextual awareness engine coordinating the entire system. This architecture follows the principles of contextual security systems outlined in recent literature [4][19].

MedicalIoTDevices

Medical IoT devices continuously collect health data, including vital signs (heart rate, blood pressure, temperature), monitoring data (electrocardiograms, blood glucose), and contextual information (patient activity, location). These devices operate under strict resource constraints: limited processing power (ARM Cor-tex-M0/M3), constrained memory (16 - 256 KB RAM), limited battery capacity (1000 - 3000 mAh), and variable network connectivity (2G/3G/4G/WiFi) [8].

AISensitivityClassifier

The AI-based sensitivity classifier automatically analyzes collected health data and assigns sensitivity levels (HIGH/MEDIUM/LOW) based on extracted medical keywords, data type (test results, imaging, prescriptions, appointments), file size and metadata, and collection context (location, time). Random Forest classifiers have demonstrated excellent performance in medical data classification tasks [14][20].

AdaptiveCryptographyModule

The adaptive cryptography module dynamically selects between two lightweight encryption algorithms. RECTANGLE offers a block cipher optimized for hardware implementation, while ASCON designated winner of the NIST Lightweight Cryptography competition is optimized for software applications [15][16]. In February 2023, NIST officially announced the selection of the Ascon family as the standard for lightweight cryptography for IoT devices [16]. Selection between the two algorithms relies on a multicriteria analysis simultaneously considering data sensitivity, current network conditions, device capabilities, and global deployment context.

To provide a rigorous security foundation for the proposed framework, we formally define the threat model and map each objective to its corresponding cryptographic mechanism in the adaptive pipeline. We consider both passive adversaries capable of eavesdropping on IoT communication channels, and active adversaries capable of replay attacks, man-in-the-middle injection, and physical side-channel attacks on resource-constrained hardware. Insider threats involving unauthorized access to sensitive classification labels are also considered.

Table 1 summarizes the five security objectives addressed by the proposed framework, the corresponding threats, and the cryptographic mechanisms employed by each adaptive pipeline component.

For sensitivity classification, we used the MedMCQA dataset, a large-scale medical corpus comprising 193,155 multiple-choice questions from Indian medical entrance examinations (AIIMS and NEET PG) [12], covering 21 diverse medical specialties, including psychiatry, radiology, surgery, and general medicine.

Table 1. Security objectives, threats addressed, and corresponding cryptographic mechanisms in the adaptive pipeline.

This mapping ensures that each layer of the adaptive pipeline directly addresses a defined security objective, providing end-to-end protection tailored to the heterogeneous threat landscape of African healthcare IoT deployments.

Data were distributed as follows: 70% for training (≈135,208 samples), 15% for validation (≈28,973 samples), and 15% for testing (≈28,974 samples). This distribution provides a solid and balanced foundation for model development and evaluation.

DataPreprocessing

We adapted MedMCQA for sensitivity classification through a methodical multistep process: extracting medical subjects and question content; and classifying each sample into three sensitivity levels based on domain expertise. The HIGH category includes psychiatry, forensic medicine, and pathology with sensitive keywords (HIV, cancer, genetic conditions, mental health). The MEDIUM category covers radiology, surgery, and general medicine. The LOW category encompasses general health and wellness topics. Figure 1 illustrates the final class distribution after data balancing.

Figure 1. Sensitivity class distribution in the dataset: HIGH (27.3%), MEDIUM (38.0%), and LOW (34.7%).

To ensure reproducibility of the sensitivity labeling process, we describe the complete protocol applied to MedMCQA samples. Labeling was performed algorithmically using a hierarchical keyword-matching procedure applied to the lowercased concatenation of each sample’s question and explanation fields. The hierarchy operates as follows: a sample is labeled HIGH if any keyword from the HIGH set is detected in the text, regardless of other signals. In the absence of HIGH keywords, the sample is labeled MEDIUM if at least one MEDIUM keyword is present. Otherwise, if at least one LOW keyword is found, the label is LOW. Samples matching none of the three categories were excluded from the training set.

The HIGH keyword set (48 terms) covers conditions associated with stigma, terminal prognosis, or legal implications: hiv, aids, antiretroviral, cancer, tumor, malignant, metastasis, carcinoma, chemotherapy, genetic, hereditary, mutation, suicide, psychiatric, schizophrenia, bipolar, addiction, forensic, autopsy, terminal, palliative, std, gonorrhea, syphilis, tuberculosis, hepatitis, epilepsy, and related terms. The MEDIUM set (32 terms) covers clinical procedures and diagnostic imaging: surgery, CT scan, MRI, ultrasound, diagnosis, treatment, biopsy, ICU, cardiac, respiratory, diabetes, hypertension, and related terms. The LOW set (28 terms) covers general health and preventive care: anatomy, vaccination, wellness, nutrition, diet, exercise, screening, checkup, physiology, and related terms.

The keyword lists were jointly validated by all four coauthors, who hold expertise in medical informatics and data science. Borderline terms were resolved by majority vote, yielding the final sets. The labeling procedure was implemented in the function label_by_content() in notebook 03_train_ai_model_NO_LEAKAGE.ipynb and applied uniformly to all 193,155 MedMCQA samples.

Table 2 provides representative examples of MedMCQA samples across the three sensitivity levels, illustrating the keyword-driven labeling protocol applied during data preprocessing.

Table 2. Representative examples of MedMCQA samples and their assigned sensitivity labels.

This protocol yielded 135,208 labeled training samples (70%), 28,973 validation samples (15%), and 28,974 test samples (15%), with the class distribution: HIGH 27.3%, MEDIUM 38.0%, LOW 34.7% (Figure 1).

We implemented a Random Forest classifier for automatic medical data sensitivity classification. The model processes medical keywords extracted from data content, data type (test results, imaging, prescriptions), file size, and source location. Random Forest is justified by its demonstrated effectiveness in medical classification tasks, handling high-dimensional data while providing detailed feature importance analysis [14][20][21].

FeatureEngineering

Medical keyword extraction relies on a multi-dimensional approach combining in-depth analysis of the medical subject (psychiatry, radiology), targeted searches for sensitive keywords (HIV, cancer, genetics), and data type analysis (test results, imaging). Features are extracted by leveraging established NLP techniques applied to the medical domain [13], ensuring precise and contextual identification of sensitive information.

ClarificationonFeatureGenerationfromMedMCQAandDeploymentAvailability

MedMCQA is a text-only dataset of multiple-choice medical questions and does not natively provide features such as file size or file type. To train the Random Forest classifier on a feature space reflecting real IoT medical data, we generated these features synthetically as follows.

File size (file_size_log) was synthetically generated for each MedMCQA sample based on the sensitivity label using a probabilistic model calibrated on realistic medical file size ranges: HIGH samples received a base size of 2500 bytes, representing lab reports and pathology records; MEDIUM samples received 1000 bytes, representing imaging metadata and prescriptions; LOW samples received 300 bytes, representing appointment notes and wellness logs. A uniform variance of ±50% was applied to each base size to break the direct label-size correlation, and an additional 10% of samples were assigned a fully random size between 100 and 5000 bytes to further prevent data leakage. Log-transformation (log1p) was then applied to reduce distributional skewness.

File type (file_type_encoded) was randomly assigned from the set {test_results, imaging, prescription, appointment, general} independently of the sensitivity label, then encoded as an integer. This independence was intentional, ensuring that the file type could not serve as a direct proxy for the sensitivity class during training. Source location was not used as a feature in the Random Forest classifier; it is used exclusively by the Contextual Awareness Engine (Section 2.5) for algorithm selection.

At deployment time on real IoT medical devices, these features are natively available without any additional instrumentation: file size is obtained directly from the operating system file descriptor before encryption; file type is determined by the device sensor API or MIME type of the payload (e.g., ECG monitor output, glucometer reading, pharmacy record). The TF-IDF features (500 dimensions) are computed on the text payload using the prefitted vectorizer saved with the model artifact. The total inference latency of 0.45 ms/sample (Table 1) is negligible for real-time medical monitoring applications.

ModelTraining

The Random Forest model was configured with 200 estimators and a maximum depth of 20 levels. In accordance with Section 2.2, data were distributed 70%/15%/15% for training, validation, and testing, respectively. Hyperparameter optimization used exhaustive Grid Search combined with 5-fold cross-validation, ensuring robustness and reducing overfitting risk. Performance was evaluated using global accuracy, precision, recall, and per-class F1 score [22].

ClarificationoftheEvaluationProcedure

The 70%/15%/15% split and the 5-fold cross-validation serve two distinct and complementary purposes in our evaluation pipeline, operating on completely separate data subsets. The full labeled dataset (193,155 samples) was first partitioned using stratified random sampling (random_state = 42) into three non-overlapping sets: a training set (70%, approx. 135,208 samples) reserved exclusively for model fitting and hyperparameter search; a validation set (15%, approx. 28,973 samples) used for model selection during Grid Search; and a test set (15%, approx. 28,974 samples) kept entirely held-out and used only once for final unbiased performance reporting.

The 5-fold cross-validation was applied exclusively within the training set (70%) during Grid Search (GridSearchCV with StratifiedKFold, n_splits = 5, shuffle = True, random_state = 42). In each fold, 80% of the training set (approx. 108,166 samples) is used to fit the Random Forest, while the remaining 20% (approx. 27,042 samples) serves as the internal fold validation set. This yields five accuracy scores, from which the mean and standard deviation are derived. The best hyperparameters identified (n_estimators = 200, max_depth = 20) are subsequently used to retrain the final model on the full training set.

The accuracy of 92.4% ± 1.2% (95% CI) reported in Table 5 corresponds to the 5-fold CV mean and the 95% confidence interval computed as mean ± 1.96 × (std/sqrt(n_folds)), consistent with standard reporting practice for k-fold cross-validation [22]. The precision, recall, and F1 scores in Table 5 were computed on the held-out test set (15%) to provide a fully independent generalization estimate.

We implemented two NIST-approved lightweight cryptography candidates:

RECTANGLECipher

RECTANGLE is a block cipher specifically designed for resource-constrained devices [15]. It operates on 64-bit blocks with a 128-bit key, using a Substitution-Permutation Network (SPN) of 25 rounds. Designed to minimize hardware area, it is suited to constrained environments. CTR mode achieves approximately 1200 cycles per block on ARM Cortex-M3 processors. Efficiency derives from bit-slice techniques, conferring excellent hardware and software performance while maintaining strong resistance to differential and linear cryptanalysis [15].

ASCONCipher

ASCON is the winner of the NIST Lightweight Cryptography competition, officially selected in February 2023 [16]. Its Authenticated Encryption with Associated Data (AEAD) architecture uses a 128-bit key. The ASCON-128 variant achieves approximately 850 cycles per byte. A key advantage is support for side-channel attack-resistant implementations, making it suitable for devices vulnerable to physical attacks [16].

Figure 2 illustrates the baseline performance comparison between RECTANGLE and ASCON across six payload sizes, confirming RECTANGLE’s higher encryption time and ASCON’s superior throughput under favorable conditions.

Figure 2. Baseline performance comparison between RECTANGLE and ASCON: (a) Encryption time vs. data size; (b) Throughput comparison across different file sizes.

The contextual awareness engine continuously collects and analyzes environmental parameters [4][19]: network conditions (connection type, signal strength, bandwidth); device location via GPS (classifying Hospital, Home, or Rural context and distance to the nearest facility); device capabilities (available memory, battery level, CPU usage); and temporal constraints (realtime for emergencies, batch processing for routine monitoring).

To ensure full reproducibility of the adaptive selection logic, we define below the complete decision function as an implementable algorithm. The system computes a composite security score S for each data packet based on four inputs: the sensitivity level s classified by the Random Forest model, the network signal strength n (in dBm), the device battery level b (in percentage), and the deployment location l.

The threshold S ≥ 3 was empirically calibrated to match the security requirements of African healthcare IoT contexts, where network instability and resource constraints justify a security-first default. The resulting selection distribution 67% RECTANGLE/33% ASCON overall, reaching 83% - 87% RECTANGLE in hospital and rural scenarios, is the direct outcome of applying Algorithm 1 to the experimental scenario distributions defined in Section 2.6.

Algorithm 1. Adaptive cryptographic algorithm selection procedure.

Table 3 summarizes the composite score S outcomes and the corresponding algorithm selection logic for representative combinations of input parameters.

Table 3. Summary of composite score S outcomes and corresponding algorithm selection.

2.9.1. System Architecture

Experiments used two complementary platforms. The development machine features an Intel Core i7-9750H @ 2.60 GHz (12 cores), 16 GB RAM, and an NVIDIA GeForce RTX 2070 Max-Q (16 GB VRAM), running Windows 11 Professional 64-bit (build 26200). Field IoT simulation used a Raspberry Pi 4 Model B (ARM Cor-tex-A72, 4 GB RAM, Raspbian OS), which is widely adopted in IoT security research for reproducing resource-constrained environments [11].

2.9.2. Detailed Benchmarking Methodology

To ensure full reproducibility of the encryption performance results reported in Table 6, we provide the complete benchmarking protocol below.

Regarding payload sizes, six standardized sizes were tested: 16, 64, 256, 1024, 2048, and 4096 KB, covering the range from short sensor readings (vital signs packets) to larger medical imaging metadata files. The values reported in Table 6 correspond to the 1024 KB payload size, representative of a typical medical IoT transmission unit in our three deployment scenarios.

Each algorithm-payload-scenario combination was executed across 100 independent trials (NUM_ITERATIONS = 100), yielding 600 measurements per algorithm across all payload sizes, and 1000 measurements per algorithm for the statistical t-test reported in Section 3.3, pooled across all scenario runs.

Encryption time was measured using Python’s time.perf_counter() with nanosecond resolution, wrapping exclusively the cipher.encrypt() call and excluding I/O operations, key schedule computation, and network transmission overhead. For RECTANGLE in CTR mode, timing covers the block cipher invocation over all blocks of the payload. For ASCON AEAD, timing covers both encryption and authentication tag generation (128-bit tag), since these operations are inseparable in the AEAD construction. This distinction is architecturally relevant: ASCON provides integrity at no additional computational step, whereas RECTANGLE in CTR mode requires a separate HMAC-SHA256 pass for application-layer integrity when deployed for HIGH-sensitivity data.

Concerning key and nonce management, a 128-bit random key was generated once per experimental run using os.urandom (16) and reused across trials within that run, simulating a session key. A fresh 96-bit random nonce (os.urandom (12)) was generated independently for each individual trial to prevent nonce reuse, a critical security requirement particularly for ASCON AEAD. Key schedule overhead was excluded from all reported encryption times.

Table 4 provides a complete summary of the benchmarking parameters used to ensure full reproducibility of the encryption performance experiments.

Table 4. Summary of benchmarking parameters for reproducibility.

2.9.3. Software Stack

The system was developed in Python 3.10.12, using: scikit-learn 1.3.0 for machine learning [22]; numpy 1.24.3; pandas 2.0.3; matplotlib 3.7.2; and scipy 1.11.1.

2.9.4. Experimental Scenarios

Three deployment scenarios were selected to represent African healthcare contexts: urban hospital in Douala-WiFi, strong signal, high data volume; residential home environment-4G, medium signal, moderate data volume; rural health center-intermittent 3G/2G, weak signal, batch low-volume data transmission. These configurations realistically reflect the WHO African Region’s diverse digital health landscape [23].

The Random Forest classifier achieved very satisfactory performance in automatic healthcare data sensitivity classification, consistent with previous studies on Random Forest for medical classification [14][20].

GlobalPerformance

Table 5 presents AI classifier performance metrics after 5-fold cross-validation:

Table 5. Classifier performance metrics.

Figure 3 presents the confusion matrix of the Random Forest classifier across the three sensitivity levels (HIGH, MEDIUM, LOW), confirming balanced performance with no dominant misclassification pattern.

Figure 3. Confusion matrix showing the classification results per sensitivity level (HIGH, MEDIUM, LOW).

FeatureImportanceAnalysis

Feature importance analysis revealed that file size (log-scaled) was the most influential predictor (70% of classification decisions), followed by file type (28%) and keyword count (2%).

Figure 4 illustrates the feature importance analysis, confirming that file_size_log (70%) and file_type_encoded (28%) are the two dominant predictors, while keyword_count contributes only 2%.

Figure 4. Feature importance analysis shows file_size_log and file_type_encoded as dominant predictors.

Table 6 presents mean encryption times across deployment scenarios:

Table 6. Mean encryption time per algorithm and scenario (ms), throughput, and memory usage.

The adaptive system demonstrated intelligent algorithm selection across contexts. Overall, RECTANGLE was selected for 67% of operations (prioritizing security for high-sensitivity data) and ASCON for 33% (optimizing performance under favorable network conditions). By scenario: Hospital 83% RECTANGLE/17% ASCON; Home 82%/18%; Rural 87%/13%. These variations reflect dynamic adaptation to each context’s specific constraints, favoring RECTANGLE’s robustness in more constrained environments.

Figure 5 shows the algorithm selection distribution across the three deployment scenarios, with RECTANGLE selected in 67% of cases overall, reaching 83% - 87% in hospital and rural settings.

Figure 5. Algorithm selection distribution across deployment scenarios.

RECTANGLEvs.ASCONComparison

Student’s t-test results: t-statistic = −1.4366, p-value = 0.1512 (1998 degrees of freedom). The p-value (0.151), well above the 0.05 significance threshold, indicates no statistically significant difference between RECTANGLE and ASCON performance, confirming comparable effectiveness in the studied context.

ScenarioComparison(ANOVA)

One-way ANOVA: F = 5.0170, p = 0.0068, η² = 0.0325. Significant performance differences among the three scenarios (p = 0.007 < 0.05) confirm that the deployment context exerts a significant impact on overall system performance [4].

Figure 6 compares encryption performance across deployment scenarios, with ANOVA confirming statistically significant differences (F = 5.0170, p = 0.0068, η² = 0.0325).

Figure 6. Performance comparison across deployment scenarios with significant differences confirmed by ANOVA (p = 0.007).

This study demonstrates that AI-driven adaptive cryptography significantly improves IoT healthcare device security while optimizing computational efficiency. Three main findings emerge: first, sensitivity classifier accuracy—the Random Forest model achieved 92.4% (±1.2%, 95% CI) after 5-fold cross-validation, demonstrating effective automated sensitivity differentiation without manual intervention [14][20]; second, adaptive system performance—mean encryption time of 52.33 ms with full security coverage for high-sensitivity data, confirming tangible benefits over static approaches [4][19]; third, contextual variability—significant performance variations across environments (ANOVA, p = 0.007) demonstrate that one-size-fits-all approaches are sub-optimal for heterogeneous IoT healthcare systems [3][11].

Our approach differs from existing work in several ways. Chinbat et al. [24] evaluated eight LWC algorithms using machine learning on Raspberry Pi 3 but did not incorporate adaptive selection. Recent surveys [3][24] highlight the need for contextual lightweight cryptography but propose no integrated solutions. Our framework bridges this gap by combining AI-driven classification with dynamic algorithm selection, achieving performance comparable to static implementations while providing enhanced security adaptability.

The proposed system is directly deployable in African healthcare environments: low computational requirements enable implementation on standard IoT devices; automatic sensitivity classification eliminates manual data labeling; contextual adaptation manages variable network conditions typical of rural areas [17][23]; and inference time (0.45 ms per classification) is negligible for real-time applications.

Several important limitations must be acknowledged, each accompanied by a mitigation strategy and a future research direction.

Firstlimitation-SimulationonRaspberryPiratherthancertifiedmedicalequipment: the evaluation used simulated IoT devices (Raspberry Pi 4) rather than real medical equipment in operational conditions, limiting direct generalizability. Mitigation strategy: The Raspberry Pi 4 (ARM Cortex-A72) is a robust, widely validated proxy in IoT literature [11]. Partnerships with hospitals equipped with connected cardiac monitors and glucose sensors should be established for more representative validation. Future direction: pilot deployment in a Douala health center with CE/ISO 13,485-certified devices over 6 months to validate real-world performance.Secondlimitation-Academictrainingdata(MedMCQA)ratherthanclinicaldata: MedMCQA relies on medical examination questions rather than authentic patient data [12], potentially introducing classification bias in real clinical contexts. Mitigation strategy: Enriching the training set with anonymized clinical metadata (DICOM, HL7 FHIR, pharmacy records) and applying transfer learning from MedMCQA to a local clinical corpus. Future direction: Collaboration with Cameroonian hospitals to build a labeled local medical data corpus, complying with Cameroon’s Personal Data Protection Law [25].Thirdlimitation-GPSreliabilityinindoorenvironments: the GPS-based location system may be unavailable or unreliable indoors (e.g., hospitals), reducing contextual awareness engine accuracy. Mitigation strategy: Integrating complementary localization mechanisms (Wi-Fi fingerprinting, Bluetooth Low Energy beacons, cellular network) for acceptable indoor triangulation accuracy. Future direction: Development of a hybrid localization module combining GPS, BLE, and Wi-Fi with sensor fusion using an extended Kalman filter.Fourthlimitation-Non-significantdifferencesbetweenRECTANGLEandASCON: No statistically significant performance difference was found between RECTANGLE and ASCON (p = 0.151, t-test), suggesting that dynamic algorithm switching gains may be limited in certain scenarios. Mitigation strategy: This does not undermine the adaptive framework, which adds value through flexibility and resilience rather than raw time improvement. Extending the portfolio (ChaCha20, SPARKLE, GIFT-COFB) would create more pronounced differences. Future direction: Integration of at least four LWC algorithms with complementary performance profiles and re-evaluation with increased test power (n ≥ 5000 measurements per scenario).