Réseau bidirectionnel intégré à la blockchain à mémoire longue durée pour la détection d’intrusion en temps réel dans l’Internet des objets médicaux en santé

Summary

Ce protocole décrit la mise en œuvre d’un système de détection d’intrusion bidirectionnel à court terme intégré à la blockchain pour les réseaux Internet des objets médicaux dans la santé, permettant la détection en temps réel des attaques, la journalisation médico-légale inviolable et l’atténuation automatisée.

Abstract

Les environnements d’Internet des objets médicaux (IoMT) dans la santé nécessitent des systèmes de détection d’intrusion qui non seulement identifient les cyberattaques avec précision, mais offrent aussi des capacités de responsabilité médico-légale, d’auditabilité et de réponse rapide. Les approches conventionnelles de détection d’intrusion mettent principalement l’accent sur la performance de classification tout en offrant un support limité pour l’enregistrement des événements à l’épreuve de la falsification et l’enquête post-incident. Cette étude présente un cadre de détection d’intrusion conscient de la criminalistique qui intègre un réseau Bidirectionnel Long Short-Term Memory (BiLSTM) avec une couche blockchain autorisée pour supporter la détection en temps réel, la journalisation sécurisée et l’atténuation automatisée dans les systèmes IoMT de la santé. Le protocole combine le prétraitement des données, la sélection de fonctionnalités AQU-IMF-RFE, la modélisation temporelle, l’apprentissage basé sur l’attention, les connexions résiduelles et l’enregistrement d’événements basé sur la blockchain. Le modèle BiLSTM étendu a été entraîné et évalué indépendamment sur les ensembles de données de référence UNSW-NB15, CICIDS2017 et Bot-IoT en utilisant un prétraitement reproductible, un partitionnement stratifié des données et des graines aléatoires fixes. Les événements d’intrusion détectés par le modèle ont été enregistrés sur une blockchain Proof-of-Authority via des contrats intelligents permettant une journalisation immuable et des actions de réponse automatisées. Les résultats expérimentaux ont démontré une forte performance de détection d’intrusion avec de faibles taux de faux positifs sur tous les ensembles de données évalués, tout en maintenant la traçabilité judiciaire et la capacité de réponse en temps réel. La couche blockchain offrait des enregistrements d’audit résistants à la falsification et une atténuation automatisée sans introduire une surcharge computationnelle prohibitionnelle. Ces résultats démontrent que l’intégration de la détection d’intrusion basée sur l’apprentissage profond avec la journalisation médico-légale habilitée par la blockchain améliore la fiabilité, la responsabilité et la facilité de déploiement pratique des systèmes de cybersécurité en santé.

Introduction

Dans le système de santé, la numérisation a inauguré une nouvelle ère de services de santé intelligents, connectés et centrés sur le patient. L’infrastructure médicale moderne repose fortement sur la communication réseau et l’échange de données entre capteurs portables, systèmes de surveillance à distance des patients, dossiers médicaux électroniques (^DME)1,2 et plateformes de diagnostic intelligentes. Cependant, cette interconnexion croissante élargit également la surface d’attaque des réseaux de santé, les exposant à des menaces cybernétiques telles que les violations de données, les ransomwares, les attaques par déni de service distribué (DDoS) et les attaques man-in-the-middle³. Ces intrusions entraînent des pertes financières importantes et, plus important encore, peuvent compromettre la sécurité des patients lorsque des données médicales sensibles ou des fonctionnalités critiques de dispositifs sont compromises.

L’ampleur et la complexité des systèmes Internet des objets médicaux (IoMT) aggravent encore ces défis de sécurité. Les réseaux de santé modernes doivent simultanément fournir une communication à faible latence, une grande fiabilité et des garanties de sécurité robustes, des exigences auxquelles les mécanismes de sécurité traditionnels peinent souvent^{à satisfaire 4}. La croissance rapide du trafic IoMT, caractérisée par des sources de données hétérogènes, des schémas de communication dynamiques et des exigences réglementaires strictes telles que la loi sur la portabilité et la responsabilité de l’assurance maladie (HIPAA) et le règlement général sur la protection des données (RGPD), nécessite des systèmes intelligents de détection d’intrusion (IDS) capables d’atteindre des taux de détection élevés tout en minimisant les fausses^{alertes 5}.

Dans les environnements de santé réglementés, la détection d’intrusion n’est pas seulement une exigence opérationnelle, mais aussi une fonction de responsabilité. Les alertes de sécurité peuvent déclencher l’isolement des dispositifs, affecter la continuité des soins, et par la suite faire l’objet d’audits, de revues réglementaires ou d’enquêtes juridiques. Par conséquent, un IDS IoMT efficace doit fournir une détection précise en temps réel, des décisions explicables soutenant le triage des incidents, ainsi que des dossiers inviolables garantissant la non-répudiation et la traçabilité^{médico-légale 6}. Cette exigence déplace l’objectif de détection d’intrusion d’une classification centrée sur la performance vers une gouvernance de sécurité centrée sur la confiance et la responsabilité.

Les techniques d’apprentissage profond, en particulier les réseaux de mémoire à court terme long (LSTM) et de mémoire bidirectionnelle à court terme (BiLSTM), ont démontré une forte capacité à modéliser les dépendances temporelles dans le trafic réseau et à détecter des comportements^{anormaux 7}. Néanmoins, les IDS existants basés sur BiLSTM souffrent fréquemment d’un surajustement, d’une attention insuffisante aux événements temporels critiques, et d’une généralisation limitée à travers des dispositifs IoMT hétérogènes et des environnements de santé. De plus, les réseaux IoMT sont exposés à une grande variété de menaces cybernétiques qui affectent la confidentialité, l’intégrité et la disponibilité (CIA) des données et services médicaux, comme résumé dans le tableau 1.

Type d’attaque	Contexte IoMT	Dimension de la CIA affectée	Impact sur les systèmes de santé
Accès nonautorisé 19	Exploitation de mécanismes d’authentification faibles pour accéder aux appareils des patients ou aux dossiers médicaux	Confidentialité, Intégrité	Fuite de données et contrôle non autorisé des dispositifs médicaux
Usurpation / usurpationd’identité 19	Un dispositif malveillant imite un nœud IoMT légitime	Intégrité	Des lectures erronées pouvant conduire à un mauvais diagnostic ou à un traitement dangereux
Écouteclandestine 21	Interception de données médicales non chiffrées lors de la transmission	Confidentialité	Violations de la vie privée et divulgation d’informations sensibles des patients
Falsification de données / Exploits du firmware19	Modification du firmware de l’appareil ou des données de santé transmises	Intégrité	Diagnostic incorrect ou décisions thérapeutiques inappropriées
Ransomware20	Chiffrement des données des patients ou du firmware des dispositifs médicaux	Disponibilité, Intégrité	Verrouillage des systèmes critiques et retards de traitement
Déni de service (DoS) / Déni de service distribué (DDoS)6	Surcharge des dispositifs médicaux ou des réseaux de santé	Disponibilité	Perturbations de service affectant les systèmes de surveillance et les opérations des unités de soins intensifs (USI)
Attaques par canallatéral 22	Extraction de clés cryptographiques par techniques de synchronisation ou d’analyse de puissance	Confidentialité	Compromission de dispositif et vol de clé cryptographique

Tableau 1 : Cyberattaques courantes affectant les environnements de santé de l’Internet des objets médicaux. Ce tableau résume les cyberattaques représentatives visant les systèmes de l’Internet des objets médicaux (IoMT), leur contexte opérationnel, les dimensions de sécurité de confidentialité, d’intégrité et de disponibilité (CIA) concernées, ainsi que leur impact potentiel sur la prestation des soins, la sécurité des patients et le fonctionnement des dispositifs médicaux.

La technologie blockchain offre plusieurs avantages qui peuvent compléter la détection d’intrusion dans les environnements IoMT. Comme résumé dans le tableau 2, la blockchain permet une journalisation immuable des événements pour la validation médico-légale, facilite l’atténuation automatisée via des contrats intelligents, élimine les points de défaillance isolés grâce à une opération décentralisée, et soutient la conformité aux réglementations de protection des données de santé en maintenant des traces d’audit traçables. Malgré ces avantages, les mécanismes de sécurité basés sur la blockchain restent sous-utilisés dans les IDS de santé.

Caractéristiques	Description	Avantages dans le contexte des soins de santé
Intégrité des données	Chaque transaction est hachée cryptographiquement et liée au bloc précédent	Garantit l’immuabilité des dossiers des patients et des appareils
Détection de falsification	Toute modification des données stockées modifie le hachage de bloc et invalide la chaîne	Permet la détection rapide de modifications non autorisées d’enregistrements
Contrôle d’accès	Les contrats intelligents appliquent des autorisations et des politiques d’autorisation prédéfinies	Restreint l’accès aux informations de santé sensibles aux utilisateurs et appareils autorisés
Provenance des données	Chaque événement est signé numériquement et avec un horodatage	Soutient la traçabilité médico-légale, l’audit et la conformité réglementaire
Consensus à faible latence	Le mécanisme de consensus Proof-of-Authority (PoA) permet une validation rapide des transactions avec une surcharge computationnelle inférieure à la Proof-of-Work	Prend en compte la journalisation des événements quasi en temps réel dans les environnements de santé critiques

Tableau 2 : Avantages de la technologie blockchain pour la santé Internet des objets médicaux Systèmes de détection d’intrusion. Ce tableau résume les principales fonctionnalités de la blockchain et leurs avantages associés dans les environnements de santé Internet des objets médicaux (IoMT). Les capacités listées supportent la journalisation immuable, la détection de falsifications, le contrôle d’accès, la provenance des données et des mécanismes de consensus à faible latence nécessaires pour une détection d’intrusion sécurisée et auditable.

Au-delà de l’évaluation des performances, l’intégration blockchain offre une protection contre de multiples menaces de sécurité dans les environnements IoMT. Le tableau 3 résume les forces et les limites de la blockchain dans ce contexte, en mettant en lumière les menaces efficacement atténuées, telles que la falsification et la répudiation des données, ainsi que les menaces nécessitant des protections supplémentaires. La couche blockchain supporte une journalisation à faible latence adaptée aux environnements de santé en temps réel, la résilience byzantine face aux nœuds défectueux ou malveillants, ainsi qu’une évolutivité sur les réseaux hospitaliers distribués et les dispositifs IoMT.

Menace à la sécurité	Traité par la blockchain ?	Mécanisme	Notes
Falsification de données27	Oui	Liaison cryptographique par hachage	Toute modification invalide l’intégrité de la chaîne
Répudiation26	Oui	Signatures numériques associées à chaque bloc	Empêche le déni des événements d’intrusion enregistrés
Défaillancecentralisée 25	Oui	Registre distribué maintenu entre les passerelles autorisées	Élimine un point de défaillance unique
Attaque Sybil24	Partiel	Consensus de procuration autorisé nécessitant des validateurs de confiance	Peut être atténué par une autorisation validatrice basée sur l’identité
51 % d’attaque23	Partiel	Nécessite la compromission de la majorité des validateurs autorisés	Moins probable dans les déploiements privés de blockchains PoA
Provenance desdonnées 26	Oui	Enregistrements d’événements horodatés et signés numériquement	Soutient la traçabilité médico-légale et la conformité réglementaire

Tableau 3 : Les menaces de sécurité prises en charge par l’intégration de la blockchain dans les environnements de santé de l’Internet des objets médicaux. Ce tableau résume les principales menaces de sécurité liées aux systèmes de l’Internet des objets médicaux (IoMT) et indique dans quelle mesure la technologie blockchain atténue chaque menace. Les mécanismes de protection sous-jacents et les considérations de mise en œuvre sont fournis pour chaque catégorie de menace.

La plupart des IDS existants reposent sur des règles prédéfinies ou des modèles légers d’apprentissage^{automatique 8,9}. Bien que ces approches puissent identifier des schémas d’attaque connus, elles peinent souvent à faire face à la nature dynamique et évolutive des cybermenaces modernes. Ils sont particulièrement inadéquats pour sécuriser des infrastructures de santé basées sur l’IoMT en pleine croissance, où des fausses alertes, une adaptabilité limitée et une mauvaise auditabilité peuvent affecter de manière significative l’efficacité opérationnelle. Les systèmes basés sur des règles génèrent fréquemment des taux élevés de faux positifs car ils ne peuvent pas distinguer de manière fiable les anomalies bénignes des attaques^{réelles 9}. Les modèles conventionnels d’apprentissage automatique entraînés sur des ensembles de données statiques ou obsolètes, ainsi que les approches existantes de détection d’intrusion basées sur l’apprentissage profond, ne généralisent souvent pas les comportements d’attaque émergents, y compris les intrusions^{zero-day 10,11}. De plus, les approches traditionnelles de journalisation centralisée restent vulnérables à la falsification, limitant ainsi la fiabilité des enquêtes médico-légales^{post-incident.} De nombreuses solutions IDS existantes imposent également une surcharge computationnelle importante, ce qui les rend difficiles à déployer sur les dispositifs IoMT et passerelles^{à ressources limitées 13}. En conséquence, les environnements IoMT de santé restent vulnérables aux cyberattaques sophistiquées et à plusieurs stades. Relever ces défis nécessite un cadre intelligent, sécurisé et efficace en ressources, capable d’apprendre les schémas temporels du trafic en temps réel tout en garantissant simultanément la fiabilité judiciaire et la mitigation automatisée des menaces détectées.

Malgré des avancées significatives dans l’apprentissage automatique et la détection d’intrusion basée sur l’apprentissage profond, plusieurs lacunes critiques subsistent. Premièrement, de nombreux modèles IDS existants sont développés et évalués à l’aide de jeux de données statiques et manquent donc d’adaptabilité aux comportements d’attaque en constante évolution. Deuxièmement, bien que les architectures avancées d’apprentissage profond puissent améliorer la précision de la détection, elles offrent souvent une interprétabilité limitée et ne priorisent pas les schémas de trafic cliniquement importants. Troisièmement, et surtout, les cadres IDS actuels ne fournissent généralement pas un support intrinsèque pour la fiabilité judiciaire, l’auditabilité ou la tenue de dossiers immuables, des capacités essentielles à la conformité réglementaire, à l’enquête sur les incidents et à la responsabilité juridique dans les systèmes de santé.

Bien que les mécanismes de journalisation basés sur la blockchain assurent intégrité et transparence des données, ils sont rarement intégrés de manière cohérente avec des modèles avancés de détection d’intrusion basés sur l’apprentissage profond dans des environnements IoMT sensibles à la latence. Les études existantes se concentrent généralement soit sur l’amélioration des performances de détection sans aborder l’intégrité médico-légale, soit sur des mécanismes de sécurité basés sur la blockchain sans intégrer la détection avancée des anomalies temporelles. Par conséquent, une lacune importante subsiste dans le développement d’un cadre unifié capable de fournir simultanément une détection d’intrusion spatio-temporelle en temps réel, une journalisation médico-légale inviolable, une atténuation automatisée et un déploiement pratique dans des environnements IoMT de santé hétérogènes et limités en ressources.

Motivée par ces défis, cette étude vise à développer un cadre de détection d’intrusion qui améliore les réseaux BiLSTM grâce à des mécanismes d’attention et des couches personnalisées pour une meilleure priorisation des fonctionnalités temporelles, intègre la technologie blockchain pour une journalisation des intrusions sécurisées et vérifiables ainsi que des réponses automatisées, et fonctionne efficacement dans des environnements IoMT de santé en temps réel. Nous émettons l’hypothèse que l’intégration d’une architecture BiLSTM étendue axée sur l’attention avec la journalisation médico-légale basée sur blockchain et des mécanismes automatisés d’atténuation améliorera l’efficacité de la détection des intrusions tout en offrant simultanément l’auditabilité, la fiabilité et la responsabilité requises dans les environnements de santé réglementés.

Ce travail répond à une lacune fondamentale dans la recherche en sécurité de l’IoMT en traitant la détection d’intrusion comme un problème de responsabilité judiciaire plutôt que comme un simple problème de classification. Le cadre proposé intègre la détection pilotée par l’intelligence artificielle (IA), l’enregistrement d’événements immuables et les mécanismes de réponse automatisée dans une architecture unifiée qui soutient la sécurité clinique, la conformité réglementaire et la confiance opérationnelle. L’adoption croissante des appareils IoMT et des infrastructures de santé connectées au cloud a fait des réseaux de santé des cibles attrayantes pour les cyberattaques, notamment les ransomwares, la manipulation de données, les accès non autorisés et les attaques par déni de service qui menacent la confidentialité, l’intégrité et la disponibilité des informations des patients. Le cadre proposé Extended BiLSTM–Blockchain établit un processus de sécurité en boucle fermée qui relie directement la détection d’attaque à la validation médico-légale et à l’atténuation automatisée.

Les principales contributions de cette étude sont quinquelles. Tout d’abord, un modèle de détection d’intrusion temporelle aligné cliniquement est développé en étendant une architecture BiLSTM conventionnelle avec un apprentissage temporel bidirectionnel, des connexions résiduelles, des mécanismes d’attention et des couches personnalisées afin d’améliorer la détection de schémas d’attaque complexes dans le trafic des réseaux de santé. Deuxièmement, une couche de sécurité légère basée sur la blockchain est intégrée au modèle BiLSTM étendu pour fournir une journalisation immuable, sécurisée et inviolable des événements d’intrusion et des actions système. Troisièmement, un pipeline IDS en temps réel de bout en bout est développé pour les environnements de santé, permettant une analyse du trafic en temps réel et la prédiction des intrusions avec une faible latence et une grande précision. Quatrièmement, le cadre proposé est évalué de manière exhaustive à l’aide de trois ensembles de données de référence publiques, à savoir UNSW-NB15, CICIDS2017 et Bot-IoT. Enfin, l’architecture est conçue comme un cadre edge-cloud évolutif et extensible, adapté à un déploiement pratique dans les réseaux de santé, les infrastructures médicales et les applications de e-santé.

En combinant les capacités d’apprentissage temporel des réseaux BiLSTM étendus avec la confiance et l’immuabilité offertes par la technologie blockchain, le cadre proposé offre un IDS sécurisé et fiable, adapté aux besoins évolutifs en cybersécurité des environnements de santé. Ce cadre comble les lacunes critiques dans la sécurité des réseaux de santé et établit les bases d’une adoption plus large de l’intégration de l’IA et de la blockchain pour protéger les infrastructures de santé critiques.

Protocol

Toutes les expériences ont été menées exclusivement à partir de jeux de données de référence d’intrusion réseau accessibles publiquement (UNSW-NB15, CIC-IDS-2017 et Bot-IoT), qui contiennent des enregistrements de trafic réseau sans informations personnelles ou médicales identifiables. Les ensembles de données ont été utilisés conformément à leurs licences et conditions d’utilisation respectives. Parce qu’aucun participant humain, échantillon de patients ou données personnelles identifiables n’a été impliqué, l’approbation éthique institutionnelle ni le consentement éclairé n’étaient pas requis.

Aperçu du cadre proposé
Cette section présente le cadre proposé de détection et de prévention des intrusions à double couche pour sécuriser les environnements IoMT. Le cadre intègre un réseau BiLSTM étendu pour la détection d’intrusion spatio-temporelle avec une couche blockchain légère pour la journalisation inviolable et l’atténuation automatisée. Contrairement aux approches IDS conventionnelles qui se concentrent uniquement sur la précision de la détection, l’architecture proposée est conçue pour soutenir simultanément la détection en temps réel, la responsabilité médico-légale et la conformité réglementaire, qui sont des exigences essentielles dans les systèmes de santé. Le flux de travail global et l’architecture du cadre proposé de détection d’intrusion BiLSTM–Blockchain étendu pour les réseaux IoMT sont illustrés dans la Figure 1.

Figure 1. Architecture du cadre proposé de détection d’intrusion BiLSTM–Blockchain pour les réseaux de l’Internet des objets médicaux. Représentation schématique du cadre proposé montrant les flux de travail de formation et de déploiement. Dans le flux de travail d’entraînement, les dispositifs de l’Internet des objets médicaux (IoMT) génèrent un trafic réseau qui subit un prétraitement des données et une ingénierie de caractéristiques avant d’être analysé par le modèle BiLSTM (Extended Bidirectional Long Short-Term Memory) avec une attention temporelle. Les paramètres du modèle sont optimisés par le calcul de la fonction de perte et l’entraînement itératif. Dans le flux de déploiement, le modèle entraîné effectue la détection d’intrusion selon la fonction de décision définie dans l’équation 13. Les événements d’intrusion détectés sont transmis au module blockchain, où une journalisation immuable, l’isolement des nœuds et la génération d’alertes par les administrateurs sont effectués. BiLSTM, mémoire bidirectionnelle à court terme ; IoMT, Internet des objets médicaux. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Les dispositifs IoMT générent des flux de données hétérogènes composés de trafic réseau, de métadonnées d’appareils et de signaux liés au patient. Ces entrées brutes sont souvent bruyantes, redondantes et incohérentes, ce qui les rend inadaptées à l’entraînement direct du modèle. Par conséquent, un pipeline de prétraitement est appliqué pour garantir la qualité et la structure des données avant de les intégrer au modèle BiLSTM étendu. Le pseudocode détaillé du prétraitement est fourni dans l’Algorithme 1 (Fichier Supplémentaire 1), qui décrit le pipeline de prétraitement appliqué aux flux de données IoMT avant l’entraînement BiLSTM étendu (pseudocode dans le Fichier Supplémentaire 1 ; implémentation dans le Fichier Supplémentaire 2). L’architecture complète de BiLSTM étendu est résumée dans l’Algorithme 2 (Fichier supplémentaire 1).

Flux de reproduction de bout en bout
L’étude complète peut être reproduite à l’aide des étapes ci-dessous. Le logiciel et le matériel sont listés dans la configuration expérimentale, et le code supplémentaire couvre chaque étape.

Obtenez les jeux de données → téléchargez UNSW-NB15. Utilisez les fichiers UNSW_NB15_training-set.csv et UNSW_NB15_testing-set.csv. Téléchargez CICIDS2017. Utilisez les cinq fichiers journaux MachineLearningCSV (du lundi au vendredi). Télécharger Bot-IoT. Utilisez les fichiers de sous-ensemble à 5 % UNSW_2018_IoT_Botnet_Full5pc_1_to_4. Les études antérieures de détection d’intrusion s’appuyaient généralement sur des ensembles de données de référence tels que KDD Cup 99,¹⁴ ; cependant, cette étude utilise les ensembles de données plus récents de l’UNSW-NB15, CICIDS2017 et Bot-IoT pour mieux représenter le trafic réseau contemporain. Traitez chaque jeu de données séparément. L’ensemble de données UNSW-NB15 est disponible auprès de l’Université de Nouvelle-Galles du Sud à https://research.unsw.edu.au/projects/unsw-nb15-dataset (dernière modification : 8 février 2024). Le jeu de données CICIDS2017 est disponible auprès de l’Institut canadien de cybersécurité à https://www.unb.ca/cic/datasets/ids-2017.html (publié : juillet 2017). Le jeu de données Bot-IoT est disponible auprès de l’Université de Nouvelle-Galles du Sud à https://research.unsw.edu.au/projects/bot-iot-dataset (dernière modification : 5 février 2024). Tous les ensembles de données ont été consultés en mai 2025 pour cette étude.

Prétraiter les données → supprimer les enregistrements corrompus. Combler les valeurs manquantes en utilisant les moyens de l’ensemble d’entraînement. Appliquer le débruit EMA (α = 0,3). Normaliser les caractéristiques à [0,1] en utilisant les statistiques de l’ensemble d’entraînement. Champs catégoriels par encodage d’étiquette. Construisez des fenêtres coulissantes (T = 20, foulée = 1). Ces étapes de prétraitement permettent une détection robuste d’intrusion en réduisant le bruit et en améliorant la qualité des représentations du trafic réseau pour les IDS^15,16 basés sur l’apprentissage automatique.

Certaines caractéristiques (AQU-IMF-RFE) → Classez les caractéristiques par information mutuelle. Affinez avec l’Aquila Optimizer. Appliquer la RFE Random Forest avec une validation croisée 10 fois. Gardez les dernières fonctionnalités. Cette stratégie hybride de sélection de caractéristiques suit le concept plus large de combinaison de techniques complémentaires de détection d’intrusion¹⁷ et est mise en œuvre à l’aide du cadre AQU-IMF-RFE développé dans notre travail^{précédent 18}.

Entraîner le modèle → Pour chaque ensemble de données, les données ont été aléatoirement partitionnées en ensembles d’entraînement (80 %) et de test (20 %) en utilisant une graine aléatoire fixe de 42. Vingt pour cent de la partition d’entraînement était en plus réservée comme ensemble de validation. Construis le BiLSTM étendu. Entraînez-vous en utilisant la perte binaire pondérée en entropie croisée et l’optimiseur Adam (taux d’apprentissage = 0,001, taille du lot = 64, maximum de 50 époques, avec arrêt précoce). Sauvez le modèle entraîné. L’utilisation de modèles d’apprentissage profond temporel convient parfaitement au trafic IoMT^{hétérogène 19}. Le flux de travail complet d’entraînement du modèle est résumé dans l’Algorithme 3 (Fichier supplémentaire 1). Les poids finaux des classes étaient calculés automatiquement à partir des distributions des classes de l’ensemble d’entraînement selon les équations 19 et 20. Les poids de classe résultants étaient les suivants : UNSW-NB15 : , ; CICIDS2017 : , ; et Bot-IoT (sous-ensemble de 5 %) : , . La grande valeur de w_n pour l’ensemble de données Bot-IoT reflète la sous-représentation sévère des échantillons bénins dans la partition d’entraînement du sous-ensemble des 5 %.

Déployez la blockchain → lancez la chaîne de preuve d’autorité (POA). Déployez le smart contract et notez son adresse. Autorisez les comptes passerelle. Exécutez le client de manière à ce que chaque intrusion détectée soit enregistrée et déclenche l’isolation et les alertes. Le flux de travail complet de détection, de journalisation blockchain et d’atténuation est résumé dans l’Algorithme 4 (Fichier Supplémentaire 1). La couche blockchain a été implémentée en utilisant le client go-ethereum (Geth) version 1.13.15 pour exploiter le réseau PoA autorisé, le compilateur Solidity (solc) version 0.8.19 pour la compilation et le déploiement de smart contracts, et la bibliothèque web3.py version 6.15.1 pour la communication entre l’IDS et le réseau blockchain.

Évaluer → tester le modèle sur l’ensemble de test tendu. Calculez la précision, la précision, le rappel, le score F1 et le taux de faux positifs. Enregistrer la latence et le débit. Vérifiez l’intégrité du registre blockchain. Le flux de travail complet de l’évaluation est résumé dans l’Algorithme 5 (Fichier Supplémentaire 1). La latence de détection (T_d) a été mesurée immédiatement avant l’appel d’inférence du modèle jusqu’au moment où les probabilités prédites ont été retournées. La latence d’atténuation de bout en bout (T_d +_{T b}) a été mesurée du même point de départ jusqu’à l’achèvement de la transaction de création de blocs blockchain correspondante. Le débit était calculé comme le nombre total de fenêtres de test prétraitées traitées par le pipeline complet de détection et de journalisation divisé par le temps d’horloge murale écoulé pour un seul passage complet de chaque ensemble de données. La charge de travail consistait en les partitions de test fenêtrées tout en conservant la distribution de classe bénigne à l’intrusion d’origine. Les fenêtres malveillantes entraînaient également la surcharge de la journalisation de la blockchain, tandis que les fenêtres inoffensives n’entraînaient que le coût de détection d’intrusion.

Générez des chiffres et des tableaux → tracez les courbes de précision et de pertes, la matrice de confusion et les graphiques d’évaluation comparative. Construis les tableaux comparatifs. Le flux complet de génération de figures et de tables est résumé dans l’Algorithme 6 (Fichier Supplémentaire 1). Le code source complet développé sur mesure utilisé pour générer toutes les figures et tableaux est fourni dans le Fichier Supplémentaire 2. En particulier, le script figures.py reproduit les chiffres du manuscrit directement à partir des résultats expérimentaux sauvegardés (par exemple, historique d’entraînement et fichiers de matrice de confusion), tandis que les scripts restants génèrent les données traitées et les métriques de performance utilisées pour construire les tableaux rapportés.

La figure 2 montre le flux de données au niveau de la mise en œuvre entre les modules IDS et blockchain. La BiLSTM étendue produit une décision par fenêtre (Équation 13) ; sur une classification malveillante, le client passerelle construit et signe une transaction et la soumet via web3/JSON-RPC au smart contract PoA, qui ajoute un bloc lié par hachage (Équation 14) au registre immuable et émet des événements (BlockCreated, NodeIsolated et AdminAlert) déclenchant l’isolement des nœuds et des alertes administrateurs.

Figure 2. Interaction au niveau de l’implémentation entre la détection d’intrusion et les modules blockchain. Diagramme de flux de travail illustrant la communication entre le système de détection d’intrusion et les composants blockchain. Le modèle BiLSTM étendu classe chaque fenêtre d’entrée et applique la règle de décision définie dans l’équation 13. Lorsqu’une intrusion est détectée, le client passerelle génère et signe une transaction qui est transmise via Web3.py/JSON-RPC au contrat intelligent Proof-of-Authority (PoA). Le contrat ajoute un bloc lié par hachage au registre immuable selon l’équation 14 et émet des événements BlockCreated, NodeIsolated et AdminAlert qui déclenchent des actions de confinement et de notification. IDS, Système de détection d’intrusion ; BiLSTM, mémoire bidirectionnelle à court terme ; Procuration, preuve d’autorité ; JSON-RPC, notation d’objet JavaScript – Appel de procédure distante. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Représentation des données
Considérons R comme le flux brut de trafic IoMT. Après prétraitement, chaque enregistrement brut est mappé dans un vecteur de caractéristiques normalisé de dimension d (Équation 1) :

(1)

Ici, f (⋅) est la fonction de transformation des caractéristiques qui mappe les enregistrements bruts en un vecteur de caractéristiques normalisé de dimension d. Soit le réseau IoMT constitué d’un ensemble de nœuds (Équation 2) :

N = {_{n 1} , n₂, ... , n_k} (2)

Chaque nœud _{n j} ∈ R produit un flux de données en série temporelle (Équation 3) :

(3)

Ici, x_t est le vecteur de caractéristiques au temps t, avec d caractéristiques (par exemple, taille du paquet, type de protocole, adresse source/destination) couramment observées dans le trafic réseau de santé de l’Internet des^{objets 19}. L’ensemble d’étiquettes correspondant est (Équation 4) :

  (4)

Ici, y_t=0 représente le trafic normal et y_t =1 désigne une intrusion.

Prétraitement des données
Le pipeline de prétraitement comprend les étapes suivantes, qui répondent aux défis courants de qualité des données et de sécurité liés au trafic^{IoMT 20} :

Nettoyage des données et gestion des valeurs manquantes :
Un enregistrement était identifié comme corrompu et supprimé avant l’imputation s’il remplissait l’une des conditions explicites suivantes : (i) tous les champs de caractéristiques de l’enregistrement étaient manquants (c’est-à-dire que l’enregistrement entier était nul), ou (ii) l’enregistrement contenait une valeur non finie (infini positif ou négatif) dans un champ numérique après coercition de type. La seconde règle supprime les entrées invalides telles que celles produites par la division par zéro lors du calcul des caractéristiques de flux (par exemple, des valeurs infinies de débits résultant de flux de durée nulle). Après la suppression des enregistrements corrompus, les valeurs manquantes restantes étaient imputées par remplacement moyen calculé par fonctionnalité, par jeu de données, et uniquement depuis la partition d’entraînement ; Les moyens obtenus ont été appliqués aux ensembles d’entraînement, de validation et de test afin d’éviter la fuite d’information. L’imputation n’était pas conditionnelle à la classe, et les moyennes n’étaient pas regroupées entre les ensembles de données.

Débruit temporel :
Le débruit temporel a été réalisé à l’aide d’un filtre à moyenne mobile exponentielle (EMA) par caractéristique appliqué le long de l’axe temporel. La forme récursive (causale ) y_t = α·x_t + (1 − α)·y_t−1 a été utilisée, avec un facteur de lissage α = 0,3, implémentée via la fonction ewm de pandas avec adjust=False. Chaque fonctionnalité était lissée indépendamment. En tant que filtre exponentiel (réponse impulsionnelle infinie), l’EMA n’a pas de fenêtre ou de taille de noyau fixe ; Le facteur de lissage α est le paramètre unique régissant le degré de lissage et la mémoire effective du filtre.

Normalisation Min–Max :
La normalisation min–max a été appliquée pour mettre chaque caractéristique à l’échelle [0,1] en utilisant la transformation x′=(x−min)/(max−min+ε), où ε = 1 × 10⁻⁸. Les statistiques minimales et maximales étaient calculées par caractéristique, par ensemble de données, et uniquement à partir de la partition d’entraînement ; Ces statistiques d’entraînement stockées étaient ensuite appliquées pour normaliser les ensembles d’entraînement, de validation et de test, empêchant ainsi la fuite d’informations cachées. Lors de l’inférence, les valeurs de caractéristiques situées en dehors de la zone d’entraînement étaient réduites à l’intervalle [0,1].

Encodage des caractéristiques catégorielles :
Les caractéristiques catégorielles ont été converties en forme numérique à l’aide du codage d’étiquette. Cela s’appliquait à toutes les variables catégorielles : dans^{UNSW-NB 15}, les champs proto, service et état ; dans Bot-IoT, le proto-champ ; CICIDS2017 ne contient aucun champ catégoriel parmi les caractéristiques sélectionnées. L’encodage était implémenté avec LabelEncoder par variable.

Fenêtrage temporel pour l’apprentissage séquentiel :
Le flux de caractéristiques prétraité était segmenté en séquences de longueur fixe à l’aide d’une fenêtre glissante de longueur T = 20 pas de temps avec une foulée de s = 1. Chaque fenêtre générée était validée avant inclusion. Une fenêtre n’était acceptée que si elle contenait exactement T = 20 pas de temps consécutifs et que toutes les valeurs des caractéristiques étaient finies. Les flux plus courts que T = 20 enregistrements ne produisaient pas de fenêtres. Cette configuration (T = 20, s = 1, chevauchement à 95 %) a été appliquée de manière cohérente à toutes les expériences et ensembles de données. Le flux de travail complet du prétraitement est résumé dans l’Algorithme 1 (Fichier supplémentaire 1).

L’objectif du prétraitement est de permettre une correspondance prédictive des séquences d’entrée vers les labels d’intrusion (Équation 5).

(5)

paramétrée par θ, cela prédit si un événement est bénin ou malveillant.

Sélection des caractéristiques à l’aide de AQU-IMF-RFE
La sélection des caractéristiques a été réalisée à l’aide d’AQU-IMF-RFE, une méthode hybride qui intègre l’information mutuelle (MI), l’Aquila Optimizer (AO) et l’élimination des caractéristiques récursives (RFE), introduite dans notre travail^{précédent 18}. La méthode fonctionne en trois étapes. Lors de la première étape, l’information mutuelle entre chaque caractéristique et l’étiquette de classe est calculée pour obtenir un classement initial de pertinence. Lors de la deuxième étape, l’Aquila Optimizer effectue une recherche globale sur des sous-ensembles de caractéristiques candidats en utilisant ses quatre stratégies d’optimisation. À la troisième étape, le sous-ensemble raffiné est passé par l’élimination des caractéristiques récursives avec une validation croisée de 10 fois à l’aide d’un estimateur Random Forest (RF).

L’Aquila Optimizer était configuré avec une population de 100 personnes, un maximum de 10 itérations, un facteur d’exploitation de 0,1, un taux d’apprentissage de 0,1 et un facteur d’attraction de 0,005. Appliqué indépendamment à chaque jeu de données, AQU-IMF-RFE a conservé 14 fonctionnalités pour UNSW-NB15, 24 pour CICIDS2017 et 12 pour Bot-IoT. Le pseudocode complet est fourni dans le Fichier Supplémentaire 1, et les sous-ensembles de caractéristiques sélectionnés sont listés dans le Tableau 4.

Tableau 4A. Caractéristiques sélectionnées conservées pour UNSW-NB15
S. Non.	Caractéristiques	Type	Catégorie
1	dur	Numérique (flottant)	Base
2	sbytes	Numérique (entier)	Base
3	Taux	Numérique (flottant)	Base
4	dload	Numérique (flottant)	Base
5	sinpkt	Numérique (flottant)	Temps
6	Dinpkt	Numérique (flottant)	Temps
7	sjit	Numérique (flottant)	Temps
8	TCPrtt	Numérique (flottant)	Temps
9	synack	Numérique (flottant)	Temps
10	ackdat	Numérique (flottant)	Temps
11	smean	Numérique (entier)	Contenu
12	ct_srv_src	Numérique (entier)	Connexion
13	ct_dst_src_ltm	Numérique (entier)	Connexion
14	ct_srv_dst	Numérique (entier)	Connexion
Tableau 4B. Caractéristiques sélectionnées conservées pour CICIDS2017
S. Non.	Caractéristiques
1	Destination Port
2	Durée de l’écoulement
3	Longueur totale des paquets en avant
4	Longueur totale des paquets inversés
5	Longueur maximale de paquet en transfert
6	Longueur maximale de paquet en arrière
7	Moyenne inverse de la longueur des paquets
8	Paquets de flux
9	Temps maximal d’inter-arrivée du débit
10	Temps total avant avant entre les arrivées
11	Longueur de la tête avant
12	Longueur de l’en-tête à l’envers
13	Paquets avant par seconde
14	Longueur maximale du paquet
15	Moyenne de la longueur des paquets
16	Écart-type de longueur de paquet
17	Variance de la longueur des paquets
18	Taille moyenne des paquets
19	Taille moyenne des segments à l’envers
20	Octets en avant du sous-flux
21	Octets rétro de sous-flux
22	Octets de fenêtre initiaux en avant
23	Octets de fenêtre initiale à l’envers
24	Longueur des paquets en avant
Tableau 4C. Fonctionnalités sélectionnées conservées pour Bot-IoT
S. Non.	Caractéristiques	Type
1	seq	Numérique
2	Moyenne	Numérique
3	STDDEV	Numérique
4	min	Numérique
5	Max	Numérique
6	srate	Numérique (flottant)
7	drate	Numérique (flottant)
8	N_IN_Conn_P_SrcIP	Numérique (entier)
9	N_IN_Conn_P_DstIP	Numérique (entier)
10	proto	Catégorique (encodé)
11	state_number	Numérique (entier)
12	Taux	Numérique (flottant)

Tableau 4 : Caractéristiques sélectionnées par la méthode de sélection de caractéristiques AQU-IMF-RFE. Ce tableau liste les sous-ensembles finaux de caractéristiques sélectionnés par le cadre de sélection de caractéristiques AQU-IMF-RFE pour les ensembles de données UNSW-NB15, CICIDS2017 et Bot-IoT. Les noms de caractéristiques, types de données et catégories fonctionnelles sont fournis lorsque cela est applicable.

Installation expérimentale
Toutes les expériences ont été menées sur un serveur Dell PowerEdge R740 équipé d’un processeur Intel Xeon Silver 4214 fonctionnant à une fréquence de base de 2,20 GHz, avec 12 cœurs physiques, 24 threads logiques, 16,5 Mo de cache et une vitesse Intel Ultra Path Interconnect (UPI) de 9,6 GT/s. Le serveur était configuré avec 128 Go de RAM, un SSD (SSD) de 512 Go, et fonctionnait sous Microsoft Windows 11. La pile logicielle comprenait Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 et NumPy 2.4.4. La couche blockchain a été implémentée sur la même station de travail en utilisant un réseau PoA Ethereum. La communication entre l’IDS et la blockchain se faisait via JSON-RPC en utilisant le client go-ethereum (Geth) version 1.13.15, le compilateur Solidity (solc) version 0.8.19 pour la compilation et le déploiement de smart contracts, ainsi que la version 6.15.1 de la bibliothèque Web3.py. Le temps d’entraînement rapporté, la latence d’inférence et le débit ont été mesurés sur cette configuration matérielle et logicielle.

Architecture et formation de modèles
Le modèle BiLSTM étendu constitue le composant central de détection du cadre, s’appuyant sur les approches précédentes de détection d’intrusion basées sur l’apprentissage développées pour les environnements^{IoMT 21}. Des études antérieures de détection d’intrusion ont souligné à la fois l’importance d’équilibrer la performance de détection avec la réduction des fausses^{alertes 15} et les défis uniques liés à l’application de méthodes d’apprentissage automatique au trafic réseau^{en évolution 16}. Les architectures collaboratives de détection d’intrusion par réseau neuronal ont également démontré la valeur de l’apprentissage séquentiel profond des caractéristiques pour le trafic réseau^{complexe 22}. Alors que les modèles BiLSTM standards capturent des dépendances temporelles bidirectionnelles, le trafic IoMT présente à la fois des motifs de rafales à court terme et des dépendances à longue portée causées par des attaques à plusieurs étages. Pour y remédier, le modèle proposé étend BiLSTM avec l’extraction de caractéristiques temporelles, un apprentissage temporel bidirectionnel amélioré, des connexions résiduelles et une priorisation temporelle basée sur l’attention. Les LSTM bidirectionnels (BiLSTM) surmontent cette limitation en combinant des états cachés avant et arrière, permettant une représentation temporelle plus riche des schémas de trafic IoMT, comme indiqué dans l’Algorithme 2 (Fichier Supplémentaire 1).

Soit la séquence d’entrée X^(n_j) = {_{x 1} , x₂ , ... , x_T }, où chaque x_t ∈ R^d est un vecteur de caractéristiques prétraité.

Extraction des caractéristiques temporelles :
Une convolution légère unidimensionnelle est appliquée sur la dimension temporelle pour souligner les anomalies temporelles à courte portée (Équation 6) :

U = φ (Conv1D(X^{(_{n j})}), U = {u₁, u₂, ..., u_T } (6)

Ici, φ(⋅) est une fonction d’activation non linéaire et les caractéristiques convoluelles u_t sont transmises à la BiLSTM.

La couche Conv1D extrait des motifs temporels à courte portée avant la modélisation bidirectionnelle des séquences. Les paramètres complets d’implémentation sont fournis dans le fichier supplémentaire 3B.

Apprentissage LSTM bidirectionnel empilé :
Les états cachés avant et arrière sont calculés comme (Équation 7) :

(7)

La représentation finale de la BiLSTM est la concaténation des états cachés passés (en avant) et futurs (en arrière) (Équation 8).

(8)

Deux couches BiLSTM empilées modélisent les dépendances temporelles bidirectionnelles. Des paramètres architecturaux détaillés sont fournis dans le fichier supplémentaire 3B. Les détails de l’initialisation des poids sont fournis dans le fichier supplémentaire 3B.

Connexion résiduelle et normalisation
Après projection linéaire à des dimensions correspondantes, les connexions résiduelles et la normalisation des couches sont appliquées (Équation 9) :

La projection résiduelle et la normalisation des couches alignent les représentations convolutionnelles et BiLSTM avant l’attention. Les paramètres d’implémentation détaillés sont fournis dans le fichier supplémentaire 3B.

Mécanisme d’attention
Bien que BiLSTM fournisse une modélisation temporelle solide, tous les pas de temps ne contribuent pas de manière égale à la prédiction. Pour souligner les horodatages critiques (par exemple, des pics anormales soudains), un mécanisme d’attention est introduit. Chaque état caché se voit attribuer un score de pertinence α_t pour améliorer la précision de la détection (Équation 10).

Ici, W_a est un paramètre entraînable et les poids d’attention satisfont

Le vecteur de contexte c agrège les états cachés en fonction de leur importance apprise (Équation 11) :

Le mécanisme de l’attention agrège les représentations temporelles dans un vecteur de contexte. Les paramètres d’implémentation détaillés sont fournis dans le fichier supplémentaire 3B.

Couche de sortie et classification
Le vecteur de contexte agrégé est fait passer par une couche entièrement connexe suivie d’une activation sigmoïde pour obtenir la prédiction finale (Équation 12) :

Ici, W_c et b_c sont des paramètres entraînables, et σ(·) est la fonction d’activation sigmoïde qui associe la sortie à l’intervalle [0,1]. Un seuil est appliqué pour classer le trafic comme bénin () ou intrusif ().

La régularisation du dropout et le seuil de classification fixe utilisé lors de l’inférence sont décrits dans le Fichier Supplémentaire 3B.

L’architecture BiLSTM étendue est identique sur les trois ensembles de données ; seule la dimension des caractéristiques d’entrée diffère, prenant respectivement les valeurs 14, 24 et 12 pour UNSW-NB15, CICIDS2017 et Bot-IoT. Comme la couche Conv1D associe toute entrée de dimension à une représentation fixe de 64 canaux, toutes les couches suivantes sont indépendantes du jeu de données, et seule la forme d’entrée et le nombre de paramètres Conv1D varient avec . L’architecture complète couche par couche est résumée dans le tableau 5, avec les comptes de paramètres exprimés en termes de d ; Les totaux obtenus sont de 184 641, 186 561 et 184 257 paramètres entraînables pour D = 14, D = 24 et D = 12, respectivement.

S. Non.	Couche (type)	Forme de sortie	Paramètres adaptés à l’entraînement	Fonction d’activation
1	Entrée	(20, d)	0	—
2	Conv1D (64 filtres, taille du noyau = 3, même remplissage)	(20, 64)	192d + 64	ReLU
3	LSTM bidirectionnel couche 1 (64 unités par direction)	(20, 128)	66,048	tanh / sigmoïde
4	LSTM bidirectionnel couche 2 (64 unités par direction)	(20, 128)	98,816	tanh / sigmoïde
5	Projection résiduelle dense	(20, 128)	8,320	Linéaire
6	Ajout résiduel	(20, 128)	0	—
7	Normalisation des couches (axe = −1, ε = 1 × 10⁻³)	(20, 128)	256	—
8	Attention temporelle (Wa ∈ R¹²⁸×¹)	128	128	Softmax
9	Couche cachée dense	64	8,256	ReLU
10	Abandon (p = 0,3)	64	0	—
11	Couche de sortie dense	1	65	Sigmoïde

Tableau 5 : Architecture couche par couche du modèle de mémoire bidirectionnelle longue et courte durée étendue. Ce tableau résume l’architecture du modèle proposé de mémoire bidirectionnelle longue et courte durée (BiLSTM), incluant les types de couches, les dimensions de sortie, le nombre de paramètres entraînables et les fonctions d’activation.

Le logiciel et l’environnement informatique utilisés pour toutes les expériences sont résumés dans le tableau 6.

Composant	Version / Spécification
Système d’exploitation	Windows
Plateforme serveur	Dell PowerEdge
CPU	Processeur 64 cœurs
RAM	128 Go
Stockage	SSD 512 Go
Python	3.12.7
NumPy	2.4.4
Pandas	3.0.2
scikit-learn	1.8.0
TensorFlow / Keras	2.16.1
Web3 (client blockchain)	6.15.1
eth-account	0.1
Compilateur Solidity (solc)	0.8.19
go-ethereum (Geth)	1.13.15

Tableau 6 : Logiciels et environnement informatique utilisés pour la mise en œuvre et l’évaluation du cadre proposé. Ce tableau résume les spécifications matérielles, les composants logiciels, les outils blockchain et les numéros de version utilisés pour le prétraitement des données, la sélection des fonctionnalités, l’entraînement des modèles, le déploiement de blockchain et l’évaluation des performances.

Décision d’intrusion et réponse automatisée
La détection d’intrusion dans les environnements de santé n’est efficace que si elle est suivie d’une réponse rapide et d’une atténuation. La couche de détection d’intrusion convertit la probabilité prédite en décision. Formellement, la décision d’intrusion à l’étape temporelle t est représentée comme suit (Équation 13) :

Ici, est la probabilité d’intrusion prédite au temps t et est le seuil de classification.

Une fois une intrusion détectée, la couche de détection d’intrusion interagit directement avec le module blockchain, qui effectue une journalisation immuable, une atténuation automatisée et une application de la sécurité en boucle fermée. Les détails des événements, y compris les informations sur la source, les informations de destination et certaines fonctionnalités de trafic, sont enregistrés dans un nouveau bloc blockchain. Les contrats intelligents exécutent des actions d’atténuation en temps réel telles que l’isolement des nœuds et les alertes aux administrateurs. Cette architecture en boucle fermée permet aux résultats de détection d’intrusion d’alimenter directement les mécanismes de prévention, minimisant ainsi la latence d’atténuation. Ainsi, la couche de détection d’intrusion sert de pont entre la détection temporelle utilisant le modèle BiLSTM étendu et la réponse sécurisée utilisant la technologie blockchain, complétant ainsi la fonctionnalité de bout en bout du cadre proposé.

Journalisation médico-légale basée sur la blockchain
Bien que le modèle BiLSTM étendu permette la détection d’intrusion en temps réel, le stockage sécurisé et l’audit vérifiable des événements d’intrusion sont tout aussi critiques dans les environnements de santé IoMT. Les mécanismes traditionnels de journalisation centralisée sont vulnérables à la falsification et compromettent la traçabilité médico-légale. Pour répondre à cette limitation, le cadre proposé intègre un module blockchain léger qui garantit l’immutabilité, la décentralisation et la réponse automatisée basée sur les contrats intelligents.

Chaque événement d’intrusion détecté génère un bloc qui est ajouté à la blockchain. Un bloc B_i est défini comme suit (Équation 14) :

Ici, H_i est le hachage cryptographique des données de l’événement, de l’horodatage et du résultat de prédiction, T_i est l’horodatage, D_i contient certaines caractéristiques d’intrusion d’événement, Si_gi est la signature numérique, et PrevHash relie le bloc au bloc précédent, assurant l’immutabilité.

Cette conception garantit la résistance à la falsification car toute modification de D_i ou T_i modifie le hachage du bloc et rompt l’intégrité de la chaîne. Il offre également une auditabilité car toutes les anomalies détectées sont stockées et vérifiables de façon permanente. L’atténuation automatisée est prise en charge par des smart contracts qui exécutent des actions prédéfinies telles que l’isolement des nœuds et les alertes aux administrateurs. La décentralisation est obtenue grâce à plusieurs passerelles IoMT qui maintiennent le grand livre distribué, éliminant ainsi un point de défaillance unique.

La génération de blocs utilise la fonction de hachage cryptographique Keccak-256, la primitive de hachage native de l’environnement Ethereum/Solidity (invoquée via keccak256 de Solidity). Pour chaque bloc d’intrusion, le hachage du bloc est calculé comme suit :

Ici, D_i est le résumé de la caractéristique événement, T_i est l’horodatage, et PrevHash est le hachage du bloc précédent. Les champs sont concaténés à l’aide de l’encodage très compact de Solidity (abi.encodePacked) avant le hachage, produisant un résumé sur 256 bits.

Le même calcul Keccak-256 est utilisé par la routine de vérification de chaîne, qui recalcule chaque hachage de bloc à partir de ses champs stockés et confirme qu’il correspond à la valeur enregistrée, validant ainsi l’intégrité de la chaîne. Keccak-256 a été choisi car il s’agit de l’algorithme de hachage résistant aux collisions standard utilisé nativement dans les smart contracts Ethereum. Le smart contract a été développé dans Solidity et compilé à l’aide du compilateur Solidity (solc) version 0.8.19. Il a été déployé sur un réseau privé Ethereum Proof-of-Authority (PoA) exploité avec Geth version 1.13.15. Le réseau blockchain était configuré avec quatre nœuds validateurs utilisant le protocole de consensus Clique Proof-of-Authority, un identifiant de chaîne de 9848, une période de blocage de 5 s et une limite de gaz de bloc de 30 000 000. La communication entre le moteur de détection d’intrusion BiLSTM étendu et la couche blockchain a été réalisée via la bibliothèque Web3.py version 6.15.1 via l’interface JSON-RPC HTTP.

Mécanisme de consensus des points d’intérêt
Parce que les systèmes IoMT de santé sont très sensibles à la latence, le cadre proposé utilise un mécanisme de consensus PoA au lieu d’une Proof-of-Work (PoW)²³, coûteuse en calcul. Dans le point de retrait, un ensemble fixe de nœuds validateurs de confiance, tels que les passerelles hospitalières, autorise les transactions, offrant à la fois efficacité et résilience.

La complexité temporelle de la validation par blocs sous PoW peut s’exprimer comme suit (Équation 15) :

Ici, d représente la difficulté de minage.

En revanche, la complexité temporelle du consensus PoA est donnée comme suit (Équation 16) :

car la validation ne nécessite que la vérification par signature numérique par des nœuds validateurs autorisés.

En conséquence, PoA offre un fonctionnement à faible latence adapté aux alertes médicales en temps réel, une efficacité énergétique en évitant le minage à forte intensité de calcul, et une résilience face à un nombre limité de validateurs malveillants. Le réseau PoA était configuré avec quatre nœuds validateurs, et cette configuration est restée fixe tout au long de toutes les expériences afin d’assurer des mesures de latence cohérentes, une évaluation des performances reproductibles et une comparaison équitable entre tous les ensembles de données de benchmark.

Implémentation de la blockchain et fonctionnement des contrats intelligents
La composante blockchain a été mise en œuvre sur un réseau Ethereum autorisé fonctionnant selon le modèle de consensus^{PoA 24}. Le réseau était exploité via le client go-ethereum (Geth) avec le protocole de consensus^{Clique PoA 25}, dans lequel un ensemble de nœuds validateurs (sealer) autorisés sont responsables de la production et de la validation des blocs. Le smart contract à intrusion logging (IoMTIntrusionLedger) a été écrit dans Solidity et déployé sur ce réseau, suivant des architectures de sécurité IoT basées sur blockchain pour une gestion d’événements décentralisée^{sécurisée 26}. Seuls les comptes passerelle autorisés en chaîne (via la fonction de contrôle d’accès du contrat) étaient autorisés à soumettre des enregistrements d’intrusion, conformément aux architectures de smart contracts blockchain autorisées pour les applications Internet^{des objets 27}. La couche blockchain a été implémentée en utilisant le client go-ethereum (Geth) version 1.13.15 pour l’exploitation du réseau PoA autorisé, le compilateur Solidity (solc) version 0.8.19 pour la compilation et le déploiement de smart contracts, et la bibliothèque Web3.py version 6.15.1 pour la communication entre l’IDS et le réseau blockchain.

Les paramètres détaillés de déploiement et de configuration de la blockchain sont fournis dans le fichier supplémentaire 3C.

Chaque enregistrement d’intrusion est signé numériquement avant d’être inscrit dans le registre, soutenant l’auditabilité des soins de santé basée sur la blockchain et la tenue sécurisée des dossiers^{médico-légaux 28}. Les procédures de génération et de vérification de signatures numériques, y compris l’ECDSA sur la courbe secp256k1^29,30, sont décrites dans le Fichier Supplémentaire 3D. Chaque passerelle contient une paire de clés Ethereum composée d’une clé privée de 256 bits (32 octets) et de la clé publique correspondante, à partir de laquelle son adresse de compte est dérivée ; La génération de clés suit la procédure standard d’Ethereum, utilisant une clé privée aléatoire de 256 bits cryptographiquement sécurisée, la clé publique obtenue par multiplication scalaire secp256k1. Pour créer une signature, le client passerelle calcule le digest de la caractéristique d’événement D_i et le signe avec sa clé privée en utilisant le format de signature de messages EIP-191, produisant une signature de 65 octets composée des composants r, s et v. La signature est soumise avec l’enregistrement d’intrusion. La vérification est effectuée en chaîne par le contrat intelligent : en utilisant la précompilation EVM ecreais, le contrat récupère l’adresse du signataire à partir du digest et de la signature signés et exige qu’elle soit égale à l’adresse de la passerelle autorisée soumettant la transaction. Si l’adresse récupérée ne correspond pas à une passerelle autorisée, la transaction est rejetée. Cela lie chaque entrée de registre à une passerelle autorisée spécifique et empêche les enregistrements d’intrusion non autorisés ou falsifiés.

Les contrats intelligents sont déclenchés automatiquement lors de la détection d’intrusion, garantissant une réponse en temps réel sans intervention manuelle (Équation 17) :

(17)

Le module blockchain fonctionne en parallèle avec le classificateur BiLSTM étendu. Une fois qu’une anomalie est détectée : (i) l’événement est étiqueté et classifié par le BiLSTM, (ii) un bloc est généré, signé et ajouté au registre de la blockchain, et (iii) les contrats intelligents appliquent des politiques de réponse automatique.

Le smart contract de journalisation des intrusions (IoMTIntrusionLedger) maintient un registre uniquement annexé des blocs d’intrusion ainsi qu’un registre des comptes passerelle autorisés, et expose les fonctions résumées dans le tableau 7. Le contrat impose deux rôles d’accès via des modificateurs : onlyAdmin (l’administrateur du déploiement) et onlyGateway (comptes autorisés à soumettre des enregistrements d’intrusion). L’état se compose de la correspondance d’autorisation de passerelle, du tableau de registre de blocs, et de la tête de chaîne courante (le hachage du bloc le plus récent).

S. Non.	Fonction / Composant	Type	Accès	Logique
1	constructeur	Constructeur	—	Définit le déployeur comme administrateur et l’autorise comme passerelle initiale.
2	setGateway (adresse, bool)	Fonction	onlyAdmin	Ajoute ou supprime un compte de passerelle autorisé ; émet GatewayUpdated.
3	recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate)	Fonction	onlyGateway	Calcule Hi = Keccak-256(Di ∥ Ti ∥ probabilité ∥ PrevHash) ; vérifie la signature ECDSA de la passerelle sur Di via ecrecover ; ajoute le bloc au grand livre ; avance la tête de la chaîne ; émet BlockCreated, optionnellement NodeIsolated, et AdminAlert. Retour de H. i.
4	verifyChain()	Fonction de vue	Public	Recalcule le hachage de chaque bloc à partir de ses champs stockés et vérifie la liaison PrevHash ; revient vrai seulement si toute la chaîne est cohérente (détection de falsification).
5	ledgerLength()	Fonction de vue	Public	Retourne le nombre de blocs dans le registre.
6	_recoverSigner(hachage, signature)	Fonction interne	—	Divise la signature de 65 octets en (r, s, v) et récupère l’adresse de signature via la précompilation ecreper.
7	BlockCreated / NodeIsolated / AdminAlert / GatewayUpdated	Événements	—	Émis pour que les auditeurs hors chaîne puissent piloter la journalisation, l’isolement des nœuds, les alertes administrateur et les mises à jour du registre de passerelle.
8	onlyAdmin / onlyGateway	Modificateurs	—	Limitez les fonctions à l’administrateur et aux passerelles autorisées, respectivement.

Tableau 7 : Fonctions, événements et composants de contrôle d’accès du contrat intelligent IoMTIntrusionLedger. Ce tableau résume les principales fonctions, événements et modificateurs de contrôle d’accès implémentés dans le contrat intelligent blockchain autorisé. Ces composants supportent l’autorisation de passerelle, la journalisation des intrusions, la vérification blockchain, la génération d’événements et l’atténuation automatisée.

La propriété d’immuabilité de la blockchain découle directement de l’équation 14, où toute modification des données d’événements ou des horodatages invalide la chaîne de hachage. La blockchain offre ainsi intégrité des données, traçabilité et auditabilité aux systèmes de santé grâce à des dossiers médico-légaux immuables. Les dossiers d’intrusion des patients et des appareils restent inchangés une fois stockés, chaque bloc est lié de manière sécurisée au bloc précédent permettant la reconstruction chronologique des événements, et les administrateurs ou régulateurs de santé peuvent vérifier les incidents d’intrusion sans risque de falsification.

Fonction de perte et optimisation des modèles
Le modèle BiLSTM étendu proposé répond au problème de classification binaire consistant à distinguer entre le trafic normal et les événements d’intrusion dans les réseaux IoMT. Pour guider le processus d’entraînement, une perte binaire d’entropie croisée (BCE) est adoptée, ce qui convient parfaitement aux sorties probabilistes de la couche d’activation sigmoïde. Pour un ensemble de données avec N échantillons, la perte est définie comme suit (Équation 18) :

(18)

Ici, est l’étiquette de vérité fondamentale de la ^i-ème suite d’entrée (0 = bénigne, 1 = intrusion), et est la probabilité prédite d’intrusion.

Le cadre fonctionne comme un pipeline de classification en deux étapes. La première étape effectue la détection d’intrusion binaire : la BiLSTM étendue produit une sortie sigmoïde et applique le seuil τ = 0,5 pour classer chaque fenêtre comme bénigne ou intrusive (Équations 12,13), entraînée avec une perte binaire pondérée en entropie croisée. Une seconde étape peut effectuer la catégorisation des attaques, dans laquelle les fenêtres identifiées comme intrusions sont transmises à un classificateur multiclasse qui attribue la catégorie d’attaque spécifique à l’aide d’une couche de sortie softmax entraînée à l’entropie croisée catégorique. La présente étude se concentre sur et évalue le stade de détection binaire. Les deux étapes partagent la même colonne vertébrale d’extraction de caractéristiques Extended BiLSTM (Conv1D, BiLSTM, couches résiduelles, de normalisation et d’attention) ; ils ne diffèrent que par leur couche de sortie (sigmoïde pour la détection et softmax pour la catégorisation) et la fonction de perte correspondante. L’étape de détection binaire et la phase de catégorisation multiclasse ont été entraînées et évaluées selon les mêmes partitions de données, graines aléatoires et conditions d’entraînement décrites ci-dessus.

Bien que le trafic IoMT soit souvent déséquilibré, une perte binaire pondérée d’entropie croisée est utilisée pour pénaliser la mauvaise classification de la classe minoritaire. Les poids de classe sont calculés en utilisant le nombre d’échantillons d’intrusion N_p, le nombre d’échantillons bénins N n, et le nombre total d’échantillons N (Équations 19,20) :

Cette pondération garantit que le modèle n’est pas biaisé en faveur de la classe dominante de trafic bénin et reste sensible aux événements d’intrusion rares mais critiques.

La perte binaire pondérée en entropie croisée est donnée comme suit (Équation 21) :

(21)

La formation était réalisée à l’aide de mini-séries de taille 64. Au début de chaque époque, les échantillons d’entraînement étaient aléatoirement regroupés avant d’être partitionnés en lots, de sorte que la composition des lots variait selon les époques et que le modèle ne voyait pas d’exemples dans un ordre fixe. Les lots n’étaient pas explicitement équilibrés ou stratifiés par classe ; au contraire, chaque lot reflétait la distribution naturelle des classes de l’ensemble d’entraînement, et le déséquilibre de classe était corrigé par la perte binaire pondérée par classe (Équations 19–21). Le sous-ensemble de validation réservé à la partition d’entraînement restait fixe à travers les époques et n’était pas regroupé dans les lots d’entraînement.

Les poids de classe dans la perte binaire pondérée par entropie croisée n’ont pas été définis manuellement mais calculés automatiquement pour chaque jeu de données à partir de ses décomptes de classes dans l’ensemble d’entraînement selon les équations 19 et 20. Pour le jeu de données UNSW-NB15, les poids de classe résultants concernaient la classe normale et la classe d’intrusion. Pour le jeu de données CICIDS2017, les poids de classe résultants concernaient la classe normale et la classe intrusion. Pour le jeu de données Bot-IoT (sous-ensemble de 5 %), les poids de classe résultants concernaient la classe normale et la classe intrusion.

Stratégie d’entraînement et optimisation
Le modèle BiLSTM étendu a été entraîné en utilisant des mini-lots de taille B = 64 avec perte binaire pondérée d’entropie croisée, l’optimiseur Adam, et un arrêt précoce basé sur la perte de validation. L’entraînement était limité à 50 époques, et l’arrêt précoce était appliqué avec patience K = 5. Si la perte de validation ne s’améliorait pas pendant cinq époques consécutives, l’entraînement était interrompu et les poids du modèle étaient rétablis à ceux de l’époque ayant la perte de validation la plus faible. Ainsi, 50 époques représentaient le budget maximal de formation plutôt qu’une durée fixe. Une probabilité d’abandon de 0,3 a été appliquée pour la régularisation. Les réglages architecturaux comprenaient 64 filtres Conv1D, 64 unités LSTM par direction, une longueur de fenêtre de T = 20, et une foulée de s = 1. La stratégie d’entraînement adoptée est résumée dans l’Algorithme 3 (Fichier Supplémentaire 1). Les équations de mise à jour d’Adam utilisées pour l’optimisation sont fournies dans le fichier supplémentaire 3A.

L’optimiseur Adam était configuré avec un taux d’apprentissage de , un taux de désintégration au premier moment (β₁) de 0,9, un taux de désintégration au second moment (β₂) de 0,999, et une constante de stabilité numérique () de 1 × 10-7. Aucune option d’optimiseur supplémentaire n’a été utilisée, et aucune décroissance de poids ni découpage de gradient n’a été appliquée.

Génération d’alertes et atténuation automatisée
La détection seule est insuffisante dans les réseaux IoMT sensibles à la latence, où une réponse rapide est cruciale pour garantir la sécurité des patients. La couche de génération et d’atténuation d’alertes opérationnelle permet de prendre la décision d’intrusion prise par le modèle BiLSTM étendu et le mécanisme de journalisation blockchain. Si δ_t = 1, le module blockchain ajoute un nouveau bloc contenant les détails de l’intrusion . Simultanément, un contrat intelligent est exécuté pour déclencher des actions d’atténuation (Équation 22) :

(12)

Ici, BlockCreation assure une journalisation médico-légale immuable de l’événement, NodeIsolation (_{n j}) met en quarantaine le nœud IoMT compromis pour éviter d’autres dommages, et AdminAlert fournit une notification en temps réel aux administrateurs système. Pour faire fonctionner ce pipeline de réponse à double couche, le pseudocode est présenté dans l’Algorithme 4 (Fichier Supplémentaire 1).

Le traitement des événements par smart contract et les mécanismes de réponse hors chaîne sont décrits dans le fichier supplémentaire 3E.

Chaque entrée engagée dans le registre blockchain est stockée sous forme d’enregistrement IntrusionBlock, dont les champs et formats de données sont listés dans le tableau 8. Le registre est un tableau uniquement à ajouter de ces enregistrements, et la tête de chaîne actuelle stocke le hachage du bloc le plus récemment ajouté.

S. Non.	Terrain	Type de données	Taille	Description
1	hashId	bytes32	32 octets	Hachage de bloc Hi = Keccak-256(Di ∥ Ti ∥ probabilité ∥ PrevHash)
2	Horodatage	uint256	32 octets	Temps de création du bloc Ti (secondes d’époque Unix, à partir de l’horodatage du bloc)
3	nodeId	bytes32	32 octets	Identifiant du nœud IoMT nj
4	patientId	bytes32	32 octets	Identifiant patient/appareil (métadonnées médico-légales)
5	Classe d’attaque	uint16	2 octets	Code de catégorie d’attaque (0 = Normal, 1 = DDoS, 2 = Usurpation, ...)
6	probabilitéBp	uint16	2 octets	Probabilité d’intrusion prédite ŷ en points de base (0–10000, c’est-à-dire 0,00–100,00 %)
7	dataDigest	bytes32	32 octets	Le résumé Di des événements sélectionnés présente
8	Signature	Octets	Variable (65 octets)	Signature ECDSA Sigi du digest d’événements par la passerelle (r, s, v)
9	prevHash	bytes32	32 octets	Hachage du bloc précédent (PrevHash), reliant la chaîne
10	isolé	bool	1 octet	Si l’isolation des nœuds a été déclenchée pour cet enregistrement

Tableau 8 : Structure de l’enregistrement IntrusionBlock stocké dans le registre blockchain. Ce tableau décrit les champs, types de données, tailles de stockage et objectifs des enregistrements du registre blockchain utilisés pour stocker les événements d’intrusion. La structure prend en charge la vérification de l’intégrité cryptographique, la traçabilité médico-légale et les mécanismes automatisés de réponse.

La latence globale d’atténuation peut s’exprimer comme la somme du délai de détection (T_d) du modèle BiLSTM étendu et du délai d’exécution de la blockchain (T_b) (Équation 23) :

(23)

Analyse de la complexité computationnelle
L’efficacité du cadre BiLSTM–Blockchain étendu proposé est déterminée à la fois par le coût de calcul du modèle BiLSTM et par la surcharge introduite par le module blockchain. Le cadre proposé intègre la détection étendue de BiLSTM avec la journalisation blockchain afin de satisfaire aux exigences de sécurité fondamentales de la triade Confidentialité, Intégrité et Disponibilité (CIA).

Soit la longueur de la séquence d’entrée prétraitée T, la dimension des caractéristiques d, et la dimension cachée du BiLSTM h.

Pour chaque pas de temps, un BiLSTM traite une entrée de dimension d de taille cachée h. Puisqu’elle est bidirectionnelle (avant + arrière) (Équation 24) :

) (24)

Ici, T est la longueur de la suite (pas de temps), d est la dimension de la caractéristique d’entrée, h est la dimension d’état caché

La couche d’attention calcule les poids d’importance et agrège les états cachés avec complexité (Équation 25).

(25)

qui est linéaire à la fois dans la longueur de la suite T et dans la dimension cachée h.

La complexité globale de détection par séquence est donc donnée comme suit (Équation 26) :

(26)

démontrant que la modélisation temporelle domine le coût computationnel, tandis que le mécanisme d’attention n’introduit qu’une surcharge légère.

Pour chaque événement d’intrusion détecté, la journalisation blockchain effectue des opérations de hachage, de signature et d’ajout de blocs (Équation 27) :

(27)

Pour N événements de détection d’intrusion, la complexité combinée devient la suivante (Équation 28) :

(28)

qui peut être simplifiée comme suit (Équation 29) :

(29)

car la surcharge blockchain croît linéairement avec le nombre d’événements et reste négligeable comparée aux calculs de traitement de séquences.

La complexité computationnelle est résumée dans les équations 24–29. Une interprétation détaillée est fournie dans le Fichier Supplémentaire 3F.

Results

Les résultats sont organisés pour suivre les étapes méthodologiques du protocole, chaque sous-section rapportant les observations produites par l’étape correspondante.

Gestion des jeux de données et mise en place expérimentale
Les trois ensembles de données de référence ont été analysés indépendamment plutôt que fusionnés. Parce que UNSW-NB15, CICIDS2017 et Bot-IoT utilisent des schémas de caractéristiques et des conventions d’étiquetage différents, chaque jeu de données a été prétraité, fenêtré et évalué séparément en utilisant sa propre répartition 80:20 train/test. Le modèle BiLSTM étendu a été entraîné et testé indépendamment sur chaque jeu de données, et les métriques de performance (précision, exactitude, rappel et score F1) sont rapportées séparément pour chaque ensemble de données. Ce protocole d’évaluation indépendant évite les incohérences en espace de caractéristiques qui résulteraient de la combinaison de jeux de données hétérogènes et permet d’évaluer la robustesse du cadre proposé à travers trois environnements réseau distincts.

Le modèle BiLSTM-BC étendu proposé a été entraîné et évalué à partir de trafic normal et malveillant prétraité extrait des ensembles de données CICIDS2017, UNSW-NB15 et Bot-IoT. Les données étaient partitionnées selon une seule répartition stratifiée de retenue. L’ensemble de données UNSW-NB15 fournit des partitions d’entraînement et de test prédéfinies, qui ont été utilisées directement dans cette étude. Pour les deux jeux de données restants (CICIDS2017 et Bot-IoT), les échantillons fenêtrés prétraités ont été divisés en ensembles d’entraînement et de test en utilisant une répartition 80:20 avec un échantillonnage aléatoire stratifié (scikit-learn train_test_split, stratifié par étiquette de classe), préservant ainsi le ratio bénin-intrusion entre les partitions. Dans l’ensemble d’entraînement, 20 % supplémentaires étaient réservés à la validation (Keras validation_split), ce qui aboutit à un entraînement effectif de 64 %, 16 % de validation et 20 % de partition de test. Le jeu de validation était utilisé pour l’arrêt précoce. Une graine aléatoire fixe de 42 a été appliquée à scikit-learn, NumPy et TensorFlow pour soutenir la reproductibilité. Le réseau BiLSTM étendu a été optimisé à l’aide de l’optimiseur Adam avec un taux d’apprentissage de 0,001, une taille de lot de 64 et un maximum de 50 époques d’entraînement.

Résultats de la sélection des fonctionnalités
Avant l’entraînement du modèle, la sélection des caractéristiques était effectuée indépendamment pour chaque jeu de données à l’aide de l’AQU-IMF-RFE, une procédure d’élimination des caractéristiques récursives guidée par l’Aquila Optimizer (AO) dans laquelle les caractéristiques candidates étaient classées selon leur information mutuelle (MI) avec l’étiquette de classe et éliminées de manière itérative pendant que l’Aquila Optimizer recherchait le sous-ensemble de caractéristiques optimal. Les champs d’identification (par exemple, identifiants de flux, adresses IP et numéros de port) et les champs textuels de catégorie d’attaque étaient exclus avant la sélection des fonctionnalités afin d’éviter la fuite d’informations. Cette procédure a conservé 14 fonctionnalités pour UNSW-NB15, 24 pour CICIDS2017 et 12 pour Bot-IoT. La liste complète des variables d’entrée sélectionnées, leurs types de données et leurs ensembles de données sources est fournie dans le tableau 4, et une description approfondie de chaque fonctionnalité est incluse dans le fichier supplémentaire 2.

Entraînement et convergence
Pendant l’entraînement, le modèle a démontré une convergence stable, les performances de l’entraînement et de la validation s’améliorant à mesure que les paramètres du réseau approchaient de leurs valeurs optimales. L’architecture couche par couche du modèle BiLSTM étendu proposé est résumée dans le Tableau 5, tandis que le logiciel et l’environnement informatique utilisés pour la mise en œuvre et l’évaluation sont présentés dans le Tableau 6. Les fonctions de smart contract blockchain supportant la journalisation des intrusions et l’atténuation automatisée sont résumées dans le Tableau 7, et la structure de l’enregistrement d’intrusion blockchain est présentée dans le Tableau 8. L’ensemble complet des hyperparamètres d’entraînement utilisés dans cette étude est résumé dans le tableau 9, soutenant la reproductibilité du cadre proposé.

Hyperparamètre d’entraînement	Valeur
Taux d’apprentissage	0.001
Optimiseur	Adam
Taille du lot	64
Époques maximales	50
Fonction d’activation de sortie	Sigmoïde
Séparation train-test	80:20, stratifié
Répartition de validation	20 % de la partition d’entraînement
Graine aléatoire	42
Longueur de la fenêtre d’entrée	20 pas de temps
Foulée à fenêtre coulissante	1
Filtres Conv1D	64
Taille du noyau Conv1D	3
Rembourrage Conv1D	Pareil
Activation de Conv1D	ReLU
Couches BiLSTM	2
Unités BiLSTM	64 unités par direction
Dimension de sortie BiLSTM	128
Activation du LSTM	Tanh
Dimension de projection résiduelle	128
Patience à arrêter tôt	5 époques
Unités denses à couches cachées	64
Activation dense en couche cachée	ReLU
Taux d’abandon scolaire	0.3
Unités de sortie	1
Seuil de classification	0.5
Fonction de perte	Entropie binaire interposée pondérée (WBCE)

Tableau 9 : Configuration des hyperparamètres utilisée pour entraîner le modèle de mémoire bidirectionnelle longue et courte durée étendue. Ce tableau liste les principaux hyperparamètres d’entraînement utilisés lors du développement du modèle de détection d’intrusion Bidirectionnelle Bidirectionnelle à court terme (BiLSTM), incluant les paramètres d’optimisation, la fonction d’activation, la taille du lot, la durée de l’entraînement et la fonction de perte.

Le tableau 10 présente les précisions de l’entraînement et de la validation du modèle proposé sur 50 époques, enregistrées à des intervalles de 5 èpoques. Le modèle a montré une amélioration rapide durant les dix premières époques, atteignant des précisions d’entraînement et de validation de 96,0 % et 95,5 % respectivement. Au-delà de l’époque 20, les gains de précision sont devenus incrémentaux, et les deux courbes ont convergé de près. À l’époque 50, le modèle s’est stabilisé à 99,1 % de précision d’entraînement et 98,5 % de validation, indiquant un surajustement minimal et une forte généralisation. La courbe d’apprentissage correspondante est illustrée à la Figure 3, illustrant la progression de la précision de l’entraînement et de la validation tout au long du processus d’optimisation.

Époque	Précision de l’entraînement ( %)	Précision de validation ( %)
1	72.1	70
5	90	89
10	96	95.5
15	97.1	96.5
20	97.8	97.2
25	98.2	97.5
30	98.5	97.8
35	98.7	98
40	98.9	98.2
45	99	98.4
50	99.1	98.5

Tableau 10 : Précision de l’entraînement et de la validation lors de l’entraînement du modèle bidirectionnel étendu de mémoire à court terme à court terme. Ce tableau rapporte la précision de l’entraînement et de la validation mesurée à certaines époques d’entraînement lors de l’optimisation du modèle BiLSTM (Extended Bidirectional Long Short-Term Memory) proposé. Ces valeurs ont été utilisées pour générer la courbe de convergence de précision illustrée à la Figure 3.

Figure 3. La précision de l’entraînement et de la validation du modèle BiLSTM étendu. Graphique linéaire montrant la précision de la classification lors de l’entraînement du modèle. L’axe des x représente les époques d’entraînement (1–50), et l’axe des y représente la précision de classification ( %). Les cercles bleus indiquent la précision de l’entraînement, et les carrés orange indiquent la précision de la validation. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Le tableau 11 présente les valeurs de perte d’entraînement et de validation enregistrées aux mêmes intervalles de 5 époques. Lors de la phase initiale d’entraînement, la perte d’entraînement a diminué de 0,64 à 0,28, tandis que la perte de validation est passée de 0,67 à 0,31 à l’époque 5. Après l’époque 20, le taux de réduction des pertes est devenu plus progressif, et les deux courbes ont convergé de manière régulière. À l’époque 50, la perte d’entraînement s’est stabilisée à 0,08, tandis que la perte de validation est restée proche à 0,12, indiquant seulement une petite différence entre les deux courbes. Cette convergence reflète une optimisation efficace, un overfit limité et une bonne généralisation des données inédites. Les courbes de perte correspondantes d’entraînement et de validation sont présentées dans la Figure 4. L’efficacité computationnelle des modèles évalués, incluant la latence d’inférence et le débit, est résumée dans le tableau 12. Une analyse détaillée de ces mesures est présentée plus loin dans la sous-section Efficacité computationnelle.

Époque	Pertes à l’entraînement	Perte de validation
1	0.64	0.67
5	0.28	0.31
10	0.13	0.17
15	0.11	0.15
20	0.1	0.14
25	0.095	0.13
30	0.09	0.125
35	0.085	0.122
40	0.083	0.12
45	0.082	0.118
50	0.08	0.12

Tableau 11 : Perte d’entraînement et de validation lors de l’entraînement du modèle de mémoire longue et courte durée bidirectionnel étendu. Ce tableau rapporte les valeurs de perte binaire pondérée par ions d’entraînement et de validation mesurées à certaines époques d’entraînement lors de l’optimisation du modèle Bidirectionnel Extended Long Short-Term Memory (BiLSTM) proposé par les ions. Ces valeurs ont été utilisées pour générer la courbe de convergence des pertes illustrée à la Figure 4.

Figure 4. Perte d’entraînement et de validation du modèle BiLSTM étendu. Graphique linéaire montrant la perte pondérée d’entropie binaire croisée lors de l’entraînement du modèle. L’axe des x représente les époques d’entraînement (1–50), et l’axe des y représente les valeurs de perte. Les cercles bleus indiquent la perte d’entraînement, et les cases orange indiquent la perte de validation. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Modèle	Latence (moyenne ms/événement)	Débit (Moyen/s)
Arbre de décision	40	845
Machine à vecteurs de support	75	670
LSTM	110	559
Cadre BiLSTM–Blockchain étendu proposé	135	320

Tableau 12 : Comparaison de latence et de débit des modèles de détection d’intrusion. Ce tableau compare la latence d’inférence et le débit de traitement entre les modèles représentatifs de détection d’intrusion en apprentissage automatique et en apprentissage profond. La latence est rapportée en millisecondes par événement et le débit en événements traités par seconde.

Performances de détection
Le tableau 13 présente l’évaluation comparative du cadre proposé par rapport aux modèles de référence conventionnels de ML et DL répartis sur les trois ensembles de données de référence. Le modèle proposé a obtenu des précisions de 98,9 % sur CICIDS2017, 95,9 % sur UNSW-NB15 et 98,8 % sur Bot-IoT, ainsi que des sensibilités élevées de 96,9 %, 97,6 % et 98,8 % respectivement. Sur CICIDS2017 et UNSW-NB15, le modèle proposé a obtenu la plus grande précision parmi tous les modèles évalués, tandis que sur Bot-IoT il a obtenu la plus grande précision (98,8 %), égalée par la référence de l’Arbre de Décision (DT). Sur Bot-IoT, le modèle proposé a légèrement surpassé la référence LSTM (98,3 %) et a performé de manière comparable à celle de la Support Vector Machine (SVM) (98,7 %) ; Les marges de performance plus faibles sur ce jeu de données reflètent son déséquilibre extrême de classes, dans lequel le trafic bénin ne représente qu’une très petite fraction de l’ensemble de test. Dans l’ensemble, le modèle proposé a maintenu un fort équilibre entre sensibilité et précision, démontrant une performance robuste de détection d’intrusion sur tous les ensembles de données tout en fournissant l’évaluation la plus fiable sur les ensembles de données de référence plus équilibrés (CICIDS2017 et UNSW-NB15). Les comparaisons correspondantes de précision, de précision et de mémoire entre ensembles de données et modèles de référence sont présentées dans les Figures 5 à 7.

Jeu de données	Modèle	Sensibilité ( %)	Spécificité ( %)	Précision ( %)	Précision ( %)	Rappel (%)
CICIDS2017	BiLSTM–Blockchain étendu proposé	96.9	99.4	98.9	97.5	96.9
	LSTM	93.3	98.5	97.5	93.9	93.3
	SVM	94.8	98.8	98.1	95.1	94.8
	DT	93.1	98.7	97.5	94.6	93.1
UNSW-NB15	BiLSTM–Blockchain étendu proposé	97.6	93.9	95.9	95.1	97.6
	LSTM	95.2	88.5	92.2	91.1	95.2
	SVM	96.5	91.1	94.1	93.1	96.5
	DT	96.9	92.2	94.8	93.8	96.9
Bot-IoT	BiLSTM–Blockchain étendu proposé	98.8	90.5	98.8	99.3	98.8
	LSTM	98.3	89.4	98.3	99.2	98.3
	SVM	98.7	88.4	98.7	99.3	98.7
	DT	98.8	93.6	98.8	99.3	98.8

Tableau 13 : Comparaison des performances des modèles de détection d’intrusion à travers des ensembles de données de référence. Ce tableau compare le cadre proposé et les modèles de référence de détection d’intrusion sur les ensembles de données CICIDS2017, UNSW-NB15 et Bot-IoT en utilisant des métriques de sensibilité, spécificité, précision, précision et rappel.

Figure 5. Comparaison de précision entre ensembles de données et modèles d’apprentissage automatique/deep learning. Graphique à barres groupé comparant la précision de la classification ( %) obtenue par différents modèles à travers les ensembles de données CICIDS2017, UNSW-NB15 et Bot-IoT. Les barres représentent le modèle proposé : la mémoire à court terme long (LSTM), la machine à vecteurs de support (SVM) et l’arbre de décision (DT). L’axe des x représente les jeux de données, et l’axe des y représente la précision de la classification ( %). Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 6. Comparaison précise des modèles de classification à travers des ensembles de données de détection d’intrusion. Graphique à barres groupé montrant la précision ( %) obtenue par différents modèles sur les ensembles de données CICIDS2017, UNSW-NB15 et Bot-IoT. L’axe des x représente les modèles de classification, et l’axe des y représente la précision ( %). LSTM, mémoire à court terme ; SVM, machine à vecteurs de support ; DT, arbre de décision. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 7. Rappelons la comparaison des modèles de classification entre les ensembles de données de détection d’intrusion. Graphique à barres groupé montrant la mémoire ( %) obtenu par différents modèles sur les ensembles de données CICIDS2017, UNSW-NB15 et Bot-IoT. L’axe des x représente les modèles de classification, et l’axe des y représente le rappel ( %). LSTM, mémoire à court terme ; SVM, machine à vecteurs de support ; DT, arbre de décision. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Pour mieux comprendre la contribution de chaque composante architecturale, une étude d’ablation a été réalisée. Les résultats, résumés dans le tableau 14, montrent que le mécanisme d’attention a amélioré la priorisation temporelle, que les couches résiduelle et convolutionnelle ont amélioré l’extraction des caractéristiques et l’apprentissage stabilisé, et que l’intégration blockchain a permis une journalisation médico-légale inviolable ainsi qu’une atténuation automatisée. Chaque amélioration architecturale a contribué de manière incrémentale à une précision de détection accrue tout en réduisant les prédictions de faux positifs.

Variante du modèle	Précision ( %)	Précision ( %)	Rappel (%)	F1-Score ( %)	Taux de faux positifs (%)	Notes
BiLSTM simple	97.5	93.9	93.3	93.67	1.47	Modèle de base de détection d’intrusion séquentielle
BiLSTM + Attention	98.04	95.18	94.85	95.01	1.18	Le mécanisme d’attention privilégie les caractéristiques temporelles informatives
BiLSTM étendu (résiduel + Conv1D)	97.5	94.6	93.06	93.82	1.3	Les connexions résiduelles et les couches convolutionnelles améliorent l’extraction des caractéristiques temporelles et la stabilité de l’entraînement
BiLSTM étendu + Blockchain	98.9	97.5	96.9	97.3	0.59	Cadre complet avec détection d’intrusion, journalisation immuable et atténuation automatisée

Tableau 14 : Étude d’ablation des composants architecturaux dans le cadre proposé de détection d’intrusion. Ce tableau résume la contribution des composants architecturaux individuels, y compris les mécanismes d’attention, l’apprentissage résiduel, l’extraction de caractéristiques convolutionnelles et l’intégration blockchain, à la performance globale du cadre proposé.

Pour chaque variante d’ablation, un seul composant du cadre proposé était supprimé tandis que toutes les conditions restantes étaient maintenues constantes. Le même jeu de données, les entrées fenêtrées pré-traitées, la répartition stratifiée train/test 80:20 identique avec partitionnement de validation, la graine aléatoire fixe (42), l’optimiseur (Adam), le taux d’apprentissage (0,001), la taille du lot (64), le maximum de 50 époques d’entraînement, le critère d’arrêt précoce (patience = 5), le taux d’abandon (0,3) et l’architecture réseau ont été maintenus dans toutes les expériences. Seul le composant évalué a été modifié, garantissant ainsi que les différences de performance observées étaient attribuables uniquement au composant retiré.

Le cadre proposé maintenait un équilibre favorable entre précision et rappel par rapport aux modèles de référence (LSTM, SVM et DT), démontrant une meilleure discrimination des schémas d’attaque subtils sans augmenter substantiellement les prédictions de faux positifs. Cette performance équilibrée se reflète dans la différence constamment faible entre la précision et les valeurs de rappel, indiquant un score F1 élevé et une généralisation robuste sur un trafic réseau hétérogène. Les comparaisons de précision et de rappel sont présentées dans les Figures 6 et 7.

Comparé aux références représentatives de l’IDS, incluant SVM, DT et LSTM, le cadre proposé a démontré un avantage de performance constant sur les ensembles de données de référence avec un trafic bénin suffisant. Le CICIDS2017, le modèle BiLSTM–Blockchain étendu proposé a atteint une précision de 98,9 %, dépassant les références LSTM (97,5 %), DT (97,5 %) et SVM (98,1 %). Sur UNSW-NB15, elle a obtenu une précision de 95,9 %, encore une fois la plus élevée parmi les modèles évalués (LSTM 92,2 %, SVM 94,1 %, DT 94,8 %). Sur Bot-IoT, caractérisé par un déséquilibre de classe extrême avec une très petite classe bénigne, le modèle proposé a atteint une précision de 98,8 %, correspondant à la référence DT et dépassant légèrement les références LSTM (98,3 %) et SVM (98,7 %). Les modèles traditionnels d’apprentissage automatique présentaient une capacité relativement limitée à modéliser les dépendances temporelles à longue portée, tandis que le LSTM améliorait l’apprentissage des caractéristiques temporelles ; Cependant, aucun de ces modèles de base ne fournissait la journalisation médico-légale résistante à la falsification ni la traçabilité automatisée des événements basée sur la blockchain. En intégrant l’apprentissage résiduel, un mécanisme d’attention et la journalisation immuable basée sur la blockchain avec l’architecture BiLSTM étendue, le cadre proposé combinait une performance concurrentielle de détection d’intrusion avec une responsabilité judiciaire vérifiable au-delà de celle fournie par les méthodes de base. Le composant blockchain enregistre chaque intrusion détectée sous forme d’une entrée de registre immuable contenant l’identifiant de bloc, l’horodatage, les données d’événements chiffrées, le hachage cryptographique et la signature numérique. Un exemple de structure d’enregistrement blockchain est montré dans la Figure 8. La précision comparative et le taux d’erreur entre les modèles évalués sont présentés respectivement dans les Figures 9 et 10, tandis que la Figure 11 compare les temps d’entraînement des modèles évalués. Les métriques globales de performance du cadre proposé, incluant la précision, la précision, la rappel, le score F1 et le taux de faux positifs, sont résumées dans la Figure 12, et la comparaison combinée de la précision et du score F1 est présentée dans la Figure 13.

Figure 8. Exemple d’enregistrement d’intrusion blockchain généré après détection d’intrusion. Exemple illustratif d’un enregistrement blockchain créé après une détection d’intrusion. L’enregistrement contient un identifiant de bloc, un identifiant patient/appareil, un horodatage, des données d’événements chiffrées, un hachage du bloc précédent, un hachage du bloc courant et une signature numérique. La structure de l’enregistrement correspond à la représentation de la blockchain définie dans l’équation 14. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 9. Comparaison de précision entre le cadre proposé et les modèles de détection d’intrusion de référence. Graphique à barres comparant la précision de classification du cadre BiLSTM–Blockchain étendu proposé avec les modèles de détection d’intrusion de référence. L’axe des x représente les modèles de classification, et l’axe des y représente la précision de la classification ( %). LSTM, mémoire à court terme ; SVM, machine à vecteurs de support ; DT, arbre de décision. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 10. Comparaison du taux d’erreur entre le cadre proposé et les modèles de détection d’intrusion de référence. Graphique à barres montrant les taux d’erreur finaux obtenus par le cadre BiLSTM–Blockchain étendu proposé et les modèles de détection d’intrusion de référence. L’axe des x représente les modèles de classification, et l’axe des y représente le taux d’erreur ( %). Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 11. Comparaison du temps d’entraînement des modèles de détection d’intrusion. Graphique à barres montrant la durée de l’entraînement à l’horloge murale de chaque modèle évalué. L’axe des x représente les modèles de classification, et l’axe des y représente le temps d’entraînement (secondes). Les temps d’entraînement étaient mesurés à l’aide de l’environnement informatique expérimental décrit dans le protocole. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 12. Indicateurs de performance du cadre BiLSTM–Blockchain étendu proposé. Graphique à barres résumant la performance du cadre proposé. Les métriques incluent la précision, la précision, le rappel (taux de détection) et le score F1. Le taux de faux positifs (FPR = 0,59 %) est également indiqué comme une annotation dans la figure. L’axe des y représente les valeurs de performance ( %). FPR, taux de faux positifs. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

Figure 13. Comparaison de précision et de scores F1 entre modèles de détection d’intrusion. Graphique à barres groupé comparant la précision de la classification et le score F1 à travers les modèles évalués de détection d’intrusion. Les barres violettes représentent la précision, et les barres vertes représentent le score F1. L’axe des x représente les modèles de classification, et l’axe des y représente la performance ( %). LSTM, mémoire à court terme ; SVM, machine à vecteurs de support ; DT, arbre de décision. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

La matrice de confusion obtenue à partir de la classification binaire est présentée dans le tableau 15 et visualisée à la figure 14. Répartis sur les trois ensembles de tests de référence, le modèle a correctement classé 486 798 cas normaux, avec 4 916 échantillons normaux mal classés comme intrusions. Pour la classe d’intrusion, 877 494 cas d’intrusion ont été correctement identifiés, tandis que 12 978 échantillons d’intrusion ont été incorrectement classés comme normaux. Ces résultats démontrent une forte capacité discriminative avec relativement peu d’erreurs de classification, indiquant une performance fiable pour la détection d’intrusion binaire dans les environnements IoMT. La précision rapportée, le score F1, la latence et le débit correspondent exclusivement au stade de détection d’intrusion binaire évalué dans cette étude.

Modèle	Jeu de données	Taille de l’ensemble de test	True Class	Normal prédit	Intrusion prédite	Total (Vrai)
BiLSTM étendu proposé - Blockchain	CICIDS 2017	566149	Normal	451946	2673	454619
			Intrusion	3426	108104	111530
			Total (Prédit)	455372	110777	566149
	UNSW-NB 15	82332	Normal	34764	2236	37000
			Intrusion	1087	44245	45332
			Total (Prédit)	35851	46481	82332
	Bot-IoT	733705	Normal	88	7	95
			Intrusion	8465	725145	733610
			Total (Prédit)	8553	725152	733705
LSTM	CICIDS 2017	566149	Normal	447946	6673	454619
			Intrusion	7396	104134	111530
			Total (Prédit)	455342	110807	566149
	UNSW-NB 15	82332	Normal	32765	4235	37000
			Intrusion	2153	43179	45332
			Total (Prédit)	34918	47414	82332
	Bot-IoT	733705	Normal	85	10	95
			Intrusion	12465	721145	733610
			Total (Prédit)	12550	721155	733705
SVM	CICIDS 2017	566149	Normal	449257	5362	454619
			Intrusion	5743	105787	111530
			Total (Prédit)	455000	111149	566149
	UNSW-NB 15	82332	Normal	33729	3271	37000
			Intrusion	1568	43764	45332
			Total (Prédit)	35297	47035	82332
	Bot-IoT	733705	Normal	84	11	95
			Intrusion	9465	724145	733610
			Total (Prédit)	9549	724156	733705
DT	CICIDS 2017	566149	Normal	448697	5922	454619
			Intrusion	7743	103787	111530
			Total (Prédit)	456440	109709	566149
	UNSW-NB 15	82332	Normal	34129	2871	37000
			Intrusion	1397	43935	45332
			Total (Prédit)	35526	46806	82332
	Bot-IoT	733705	Normal	89	6	95
			Intrusion	8465	725145	733610
			Total (Prédit)	8554	725151	733705

Tableau 15 : Matrice de confusion du modèle proposé de détection d’intrusion. Ce tableau présente la matrice de confusion obtenue à partir de l’évaluation par ensemble de tests du modèle proposé. Les lignes correspondent aux véritables étiquettes de classe et les colonnes correspondent aux étiquettes de classe prédites pour les classes de trafic normal et intrusion.

Figure 14. Matrices de confusion du système proposé de détection d’intrusion BiLSTM–Blockchain à travers les ensembles de données de benchmark. Matrices de confusion montrant les résultats de classification pour les ensembles de données CICIDS2017, UNSW-NB15 et Bot-IoT. Les lignes correspondent à de vraies étiquettes et les colonnes à des étiquettes prédites. Les valeurs de cellules indiquent le nombre d’instances attribuées à chaque résultat de classification. IDS, Système de Détection d’Intrusion. Veuillez cliquer ici pour voir une version agrandie de cette figurine.

La précision par classe, le rappel et les valeurs de score F1 dérivées de la matrice de confusion sont résumés dans le tableau 16. Une grande précision indique que le cadre proposé a rarement mal classé le trafic bénin comme malveillant, réduisant ainsi les alertes inutiles dans les environnements de santé. De même, les valeurs élevées de rappel démontrent une détection efficace des événements d’intrusion tout en minimisant les attaques manquées. Les scores F1 constamment solides dans les deux catégories confirment que le cadre proposé a permis un compromis équilibré entre la sensibilité à la détection et la précision de la classification, soutenant son adéquation à la détection d’intrusion IoMT en temps réel.

Classe	Précision ( %)	Rappel (%)	F1-Score (%)
Normal	97.4	99	98.2
Intrusion	99.44	98.54	98.99
Moyenne	98.42	98.77	98.59

Tableau 16 : Indicateurs de performance par classe du modèle proposé de détection d’intrusion. Ce tableau rapporte la précision, le rappel et les valeurs de score F1 pour les classes normales et intrusion, ainsi que la performance moyenne globale obtenue lors de l’évaluation des jeux de test.

Efficacité de calcul
La performance en temps réel a été évaluée à l’aide de mesures de synchronisation hors ligne sur les fenêtres de test prétraitées plutôt qu’en streaming en direct. Pour chaque jeu de données, les échantillons de test fenêtrés prétraités ont été traités via l’ensemble du pipeline de détection et de journalisation blockchain, et le temps d’exécution de l’horloge murale a été enregistré. Les limites temporelles étaient définies comme suit. La latence de détection (T_d) était mesurée de l’instant immédiatement précédant l’appel d’inférence du modèle jusqu’à ce que les probabilités prédites soient retournées. La latence d’atténuation de bout en bout (T_mitigation = T_d + T_b) a été mesurée du même point de départ jusqu’à l’achèvement de la transaction finale de création de blocs blockchain, avec la composante d’écriture blockchain (T_b) calculée comme la différence entre les deux mesures. La vérification du registre était effectuée après l’arrêt du minuteur de mitigation-latence et était donc exclu de la latence signalée.

Le débit était calculé comme le nombre total de fenêtres traitées divisé par le temps d’horloge murale écoulé nécessaire pour un passage complet de la partition de test de chaque jeu de données. La latence par événement était obtenue en divisant le temps écoulé correspondant par le nombre total de fenêtres traitées. La charge de travail consistait en les partitions de test fenêtrées des trois ensembles de données de benchmark tout en préservant leurs distributions de classes bénéfiques à l’intrusion. Les fenêtres classées comme malveillantes entraînaient une charge supplémentaire de journalisation blockchain, incluant le calcul digest, la signature numérique et l’exécution de transactions de contrats intelligents, tandis que les fenêtres insensibles n’assumaient que le coût de détection.

La comparaison de latence et de débit entre les modèles représentatifs de détection d’intrusion est présentée dans le tableau 12. Les modèles conventionnels d’apprentissage automatique, y compris DT et SVM, ont démontré une latence d’inférence inférieure et un débit plus élevé que le cadre d’apprentissage profond proposé. La référence LSTM a atteint des performances intermédiaires. Le cadre BiLSTM–Blockchain étendu proposé fonctionnait à une latence de détection d’environ 135 ms par événement et un débit d’environ 320 événements/s sur le déploiement Clique PoA à nœud unique décrit dans l’Expérimental Setup. Ces mesures caractérisent la performance du prototype à validateur unique plutôt qu’une évaluation de la scalabilité multinœud.

En plus de la performance en inférence, le temps d’entraînement de chaque modèle évalué a été comparé à l’évaluation de l’efficacité computationnelle. Le temps d’entraînement est un élément important pour les applications IoMT en temps réel, où un déploiement rapide du modèle est souhaitable. Comme montré à la Figure 11, la DT a atteint la latence par événement la plus basse (environ 40 ms) et le débit le plus élevé (environ 845 événements/s), suivie par la SVM (environ 75 ms, 670 événements/s) et la LSTM (environ 110 ms, 559 événements/s). Le cadre BiLSTM–Blockchain étendu proposé a affiché la latence la plus élevée (environ 135 ms) et le débit le plus faible (environ 320 événements/s) parmi les modèles évalués. Ce coût computationnel supplémentaire provient de l’architecture bidirectionnelle, du mécanisme d’attention temporelle et de la journalisation immuable basée sur la blockchain, qui offrent ensemble un apprentissage des caractéristiques temporelles amélioré et une traçabilité médico-légale à l’épreuve de la falsification. Bien que ces composants augmentent la latence par événement, le débit atteint reste suffisant pour une surveillance d’intrusion quasi en temps réel dans les environnements IoMT.

Une évaluation complète de la scalabilité, impliquant plusieurs nœuds validateurs et des charges de transactions variables, dépassait le cadre du prototype actuel à nœud unique. L’évaluation du débit et de la latence en fonction du nombre de validateurs et de la charge des transactions dans des conditions contrôlées représente une orientation importante pour les travaux futurs visant à caractériser la scalabilité du cadre dans des environnements hospitaliers distribués plus larges.

Journalisation et atténuation de la blockchain
La figure 8 illustre un exemple d’enregistrement d’intrusion blockchain. Chaque bloc stocke de manière sécurisée une intrusion ou une transaction de données médicales dans le registre blockchain en enregistrant un identifiant de bloc unique (Block_ID), un identifiant de patient ou d’appareil (Patient_ID), un horodatage, des données d’intrusion chiffrées, le hachage précédent du bloc, le hachage actuel et une signature numérique. Collectivement, ces champs offrent confidentialité, intégrité, immutabilité, authentification et traçabilité médico-légale dans le cadre proposé de détection d’intrusion BiLSTM–Blockchain.

Dans l’ensemble, les résultats soutiennent l’hypothèse centrale selon laquelle l’intégration d’un détecteur d’intrusion BiLSTM étendu amélioré par l’attention avec une couche de journalisation basée sur blockchain permet une détection d’intrusion précise, efficace et inviolable pour les réseaux IoMT. Le cadre proposé a atteint une précision globale de 98,71 % et un score F1 de 98,99 %, surpassant constamment les modèles de référence évalués en apprentissage automatique et en apprentissage profond tout en maintenant une convergence stable et des preuves minimales de sur-ajustement. L’étude d’ablation a démontré que chaque composant architectural, y compris les couches convolutionnelle et résiduelle, le mécanisme d’attention et l’intégration blockchain, contribuait de manière incrémentale à la performance globale de détection et aux capacités médico-légales. Sur le prototype à nœud unique, le framework maintenait une latence moyenne d’environ 135 ms par événement et un débit d’environ 320 événements par seconde tout en fournissant une journalisation des intrusions immuable et vérifiable. Collectivement, ces résultats confirment la pertinence du cadre intégré de détection et de blockchain proposé pour la détection d’intrusion en temps réel et la saisie judiciaire sécurisée dans les environnements IoMT.

Disponibilité des données :
Les ensembles de données de référence utilisés dans cette étude sont accessibles au public. L’ensemble de données UNSW-NB15 est disponible dans le dépôt UNSW Canberra (https://research.unsw.edu.au/projects/unsw-nb15-dataset), le jeu de données CICIDS2017 est disponible auprès de l’Institut canadien de cybersécurité (https://www.unb.ca/cic/datasets/ids-2017.html), et le jeu de données Bot-IoT est disponible dans le dépôt UNSW Canberra (https://research.unsw.edu.au/projects/bot-iot-dataset).

Les documents complets nécessaires à la reproduction de l’étude sont fournis sous forme de fichiers complémentaires. Le Fichier Supplémentaire 1 contient le pseudocode complet pour le prétraitement, la sélection de fonctionnalités, l’entraînement de modèles, la détection d’intrusion, la blockchain et les algorithmes de smart contract décrits dans le protocole. Le Fichier Supplémentaire 2 contient l’implémentation complète du pipeline de prétraitement des données, du modèle BiLSTM étendu, des scripts d’entraînement et d’évaluation, du client blockchain, des scripts de génération de figures et du pipeline d’exécution de bout en bout. Le README accompagnant fournit des instructions étape par étape pour reproduire le flux de travail, incluant la préparation des ensembles de données, l’entraînement du modèle, l’évaluation, la génération de figures et le déploiement optionnel de la blockchain. Le fichier requirements.txt accompagnant spécifie les dépendances du paquet Python nécessaires pour recréer l’environnement informatique.

Figure	Figure Type	Généré à partir de
1	Diagramme d’architecture conceptuel	Logiciel de dessin vectoriel
2	Diagramme de flux de données au niveau de l’implémentation	Logiciel de dessin vectoriel
3	Courbe de convergence de précision	Historique de la formation (précision de l’entraînement et de la validation par époque)
4	Courbe de convergence de pertes	Historique de la formation (perte d’entraînement et de validation par époque)
5	Graphique de comparaison de barres de précision	Valeurs de précision par modèle
6	Graphique à barres comparatif de précision	Valeurs de précision par modèle
7	Graphique comparatif de rappels	Valeurs de rappel par modèle
8	Diagramme de structure par blocs de la blockchain	Structure conceptuelle des enregistrements blockchain
9	Tableau comparatif de précision	Valeurs de précision par méthode
10	Tableau comparatif des taux d’erreur	Valeurs du taux d’erreur par méthode
11	Tableau comparatif des temps d’entraînement	Durée mesurée des entraînements
12	Tableau de résumé des performances	Valeurs de précision, rappel, exactitude, score F1 et taux de faux positifs du modèle proposé
13	Graphique comparatif de précision et de scores F1	Précision par méthode et valeurs de score F1
14	Matrice de confusion	Comptage de matrices de confusion

Tableau 17 : Sources de données utilisées pour générer les chiffres inclus dans l’étude. Ce tableau résume les sources de données et les sorties computationnelles utilisées pour générer chaque figure présentée dans le manuscrit. Les chiffres quantitatifs ont été générés de manière programmatique à partir des historiques d’entraînement des modèles, des métriques d’évaluation, des sorties de matrices de confusion et des mesures de performance, tandis que les diagrammes conceptuels ont été créés à l’aide d’un logiciel de dessin vectoriel.

Fichier supplémentaire 1. Algorithmes et pseudocode pour le cadre de détection d’intrusion BiLSTM–Blockchain proposé Extended BiLSTM. Ce fichier complémentaire contient le pseudocode complet pour le pipeline de prétraitement (Algorithme 1), la détection d’intrusion BiLSTM étendue (Algorithme 2), l’entraînement du modèle avec arrêt précoce (Algorithme 3), la détection et la mitigation d’intrusion basées sur blockchain (Algorithme 4), la sélection de fonctionnalités AQU-IMF-RFE (Algorithme 5) et la procédure d’enregistrement des intrusions par smart contract (Algorithme 6). Veuillez cliquer ici pour télécharger ce fichier.

Dossier supplémentaire 2. Code source pour le cadre proposé de détection d’intrusion BiLSTM–Blockchain. Ce fichier complémentaire contient l’implémentation complète du pipeline de prétraitement, du modèle BiLSTM étendu, de l’entraînement et de l’évaluation du modèle, du pipeline d’exécution de bout en bout, du client blockchain et des scripts de génération de figures nécessaires à la reproduction des résultats rapportés. Veuillez cliquer ici pour télécharger ce fichier.

Dossier supplémentaire 3. Procédures détaillées de mise en œuvre et d’optimisation pour le cadre proposé de détection d’intrusion BiLSTM–Blockchain. Ce fichier complémentaire fournit des détails d’implémentation omis-en-ciel du protocole principal pour des raisons de concision, incluant (A) l’optimisation de l’entraînement BiLSTM étendu et la formulation mathématique (objectif d’entraînement, optimisation Adam, arrêt précoce et configuration des hyperparamètres) ; (B) implémentation détaillée de réseaux neuronaux (Conv1D, BiLSTM empilée, projection résiduelle, mécanisme d’attention, initialisation de poids, abandon et paramètres de classification) ; (C) le déploiement de blockchain et la mise en place des smart contracts ; (D) les procédures de génération et de vérification de signatures numériques ; (E) traitement d’événements par contrats intelligents et flux de travail automatisé de réponse ; et (F) l’interprétation de l’analyse de complexité computationnelle. Ces détails soutiennent la pleine reproductibilité du cadre proposé tout en maintenant la lisibilité du protocole principal. Veuillez cliquer ici pour télécharger ce fichier.

README.
Instructions pour reproduire le flux de travail proposé. Ce fichier fournit des instructions d’installation logicielle, la préparation des jeux de données, l’exécution de l’ensemble du pipeline de traitement, l’entraînement du modèle, l’évaluation, la génération de figures, le déploiement blockchain et des conseils de reproductibilité pour le cadre proposé.

requirements.txt
Dépendances logicielles pour reproduire l’environnement de calcul. Ce fichier liste les dépendances du paquet Python et les exigences de version compatibles nécessaires pour exécuter les composants de prétraitement, d’entraînement du modèle, d’évaluation, de blockchain et de visualisation du cadre proposé.

Discussion

La présente étude propose un cadre intégré Extended BiLSTM–Blockchain pour la détection et la prévention des intrusions dans les environnements IoMT. Les résultats démontrent que ce cadre identifie efficacement les schémas d’intrusion dans le trafic hétérogène du réseau IoMT en combinant l’apprentissage temporel bidirectionnel avec la journalisation médico-légale basée sur la blockchain. L’architecture bidirectionnelle permet au modèle de capturer à la fois les dépendances temporelles avant et arrière au sein du trafic réseau, ce qui donne une grande précision (99,44 %), un rappel de 98,54 % et un score F1 de 98,99 % pour la classe d’intrusion, tout en maintenant un faible taux de faux positifs (environ 1,0 %) comparé aux modèles de détection d’intrusion de référence évalués. Contrairement aux architectures LSTM unidirectionnelles conventionnelles ou de baseline, qui peuvent ne pas capturer les dépendances temporelles à longue portée, le modèle proposé reconnaît plus efficacement les schémas de trafic séquentiel, améliorant la discrimination entre trafic réseau bénin et malveillant. Ces résultats soutiennent l’hypothèse de l’étude selon laquelle l’intégration d’un détecteur BiLSTM étendu à attention améliorée avec une couche de journalisation blockchain améliore à la fois la performance de détection d’intrusion et la responsabilité médico-légale.

Le cadre proposé peut s’inscrire dans plusieurs axes de recherche établis. Une ligne de recherche porte sur la détection d’intrusion améliorée par sélection de caractéristiques pour les systèmes IoMT, incluant les approches basées sur des arbres et des^{filtres 8}, les détecteurs d’apprentissage d’ensemble⁹, et notre cadre de sélection de caractéristiques AQU-IMF-RFE précédemment^{rapporté 18}. Ces approches améliorent la précision de la détection grâce à la réduction de la dimensionnalité mais reposent généralement sur des classificateurs qui ne modélisent pas explicitement les dépendances temporelles bidirectionnelles dans le trafic réseau. Le cadre proposé complète plutôt que ne remplace ces méthodes en utilisant AQU-IMF-RFE¹⁸ pour construire un espace de fonctionnalités optimisé, sur lequel le BiLSTM étendu effectue la détection d’intrusion temporelle tandis que la couche blockchain fournit une journalisation médico-légale immuable. Une seconde ligne de recherche utilise des modèles d’apprentissage de séquences pour la détection d’intrusion, incluant les architectures BiLSTM à attention^{améliorée 7}, les IDS de réseau basés sur BiLSTM³¹, et les approches de réseaux neuronaux^{récurrents 32,33}. Conformément à ces études, les résultats présents confirment la valeur de la modélisation temporelle bidirectionnelle, la BiLSTM étendue augmentée par l’attention obtenant des scores F1 supérieurs aux références LSTM et CNN évaluées dans cette étude. Contrairement à ces modèles axés sur la détection, cependant, le cadre proposé intègre également la journalisation de la blockchain à l’épreuve de la falsification. Une troisième orientation de recherche explore la sécurité basée sur la blockchain pour les systèmes de santé et IoT, incluant les architectures de santé et l’intégrité médico-légale^{compatibles blockchain 28,34,35}, le contrôle d’accès blockchain^{autorisé 36,37}, et la détection d’intrusion fédérée pilotée par blockchain pour IoMT³⁸. Bien que ces études établissent la valeur de l’immutabilité et de l’auditabilité, elles considèrent généralement la détection d’intrusion et la journalisation médico-légale comme des processus distincts ou utilisent des mécanismes de consensus plus intensifs en calcul. En revanche, le cadre proposé intègre une blockchain PoA légère et autorisée directement avec le détecteur d’intrusion afin de fournir une journalisation immuable et une atténuation pilotée par les événements tout en maintenant une faible surcharge de calcul. Comparé aux approches récentes d’apprentissage profond de l’IoMT, incluant la détection d’intrusion basée sur l’ingénierie des fonctionnalités³⁹ et l’apprentissage fédéré pour l’IoT^{médical 40}, la principale contribution de la présente étude est l’intégration de la détection temporelle bidirectionnelle avec la traçabilité médico-légale basée sur la blockchain dans un cadre unifié, plutôt que d’améliorer uniquement la précision de la détection.

L’intégration de la blockchain apporte une confiance importante, une responsabilité et des capacités médico-légales au cadre proposé. Les enregistrements blockchain immuables garantissent que les événements d’intrusion ne peuvent pas être modifiés après enregistrement, soutenant ainsi la conformité réglementaire et l’audit médico-légal dans les environnements de santé. Chaque événement enregistré stocke des identifiants d’appareil, des horodatages, des hachages cryptographiques et des signatures numériques qui facilitent une vérification transparente et une traçabilité. De plus, la couche smart contract permet une atténuation automatisée pilotée par les événements en générant des drapeaux d’isolement de nœuds et des alertes administrateur traitées par un auditeur hors chaîne, réduisant ainsi le temps de réponse tout en préservant un enregistrement auditable de chaque événement de sécurité. Collectivement, ces capacités étendent le cadre au-delà de la détection d’intrusion conventionnelle en intégrant détection, journalisation sécurisée et réponse automatisée au sein d’une seule architecture.

Plusieurs limites de la présente étude doivent être reconnues. Méthodologiquement, l’évaluation du modèle a été réalisée en utilisant une seule division stratifiée de hold-out avec une graine aléatoire fixe (42) plutôt que des validations croisées répétées ou plusieurs initialisations aléatoires. Les hyperparamètres étaient sélectionnés à partir des valeurs par défaut établies plutôt que par une procédure d’optimisation exhaustive. L’évaluation expérimentale s’appuyait sur trois ensembles de données de référence publiques (UNSW-NB15, CICIDS2017 et Bot-IoT⁾41,42,43, qui, bien que largement acceptés, représentent des captures de trafic statiques plutôt que du trafic réseau en évolution continue. Leur déséquilibre inhérent de classe peut également influencer la performance du modèle malgré l’application d’un entraînement pondéré par classe. De plus, l’architecture BiLSTM étendue contient plus de paramètres entraînables et nécessite des temps d’entraînement plus longs que les bases conventionnelles de l’apprentissage automatique en raison de sa structure bidirectionnelle récurrente et de son mécanisme d’attention. Bien que la latence d’inférence mesurée permette un déploiement en temps réel sur la station d’évaluation, les exigences de calcul et de mémoire peuvent dépasser les capacités des dispositifs IoMT en périphérie limités en ressources, rendant le déploiement au niveau de la passerelle ou sur serveur plus pratique. Le cadre suppose en outre que la détection d’intrusion et la journalisation de la blockchain se produisent sur les nœuds de passerelle de confiance et que les nœuds validateurs PoA autorisés se comportent honnêtement. La journalisation blockchain introduit une latence moyenne de confirmation d’environ 2 s, et la croissance du registre à long terme peut devenir un problème de scalabilité lors de déploiements à grande échelle. L’hypothèse du validateur de confiance est une caractéristique inhérente aux blockchains PoA^{autorisées 24,25}, tandis que les défis plus larges de sécurité blockchain ont été examinés ailleurs²⁴. Par conséquent, atténuer la collusion des validateurs dans les déploiements multi-institutions reste un sujet important pour de futures recherches. Enfin, bien que les statistiques de prétraitement aient été dérivées exclusivement de la partition d’entraînement pour éviter les fuites d’informations, l’utilisation de jeux de données de benchmark hors ligne prétraités au lieu du trafic réseau en temps réel peut surestimer le débit pratique, et les artefacts connus d’étiquetage et d’échantillonnage dans les ensembles de données de benchmark peuvent introduire un biais spécifique à chaque jeu de données. Bien que le mécanisme d’attention offre un certain degré d’interprétabilité, le cadre reste en grande partie une boîte noire d’apprentissage profond, limitant potentiellement la transparence pour les cliniciens et analystes de sécurité qui nécessitent des alertes plus interprétables. Cette limitation est cohérente avec les observations rapportées lors des précédentes enquêtes de détection d’intrusion en apprentissage^{profond 6,11,44}.

Plusieurs opportunités existent pour étendre davantage le cadre proposé. La validation sur des bancs d’essai IoMT en conditions réelles ou des réseaux hospitaliers opérationnels fournirait des preuves supplémentaires de performances réelles au-delà des ensembles de données de référence hors ligne. L’implémentation blockchain pourrait être étendue du prototype actuel à nœud unique à un déploiement multivalidateur distribué afin de permettre une évaluation complète de la scalabilité. Les techniques de compression, d’élagage ou de quantification des modèles peuvent faciliter le déploiement sur des dispositifs de périphérie à ressources limitées. Des recherches supplémentaires pourraient également inclure l’apprentissage en ligne pour traiter les dérives conceptuelles et les attaques^{zero-day 45}, l’apprentissage fédéré pour permettre la formation collaborative de modèles entre établissements de santé sans partager de données sensibles^{des patients 40}, ainsi que des méthodes d’IA explicables pour fournir des alertes d’intrusion plus transparentes aux cliniciens et au personnel de cybersécurité.

Dans l’ensemble, le cadre BiLSTM–Blockchain étendu proposé démontre une forte adaptabilité, une responsabilité médico-légale et une performance robuste en détection d’intrusion. En intégrant un apprentissage temporel axé sur l’attention amélioré avec une journalisation blockchain immuable et une atténuation automatisée, le cadre combine une grande précision de détection avec une traçabilité forensique sécurisée et de faibles taux de faux positifs. Ces résultats démontrent le potentiel de l’approche proposée comme méthode pratique pour sécuriser des environnements IoMT en temps réel tout en soutenant des audits fiables et une réponse sécuritaire rapide dans les systèmes de santé.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
AQU-IMF-RFE Feature Selection Module	Self-developed	N/A	Méthode de sélection de fonctionnalités hybride intégrant Mutual Information, Aquila Optimizer et Recursive Feature Elimination
Attention Layer	Self-developed (Keras-based)	N/A	Mécanisme d'attention temporelle utilisé pour le pondération des caractéristiques dans le modèle Extended BiLSTM
Bot-IoT Dataset	UNSW Canberra Cyber	N/A	Jeu de données de référence publique utilisé pour l'évaluation de la détection d'intrusion
CICIDS2017 Dataset	Canadian Institute for Cybersecurity	N/A	Jeu de données de référence publique pour la détection d'intrusion
Ethereum Client (Geth)	Ethereum Foundation	1.13.15	Client blockchain utilisé pour déployer et opérer le réseau Proof-of-Authority
Extended BiLSTM Model	Self-developed	N/A	Modèle de détection d'intrusion en apprentissage profond intégrant Conv1D, BiLSTM, apprentissage résiduel et attention temporelle
Jupyter Notebook	Project Jupyter	7.x	Environnement interactif utilisé pour la mise en œuvre, l'expérimentation et la visualisation des résultats
NumPy	NumPy Developers	2.4.4	Bibliothèque de calcul numérique utilisée pour le prétraitement et l'entraînement du modèle
Pandas	Pandas Development Team	3.0.2	Bibliothèque de traitement de données utilisée pour le prétraitement et l'analyse des données
Proof-of-Authority Blockchain Network	Self-developed	N/A	Réseau blockchain autorisé utilisé pour la journalisation immuable des intrusions et l'atténuation automatisée
Python	Python Software Foundation	3.12.7	Langage de programmation utilisé pour le prétraitement des données, le développement de modèles, l'intégration de blockchain et l'évaluation
Random Forest Estimator	Scikit-learn Developers	N/A	Classificateur Random Forest utilisé pour l'élimination récursive des caractéristiques (RFE)
Scikit-learn	Scikit-learn Developers	1.8.0	Bibliothèque d'apprentissage automatique utilisée pour le prétraitement, la sélection de caractéristiques et l'évaluation des modèles
Solidity Compiler (solc)	Solidity Team	0.8.19	Compilateur utilisé pour la compilation et le déploiement de contrats intelligents
Solid-State Drive (SSD)	Dell	512 GB	Stockage utilisé pour les ensembles de données, les modèles entraînés et le registre blockchain
System Memory (RAM)	Dell	128 GB	Mémoire principale utilisée pendant le prétraitement, l'entraînement du modèle, l'exécution de la blockchain et l'évaluation
TensorFlow	Google	2.16.1	Framework d'apprentissage profond utilisé pour implémenter et entraîner le modèle Extended BiLSTM
UNSW-NB15 Dataset	UNSW Canberra Cyber	N/A	Jeu de données de référence publique utilisé pour l'entraînement et l'évaluation
Web3.py	Web3.py Developers	6.15.1	Interface Python utilisée pour la communication entre le système de détection d'intrusion et le réseau blockchain
Windows Operating System	Microsoft	Windows 11	Système d'exploitation utilisé pour toutes les expériences
Workstation / Server	Dell	PowerEdge R740	Plateforme informatique utilisée pour l'entraînement des modèles, le déploiement de la blockchain et l'évaluation