Blockchain-integriertes bidirektionales Langzeit-Kurzzeitgedächtnisnetzwerk für Echtzeit-Eindringerkennung im Gesundheitswesen Internet der medizinischen Dinge

Zusammenfassung

Dieses Protokoll beschreibt die Implementierung eines blockchain-integrierten bidirektionalen Langzeit-Kurzzeitgedächtnis-Intrusions-Systems für Gesundheitsnetzwerke im Internet of Medical Things, das Echtzeit-Angriffserkennung, manipulationssichere forensische Protokollierung und automatisierte Minderung ermöglicht.

Zusammenfassung

Healthcare Internet of Medical Things (IoMT)-Umgebungen benötigen Eindringlingserkennungssysteme, die Cyberangriffe nicht nur genau identifizieren, sondern auch forensische Verantwortlichkeit, Prüfbarkeit und schnelle Reaktionsmöglichkeiten bieten. Konventionelle Ansätze zur Eindringlingserkennung legen in erster Linie Wert auf die Klassifizierungsleistung und bieten begrenzte Unterstützung für manipulationssichere Ereignisaufzeichnungen und Nachuntersuchungen. Diese Studie präsentiert ein forensisch bewusstes Rahmenwerk zur Eindringlingserkennung, das ein erweitertes Bidirectional Long Short-Term Memory-Netzwerk (BiLSTM) mit einer autorisierten Blockchain-Schicht integriert, um Echtzeiterkennung, sichere Protokollierung und automatisierte Minderung in IoMT-Systemen im Gesundheitswesen zu unterstützen. Das Protokoll kombiniert Datenvorverarbeitung, AQU-IMF-RFE-Merkmalauswahl, temporale Sequenzmodellierung, aufmerksamkeitsbasiertes Lernen, Residualverbindungen und blockchain-basierte Ereignisaufzeichnung. Das erweiterte BiLSTM-Modell wurde unabhängig auf den UNSW-NB15-, CICIDS2017- und Bot-IoT-Benchmark-Datensätzen unter Verwendung reproduzierbarer Vorverarbeitung, geschichteter Datenpartitionierung und fester zufälliger Seed trainiert und bewertet. Vom Modell erkannte Eindringereignisse wurden auf einer Proof-of-Authority-Blockchain über Smart Contracts aufgezeichnet, die unveränderliche Protokollierung und automatisierte Reaktionsaktionen ermöglichten. Experimentelle Ergebnisse zeigten eine hohe Eindringerkennungsleistung mit niedrigen Fehlpositivraten über alle ausgewerteten Datensätze hinweg, während forensische Rückverfolgbarkeit und Echtzeit-Reaktionsfähigkeit erhalten blieben. Die Blockchain-Schicht bot manipulationssichere Auditaufzeichnungen und automatisierte Minderung, ohne übermäßigen Rechenaufwand einzuführen. Diese Ergebnisse zeigen, dass die Integration von Deep-Learning-basierter Intrusion Detection mit blockchain-gestütztem forensischem Logging die Vertrauenswürdigkeit, Verantwortlichkeit und praktische Einsatzfähigkeit von Cybersecurity-Systemen im Gesundheitswesen verbessert.

Einleitung

Im Gesundheitssystem hat die Digitalisierung zu einer neuen Ära intelligenter, vernetzter und patientenzentrierter Gesundheitsdienste geführt. Die moderne medizinische Infrastruktur ist stark auf Netzwerkkommunikation und Datenaustausch zwischen tragbaren Sensoren, Fernüberwachungssystemen für Patienten, elektronischen Gesundheitsakten (EHRs⁾ und intelligenten Diagnoseplattformen angewiesen. Diese zunehmende Vernetzung erweitert jedoch auch die Angriffsfläche von Gesundheitsnetzwerken und setzt sie Cyberbedrohungen wie Datenpannen, Ransomware, Distributed Denial-of-Service (DDoS)-Angriffen und Man-in-the-Middle-Angriffen^aus. Diese Eingriffe führen zu erheblichen finanziellen Verlusten und, noch wichtiger, können die Patientensicherheit gefährden, wenn sensible medizinische Daten oder die Funktionalität kritischer Geräte kompromittiert werden.

Das Ausmaß und die Komplexität der Internet of Medical Things (IoMT)-Systeme verschärfen diese Sicherheitsherausforderungen zusätzlich. Moderne Gesundheitsnetzwerke müssen gleichzeitig eine latenzarme Kommunikation, hohe Zuverlässigkeit und robuste Sicherheitsgarantien bieten, Anforderungen, die traditionelle Sicherheitsmechanismen oft nur schwer erfüllen^können. Das rasante Wachstum des IoMT-Verkehrs, gekennzeichnet durch heterogene Datenquellen, dynamische Kommunikationsmuster und strenge regulatorische Anforderungen wie das Health Insurance Portability and Accountability Act (HIPAA) und die Datenschutzverordnung (DSGVO), erfordert intelligente Einbruchserkennungssysteme (IDSs), die hohe Erkennungsraten erreichen und gleichzeitig Fehlalarme minimieren⁵.

In regulierten Gesundheitsumgebungen ist die Einbruchserkennung nicht nur eine operative Anforderung, sondern auch eine Rechenschaftsfunktion. Sicherheitswarnungen können eine Geräteisolation auslösen, die Kontinuität der Versorgung beeinträchtigen und anschließend Gegenstand von Audits, regulatorischen Überprüfungen oder rechtlichen Untersuchungen werden. Daher muss eine effektive IoMT-IDS eine genaue Echtzeiterkennung, erklärbare Entscheidungen zur Unterstützung der Vorfalltriage und manipulationssichere Aufzeichnungen bieten, die eine Unwiderlegbarkeit und forensische Rückverfolgbarkeit^{gewährleisten 6}. Diese Anforderung verlagert das Ziel der Eindringlingserkennung von einer leistungszentrierten Klassifikation hin zu vertrauenszentrierten und verantwortungsbasierten Sicherheitsgovernance.

Deep-Learning-Techniken, insbesondere Long Short-Term Memory (LSTM) und Bidirectional Long Short-Term Memory (BiLSTM) Netzwerke, haben eine starke Fähigkeit gezeigt, zeitliche Abhängigkeiten im Netzwerkverkehr zu modellieren und anomales Verhalten zu erkennen⁷. Dennoch leiden bestehende BiLSTM-basierte IDSs häufig unter Überanpassung, unzureichender Aufmerksamkeit kritischer zeitlicher Ereignisse und begrenzter Verallgemeinerung über heterogene IoMT-Geräte und Gesundheitsumgebungen. Darüber hinaus sind IoMT-Netzwerke einer Vielzahl von Cyberbedrohungen ausgesetzt, die die Vertraulichkeit, Integrität und Verfügbarkeit (CIA) medizinischer Daten und Dienste beeinträchtigen, wie in Tabelle 1 zusammengefasst.

Angriffstyp	IoMT-Kontext	Betroffene CIA-Dimension	Auswirkungen auf Gesundheitssysteme
Unbefugter Zugriff19	Nutzung schwacher Authentifizierungsmechanismen zum Zugriff auf Patientengeräte oder medizinische Unterlagen	Vertraulichkeit, Integrität	Datenlecks und unbefugte Kontrolle von medizinischen Geräten
Spoofing / Imitation19	Das bösartige Gerät imitiert einen legitimen IoMT-Knoten	Integrität	Falsche Messwerte, die zu Fehldiagnosen oder unsicheren Behandlungen führen können
21 Abhören	Abfangen unverschlüsselter medizinischer Daten während der Übertragung	Vertraulichkeit	Datenschutzverletzungen und Offenlegung sensibler Patientendaten
Datenmanipulation / Firmware-Exploits19	Änderung der Gerätefirmware oder übermittelter Gesundheitsdaten	Integrität	Falsche Diagnose oder unangemessene Therapieentscheidungen
Ransomware20	Verschlüsselung von Patientendaten oder der medizinischen Geräte-Firmware	Verfügbarkeit, Integrität	Sperrung kritischer Systeme und Behandlungsverzögerungen
Denial-of-Service (DoS) / Verteilter Denial-of-Service (DDoS)6	Überlastung von medizinischen Geräten oder Gesundheitsnetzwerken	Verfügbarkeit	Servicestörungen betreffen Überwachungssysteme und den Betrieb der Intensivstationen (ICU)
Seitenkanal-Angriffe22	Extraktion kryptografischer Schlüssel durch Zeit- oder Leistungsanalysetechniken	Vertraulichkeit	Gerätekompromittierung und Diebstahl kryptografischer Schlüssel

Tabelle 1: Häufige Cyberangriffe, die Gesundheitsumgebungen im Internet of Medical Things betreffen. Diese Tabelle fasst repräsentative Cyberangriffe zusammen, die sich gegen Internet of Medical Things (IoMT)-Systeme richten, deren operativen Kontext, die betroffenen Sicherheitsdimensionen Vertraulichkeit, Integrität und Verfügbarkeit (CIA) sowie deren potenzielle Auswirkungen auf die Gesundheitsversorgung, Patientensicherheit und den Betrieb medizinischer Geräte.

Die Blockchain-Technologie bietet mehrere Vorteile, die die Intrusionserkennung in IoMT-Umgebungen ergänzen können. Wie in Tabelle 2 zusammengefasst, ermöglicht die Blockchain unveränderliche Ereignisprotokollierung für forensische Validierung, ermöglicht automatisierte Minderung durch Smart Contracts, beseitigt einzelne Ausfallpunkte durch dezentrale Operationen und unterstützt die Einhaltung von Gesundheitsdatenschutzvorschriften durch die Pflege nachverfolgbarer Audit-Trails. Trotz dieser Vorteile bleiben blockchain-basierte Sicherheitsmechanismen in Gesundheits-IDSs ungenutzt.

Ausstattung	Beschreibung	Vorteile im Gesundheitskontext
Datenintegrität	Jede Transaktion wird kryptographisch gehasht und mit dem vorherigen Block verknüpft	Gewährleistet die Unveränderlichkeit von Patienten- und Geräteakten
Manipulationserkennung	Jede Änderung der gespeicherten Daten ändert den Blockhash und macht die Kette ungültig	Ermöglicht eine schnelle Erkennung unbefugter Datenänderungen
Zugangskontrolle	Smart Contracts setzen vordefinierte Berechtigungen und Autorisierungsrichtlinien durch.	Beschränkt den Zugang zu sensiblen Gesundheitsinformationen auf autorisierte Nutzer und Geräte
Herkunft der Daten	Jede Veranstaltung ist digital signiert und mit Zeitstempeln versehen	Unterstützt forensische Rückverfolgbarkeit, Prüfungen und regulatorische Compliance.
Konsens mit niedriger Latenz	Der Proof-of-Authority-(PoA)-Konsensmechanismus ermöglicht eine schnelle Transaktionsvalidierung mit geringerem Rechenaufwand als Proof-of-Work	Unterstützt nahezu Echtzeit-Ereignisprotokollierung in kritischen Gesundheitsumgebungen

Tabelle 2: Vorteile der Blockchain-Technologie für Gesundheitssysteme zur Störungserkennung von Internet-of-Medical Dinge. Diese Tabelle fasst die wichtigsten Blockchain-Funktionen und deren damit verbundene Vorteile in Gesundheitsumgebungen im Internet der medizinischen Dinge (IoMT) zusammen. Die aufgeführten Funktionen unterstützen unveränderliches Protokoll, Manipulationserkennung, Zugriffskontrolle, Datenherkunft und latenzarte Konsensmechanismen, die für eine sichere und prüfbare Eindringerkennung erforderlich sind.

Über die Leistungsbewertung hinaus bietet die Blockchain-Integration Schutz vor mehreren Sicherheitsbedrohungen in IoMT-Umgebungen. Tabelle 3 fasst die Stärken und Schwächen der Blockchain in diesem Zusammenhang zusammen und hebt Bedrohungen hervor, die effektiv gemindert werden können, wie Datenmanipulation und -zurückweisung sowie Bedrohungen, die zusätzliche Schutzmaßnahmen erfordern. Die Blockchain-Schicht unterstützt latenzarte Protokollierung, die für Echtzeit-Gesundheitsumgebungen geeignet ist, byzantinische Widerstandsfähigkeit gegen fehlerhafte oder bösartige Knoten sowie Skalierbarkeit über verteilte Krankenhausnetzwerke und IoMT-Geräte hinweg.

Sicherheitsbedrohung	Wird es durch die Blockchain angesprochen?	Mechanismus	Anmerkungen
Datenmanipulation27	Ja	Kryptographisches Hash-Linking	Jede Änderung macht die Kettenintegrität ungültig
Ablehnung26	Ja	Digitale Signaturen, die jedem Block zugeordnet sind	Verhindert die Ablehnung aufgezeichneter Eindringereignisse
Zentralisierter Fehler25	Ja	Verteiltes Hauptbuch, das über autorisierte Gateways geführt wird	Beseitigt einen einzelnen Fehlerpunkt
Sybil-Angriff24	Teilweise	Permissioned PoA-Konsens, der vertrauenswürdige Validatoren erfordert	Kann durch identitätsbasierte Validator-Autorisierung gemildert werden
51% Angriff23	Teilweise	Erfordert einen Kompromiss der Mehrheit der autorisierten Validatoren	Weniger wahrscheinlich bei privaten PoA-Blockchain-Implementierungen
Datenherkunft26	Ja	Zeitgestempelte und digital signierte Veranstaltungsaufzeichnungen	Unterstützt forensische Rückverfolgbarkeit und Einhaltung gesetzlicher Vorschriften

Tabelle 3: Sicherheitsbedrohungen, die durch Blockchain-Integration in Gesundheitsumgebungen im Internet der medizinischen Dinge adressiert werden. Diese Tabelle fasst die wichtigsten Sicherheitsbedrohungen zusammen, die für Internet of Medical Things (IoMT)-Systeme relevant sind, und zeigt an, inwieweit die Blockchain-Technologie jede Bedrohung abmildert. Die zugrunde liegenden Schutzmechanismen und Implementierungsaspekte werden für jede Bedrohungskategorie bereitgestellt.

Die meisten bestehenden IDSs basieren auf vordefinierten Regeln oder leichten maschinellen Lernmodellen ^8,9. Obwohl solche Ansätze bekannte Angriffsmuster erkennen können, haben sie oft Schwierigkeiten, mit der dynamischen und sich wandelnden Natur moderner Cyberbedrohungen umzugehen. Sie sind besonders unzureichend, um schnell wachsende IoMT-basierte Gesundheitsinfrastrukturen zu sichern, wo Fehlalarme, begrenzte Anpassungsfähigkeit und schlechte Auditierbarkeit die operative Effizienz erheblich beeinträchtigen können. Regelbasierte Systeme erzeugen häufig hohe Falsch-Positiv-Raten, da sie gutartige Anomalien nicht zuverlässig von echten Angriffen unterscheiden^{können 9}. Konventionelle Machine-Learning-Modelle, die auf statischen oder veralteten Datensätzen trainiert sind, sowie bestehende Deep-Learning-basierte Intrusion Detection-Ansätze versäumen es oft, aufkommende Angriffsverhalten zu verallgemeinern, einschließlich Zero-Day-Intrusions^10,11. Darüber hinaus bleiben traditionelle zentralisierte Protokollansätze anfällig für Manipulationen, was die Zuverlässigkeit der forensischen Untersuchungen nach Vorfällen^{einschränkt 12}. Viele bestehende IDS-Lösungen verursachen zudem erheblichen Rechenaufwand, was die Bereitstellung auf ressourcenbegrenzten IoMT-Geräten und Gateways¹³ erschwert. Daher bleiben IoMT-Umgebungen im Gesundheitswesen anfällig für ausgeklügelte, mehrstufige Cyberangriffe. Die Bewältigung dieser Herausforderungen erfordert ein intelligentes, sicheres und ressourceneffizientes Eindringerkennungsframework, das in der Lage ist, temporale Verkehrsmuster in Echtzeit zu erfassen und gleichzeitig forensische Vertrauenswürdigkeit sowie automatisierte Minderung erkannter Bedrohungen sicherzustellen.

Trotz bedeutender Fortschritte im maschinellen Lernen und auf Deep Learning basierenden Intrusionserkennung bestehen mehrere kritische Lücken. Erstens werden viele bestehende IDS-Modelle mit statischen Datensätzen entwickelt und evaluiert und haben daher keine Anpassungsfähigkeit an sich ständig entwickelnde Angriffsverhalten. Zweitens können fortschrittliche Deep-Learning-Architekturen zwar die Erkennungsgenauigkeit verbessern, bieten aber oft eine begrenzte Interpretierbarkeit und versäumen es, klinisch wichtige Verkehrsmuster zu priorisieren. Drittens und am wichtigsten bieten die aktuellen IDS-Rahmenwerke im Allgemeinen keine intrinsische Unterstützung für forensische Vertrauenswürdigkeit, Prüfbarkeit oder unveränderliche Datenführung – Fähigkeiten, die für regulatorische Konformität, Vorfalluntersuchung und rechtliche Verantwortlichkeit im Gesundheitssystem unerlässlich sind.

Obwohl blockchain-basierte Logging-Mechanismen Datenintegrität und Transparenz bieten, sind sie selten kohärent mit fortschrittlichen, auf Deep-Learning-basierten Intrusion Detection-Modellen in latenzempfindlichen IoMT-Umgebungen integriert. Bestehende Studien konzentrieren sich typischerweise entweder darauf, die Erkennungsleistung zu verbessern, ohne forensische Integrität zu berücksichtigen, oder auf blockchain-basierte Sicherheitsmechanismen, ohne fortschrittliche zeitliche Anomalieerkennung einzubeziehen. Daher bleibt eine erhebliche Lücke bei der Entwicklung eines einheitlichen Rahmens, das gleichzeitig eine Echtzeit-Erkennung von räumlich-zeitlichen Eindringen, manipulationssichere forensische Protokollierung, automatisierte Minderung und praktische Implementierung in heterogenen und ressourcenbegrenzten Gesundheits-IoMT-Umgebungen bereitstellen kann.

Motiviert von diesen Herausforderungen zielt diese Studie darauf ab, ein Intrusion-Detection-Framework zu entwickeln, das BiLSTM-Netzwerke durch Aufmerksamkeitsmechanismen und benutzerdefinierte Schichten verbessert, um temporale Feature-Priorisierung zu verbessern, Blockchain-Technologie für sichere und verifizierbare Intrusion Logging und automatisierte Reaktionen integriert und effizient in Echtzeit-Gesundheits-IoMT-Umgebungen arbeitet. Wir vermuten, dass die Integration einer aufmerksamkeitsverstärkten erweiterten BiLSTM-Architektur mit blockchain-basierter forensischer Protokollierung und automatisierten Minderungsmechanismen die Effektivität der Eindringlingserkennung verbessert und gleichzeitig die Prüfbarkeit, Vertrauenswürdigkeit und Verantwortlichkeit bietet, die in regulierten Gesundheitsumgebungen erforderlich sind.

Diese Arbeit adressiert eine grundlegende Lücke in der IoMT-Sicherheitsforschung, indem sie Eindringlingserkennung als forensisches Verantwortlichkeitsproblem und nicht ausschließlich als Klassifikationsproblem betrachtet. Das vorgeschlagene Framework integriert künstliche Intelligenz (KI)-gesteuerte Erkennung, unveränderliche Ereignisaufzeichnung und automatisierte Reaktionsmechanismen in eine einheitliche Architektur, die klinische Sicherheit, regulatorische Compliance und betriebliches Vertrauen unterstützt. Die zunehmende Nutzung von IoMT-Geräten und cloudverbundenen Gesundheitsinfrastrukturen hat Gesundheitsnetzwerke zu attraktiven Zielen für Cyberangriffe gemacht, darunter Ransomware, Datenmanipulation, unbefugter Zugriff und Denial-of-Service-Angriffe, die die Vertraulichkeit, Integrität und Verfügbarkeit von Patientendaten bedrohen. Das vorgeschlagene erweiterte BiLSTM–Blockchain-Framework etabliert einen geschlossenen Sicherheitskreislauf, der die Angriffserkennung direkt mit forensischer Validierung und automatisierter Minderung verbindet.

Die Hauptbeiträge dieser Studie sind fünffach. Erstens wird ein klinisch ausgerichtetes Modell zur Erkennung von temporalen Intrusionen entwickelt, indem eine konventionelle BiLSTM-Architektur mit dualdirektionalem temporalem Lernen, Residualverbindungen, Aufmerksamkeitsmechanismen und benutzerdefinierten Schichten erweitert wird, um die Erkennung komplexer Angriffsmuster im Gesundheitsnetzwerkverkehr zu verbessern. Zweitens ist eine leichte, blockchainbasierte Sicherheitsschicht in das Extended BiLSTM-Modell integriert, um eine unveränderliche, sichere und manipulationssichere Protokollierung von Eindringereignissen und Systemaktionen zu ermöglichen. Drittens wird eine End-to-End-Echtzeit-IDS-Pipeline für Gesundheitsumgebungen entwickelt, die Live-Verkehrsanalysen und Eindringlingsvorhersagen mit geringer Latenz und hoher Genauigkeit ermöglicht. Viertens wird das vorgeschlagene Framework umfassend mit drei öffentlich zugänglichen Benchmark-Datensätzen bewertet, nämlich UNSW-NB15, CICIDS2017 und Bot-IoT. Schließlich ist die Architektur als skalierbares und erweiterbares Edge-Cloud-Framework konzipiert, das sich für den praktischen Einsatz in Gesundheitsnetzwerken, medizinischen Infrastrukturen und E-Health-Anwendungen eignet.

Durch die Kombination der temporalen Lernfähigkeiten erweiterter BiLSTM-Netzwerke mit dem Vertrauen und der Unveränderlichkeit der Blockchain-Technologie liefert das vorgeschlagene Framework ein sicheres und vertrauenswürdiges IDS, das auf die sich wandelnden Cybersicherheitsanforderungen von Gesundheitsumgebungen zugeschnitten ist. Das Framework überbrückt kritische Lücken in der Sicherheit von Gesundheitsnetzwerken und legt die Grundlage für eine breitere Einführung von KI und Blockchain-Integration zum Schutz kritischer Gesundheitsinfrastrukturen.

Protokoll

Alle Experimente wurden ausschließlich mit öffentlich verfügbaren Benchmark-Netzwerk-Intrusion-Datensätzen (UNSW-NB15, CIC-IDS-2017 und Bot-IoT) durchgeführt, die Netzwerkverkehrsdaten ohne identifizierbare persönliche oder medizinische Informationen enthalten. Die Datensätze wurden gemäß ihren jeweiligen Lizenzen und Nutzungsbedingungen verwendet. Da keine menschlichen Teilnehmer, Patientenproben oder identifizierbaren personenbezogenen Daten beteiligt waren, waren keine institutionelle ethische Zustimmung und informierte Zustimmung erforderlich.

Überblick über das vorgeschlagene Rahmenwerk
Dieser Abschnitt stellt das vorgeschlagene Dual-Layer-Intrusion Detection and Prevention Framework zur Sicherung von IoMT-Umgebungen vor. Das Framework integriert ein erweitertes BiLSTM-Netzwerk zur räumlich-zeitlichen Eindringerkennung mit einer leichtgewichtigen Blockchain-Schicht für manipulationssicheres Logging und automatisierte Minderung. Im Gegensatz zu herkömmlichen IDS-Ansätzen, die sich ausschließlich auf die Erkennungsgenauigkeit konzentrieren, ist die vorgeschlagene Architektur darauf ausgelegt, gleichzeitig Echtzeiterkennung, forensische Verantwortlichkeit und regulatorische Compliance zu unterstützen, die wesentliche Anforderungen in Gesundheitssystemen sind. Der gesamte Arbeitsablauf und die Architektur des vorgeschlagenen erweiterten BiLSTM–Blockchain-Intrusionserkennungsrahmens für IoMT-Netzwerke sind in Abbildung 1 dargestellt.

Abbildung 1. Architektur des vorgeschlagenen erweiterten BiLSTM–Blockchain-Intrusionserkennungsrahmens für Internet-of-Medizin-Netzwerke. Schematische Darstellung des vorgeschlagenen Frameworks, die die Trainings- und Bereitstellungsabläufe darstellen. Im Trainings-Workflow erzeugen Internet of Medical Things (IoMT)-Geräte Netzwerkverkehr, der Datenvorverarbeitung und Feature Engineering durchläuft, bevor er vom Extended Bidirectional Long Short-Term Memory (BiLSTM)-Modell mit zeitlicher Aufmerksamkeit analysiert wird. Modellparameter werden durch Verlustfunktionsberechnung und iteratives Training optimiert. Im Deployment-Workflow führt das trainierte Modell Intrusionserkennung gemäß der Entscheidungsfunktion aus Gleichung 13 durch. Erkannte Eindringereignisse werden an das Blockchain-Modul weitergeleitet, wo unveränderliches Protokoll, Knotenisolation und Administratorwarnungsgenerierung durchgeführt werden. BiLSTM, bidirektionales Langzeitgedächtnis; IoMT, Internet der medizinischen Dinge. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

IoMT-Geräte erzeugen heterogene Datenströme, die aus Netzwerkverkehr, Gerätemetadaten und patientenbezogenen Signalen bestehen. Solche Roheingaben sind oft rausch, redundant und inkonsistent, was sie für direktes Modelltraining ungeeignet macht. Daher wird eine Preprocessing-Pipeline angewendet, um die Qualität und Struktur der Daten sicherzustellen, bevor sie in das erweiterte BiLSTM-Modell eingespeist werden. Der detaillierte Vorverarbeitungs-Pseudocode wird in Algorithmus 1 (Supplementary File 1) bereitgestellt, der die Preprocessing-Pipeline beschreibt, die vor dem erweiterten BiLSTM-Training auf IoMT-Datenströme angewendet wurde (Pseudocode in Supplementary File 1; Implementierung in Supplementary File 2). Die vollständige erweiterte BiLSTM-Architektur wird in Algorithmus 2 (Supplementary File 1) zusammengefasst.

End-to-End-Reproduktionsworkflow
Die vollständige Studie kann mit den folgenden Schritten reproduziert werden. Software und Hardware sind im Experimental Setup aufgeführt, und der Zusatzcode deckt jeden Schritt ab.

Laden Sie die Datensätze → UNSW-NB15 herunter. Verwenden Sie die Dateien UNSW_NB15_training-set.csv und UNSW_NB15_testing-set.csv. Laden Sie CICIDS2017 herunter. Verwenden Sie die fünf MachineLearningCSV-Tagesdateien (Montag bis Freitag). Laden Sie Bot-IoT herunter. Nutze die 5%-Subset-Dateien UNSW_2018_IoT_Botnet_Full5pc_1_to_4. Frühere Studien zur Intrusionserkennung stützten sich häufig auf Benchmark-Datensätze wie KDD Cup 99¹⁴; diese Studie verwendet jedoch die neueren UNSW-NB15-, CICIDS2017- und Bot-IoT-Datensätze, um den zeitgenössischen Netzwerkverkehr besser darzustellen. Bearbeiten Sie jeden Datensatz einzeln. Der UNSW-NB15-Datensatz ist von der University of New South Wales in https://research.unsw.edu.au/projects/unsw-nb15-dataset verfügbar (zuletzt geändert: 8. Februar 2024). Der CICIDS2017-Datensatz ist vom Canadian Institute for Cybersecurity bei https://www.unb.ca/cic/datasets/ids-2017.html verfügbar (veröffentlicht: Juli 2017). Der Bot-IoT-Datensatz ist von der University of New South Wales in https://research.unsw.edu.au/projects/bot-iot-dataset verfügbar (zuletzt geändert: 5. Februar 2024). Alle Datensätze wurden im Mai 2025 für diese Studie abgerufen.

Die Daten vorverarbeiten → beschädigte Datensätze entfernen. Füllen Sie fehlende Werte mit Trainingsset-Mitteln aus. EMA-Enttäuschung auftragen (α = 0,3). Normalisieren Sie Funktionen auf [0,1] mithilfe von Trainingsset-Statistiken. Kategorische Felder beschriften-enkodieren. Baue Schiebefenster (T = 20, Schritt = 1). Diese Vorverarbeitungsschritte unterstützen eine robuste Eindringerkennung, indem sie Rauschen reduzieren und die Qualität der Netzwerkverkehrsrepräsentationen für maschinell-lernende IDSs^15,16 verbessern.

Funktionen auswählen (AQU-IMF-RFE) → Bewerten Sie Funktionen nach gegenseitigen Informationen. Verfeinere mit dem Aquila Optimizer. Wenden Sie Random Forest RFE mit 10-facher Kreuzvalidierung an. Behalte die letzten Features. Diese hybride Merkmalsauswahlstrategie folgt dem übergeordneten Konzept der Kombination komplementärer Intrusionsdetektionstechniken^{17 und} wird mit dem AQU-IMF-RFE-Framework umgesetzt, das in unserer vorherigen Arbeit¹⁸ entwickelt wurde.

Trainieren Sie das Modell → Für jeden Datensatz wurden die Daten zufällig in Trainings- (80 %) und Testsätze (20 %) mit einem festen zufälligen Seed von 42 aufgeteilt. Zwanzig Prozent der Trainingspartition wurden zusätzlich als Validierungsset reserviert. Baue das erweiterte BiLSTM. Trainieren Sie mit gewichtetem binären Kreuzentropieverlust und dem Adam-Optimierer (Lernrate = 0,001, Batchgröße = 64, maximal 50 Epochen, mit vorzeitigem Stopp). Rette das trainierte Modell. Der Einsatz temporaler Deep-Learning-Modelle eignet sich gut für heterogener IoMT-Verkehr¹⁹. Der vollständige Modelltrainings-Workflow wird in Algorithmus 3 (Supplementary File 1) zusammengefasst. Die endgültigen Klassengewichte wurden automatisch aus den trainingsbasierten Klassenverteilungen gemäß den Gleichungen 19 und 20 berechnet. Die daraus resultierenden Klassengewichte waren wie folgt: UNSW-NB15: , ; CICIDS2017: , ; und Bot-IoT (5 % Teilmenge): , . Der hohe Wert von w_n für den Bot-IoT-Datensatz spiegelt die starke Unterrepräsentation gutartiger Stichproben in der Trainingspartition der 5%-Teilmenge wider.

Setzen Sie die Blockchain → starten Sie die Proof-of-Authority-(PoA)-Kette. Stellen Sie den Smart Contract bereit und notieren Sie dessen Adresse. Autorisiere die Gateway-Konten. Führe den Client so aus, dass jeder erkannte Einbruch protokolliert wird und Isolation sowie Warnungen auslöst. Der vollständige Ablauf für Erkennung, Blockchain-Logging und Minderung wird in Algorithmus 4 (Supplementary File 1) zusammengefasst. Die Blockchain-Schicht wurde mit dem go-ethereum (Geth) Client Version 1.13.15 implementiert, um das genehmigte PoA-Netzwerk zu betreiben, den Solidity-Compiler (solc) Version 0.8.19 für Smart-Contract-Kompilierung und -Bereitstellung sowie die web3.py Bibliotheksversion 6.15.1 für die Kommunikation zwischen IDS und dem Blockchain-Netzwerk.

Bewerten → testen Sie das Modell auf dem aufbewahrten Testset. Berechnen Sie Genauigkeit, Präzision, Rückruf, F1-Wert und Falsch-Positiv-Rate. Aufzeichnungslatenz und Durchsatz verwenden. Überprüfen Sie die Integrität des Blockchain-Hauptbuchs. Der vollständige Evaluationsworkflow wird in Algorithmus 5 (Supplementary File 1) zusammengefasst. Die Detektionslatenz (T_d) wurde von unmittelbar vor dem Modellinferenzaufruf bis zu dem Zeitpunkt gemessen, zu dem die vorhergesagten Wahrscheinlichkeiten zurückgegeben wurden. Die End-to-End-Mitigationslatenz (T_d + T_b) wurde vom selben Ausgangspunkt bis zum Abschluss der entsprechenden Blockchain-Blockerstellungstransaktion gemessen. Der Durchsatz wurde berechnet als die Gesamtzahl der vorverarbeiteten Testfenster, die durch die vollständige Erkennungs- und Protokollierungspipeline verarbeitet wurden, geteilt durch die vergangene Wanduhr-Zeit, die für einen einzigen vollständigen Durchgang durch den Testsatz jedes Datensatzes benötigt wird. Die Arbeitslast bestand aus den fensterbasierten Testpartitionen, während die ursprüngliche Verteilung der gutartigen Klassen erhalten blieb. Bösartige Fenster verursachten zudem den Blockchain-Logging-Overhead, während harmlose Fenster nur die Kosten für die Störungserkennung verursachten.

Erstellen Sie Zahlen und Tabellen → Zeichnen Sie die Genauigkeits- und Verlustkurven, die Verwirrungsmatrix und vergleichende Bewertungsdiagramme auf. Erstelle die Vergleichstabellen. Der vollständige Ablauf zur Abbildung und Tabellengenerierung wird in Algorithmus 6 (Supplementary File 1) zusammengefasst. Der vollständige, speziell entwickelte Quellcode, der zur Erstellung aller Abbildungen und Tabellen verwendet wird, ist in Supplementary File 2 bereitgestellt. Insbesondere reproduziert das figures.py-Skript die Manuskriptfiguren direkt aus den gespeicherten experimentellen Ausgaben (z. B. Trainingsverlauf- und Verwirrungsmatrix-Dateien), während die übrigen Skripte die verarbeiteten Daten und Leistungsmetriken generieren, die zur Erstellung der berichteten Tabellen verwendet werden.

Abbildung 2 zeigt den Implementierungsdatenfluss zwischen den IDS- und Blockchain-Modulen. Das erweiterte BiLSTM liefert eine Entscheidung pro Fenster (Gleichung 13); bei einer bösartigen Klassifizierung erstellt und signiert der Gateway-Client eine Transaktion und übermittelt sie über web3/JSON-RPC an den PoA-Smart Contract, der einen hashverknüpften Block (Gleichung 14) an das unveränderliche Hauptbuch anhängt und Ereignisse (BlockCreated, NodeIsolated und AdminAlert) aussendet, die Knotenisolation und Administratorwarnungen auslösen.

Abbildung 2. Implementierungsebene Interaktion zwischen Intrusion Detection und Blockchain-Modulen. Workflow-Diagramm, das die Kommunikation zwischen dem Intrusion Detection System und den Komponenten der Blockchain veranschaulicht. Das erweiterte BiLSTM-Modell klassifiziert jedes Eingabefenster und wendet die Entscheidungsregel an, die in Gleichung 13 definiert ist. Wenn eine Störung erkannt wird, erzeugt und signiert der Gateway-Client eine Transaktion, die über Web3.py/JSON-RPC an den Proof-of-Authority (PoA) Smart Contract übertragen wird. Der Vertrag fügt gemäß Gleichung 14 einen hashverknüpften Block an das unveränderliche Hauptbuch an und sendet BlockCreated-, NodeIsolated- und AdminAlert-Ereignisse, die Containment- und Benachrichtigungsaktionen auslösen. IDS, Eindringlingserkennungssystem; BiLSTM, bidirektionales Langzeitgedächtnis; PoA, Autoritätsnachweis; JSON-RPC, JavaScript Object Notation–Remote Procedure Call. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Datenrepräsentation
Betrachten wir R als den rohen IoMT-Verkehrsstrom. Nach der Vorverarbeitung wird jeder Rohdatensatz in einen normalisierten d-dimensionalen Merkmalsvektor abgebildet (Gleichung 1):

(1)

Hier ist f (⋅) die Merkmalstransformationsfunktion, die rohe Datensätze in einen d-dimensionalen normalisierten Merkmalsvektor abbildet. Sei das IoMT-Netzwerk aus einer Menge von Knoten bestehen (Gleichung 2):

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

Jeder Knoten n_j ∈ R erzeugt einen Zeitreihen-Datenstrom (Gleichung 3):

(3)

Hier ist x_t der Merkmalvektor zum Zeitpunkt t, wobei d Merkmale (z. B. Paketgröße, Protokolltyp, Quell-/Zieladresse) häufig im Internet-of-Things-Gesundheitsnetzwerkverkehr¹⁹ beobachtet werden. Die entsprechende Label-Menge ist (Gleichung 4):

  (4)

Hier steht y_t=0 für normalen Verkehr und y_t =1 für eine Intrusion.

Datenvorverarbeitung
Die Preprocessing-Pipeline umfasst die folgenden Schritte, die gängige Datenqualitäts- und Sicherheitsherausforderungen im Zusammenhang mit IoMT-Verkehr²⁰ adressieren:

Datenbereinigung und Umgang mit fehlenden Werten:
Ein Datensatz wurde vor der Imputation als beschädigt identifiziert und entfernt, wenn er eine der folgenden expliziten Bedingungen erfüllte: (i) alle Merkmalsfelder im Datensatz fehlten (d. h. der gesamte Datensatz war null), oder (ii) der Datensatz enthielt einen nicht endlichen Wert (positiv oder negativ unendlich) in jedem numerischen Feld nach Typzwang. Die zweite Regel entfernt ungültige Einträge, wie sie durch Division durch Null während der Berechnung von Flussmerkmalen entstehen (zum Beispiel unendliche Flussratenwerte, die aus Null-Dauer-Flüssen entstehen). Nachdem beschädigte Datensätze entfernt wurden, wurden die verbleibenden fehlenden Werte durch den durchschnittlichen Ersatz pro Feature, Datensatz und nur aus der Trainingspartition berechnet; Die daraus resultierenden Mittel wurden auf die Trainings-, Validierungs- und Testsets angewandt, um Informationslecks zu verhindern. Die Imputation war nicht klassenbedingt, und die Mittel wurden nicht über Datensätze hinweg gepoolt.

Zeitliche Rauschung:
Die temporale Entspannung wurde mit einem pro-feature-exponentiellen gleitenden Durchschnitt (EMA) Filter durchgeführt, der entlang der Zeitachse angewendet wurde. Die rekursive (kausale) Form y_t = α·x_t + (1 − α)·y_t−1 wurde verwendet, mit Glättungsfaktor α = 0,3, implementiert über die pandas-ewm-Funktion mit adjust=False. Jedes Merkmal wurde unabhängig voneinander geglättet. Als exponentieller (unendlicher Impuls-Antwort) Filter hat der EMA kein festes Fenster oder Kerngröße; Der Glättungsfaktor α ist der einzelne Parameter, der den Glättungsgrad und den effektiven Speicher des Filters bestimmt.

Min–Max-Normalisierung:
Min–Max-Normalisierung wurde angewendet, um jedes Merkmal auf den [0,1]-Bereich zu skalieren, wobei die Transformation x′=(x−min)/(max−min+ε) verwendet wurde, wobei ε = 1 × 10⁻⁸ gilt. Die Mindest- und Maximalstatistiken wurden pro Feature, pro Datensatz und nur aus der Trainingspartition berechnet; Diese gespeicherten Trainingsstatistiken wurden dann angewendet, um das Training, die Validierung und die Testsätze zu normalisieren und so das Auslaufen von zurückgehaltenen Informationen zu verhindern. Während der Inferenz wurden Merkmalswerte, die außerhalb des Trainingsbereichs lagen, auf das [0,1]-Intervall geschnitten.

Codierung kategorischer Merkmale:
Kategoriale Merkmale wurden mittels Beschriftungskodierung in numerische Form umgewandelt. Dies wurde auf alle kategorialen Variablen angewendet: in UNSW-NB¹⁵ die Felder proto, service und status; im Bot-IoT, dem Proto-Feld; CICIDS2017 enthält keine kategorischen Felder unter den ausgewählten Merkmalen. Die Codierung wurde mit LabelEncoder implementiert, der pro Variable angepasst wurde.

Temporales Fenstern für sequentielles Lernen:
Der vorverarbeitete Merkmalsstrom wurde in feste Längenfolgen unterteilt, wobei ein gleitendes Fenster von Länge T = 20 Zeitschritten mit einem Schritt s = 1 verwendet wurde. Jedes generierte Fenster wurde vor der Aufnahme validiert. Ein Fenster wurde nur akzeptiert, wenn es genau T = 20 aufeinanderfolgende Zeitschritte enthielt und alle Merkmalswerte endlich waren. Streams kürzer als T = 20 Datensätze erzeugten keine Fenster. Diese Konfiguration (T = 20, s = 1, 95 % Überlappung) wurde in allen Experimenten und Datensätzen konsistent angewendet. Der vollständige Vorverarbeitungs-Workflow wird in Algorithmus 1 (Supplementary File 1) zusammengefasst.

Das Ziel der Vorverarbeitung ist es, eine prädiktive Abbildung von Eingabesequenzen zu Intrusionslabels zu ermöglichen (Gleichung 5).

(5)

parametrisiert durch θ, das vorhersagt, ob ein Ereignis gutartig oder bösartig ist.

Merkmalauswahl mit AQU-IMF-RFE
Die Feature-Auswahl erfolgte mit AQU-IMF-RFE, einer hybriden Methode, die Mutual Information (MI), den Aquila-Optimierer (AO) und Rekursive Feature Elimination (RFE) integriert, wie sie in unserer vorherigen Arbeit¹⁸ eingeführt wurden. Die Methode erfolgt in drei Stufen. In der ersten Stufe werden die gegenseitigen Informationen zwischen jedem Merkmal und dem Klassenlabel berechnet, um eine anfängliche Relevanzrangfolge zu erhalten. In der zweiten Phase führt der Aquila Optimizer eine globale Suche über Kandidaten-Feature-Subsets mit seinen vier Optimierungsstrategien durch. In der dritten Phase wird die verfeinerte Teilmenge durch die Rekursive Merkmalselimination mit 10-facher Kreuzvalidierung mit einem Random Forest (RF)-Schätzer geleitet.

Der Aquila Optimizer war mit einer Populationsgröße von 100, maximal 10 Iterationen, einem Ausnutzungsfaktor von 0,1, einer Lernrate von 0,1 und einem Anziehungsfaktor von 0,005 konfiguriert. Unabhängig auf jeden Datensatz angewendet, behielt AQU-IMF-RFE 14 Funktionen für UNSW-NB15, 24 für CICIDS2017 und 12 für Bot-IoT. Der vollständige Pseudocode ist in Supplementary File 1 bereitgestellt, und die ausgewählten Feature-Teilmengen sind in Tabelle 4 aufgeführt.

Tabelle 4A. Ausgewählte Merkmale, die für UNSW-NB15 beibehalten wurden.
S. Nein.	Ausstattung	Typ	Kategorie
1	Dur	Numerisch (Float)	Grundlegend
2	Sbytes	Numerisch (ganzzahlig)	Grundlegend
3	Zinssatz	Numerisch (Float)	Grundlegend
4	dload	Numerisch (Float)	Grundlegend
5	sinpkt	Numerisch (Float)	Zeit
6	dinpkt	Numerisch (Float)	Zeit
7	sjit	Numerisch (Float)	Zeit
8	tcprtt	Numerisch (Float)	Zeit
9	Synack	Numerisch (Float)	Zeit
10	ackdat	Numerisch (Float)	Zeit
11	Smean	Numerisch (ganzzahlig)	Inhalt
12	ct_srv_src	Numerisch (ganzzahlig)	Verbindung
13	ct_dst_src_ltm	Numerisch (ganzzahlig)	Verbindung
14	ct_srv_dst	Numerisch (ganzzahlig)	Verbindung
Tabelle 4B. Ausgewählte Merkmale erhalten für CICIDS2017
S. Nein.	Ausstattung
1	Zielhafen
2	Flussdauer
3	Gesamtlänge der Forward-Pakete
4	Gesamtlänge rückwärtslaufender Pakete
5	Maximal Vorwärtspaketlänge
6	Rückwärts-Paketlänge-Maximum
7	Rückwärts-Paketlängen-Mittelwert
8	Flusspakete
9	Maximum der Zwischenankunftszeit des Durchflusses
10	Vorwärts-Inter-Arrival-Gesamtzeit
11	Vorwärts-Kopfballlänge
12	Rückwärts-Header-Länge
13	Weiterleitungspakete pro Sekunde
14	Maximale Paketlänge
15	Mittelwert der Paketlänge
16	Standardabweichung der Paketlänge
17	Paketlängenvarianz
18	Durchschnittliche Paketgröße
19	Durchschnittliche Rückwärtssegmentgröße
20	Subflow-Vorwärtsbytes
21	Unterfluss-Rückwärtsbytes
22	Initiale Fensterbytes vorwärts
23	Initiale Fensterbytes rückwärts
24	Mittelwert der Forward-Paketlänge
Tabelle 4C. Ausgewählte Funktionen, die für Bot-IoT erhalten bleiben
S. Nein.	Ausstattung	Typ
1	seq	Numerisch
2	Mittel	Numerisch
3	stddev	Numerisch
4	Min	Numerisch
5	Max	Numerisch
6	Srate	Numerisch (Float)
7	drate	Numerisch (Float)
8	N_IN_Conn_P_SrcIP	Numerisch (ganzzahlig)
9	N_IN_Conn_P_DstIP	Numerisch (ganzzahlig)
10	Proto	Kategorisch (codiert)
11	state_number	Numerisch (ganzzahlig)
12	Zinssatz	Numerisch (Float)

Tabelle 4: Merkmale, die mit der AQU-IMF-RFE-Merkmalsauswahlmethode ausgewählt werden. Diese Tabelle listet die endgültigen Feature-Subsets auf, die vom AQU-IMF-RFE-Feature-Select-Framework für die UNSW-NB15-, CICIDS2017- und Bot-IoT-Datensätze ausgewählt wurden. Feature-Namen, Datentypen und funktionale Kategorien sind, wo anwendbar, angegeben.

Versuchsaufbau
Alle Experimente wurden auf einem Dell PowerEdge R740-Server durchgeführt, der mit einem Intel Xeon Silver 4214-Prozessor ausgestattet war, der mit einer Grundfrequenz von 2,20 GHz arbeitete, mit 12 physischen Kernen, 24 logischen Threads, 16,5 MB Cache und einer Intel Ultra Path Interconnect (UPI)-Geschwindigkeit von 9,6 GT/s. Der Server war mit 128 GB RAM, einem 512 GB Solid-State-Laufwerk (SSD) konfiguriert und arbeitete unter Microsoft Windows 11. Der Software-Stack bestand aus Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 und NumPy 2.4.4. Die Blockchain-Schicht wurde auf derselben Workstation über ein PoA-Ethereum-Netzwerk implementiert. Die Kommunikation zwischen IDS und Blockchain erfolgte über JSON-RPC mit dem Go-ethereum (Geth) Client Version 1.13.15, dem Solidity Compiler (solc) Version 0.8.19 für Smart-Contract-Kompilierung und -Bereitstellung sowie der Web3.py Bibliothek Version 6.15.1. Die gemeldete Trainingszeit, Inferenzlatenz und Durchsatz wurden auf dieser Hardware- und Softwarekonfiguration gemessen.

Modellarchitektur und Training
Das erweiterte BiLSTM-Modell bildet die Kerndetektionskomponente des Frameworks und baut auf früheren lernbasierten Intrusionserkennungsansätzen auf, die für IoMT-Umgebungen²¹ entwickelt wurden. Frühere Studien zur Störungserkennung hoben sowohl die Bedeutung hervor, die Erkennungsleistung mit der False-Alarm-Reduzierung¹⁵ auszugleichen, als auch die besonderen Herausforderungen bei der Anwendung von maschinellen Lernmethoden auf den sich entwickelnden Netzwerkverkehr¹⁶. Kollaborative Architekturen zur Intrusionserkennung neuronaler Netze haben zudem den Wert tiefgehender sequentieller Feature-Learning-Elemente für komplexen Netzwerkverkehr²² demonstriert. Während Standard-BiLSTM-Modelle bidirektionale zeitliche Abhängigkeiten erfassen, zeigt der IoMT-Verkehr sowohl kurzfristige Burst-Muster als auch langfristige Abhängigkeiten, die durch Mehrstufenangriffe verursacht werden. Um dem gerecht zu werden, erweitert das vorgeschlagene Modell BiLSTM um temporale Merkmalextraktion, verbessertes bidirektionales zeitliches Lernen, Restverbindungen und aufmerksamkeitsbasierte zeitliche Priorisierung. Bidirektionale LSTMs (BiLSTM) überwinden diese Einschränkung, indem sie versteckte Vorwärts- und Rückwärtszustände kombinieren und so eine reichhaltigere zeitliche Darstellung von IoMT-Verkehrsmustern ermöglichen, wie in Algorithmus 2 (Supplementary File 1) beschrieben.

Sei die Eingabesequenz X^(n_j) = {x₁ , x₂ , ... , x_T }, wobei jedes x_t ∈ R^d ein vorverarbeiteter Merkmalsvektor ist.

Extraktion von zeitlichen Merkmalen:
Eine leichte, eindimensionale Faltung wird über die Zeitdimension hinweg angewendet, um kurzreichweitige zeitliche Anomalien hervorzuheben (Gleichung 6):

U = φ (Konv1D(X^(n_j)), U = {u₁, u₂, ..., u_T } (6)

Hier ist φ(⋅) eine nichtlineare Aktivierungsfunktion und die konvolvierten Merkmale u_t werden dem BiLSTM zugeführt.

Die Conv1D-Schicht extrahiert kurzreichweitige zeitliche Muster vor bidirektionaler Sequenzmodellierung. Vollständige Implementierungsparameter sind in der ergänzenden Datei 3B bereitgestellt.

Gestapeltes bidirektionales LSTM-Lernen:
Vorwärts und rückwärts verborgene Zustände werden berechnet wie folgt (Gleichung 7):

(7)

Die abschließende BiLSTM-Darstellung ist die Verkettung von vergangenen (vorwärts) und zukünftigen (rückwärts) verborgenen Zuständen (Gleichung 8).

(8)

Zwei gestapelte BiLSTM-Schichten modellieren bidirektionale zeitliche Abhängigkeiten. Detaillierte architektonische Parameter sind in der ergänzenden Datei 3B bereitgestellt. Details zur Gewichtsinitialisierung sind in der Ergänzungsakte 3B angegeben.

Restverbindung und Normalisierung
Nach der linearen Projektion auf passende Dimensionen werden Restverbindungen und Schichtnormalisierung angewendet (Gleichung 9):

Residualprojektion und Schichtnormalisierung richten die Konfaltions- und BiLSTM-Merkmalsrepräsentationen vor der Aufmerksamkeit aus. Detaillierte Implementierungsparameter sind in der ergänzenden Datei 3B bereitgestellt.

Aufmerksamkeitsmechanismus
Obwohl BiLSTM eine starke zeitliche Modellierung bietet, tragen nicht alle Zeitschritte gleichermaßen zur Vorhersage bei. Um kritische Zeitstempel (z. B. plötzliche anomale Spitzen) hervorzuheben, wird ein Aufmerksamkeitsmechanismus eingeführt. Jedem versteckten Zustand wird ein Relevanzwert α_t zugewiesen, um die Erkennungsgenauigkeit zu erhöhen (Gleichung 10).

Hier ist W_a ein trainierbarer Parameter und die Aufmerksamkeitsgewichte erfüllen

Der Kontextvektor c aggregiert die verborgenen Zustände basierend auf ihrer erlernten Bedeutung (Gleichung 11):

Der Aufmerksamkeitsmechanismus aggregiert zeitliche Darstellungen zu einem Kontextvektor. Detaillierte Implementierungsparameter sind in der ergänzenden Datei 3B bereitgestellt.

Ausgabeschicht und Klassifikation
Der aggregierte Kontextvektor wird durch eine vollständig zusammenhängende Schicht geleitet, gefolgt von einer sigmoiden Aktivierung, um die endgültige Vorhersage zu erhalten (Gleichung 12):

Hier sind W_c und b_c trainierbare Parameter, und σ(·) ist die sigmoidale Aktivierungsfunktion, die den Ausgang auf das Intervall [0,1] abbildet. Ein Schwellenwert wird angewandt, um Verkehr als gutartig () oder intrusiv () zu klassifizieren.

Die Dropout-Regularisierung und die während der Schlussfolgerung verwendete feste Klassifikationsschwelle sind in Supplementary File 3B beschrieben.

Die erweiterte BiLSTM-Architektur ist in allen drei Datensätzen identisch; nur die Eingabefeature-Dimension unterscheidet sich und beträgt die Werte 14, 24 und 12 für UNSW-NB15, CICIDS2017 bzw. Bot-IoT. Da die Conv1D-Schicht jede -dimensionale Eingabe auf eine feste 64-Kanal-Darstellung abbildet, sind alle nachfolgenden Schichten unabhängig vom Datensatz, und nur die Eingabeform sowie die Anzahl der Conv1D-Parameter variieren mit . Die vollständige Schicht-für-Schicht-Architektur wird in Tabelle 5 zusammengefasst, wobei die Parameterzählungen in d. Die resultierenden Gesamtsummen sind 184.641, 186.561 und 184.257 trainierbare Parameter für d = 14, d = 24 und d = 12.

S. Nein.	Schicht (Typ)	Ausgangsform	Trainierbare Parameter	Aktivierungsfunktion
1	Eingabe	(20, d)	0	—
2	Conv1D (64 Filter, Kerngröße = 3, gleiches Padding)	(20, 64)	192d + 64	ReLU
3	Bidirektionale LSTM-Schicht 1 (64 Einheiten pro Richtung)	(20, 128)	66,048	Tanh / Sigmoid
4	Bidirektionale LSTM-Schicht 2 (64 Einheiten pro Richtung)	(20, 128)	98,816	Tanh / Sigmoid
5	Dichte Restprojektion	(20, 128)	8,320	Linear
6	Restaddition	(20, 128)	0	—
7	Schichtnormalisierung (Achse = −1, ε = 1 × 10⁻³)	(20, 128)	256	—
8	Zeitliche Aufmerksamkeit (Wa ∈ R¹²⁸×¹)	128	128	Softmax
9	Dichte verborgene Schicht	64	8,256	ReLU
10	Ausstieg (p = 0,3)	64	0	—
11	Dichte Ausgabeschicht	1	65	Sigmoid

Tabelle 5: Schicht-für-Schicht-Architektur des erweiterten bidirektionalen Long Short-Term Memory-Modells. Diese Tabelle fasst die Architektur des vorgeschlagenen Extended Bidirectional Long Short-Term Memory (BiLSTM)-Modells zusammen, einschließlich Schichttypen, Ausgabedimensionen, trainierbaren Parameterzählungen und Aktivierungsfunktionen.

Die für alle Experimente verwendete Software und Rechenumgebung sind in Tabelle 6 zusammengefasst.

Komponente	Version / Spezifikation
Betriebssystem	Windows
Serverplattform	Dell PowerEdge
CPU	64-Kern-Prozessor
RAM	128 GB
Lagerung	512 GB SSD
Python	3.12.7
NumPy	2.4.4
Pandas	3.0.2
scikit-learn	1.8.0
TensorFlow / Keras	2.16.1
web3 (Blockchain-Client)	6.15.1
ETH-Account	0.1
Soliditätscompiler (solc)	0.8.19
go-ethereum (Geth)	1.13.15

Tabelle 6: Software und Rechenumgebung, die für die Implementierung und Bewertung des vorgeschlagenen Frameworks verwendet werden. Diese Tabelle fasst die Hardwarespezifikationen, Softwarekomponenten, Blockchain-Tools und Versionsnummern zusammen, die für Datenvorverarbeitung, Feature-Auswahl, Modelltraining, Blockchain-Implementierung und Leistungsbewertung verwendet werden.

Eindringlingsentscheidung und automatisierte Reaktion
Störungserkennung in Gesundheitsumgebungen ist nur wirksam, wenn sie von schneller Reaktion und Minderung gefolgt wird. Die Intrusion Detection Layer wandelt die vorhergesagte Wahrscheinlichkeit in eine Entscheidung um. Formal wird die Intrusionsentscheidung zum Zeitpunkt des Schrittes t wie folgt dargestellt (Gleichung 13):

Hier ist die vorhergesagte Intrusionswahrscheinlichkeit zum Zeitpunkt t und die Klassifikationsschwelle.

Sobald ein Eindringling erkannt wird, verbindet sich die Intrusion Detection Layer direkt mit dem Blockchain-Modul, das unveränderliches Logging, automatisierte Minderung und geschlossene Sicherheitskontrolle durchführt. Ereignisdetails, einschließlich Quellinformationen, Zielinformationen und ausgewählter Verkehrsfunktionen, werden in einem neuen Blockchain-Block erfasst. Smart Contracts führen Echtzeit-Mitigationsmaßnahmen wie Knotenisolierung und Administratorwarnungen aus. Diese geschlossene Architektur ermöglicht es, dass Eindringerkennungsergebnisse direkt in Präventionsmechanismen eingespeist werden und so die Minderungslatenz minimiert werden. Somit dient die Intrusion Detection Layer als Brücke zwischen zeitlicher Erkennung mit dem Extended BiLSTM-Modell und der sicheren Antwort mit Blockchain-Technologie und vervollständigt damit die End-to-End-Funktionalität des vorgeschlagenen Frameworks.

Blockchain-basierte forensische Protokollierung
Während das Extended BiLSTM-Modell eine Echtzeit-Eindringerkennung ermöglicht, sind sichere Speicherung und verifizierbare Audits von Eindringereignissen in IoMT-Gesundheitsumgebungen ebenso entscheidend. Traditionelle zentralisierte Protokollsysteme sind anfällig für Manipulationen und beeinträchtigen die forensische Rückverfolgbarkeit. Um diese Einschränkung zu beheben, integriert das vorgeschlagene Framework ein leichtes Blockchain-Modul, das Unveränderlichkeit, Dezentralisierung und automatisierte Antworten auf Smart-Contract-Basis gewährleistet.

Jedes erkannte Eindringlingsereignis erzeugt einen Block, der der Blockchain hinzugefügt wird. Ein Block B_i ist wie folgt definiert (Gleichung 14):

Hier ist H_i der kryptographische Hash der Ereignisdaten, des Zeitstempels und des Vorhersageergebnisses, T_i der Zeitstempel, D_i enthält ausgewählte Intrusionsereignismerkmale, Si_gi ist die digitale Signatur und PrevHash verknüpft den Block mit dem vorherigen Block, wodurch Unveränderlichkeit gewährleistet ist.

Dieses Design garantiert Manipulationsbeständigkeit, da jede Änderung von D_i oder T_i den Block-Hash verändert und die Kettenintegrität unterbricht. Es bietet außerdem Prüfbarkeit, da alle erkannten Anomalien dauerhaft gespeichert und verifizierbar sind. Automatisierte Minderung wird durch Smart Contracts unterstützt, die vordefinierte Aktionen wie Knotenisolation und Administratorwarnungen ausführen. Die Dezentralisierung wird durch mehrere IoMT-Gateways erreicht, die das verteilte Hauptbuch verwalten und so einen Single Point of Failure eliminieren.

Die Blockgenerierung verwendet die kryptographische Hashfunktion Keccak-256, das native Hash-Primitiv der Ethereum/Solidity-Umgebung (aufgerufen über Soliditys keccak256). Für jeden Intrusionsblock wird der Block-Hash wie folgt berechnet:

Hier ist D_i der Ereignisfeature-Digest, T_i der Zeitstempel und PrevHash der Hash des vorangegangenen Blocks. Die Felder werden mit Soliditys eng gepackter Codierung (abi.encodePacked) vor dem Hashing verkettet, wodurch ein 256-Bit-Digest erzeugt wird.

Die gleiche Keccak-256-Berechnung wird von der Kettenverifikationsroutine verwendet, die jeden Block-Hash aus seinen gespeicherten Feldern neu berechnet und bestätigt, dass er mit dem aufgezeichneten Wert übereinstimmt, wodurch die Kettenintegrität validiert wird. Keccak-256 wurde ausgewählt, weil es der standardmäßige kollisionsresistente Hashing-Algorithmus ist, der nativ in Ethereum-Smart Contracts verwendet wird. Der Smart Contract wurde in Solidity entwickelt und mit dem Solidity-Compiler (solc) Version 0.8.19 kompiliert. Es wurde auf einem privaten Ethereum-Proof-of-Authority-(PoA)-Netzwerk bereitgestellt, das mit der Geth-Version 1.13.15 betrieben wurde. Das Blockchain-Netzwerk war mit vier Validator-Knoten unter Verwendung des Clique Proof-of-Authority-Konsensprotokolls, einer Ketten-ID von 9848, einer Blockperiode von 5 Sekunden und einem Blockgas-Limit von 30.000.000 konfiguriert. Die Kommunikation zwischen der erweiterten BiLSTM-Intrusionserkennungs-Engine und der Blockchain-Schicht wurde mithilfe der Web3.py-Bibliotheksversion 6.15.1 über die HTTP JSON-RPC-Schnittstelle implementiert.

PoA-Konsensmechanismus
Da IoMT-Systeme im Gesundheitswesen sehr latenzempfindlich sind, verwendet das vorgeschlagene Framework einen PoA-Konsensmechanismus anstelle des rechnerisch aufwändigen Proof-of-Work (PoW)²³. In PoA autorisieren eine feste Gruppe vertrauenswürdiger Validator-Knoten, wie Krankenhaus-Gateways, Transaktionen und bieten sowohl Effizienz als auch Widerstandsfähigkeit.

Die Zeitkomplexität der Blockvalidierung unter PoW lässt sich wie folgt ausdrücken (Gleichung 15):

Hier steht d für den Bergbauschwierigkeitsgrad.

Im Gegensatz dazu ist die Zeitkomplexität des PoA-Konsenses wie folgt angegeben (Gleichung 16):

Weil die Validierung nur eine digitale Signaturverifizierung durch autorisierte Validatorknoten erfordert.

Dadurch bietet PoA einen Betrieb mit niedriger Latenz, der für medizinische Echtzeitwarnungen geeignet ist, Energieeffizienz durch Vermeidung von rechnerintensivem Mining und Widerstandsfähigkeit gegen eine begrenzte Anzahl bösartiger Validatoren. Das PoA-Netzwerk war mit vier Validator-Knoten konfiguriert, und diese Konfiguration blieb während aller Experimente stabil, um konsistente Latenzmessungen, reproduzierbare Leistungsbewertung und einen fairen Vergleich über alle Benchmark-Datensätze hinweg zu gewährleisten.

Blockchain-Implementierung und Smart-Contract-Betrieb
Die Blockchain-Komponente wurde auf einem autorisierten Ethereum-Netzwerk implementiert, das nach dem PoA-Konsensmodell²⁴ betrieben wird. Das Netzwerk wurde mit dem Go-Ethereum (Geth)-Client mit dem Clique PoA-Konsensprotokoll²⁵ betrieben, bei dem eine Reihe autorisierter Validator- (Versiegelungs-)Knoten für die Erzeugung und Validierung von Blöcken verantwortlich ist. Der Intrusion-Logging Smart Contract (IoMTIntrusionLedger) wurde in Solidity geschrieben und in diesem Netzwerk bereitgestellt, basierend auf blockchain-basierten IoT-Sicherheitsarchitekturen für sicheres dezentrales Ereignismanagement²⁶. Nur Gateway-Konten, die On-Chain (über die Zugangskontrollfunktion des Vertrags) autorisiert waren, durften Eindringdatensätze einreichen, was mit den genehmigten Blockchain-Smart-Contract-Architekturen für Internet-of-Things-Anwendungen²⁷ entspricht. Die Blockchain-Schicht wurde mit dem go-ethereum (Geth) Client Version 1.13.15 für den Betrieb des permissioned PoA-Netzwerks, dem Solidity Compiler (solc) Version 0.8.19 für Smart-Contract-Kompilierung und -Bereitstellung sowie der Web3.py Library Version 6.15.1 für die Kommunikation zwischen IDS und dem Blockchain-Netzwerk implementiert.

Detaillierte Blockchain-Implementierungs- und Konfigurationsparameter sind in der ergänzenden Datei 3C bereitgestellt.

Jeder Einbruchsdatensatz wird digital signiert, bevor er ins Hauptbuch eingetragen wird, was blockchain-basierte Gesundheitsprüfbarkeit und sichere forensische Datenführung^unterstützt. Digitale Signaturgenerierungs- und Verifizierungsverfahren, einschließlich ECDSA über der Secp256k1-Kurve^29,30, sind in der ergänzenden Datei 3D beschrieben. Jedes Gateway enthält ein Ethereum-Schlüsselpaar, das aus einem 256-Bit-(32-Byte) privaten Schlüssel und dem entsprechenden öffentlichen Schlüssel besteht, von dem seine Kontoadresse abgeleitet ist; Die Schlüsselgenerierung folgt dem Standardverfahren von Ethereum, bei dem ein kryptografisch sicherer, zufälliger 256-Bit-Privatschlüssel verwendet wird, wobei der öffentliche Schlüssel durch die Skalarmultiplikation von SEP256k1 erhalten wird. Um eine Signatur zu erstellen, berechnet der Gateway-Client das Ereignisfeature-Digest D_i und signiert es mit seinem privaten Schlüssel im EIP-191-Nachrichtensignierungsformat, wodurch eine 65-Byte-Signatur aus den Komponenten r, s und v erzeugt wird. Die Unterschrift wird zusammen mit dem Eingriffsprotokoll eingereicht. Die Verifizierung erfolgt on-chain durch den Smart Contract: Mit dem EVM ecrecover-Precompile stellt der Vertrag die Adresse des Unterzeichners aus dem signierten Digest und der Signatur zurück und verlangt, dass sie der Adresse des autorisierten Gateways entspricht, das die Transaktion einreicht. Wenn die wiederhergestellte Adresse nicht mit einem autorisierten Gateway übereinstimmt, wird die Transaktion abgelehnt. Dies bindet jeden Hauptbucheintrag an ein bestimmtes autorisiertes Gateway und verhindert unbefugte oder gefälschte Eindringdatensätze.

Smart Contracts werden bei der Eindringerkennung automatisch ausgelöst und gewährleisten so eine Echtzeitreaktion ohne manuelles Eingreifen (Gleichung 17):

(17)

Das Blockchain-Modul arbeitet parallel zum erweiterten BiLSTM-Klassifikator. Sobald eine Anomalie erkannt wird: (i) das Ereignis wird vom BiLSTM beschriftet und klassifiziert, (ii) ein Block wird generiert, signiert und an das Blockchain-Hauptbuch angehängt, und (iii) Smart Contracts setzen automatische Reaktionsrichtlinien durch.

Der Intrusion-Logging-Smart Contract (IoMTIntrusionLedger) verwaltet ein nur anhängbares Hauptbuch mit Intrusionsblöcken und ein Register autorisierter Gateway-Konten und stellt die in Tabelle 7 zusammengefassten Funktionen offen. Der Vertrag erzwingt zwei Zugriffsrollen durch Modifikatoren: onlyAdmin (der deployierende Administrator) und onlyGateway (Konten, die berechtigt sind, Eindringdatensätze einzureichen). Der Zustand besteht aus der Gateway-Autorisierungsabbildung, dem Blockledger-Array und dem aktuellen Kettenkopf (dem Hash des letzten Blocks).

S. Nein.	Funktion / Komponente	Typ	Zugang	Logik
1	Konstrukteur	Konstrukteur	—	Setzt den Deployer als Administrator und autorisiert ihn als initiales Gateway.
2	setGateway(adresse, bool)	Funktion	onlyAdmin	Fügt ein autorisiertes Gateway-Konto hinzu oder entfernt es; sendet GatewayUpdated aus.
3	recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate)	Funktion	onlyGateway	berechnet Hi = Keccak-256(Di ∥ Ti ∥ Wahrscheinlichkeit ∥ PrevHash); überprüft die ECDSA-Signatur des Gateways auf Di über ecrecover; fügt den Block dem Kassenbuch hinzu; schiebt den Kettenkopf vor; sendet BlockCreated, optional NodeIsolated und AdminAlert aus. Gibt Hi. zurück.
4	verifyChain()	Funktion anzeigen	Öffentlich	Berechent den Hash jedes Blocks aus seinen gespeicherten Feldern neu und prüft die PrevHash-Verknüpfung; gibt nur dann true zurück, wenn die gesamte Kette konsistent ist (Manipulationserkennung).
5	ledgerLength()	Funktion anzeigen	Öffentlich	Gibt die Anzahl der Blöcke im Hauptbuch zurück.
6	_recoverSigner(Hash, Sig)	Interne Funktion	—	Teilt die 65-Byte-Signatur in (r, s, v) auf und stellt die Signaturadresse über die ecrecover-Precompilierung wieder.
7	BlockCreated / NodeIsolated / AdminAlert / GatewayAktualisiert	Veranstaltungen	—	Für Off-Chain-Listener ausgesendet, um Logging, Knotenisolation, Administratorwarnungen und Gateway-Registry-Updates zu steuern.
8	onlyAdmin / onlyGateway	Modifikatoren	—	Beschränke Funktionen auf den Administrator bzw. auf autorisierte Gateways.

Tabelle 7: Funktionen, Ereignisse und Zugriffskontrollkomponenten des IoMTIntrusionLedger Smart Contract. Diese Tabelle fasst die wichtigsten Funktionen, Ereignisse und Zugangskontrollmodifikatoren zusammen, die im permissioned Blockchain Smart Contract implementiert sind. Diese Komponenten unterstützen die Gateway-Autorisierung, Intrusion Logging, Blockchain-Verifikation, Ereignisgenerierung und automatisierte Minderung.

Die Unveränderlichkeitseigenschaft der Blockchain folgt direkt aus Gleichung 14, bei der jede Änderung von Ereignisdaten oder Zeitstempeln die Hashkette ungültig macht. Die Blockchain bietet somit Datenintegrität, Rückverfolgbarkeit und Prüfbarkeit für Gesundheitssysteme durch unveränderliche forensische Aufzeichnungen. Patienten- und Geräte-Intrusionsdaten bleiben nach der Speicherung unverändert, jeder Block ist sicher mit dem vorherigen Block verknüpft, was eine chronologische Rekonstruktion von Ereignissen ermöglicht, und Gesundheitsadministratoren oder Regulierungsbehörden können Einbruchsvorfälle ohne Risiko einer Fälschung überprüfen.

Optimierung von Verlustfunktionen und Modellen
Das vorgeschlagene erweiterte BiLSTM-Modell adressiert das binäre Klassifikationsproblem, bei dem zwischen normalem Datenverkehr und Eindringereignissen in IoMT-Netzwerken unterschieden wird. Um den Trainingsprozess zu steuern, wird ein binärer Kreuzentropieverlust (BCE) verwendet, der sich gut für probabilistische Ausgaben aus der sigmoidischen Aktivierungsschicht eignet. Für einen Datensatz mit N Stichproben wird der Verlust wie folgt definiert (Gleichung 18):

(18)

Hier ist das Grundwahrheitslabel der ^i-ten Eingabesequenz (0 = gutartig, 1 = Intrusion) und die vorhergesagte Intrusionswahrscheinlichkeit.

Das Framework funktioniert als zweistufige Klassifikationspipeline. Die erste Stufe führt binäre Intrusionsdetektion durch: Das erweiterte BiLSTM erzeugt einen sigmoiden Ausgang und wendet den Schwellenwert τ = 0,5 an, um jedes Fenster als gutartig oder intrusiv zu klassifizieren (Gleichungen 12,13), trainiert mit gewichtetem binären Kreuzentropieverlust. Eine zweite Stufe kann eine Angriffskategorisierung durchführen, bei der als Eindringlinge identifizierte Fenster an einen Multiclass-Klassifikator übergeben werden, der die spezifische Angriffskategorie mithilfe einer mit kategorialer Kreuzentropie trainierten Softmax-Ausgabeschicht zuweist. Die vorliegende Studie konzentriert sich auf und bewertet die binäre Detektionsphase. Die beiden Stufen teilen dasselbe Extended BiLSTM-Merkmal-Extraktionsrückgrat (Conv1D, BiLSTM, Residual-, Normalisierungs- und Aufmerksamkeitsschichten); sie unterscheiden sich nur in ihrer Ausgangsschicht (Sigmaid für die Erkennung und Softmax für die Kategorisierung) und der entsprechenden Verlustfunktion. Die binäre Detektionsstufe und die Multiclass-Kategorisierungsstufe wurden unter denselben oben beschriebenen Datenpartitionen, zufälligen Seed- und Trainingsbedingungen trainiert und ausgewertet.

Während der IoMT-Verkehr oft unausgewogen ist, wird ein gewichteter binärer Kreuzentropieverlust verwendet, um eine Fehlklassifikation der Minderheitenklasse zu bestrafen. Die Klassengewichte werden berechnet anhand der Anzahl der Intrusionsproben N_p, der Anzahl der gutartigen Stichproben N_n und der Gesamtzahl der Stichproben N (Gleichungen 19,20):

Die Gewichtung stellt sicher, dass das Modell nicht zugunsten der dominanten gutartigen Verkehrsklasse verzerrt ist und empfindlich gegenüber seltenen, aber kritischen Intrusionsereignissen bleibt.

Der gewichtete binäre Kreuzentropieverlust ist wie folgt angegeben (Gleichung 21):

(21)

Das Training erfolgte mit Mini-Chargen der Größe 64. Zu Beginn jeder Epoche wurden die Trainingsproben zufällig gemischt, bevor sie in Chargen aufgeteilt wurden, sodass die Batch-Zusammensetzung zwischen den Epochen variierte und das Modell keine Beispiele in einer festen Reihenfolge sah. Die Chargen waren nicht explizit nach Klassen ausgewogen oder geschichtet; stattdessen spiegelte jede Charge die natürliche Klassenverteilung des Trainingssatzes wider, und das Klassenungleichgewicht wurde durch den klassengewichteten binären Kreuzentropieverlust adressiert (Gleichungen 19–21). Die Validierungsteilmenge, die aus der Trainingspartition reserviert war, blieb über Epochen hinweg fest und wurde nicht in die Trainingsbatches gemischt.

Die Klassengewichte im gewichteten binären Kreuzentropieverlust wurden nicht manuell festgelegt, sondern automatisch für jeden Datensatz aus den Trainingsmengen-Klassenzählungen gemäß den Gleichungen 19 und 20 berechnet. Für den UNSW-NB15-Datensatz waren die resultierenden Klassengewichte für die normale Klasse und für die Intrusionsklasse. Für den CICIDS2017-Datensatz waren die resultierenden Klassengewichte für die normale Klasse und für die Intrusionsklasse. Für den Bot-IoT-Datensatz (5 % Teilmenge) waren die resultierenden Klassengewichte für die normale Klasse und für die Intrusionsklasse.

Trainingsstrategie und Optimierung
Das erweiterte BiLSTM-Modell wurde mit Mini-Batches der Größe B = 64 trainiert, mit gewichtetem binären Kreuzentropieverlust, dem Adam-Optimierer und frühzeitigem Stopp basierend auf Validierungsverlust. Die Ausbildung wurde auf 50 Epochen begrenzt, und das frühe Stoppen wurde mit Geduld K = 5 angewandt. Wenn sich der Validierungsverlust in fünf aufeinanderfolgenden Epochen nicht verbesserte, wurde das Training gestoppt und die Modellgewichte auf jene aus der Epoche mit dem niedrigsten Validierungsverlust zurückgesetzt. Daher stellten 50 Epochen das maximale Ausbildungsbudget dar, anstatt eine feste Ausbildungsdauer. Für die Regularisierung wurde eine Dropout-Wahrscheinlichkeit von 0,3 angewendet. Die architektonischen Einrichtungen umfassten 64 Conv1D-Filter, 64 LSTM-Einheiten pro Richtung, eine Fensterlänge von T = 20 und einen Schritt von s = 1. Die gewählte Trainingsstrategie ist in Algorithmus 3 (Supplementary File 1) zusammengefasst. Die für die Optimierung verwendeten Adam-Update-Gleichungen sind in der ergänzenden Datei 3A bereitgestellt.

Der Adam-Optimierer war mit einer Lernrate von , einer Erstmoment-Zerfallrate (β₁) von 0,9, einer Zweitmoment-Zerfallrate (β₂) von 0,999 und einer numerischen Stabilitätskonstante () von 1 × 10-7 konfiguriert. Es wurden keine zusätzlichen Optimiereroptionen verwendet, und es wurden weder Gewichtsabnahme noch Gradientenclipping angewendet.

Benachrichtigungsgenerierung und automatisierte Minderung
Die bloße Erkennung ist in latenzsensitiven IoMT-Netzwerken unzureichend, da eine schnelle Reaktion entscheidend ist, um die Patientensicherheit zu gewährleisten. Die Alert Generation and Mitigation Layer operationalisiert die Intrusionsentscheidung des Extended BiLSTM-Modells und des Blockchain-Protokollierungsmechanismus. Wenn δ_t = 1, fügt das Blockchain-Modul einen neuen Block mit den Intrusionsdetails hinzu. Gleichzeitig wird ein Smart Contract ausgeführt, um Minderungsmaßnahmen auszulösen (Gleichung 22):

(12)

Hier sorgt BlockCreation für eine unveränderliche forensische Protokollierung des Ereignisses, NodeIsolation (n_j) isoliert den kompromittierten IoMT-Knoten, um weiteren Schaden zu verhindern, und AdminAlert liefert Systemadministratoren eine Echtzeitbenachrichtigung. Um diese zweischichtige Antwortpipeline zu betreiben, wird der Pseudocode im Algorithmus 4 (Supplementary File 1) präsentiert.

Smart-Contract-Ereignisverarbeitung und Off-Chain-Response-Mechanismen sind in Supplementary File 3E beschrieben.

Jeder im Blockchain-Hauptbuch festgelegte Eintrag wird als IntrusionBlock-Datensatz gespeichert, dessen Felder und Datenformate in Tabelle 8 aufgeführt sind. Das Hauptbuch ist ein nur anhängendes Array dieser Datensätze, und der aktuelle Kettenkopf speichert den Hash des zuletzt hinzugefügten Blocks.

S. Nein.	Spielfeld	Datentyp	Größe	Beschreibung
1	hashId	bytes32	32 Bytes	Block-Hash Hi = Keccak-256(Di ∥ Ti ∥ Wahrscheinlichkeit ∥ PrevHash)
2	Zeitstempel	uint256	32 Bytes	Blockerstellungszeit Ti (Unix-Epochensekunden, aus dem Blockzeitstempel)
3	nodeId	bytes32	32 Bytes	Identifikator des IoMT-Knotens nj
4	PatientenID	bytes32	32 Bytes	Patienten-/Gerätekennung (forensische Metadaten)
5	attackClass	uint16	2 Bytes	Angriffskategorie-Code (0 = Normal, 1 = DDoS, 2 = Spoofing, ...)
6	WahrscheinlichkeitBp	uint16	2 Bytes	Vorhergesagte Intrusionswahrscheinlichkeit ŷ in Basispunkten (0–10000, also 0,00–100,00 %)
7	dataDigest	bytes32	32 Bytes	Digest Di der ausgewählten Veranstaltungsmerkmale
8	Signatur	Bytes	Variable (65 Bytes)	ECDSA-Signatur Sigi des Ereignisdigests des Gateways (r, s, v)
9	prevHash	bytes32	32 Bytes	Hash des vorherigen Blocks (PrevHash), der die Kette verknüpft
10	isoliert	Bool	1 Byte	Ob die Knotenisolation für diesen Datensatz ausgelöst wurde

Tabelle 8: Struktur des IntrusionBlock-Datensatzes, der im Blockchain-Hauptbuch gespeichert ist. Diese Tabelle beschreibt die Felder, Datentypen, Speichergrößen und Zwecke der Blockchain-Hauptbuchdatensätze, die zur Speicherung von Eindringereignissen verwendet werden. Die Struktur unterstützt die Verifikation kryptographischer Integrität, forensische Rückverfolgbarkeit und automatisierte Reaktionsmechanismen.

Die Gesamtminderungslatenz kann als Summe der Erkennungsverzögerung (T_d) aus dem Extended BiLSTM-Modell und der Blockchain-Ausführungsverzögerung (T_b) (Gleichung 23) ausgedrückt werden:

(23)

Berechnung der Komplexitätsanalyse
Die Effizienz des vorgeschlagenen erweiterten BiLSTM–Blockchain-Frameworks wird sowohl durch die Rechenkosten des BiLSTM-Modells als auch durch den durch das Blockchain-Modul eingeführten Overhead bestimmt. Das vorgeschlagene Framework integriert erweiterte BiLSTM-Erkennung mit Blockchain-Logging, um die Kernsicherheitsanforderungen der Confidentiality, Integrity, and Availability (CIA)-Triade zu erfüllen.

Sei die vorverarbeitete Eingabesequenzlänge T, die Merkmalsdimension d und die versteckte Dimension des BiLSTM h.

Für jeden Zeitsprung verarbeitet ein BiLSTM Eingaben der Dimension d mit verborgener Größe h. Da sie bidirektional ist (vorwärts + rückwärts) (Gleichung 24):

) (24)

Hier ist T die Sequenzlänge (Zeitschritte), d die Eingabemerkmaldimension, h die Dimension des verborgenen Zustands

Die Aufmerksamkeitsschicht berechnet Wichtigkeitsgewichte und aggregiert verborgene Zustände mit Komplexität (Gleichung 25).

(25)

die sowohl in der Sequenzlänge T als auch in der verborgenen Dimension h linear ist.

Die gesamte Detektionskomplexität pro Sequenz ist daher wie folgt angegeben (Gleichung 26):

(26)

und zeigt, dass zeitliche Modellierung die Rechenkosten dominiert, während der Aufmerksamkeitsmechanismus nur einen geringen Overhead einführt.

Für jedes erkannte Eindringereignis führt das Blockchain-Logging Hashing-, Unterzeichnungs- und Blockanhängungsoperationen durch (Gleichung 27):

(27)

Für N Intrusions-Detektionsereignisse ergibt sich die kombinierte Komplexität wie folgt (Gleichung 28):

(28)

was wie folgt vereinfacht werden kann (Gleichung 29):

(29)

Weil der Blockchain-Overhead linear mit der Anzahl der Ereignisse wächst und im Vergleich zu Sequenzverarbeitungsberechnungen vernachlässigbar bleibt.

Die Berechnungskomplexität wird in den Gleichungen 24–29 zusammengefasst. Eine ausführliche Interpretation findet sich in der ergänzenden Akte 3F.

Ergebnisse

Die Ergebnisse sind so organisiert, dass sie die methodischen Schritte des Protokolls widerspiegeln, wobei jeder Unterabschnitt die Beobachtungen des jeweiligen Schrittes berichtet.

Datensatzbehandlung und experimenteller Aufbau
Die drei Benchmark-Datensätze wurden unabhängig voneinander analysiert und nicht zusammengeführt. Da UNSW-NB15, CICIDS2017 und Bot-IoT unterschiedliche Merkmalsschemata und Beschriftungskonventionen verwenden, wurde...

Diskussion

Die vorliegende Studie schlägt ein integriertes erweitertes BiLSTM–Blockchain-Framework zur Erkennung und Prävention von Eindringlingen in IoMT-Umgebungen vor. Die Ergebnisse zeigen, dass das Framework Intrusionsmuster im heterogenen IoMT-Netzwerkverkehr effektiv identifiziert, indem es bidirektionales temporales Lernen mit blockchain-basiertem forensischem Logging kombiniert. Die bidirektionale Architektur ermöglicht es dem Modell, sowohl vorwärts- als auch rückwärtszeitliche Abhängigke...

Materialien

Liste der in diesem Artikel verwendeten Materialien

Name	Unternehmen	Katalognummer	Kommentare
AQU-IMF-RFE Feature Selection Module	Selbst entwickelt	N/A	Hybride Merkmalsauswahlmethode, die Mutual Information, Aquila Optimizer und rekursive Merkmalsbeseitigung integriert
Attention Layer	Selbst entwickelt (Keras-basiert)	N/A	Temporales Aufmerksamkeitsmechanismus zur Merkmalsgewichtung im erweiterten BiLSTM-Modell
Bot-IoT Dataset	UNSW Canberra Cyber	N/A	Öffentliches Benchmark-Datenset zur Auswertung der Intrusion-Detection
CICIDS2017 Dataset	Canadian Institute for Cybersecurity	N/A	Öffentliches Benchmark-Intrusion-Detection-Datenset
Ethereum Client (Geth)	Ethereum Foundation	1.13.15	Blockchain-Client zum Bereitstellen und Betreiben des Proof-of-Authority-Netzwerks
Extended BiLSTM Model	Selbst entwickelt	N/A	Deep-Learning-Intrusion-Detection-Modell, das Conv1D, BiLSTM, residuales Lernen und Temporal Attention integriert
Jupyter Notebook	Project Jupyter	7.x	Interaktive Umgebung zur Implementierung, Experimentierung und Ergebnisvisualisierung
NumPy	NumPy-Entwickler	2.4.4	Numerische Rechenbibliothek zur Vorverarbeitung und zum Modelltraining
Pandas	Pandas Development Team	3.0.2	Datenverarbeitungsbibliothek zur Vorverarbeitung und Datenanalyse
Proof-of-Authority Blockchain Network	Selbst entwickelt	N/A	Permissioniertes Blockchain-Netzwerk zur unveränderlichen Intrusion-Protokollierung und automatisierten Minderung
Python	Python Software Foundation	3.12.7	Programmiersprache zur Datenvorverarbeitung, Modellentwicklung, Blockchain-Integration und Bewertung
Random Forest Estimator	Scikit-learn-Entwickler	N/A	Random Forest Classifier zur rekursiven Merkmalsbeseitigung (RFE)
Scikit-learn	Scikit-learn-Entwickler	1.8.0	Maschinelles Lernbibliothek zur Vorverarbeitung, Merkmalsauswahl und Modellbewertung
Solidity Compiler (solc)	Solidity Team	0.8.19	Compiler zur Smart-Contract-Kompilierung und Bereitstellung
Solid-State Drive (SSD)	Dell	512 GB	Speicher für Datensätze, trainierte Modelle und Blockchain-Ledger
System Memory (RAM)	Dell	128 GB	Hauptspeicher für Vorverarbeitung, Modelltraining, Blockchain-Ausführung und Bewertung
TensorFlow	Google	2.16.1	Deep-Learning-Framework zur Implementierung und zum Training des erweiterten BiLSTM-Modells
UNSW-NB15 Dataset	UNSW Canberra Cyber	N/A	Öffentliches Benchmark-Datenset zur Trainings- und Bewertung
Web3.py	Web3.py-Entwickler	6.15.1	Python-Schnittstelle zur Kommunikation zwischen dem Intrusion-Detection-System und dem Blockchain-Netzwerk
Windows-Betriebssystem	Microsoft	Windows 11	Betriebssystem für alle Experimente
Workstation / Server	Dell	PowerEdge R740	Rechenplattform für Modelltraining, Blockchain-Bereitstellung und Bewertung