Rete di memoria bidirezionale a breve termine integrata in blockchain per il rilevamento in tempo reale delle intrusioni nell'Internet delle Cose Mediche nel settore sanitario

Summary

Questo protocollo descrive l'implementazione di un sistema di rilevamento di intrusioni di memoria a breve termine bidirezionale integrato nella blockchain per reti Internet delle Cose Mediche sanitarie, che consente il rilevamento di attacchi in tempo reale, la registrazione forense a prova di manomissione e la mitigazione automatica.

Abstract

Gli ambienti di Internet delle Cose Mediche (IoMT) nel settore sanitario richiedono sistemi di rilevamento delle intrusioni che non solo identifichino con precisione gli attacchi informatici, ma offrano anche responsabilità forense, revisione e capacità di risposta rapida. Gli approcci convenzionali di rilevamento delle intrusioni enfatizzano principalmente le prestazioni di classificazione, offrendo al contempo un supporto limitato per la registrazione degli eventi a prova di manomissione e per l'indagine post-incidente. Questo studio presenta un framework di rilevamento delle intrusioni consapevole della forense che integra una rete Bidirezionale Estesa a Long Short-Term Memory (BiLSTM) con uno strato blockchain autorizzato per supportare la rilevazione in tempo reale, la registrazione sicura e la mitigazione automatica nei sistemi IoMT sanitari. Il protocollo combina preprocessing dei dati, selezione delle funzionalità AQU-IMF-RFE, modellazione temporale delle sequenze, apprendimento basato sull'attenzione, connessioni residue e registrazione di eventi basata su blockchain. Il modello BiLSTM esteso è stato addestrato e valutato indipendentemente sui dataset benchmark UNSW-NB15, CICIDS2017 e Bot-IoT utilizzando preprocessing riproducibile, partizionamento stratificato dei dati e seed casuali fissi. Gli eventi di intrusione rilevati dal modello sono stati registrati su una blockchain Proof-of-Authority tramite smart contract che hanno permesso logging immutabile e azioni di risposta automatica. I risultati sperimentali hanno dimostrato elevate prestazioni di rilevamento dell'intrusione con bassi tassi di falsi positivi su tutti i dataset valutati, mantenendo al contempo la tracciabilità forense e la capacità di risposta in tempo reale. Il livello blockchain forniva registri di audit a prova di manomissione e mitigazione automatica senza introdurre un overhead computazionale proibitivo. Questi risultati dimostrano che integrare il rilevamento delle intrusioni basato sul deep learning con il logging forense abilitato dalla blockchain migliora l'affidabilità, la responsabilità e la possibilità di implementazione pratica dei sistemi di cybersecurity sanitaria.

Introduction

Nel sistema sanitario, la digitalizzazione ha portato a una nuova era di servizi sanitari intelligenti, connessi e centrati sul paziente. L'infrastruttura medica moderna si basa fortemente sulla comunicazione di rete e sullo scambio di dati tra sensori indossabili, sistemi di monitoraggio remoto dei pazienti, cartelle cliniche elettroniche (EHR^)1,2 e piattaforme diagnostiche intelligenti. Tuttavia, questa crescente interconnessione amplia anche la superficie di attacco delle reti sanitarie, esponendole a minacce informatiche come violazioni di dati, ransomware, attacchi DDoS distribuiti e attacchi^{man-in-the-middle 3}. Queste intrusioni comportano perdite finanziarie sostanziali e, cosa più importante, possono compromettere la sicurezza del paziente quando dati medici sensibili o funzionalità critiche del dispositivo vengono compromesse.

La scala e la complessità dei sistemi Internet of Medical Things (IoMT) aggravano ulteriormente queste sfide di sicurezza. Le reti sanitarie moderne devono fornire contemporaneamente comunicazioni a bassa latenza, alta affidabilità e garanzie di sicurezza robuste, requisiti che i meccanismi di sicurezza tradizionali spesso faticano a soddisfare⁴. La rapida crescita del traffico IoMT, caratterizzata da fonti di dati eterogenee, schemi di comunicazione dinamici e rigorosi requisiti normativi come il Health Insurance Portability and Accountability Act (HIPAA) e il General Data Protection Regulation (GDPR), richiede sistemi intelligenti di rilevamento intrusioni (IDS) in grado di raggiungere alti tassi di rilevamento minimizzando i falsi^{allarmi 5}.

Negli ambienti sanitari regolamentati, il rilevamento delle intrusioni non è solo un requisito operativo, ma anche una funzione di responsabilità. Gli avvisi di sicurezza possono attivare l'isolamento del dispositivo, compromettere la continuità dell'assistenza e successivamente diventare soggetti a audit, revisioni normative o indagini legali. Di conseguenza, un IDS IoMT efficace deve fornire una rilevazione accurata in tempo reale, decisioni spiegabili che supportino il triage degli incidenti e registrazioni a prova di manomissione che garantiscano la non ripudiazione e la tracciabilità^{forense 6}. Questo requisito sposta l'obiettivo del rilevamento delle intrusioni dalla classificazione incentrata sulle prestazioni a una governance della sicurezza incentrata sulla fiducia e sulla responsabilità.

Le tecniche di deep learning, in particolare le reti di Long Short-Term Memory (LSTM) e Bidirectional Long Short-Term Memory (BiLSTM), hanno dimostrato una forte capacità nel modellare le dipendenze temporali all'interno del traffico di rete e nel rilevare comportamenti anomali⁷. Tuttavia, gli IDS basati su BiLSTM esistenti spesso soffrono di sovrafitting, insufficiente attenzione agli eventi temporali critici e limitata generalizzazione tra dispositivi IoMT eterogenei e ambienti sanitari. Inoltre, le reti IoMT sono esposte a una vasta gamma di minacce informatiche che influenzano la Riservatezza, l'Integrità e la Disponibilità (CIA) dei dati e dei servizi medici, come riassunto nella Tabella 1.

Tipo di attacco	Contesto IoMT	Dimensione CIA colpita	Impatto sui sistemi sanitari
Accesso nonautorizzato 19	Sfruttamento di meccanismi di autenticazione deboli per accedere ai dispositivi dei pazienti o alle cartelle cliniche	Riservatezza, Integrità	Perdita di dati e controllo non autorizzato di dispositivi medici
Parodia /Impersonificazione 19	Un dispositivo malevolo imita un nodo IoMT legittimo	Integrità	Letture errate che possono portare a diagnosi errate o trattamenti insicuri
Origliare 21	Intercettazione di dati medici non criptati durante la trasmissione	Riservatezza	Violazioni della privacy ed esposizione di informazioni sensibili sui pazienti
Manipolazione dei dati / Exploit firmware19	Modifica del firmware del dispositivo o dei dati sanitari trasmessi	Integrità	Diagnosi errata o decisioni terapeutiche inappropriate
Ransomware20	Crittografia dei dati del paziente o firmware dei dispositivi medici	Disponibilità, Integrità	Blocco dei sistemi critici e ritardi nei trattamenti
Denial-of-Service (DoS) / Denial-of-Service distribuito (DDoS)6	Sovraccarico di dispositivi medici o reti sanitarie	Disponibilità	Interruzioni del servizio che influenzano i sistemi di monitoraggio e le operazioni delle unità di terapia intensiva (ICU)
Attacchi nel canalelaterale 22	Estrazione di chiavi crittografiche tramite tecniche di temporizzazione o analisi di potenza	Riservatezza	Compromessa del dispositivo e furto di chiavi crittografiche

Tabella 1: Attacchi informatici comuni che colpiscono gli ambienti sanitari dell'Internet delle Cose Mediche. Questa tabella riassume gli attacchi informatici rappresentativi che prendono di mira i sistemi Internet of Medical Things (IoMT), il loro contesto operativo, le dimensioni di sicurezza di Riservatezza, Integrità e Disponibilità (CIA) interessate e il loro potenziale impatto sull'erogazione delle cure sanitarie, la sicurezza dei pazienti e il funzionamento dei dispositivi medici.

La tecnologia blockchain offre diversi vantaggi che possono integrare il rilevamento delle intrusioni negli ambienti IoMT. Come riassunto nella Tabella 2, la blockchain consente la registrazione immutabile degli eventi per la validazione forense, facilita la mitigazione automatica tramite smart contract, elimina i singoli punti di guasto tramite operazioni decentralizzate e supporta la conformità alle normative sulla protezione dei dati sanitari mantenendo tracce di audit tracciabili. Nonostante questi benefici, i meccanismi di sicurezza basati su blockchain rimangono sottoutilizzati negli IDS sanitari.

Caratteristiche	Descrizione	Benefici nel contesto sanitario
Integrità dei Dati	Ogni transazione è crittograficamente hashata e collegata al blocco precedente	Garantisce l'immutabilità delle cartelle cliniche e dei dispositivi
Rilevamento di manomissioni	Qualsiasi modifica ai dati memorizzati modifica l'hash del blocco e invalida la catena	Consente il rilevamento rapido di modifiche non autorizzate dei record
Controllo degli accessi	Gli smart contract fanno rispettare permessi predefiniti e politiche di autorizzazione	Restringe l'accesso alle informazioni sanitarie sensibili agli utenti autorizzati e ai dispositivi
Provenienza dei dati	Ogni evento è firmato digitalmente e con timestamp	Supporta la tracciabilità forense, la revisione e la conformità normativa
Consenso a bassa latenza	Il meccanismo di consenso Proof-of-Authority (PoA) consente una validazione rapida delle transazioni con un overhead computazionale inferiore rispetto alla Proof-of-Work	Supporta la registrazione degli eventi quasi in tempo reale in ambienti sanitari critici

Tabella 2: Benefici della tecnologia blockchain per la sanità Internet delle Cose Mediche sistemi di rilevamento intrusioni. Questa tabella riassume le principali funzionalità blockchain e i loro benefici associati negli ambienti sanitari dell'Internet delle Cose Mediche (IoMT). Le capacità elencate supportano la registrazione immutabile, il rilevamento di manomissioni, il controllo degli accessi, la provenienza dei dati e meccanismi di consenso a bassa latenza necessari per un rilevamento sicuro e auditabile dell'intrusione.

Oltre alla valutazione delle prestazioni, l'integrazione blockchain offre protezione contro molteplici minacce alla sicurezza negli ambienti IoMT. La Tabella 3 riassume i punti di forza e i limiti della blockchain in questo contesto, evidenziando minacce che sono efficacemente mitigate, come la manomissione e la ripudiazione dei dati, e le minacce che richiedono ulteriori salvaguardie. Il livello blockchain supporta logging a bassa latenza adatto agli ambienti sanitari in tempo reale, resilienza bizantina contro nodi difettosi o dannosi, e scalabilità su reti ospedaliere distribuite e dispositivi IoMT.

Minaccia alla sicurezza	Risolto dalla blockchain?	Meccanismo	Note
Manomissione dei dati27	Sì	Collegamento crittografico degli hash	Qualsiasi modifica invalida l'integrità della catena
Ripudio 26	Sì	Firme digitali associate a ogni blocco	Previene la negazione degli eventi di intrusione registrati
Guastocentralizzato 25	Sì	Registro distribuito mantenuto tra gateway autorizzati	Elimina un singolo punto di guasto
Attacco Sybil24	Parziale	Consenso procuratoriale autorizzato che richiede validatori affidabili	Può essere mitigato tramite l'autorizzazione del validatore basata sull'identità
51%Attacco 23	Parziale	Richiede la compromessa della maggioranza dei validatori autorizzati	Meno probabile nelle implementazioni private di blockchain PoA
Data Provenance26	Sì	Record degli eventi con timestamp e firmati digitalmente	Supporta la tracciabilità forense e la conformità normativa

Tabella 3: Minacce alla sicurezza affrontate dall'integrazione blockchain negli ambienti sanitari Internet of Medical Things. Questa tabella riassume le principali minacce alla sicurezza rilevanti per i sistemi dell'Internet delle Cose Mediche (IoMT) e indica fino a che punto la tecnologia blockchain mitighi ciascuna minaccia. I meccanismi di protezione sottostanti e le considerazioni di implementazione sono forniti per ciascuna categoria di minaccia.

La maggior parte degli IDS esistenti si basa su regole predefinite o su modelli di apprendimento automatico^{leggeri 8,9}. Sebbene tali approcci possano identificare schemi di attacco noti, spesso faticano a far fronte alla natura dinamica e in evoluzione delle minacce informatiche moderne. Sono particolarmente inadeguati per garantire infrastrutture sanitarie basate sull'IoMT in rapida crescita, dove falsi allarmi, limitata adattabilità e scarsa revisionibilità possono influire significativamente sull'efficienza operativa. I sistemi basati su regole generano frequentemente alti tassi di falsi positivi perché non riescono a distinguere in modo affidabile anomalie benigne da attacchi reali⁹. I modelli convenzionali di apprendimento automatico addestrati su dataset statici o obsoleti, così come gli approcci esistenti di rilevamento di intrusioni basati sul deep learning, spesso non generalizzano i comportamenti di attacco emergenti, inclusi gli intrusioni^{zero-day 10,11}. Inoltre, gli approcci tradizionali di logging centralizzato rimangono vulnerabili alle manomissioni, limitando così l'affidabilità delle indagini forensi^{post-incidenti 12}. Molte soluzioni IDS esistenti impongono anche un notevole overhead computazionale, rendendole difficili da implementare su dispositivi IoMT e gateway¹³ con risorse limitate. Di conseguenza, gli ambienti IoMT sanitari rimangono vulnerabili a attacchi informatici sofisticati e multistadio. Affrontare queste sfide richiede un framework intelligente, sicuro ed efficiente dal punto di vista delle risorse, capace di apprendere i modelli temporali del traffico in tempo reale, garantendo al contempo l'affidabilità forense e la mitigazione automatica delle minacce rilevate.

Nonostante i significativi progressi nel machine learning e nel rilevamento delle intrusioni basato su deep learning, rimangono diverse lacune critiche. Innanzitutto, molti modelli IDS esistenti vengono sviluppati e valutati utilizzando dataset statici e quindi mancano di adattabilità ai comportamenti di attacco in continua evoluzione. In secondo luogo, sebbene le architetture avanzate di deep learning possano migliorare la precisione del rilevamento, spesso offrono un'interpretabilità limitata e non danno priorità ai modelli di traffico clinicamente importanti. In terzo luogo, e più importante, i quadri IDS attuali generalmente non forniscono un supporto intrinseco per l'affidabilità forense, l'auditabilità o la tenuta immutabile dei registri, capacità essenziali per la conformità normativa, l'indagine sugli incidenti e la responsabilità legale nei sistemi sanitari.

Sebbene i meccanismi di logging basati su blockchain forniscano integrità e trasparenza dei dati, raramente sono integrati in modo coerente con modelli avanzati di rilevamento di intrusioni basati su deep learning in ambienti IoMT sensibili alla latenza. Gli studi esistenti si concentrano tipicamente sul miglioramento delle prestazioni di rilevamento senza affrontare l'integrità forense, oppure su meccanismi di sicurezza basati su blockchain senza incorporare una rilevazione avanzata delle anomalie temporali. Di conseguenza, rimane una lacuna significativa nello sviluppo di un framework unificato in grado di offrire simultaneamente rilevamento di intrusioni spazio-temporali in tempo reale, registrazione forense a prova di manomissione, mitigazione automatica e implementazione pratica in ambienti sanitari IoMT eterogenei e limitati in risorse.

Motivato da queste sfide, questo studio mira a sviluppare un framework di rilevamento delle intrusioni che migliori le reti BiLSTM attraverso meccanismi di attenzione e strati personalizzati per una migliore priorità temporale delle caratteristiche, integri la tecnologia blockchain per un logging di intrusioni sicuro e verificabile e una risposta automatizzata, e operi in modo efficiente in contesti sanitari IoMT in tempo reale. Ipotizziamo che integrare un'architettura BiLSTM estesa migliorata con attenzione con la registrazione forense basata su blockchain e meccanismi automatizzati di mitigazione migliorerà l'efficacia del rilevamento delle intrusioni, fornendo allo stesso tempo l'auditabilità, l'affidabilità e la responsabilità richieste negli ambienti sanitari regolamentati.

Questo lavoro affronta una lacuna fondamentale nella ricerca sulla sicurezza dell'IoMT, trattando il rilevamento delle intrusioni come un problema di responsabilità forense piuttosto che solo come un problema di classificazione. Il framework proposto integra il rilevamento guidato dall'intelligenza artificiale (IA), la registrazione immutabile degli eventi e i meccanismi di risposta automatica in un'architettura unificata che supporta la sicurezza clinica, la conformità normativa e la fiducia operativa. La crescente adozione di dispositivi IoMT e infrastrutture sanitarie connesse al cloud ha reso le reti sanitarie bersagli attraenti per attacchi informatici, inclusi ransomware, manipolazione dei dati, accessi non autorizzati e attacchi di denial-of-service che minacciano la riservatezza, l'integrità e la disponibilità delle informazioni dei pazienti. Il framework proposto Extended BiLSTM–Blockchain stabilisce un processo di sicurezza a ciclo chiuso che collega direttamente il rilevamento degli attacchi alla validazione forense e alla mitigazione automatica.

I principali contributi di questo studio sono cinque. Innanzitutto, viene sviluppato un modello di rilevamento dell'intrusione temporale allineato clinicamente estendendo un'architettura BiLSTM convenzionale con apprendimento temporale bidirezionale, connessioni residue, meccanismi di attenzione e strati personalizzati per migliorare la rilevazione di pattern di attacco complessi nel traffico delle reti sanitarie. In secondo luogo, uno strato di sicurezza leggero basato su blockchain è integrato con il modello BiLSTM Esteso per fornire una registrazione immutabile, sicura e a prova di manomissione degli eventi di intrusione e delle azioni di sistema. In terzo luogo, è stata sviluppata una pipeline IDS end-to-end in tempo reale per ambienti sanitari, che consente analisi del traffico in tempo reale e previsione delle intrusioni con bassa latenza e alta precisione. In quarto luogo, il framework proposto viene valutato in modo completo utilizzando tre dataset benchmark pubblicamente disponibili, ovvero UNSW-NB15, CICIDS2017 e Bot-IoT. Infine, l'architettura è progettata come un framework edge-cloud scalabile ed estesibile adatto per una distribuzione pratica in reti sanitarie, infrastrutture mediche e applicazioni e-health.

Combinando le capacità di apprendimento temporale delle reti BiLSTM estese con la fiducia e l'immutabilità offerte dalla tecnologia blockchain, il framework proposto offre un IDS sicuro e affidabile, adattato alle esigenze di cybersecurity in evoluzione degli ambienti sanitari. Il quadro colma le lacune critiche nella sicurezza delle reti sanitarie e stabilisce le basi per un'adozione più ampia dell'integrazione di IA e blockchain nella protezione delle infrastrutture sanitarie critiche.

Protocol

Tutti gli esperimenti sono stati condotti esclusivamente utilizzando dataset di benchmark di intrusione di rete pubblicamente disponibili (UNSW-NB15, CIC-IDS-2017 e Bot-IoT), che contengono registri del traffico di rete senza informazioni personali o mediche identificabili. I dataset sono stati utilizzati in conformità con le rispettive licenze e i termini di utilizzo. Poiché non erano coinvolti partecipanti umani, campioni di pazienti o dati personali identificabili, non erano necessarie l'approvazione etica istituzionale e il consenso informato.

Panoramica del Quadro Proposto
Questa sezione presenta il framework proposto per il rilevamento e la prevenzione dell'intrusione a doppio livello per la sicurezza degli ambienti IoMT. Il framework integra una rete BiLSTM estesa per il rilevamento di intrusioni spazio-temporali con uno strato blockchain leggero per la registrazione a prova di manomissioni e mitigazione automatica. A differenza degli approcci IDS convenzionali che si concentrano esclusivamente sulla precisione del rilevamento, l'architettura proposta è progettata per supportare contemporaneamente la rilevazione in tempo reale, la responsabilità forense e la conformità normativa, requisiti essenziali nei sistemi sanitari. Il flusso di lavoro complessivo e l'architettura del framework proposto per il rilevamento delle intrusioni BiLSTM–Blockchain Extended per le reti IoMT sono illustrati nella Figura 1.

Figura 1. Architettura del framework proposto per il rilevamento di intrusioni Extended BiLSTM–Blockchain per reti Internet of Medical Things. Rappresentazione schematica del framework proposto che mostra i flussi di lavoro di formazione e implementazione. Nel flusso di lavoro di addestramento, i dispositivi Internet of Medical Things (IoMT) generano traffico di rete che subisce preprocessing dati e ingegneria delle funzionalità prima di essere analizzato con attenzione temporale dal modello Extended Bidirectional Long Short-Term Memory (BiLSTM). I parametri del modello sono ottimizzati tramite calcolo della funzione di perdita e addestramento iterativo. Nel flusso di lavoro di implementazione, il modello addestrato esegue il rilevamento delle intrusioni secondo la funzione decisionale definita nell'Equazione 13. Gli eventi di intrusione rilevati vengono inoltrati al modulo blockchain, dove vengono effettuati logging immutabili, isolamento dei nodi e generazione di avvisi da parte degli amministratori. BiLSTM, Memoria Bidirezionale a Breve Termine; IoMT, Internet delle cose mediche. Clicca qui per visualizzare una versione più grande di questa figura.

I dispositivi IoMT generano flussi di dati eterogenei costituiti da traffico di rete, metadati dei dispositivi e segnali relativi al paziente. Tali input grezzi sono spesso rumorosi, ridondanti e incoerenti, rendendoli inadatti all'addestramento diretto del modello. Pertanto, viene applicata una pipeline di preprocessing per garantire la qualità e la struttura dei dati prima di inserirli nel modello Extended BiLSTM. Il pseudocodice dettagliato della preprocessing è fornito nell'Algoritmo 1 (File Supplementare 1), che delinea la pipeline di preprocessing applicata ai flussi dati IoMT prima dell'addestramento BiLSTM Esteso (pseudocodice nel File Supplementare 1; implementazione nel File Supplementare 2). L'architettura completa di BiLSTM estesa è riassunta nell'Algoritmo 2 (Supplementary File 1).

Flusso di lavoro di riproduzione end-to-end
Lo studio completo può essere riprodotto utilizzando i passaggi seguenti. Software e hardware sono elencati nell'Ambientazione Sperimentale, e il codice supplementare copre ogni passaggio.

Scarica i dataset → scarica UNSW-NB15. Usa i file UNSW_NB15_training-set.csv e UNSW_NB15_testing-set.csv. Scarica CICIDS2017. Usa i cinque file giornalieri MachineLearningCSV (dal lunedì al venerdì). Scarica Bot-IoT. Usa i file del sottoinsieme al 5% UNSW_2018_IoT_Botnet_Full5pc_1_to_4. I precedenti studi di rilevamento delle intrusioni si basavano comunemente su dataset benchmark come KDD Cup 99,¹⁴; tuttavia, questo studio utilizza i più recenti dataset UNSW-NB15, CICIDS2017 e Bot-IoT per rappresentare meglio il traffico di rete contemporaneo. Elabora ogni dataset separatamente. Il dataset UNSW-NB15 è disponibile presso l'Università del New South Wales a https://research.unsw.edu.au/projects/unsw-nb15-dataset (ultima modifica: 8 febbraio 2024). Il dataset CICIDS2017 è disponibile presso il Canadian Institute for Cybersecurity al https://www.unb.ca/cic/datasets/ids-2017.html (rilasciato: luglio 2017). Il dataset Bot-IoT è disponibile presso l'Università del New South Wales a https://research.unsw.edu.au/projects/bot-iot-dataset (ultima modifica: 5 febbraio 2024). Tutti i dataset sono stati consultati a maggio 2025 per questo studio.

Pre-elaborare i dati → rimuovere i record corrotti. Riempire i valori mancanti usando mezzi dell'allenamento. Applicare la riduzione del rumore EMA (α = 0,3). Normalizzare le caratteristiche a [0,1] utilizzando statistiche degli insiemi di addestramento. Campi categoriali con etichetta e codifica. Costruisci finestre scorrevoli (T = 20, passo = 1). Questi passaggi di preprocessing supportano una rilevazione robusta delle intrusioni riducendo il rumore e migliorando la qualità delle rappresentazioni del traffico di rete per gli IDS basati su apprendimento^{automatico 15,16}.

Seleziona le caratteristiche (AQU-IMF-RFE) → Classifica le caratteristiche tramite informazioni comuni. Affina con l'Aquila Optimizer. Applicare la RFE Random Forest con validazione incrociata a 10 volte. Conserva le caratteristiche finali. Questa strategia ibrida di selezione delle caratteristiche segue il concetto più ampio di combinare tecniche complementari di rilevamento^{intrusioni 17} ed è implementata utilizzando il framework AQU-IMF-RFE sviluppato nel nostro lavoro^{precedente 18}.

Addestrare il modello → Per ogni dataset, i dati sono stati suddivisi casualmente in set di addestramento (80%) e test (20%) utilizzando un seed casuale fisso di 42. Il venti percento della partizione di addestramento era ulteriormente riservato come set di validazione. Costruisci il BiLSTM esteso. Allenarsi usando perdita binaria di entropia incrociata ponderata e l'ottimizzatore Adam (tasso di apprendimento = 0,001, dimensione del lotto = 64, massimo di 50 epoche, con fermata anticipata). Salva il modello addestrato. L'uso di modelli di deep learning temporale è ben adatto al traffico eterogeneo^{IoMT 19}. Il flusso di lavoro completo dell'addestramento del modello è riassunto nell'Algoritmo 3 (File Supplementare 1). I pesi finali delle classi venivano calcolati automaticamente dalle distribuzioni delle classi del set di addestramento secondo le Equazioni 19 e 20. I pesi di classe risultanti furono i seguenti: UNSW-NB15: , ; CICIDS2017: , ; e Bot-IoT (sottoinsieme del 5%): , . Il grande valore di w_n per il dataset Bot-IoT riflette la grave sottorappresentazione di campioni benigni nella partizione di addestramento del sottoinsieme del 5%.

Implementare la blockchain → avviare la catena di Proof-of-Authority (PoA). Installa lo smart contract e annota il suo indirizzo. Autorizza gli account gateway. Esegui il client in modo che ogni intrusione rilevata venga registrata e attivi isolamenti e allarmi. Il flusso di lavoro completo di rilevamento, registrazione della blockchain e mitigazione è riassunto nell'Algoritmo 4 (File Supplementare 1). Il livello blockchain è stato implementato utilizzando il client go-ethereum (Geth) versione 1.13.15 per gestire la rete PoA autorizzata, il compilatore Solidity (solc) versione 0.8.19 per la compilazione e distribuzione di smart contract e la libreria web3.py versione 6.15.1 per la comunicazione tra IDS e la rete blockchain.

Valuta → Testa il modello sul set di test esposto. Calcolare accuratezza, precisione, richiamo, punteggio F1 e tasso di falsi positivi. Registrare latenza e throughput. Verifica l'integrità del registro blockchain. Il flusso di lavoro completo della valutazione è riassunto nell'Algoritmo 5 (File Supplementare 1). La latenza di rilevamento (T_d) è stata misurata immediatamente prima della chiamata di inferenza del modello fino al momento in cui sono state restituite le probabilità previste. La latenza di mitigazione end-to-end (T_d +_{T b}) è stata misurata dallo stesso punto di partenza fino al completamento della corrispondente transazione di creazione di blocchi blockchain. La velocità di lavoro veniva calcolata come il numero totale di finestre di test preprocessate elaborate dalla pipeline completa di rilevamento e registrazione, diviso per il tempo di orologio a muro trascorso per un singolo passaggio completo attraverso il set di test di ciascun dataset. Il carico di lavoro consisteva nelle partizioni di test a finestre mantenendo la distribuzione originale di classi benigna all'intrusione. Le finestre dannose comportavano inoltre il sovraccarico di logging blockchain, mentre le finestre innocue sostenevano solo il costo di rilevamento intrusione.

Generare figure e tabelle → tracciare le curve di accuratezza e perdita, la matrice di confusione e i grafici di valutazione comparativa. Costruisci le tabelle di confronto. Il flusso di lavoro completo di generazione di figure e tabelle è riassunto nell'Algoritmo 6 (File Supplementare 1). Il codice sorgente completo sviluppato su misura utilizzato per generare tutte le figure e le tabelle è fornito nel Supplementary File 2. In particolare, lo script figures.py riproduce direttamente le figure del manoscritto dai risultati sperimentali salvati (ad esempio, cronologia dell'addestramento e file di matrice di confusione), mentre gli script rimanenti generano i dati elaborati e le metriche di performance utilizzate per costruire le tabelle riportate.

La Figura 2 è il flusso di dati a livello di implementazione tra i moduli IDS e blockchain. La BiLSTM estesa produce una decisione per finestra (Equazione 13); su una classificazione malevola, il client gateway costruisce e firma una transazione e la invia tramite web3/JSON-RPC allo smart contract PoA, che aggiunge un blocco hash-linked (Equazione 14) al registro immutabile ed emette eventi (BlockCreated, NodeIsolated e AdminAlert) che attivano l'isolamento dei nodi e gli avvisi degli amministratori.

Figura 2. Interazione a livello di implementazione tra il rilevamento intrusioni e i moduli blockchain. Diagramma del flusso di lavoro che illustra la comunicazione tra il sistema di rilevamento intrusioni e i componenti blockchain. Il modello BiLSTM esteso classifica ogni finestra di input e applica la regola decisionale definita nell'Equazione 13. Quando viene rilevata un'intrusione, il client gateway genera e firma una transazione che viene trasmessa tramite Web3.py/JSON-RPC allo smart contract Proof-of-Authority (PoA). Il contratto aggiunge un blocco collegato a hash al registro immutabile secondo l'Equazione 14 ed emette eventi BlockCreated, NodeIsolated e AdminAlert che attivano azioni di contenimento e notifica. IDS, Sistema di Rilevamento Intrusioni; BiLSTM, Memoria Bidirezionale a Breve Termine; Procura, Prova di autorità; JSON-RPC, JavaScript Object Notation–Chiamata procedura remota. Clicca qui per visualizzare una versione più grande di questa figura.

Rappresentazione dei dati
Consideriamo R come il flusso grezzo di traffico IoMT. Dopo la preelaborazione, ogni record grezzo viene mappato in un vettore di caratteristiche normalizzato a d dimensioni (Equazione 1):

(1)

Qui, f (⋅) è la funzione di trasformazione delle caratteristiche che mappa i record grezzi in un vettore di caratteristiche normalizzato a d dimensioni. Sia la rete IoMT composta da un insieme di nodi (Equazione 2):

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

Ogni nodo _{n j} ∈ R produce un flusso di dati a serie temporale (Equazione 3):

(3)

Qui, x_t è il vettore di caratteristiche al tempo t, con d caratteristiche (ad esempio, dimensione del pacchetto, tipo di protocollo, indirizzo di origine/destinazione) comunemente osservate nel traffico di rete sanitaria^{dell'Internet delle Cose 19}. L'insieme corrispondente di etichette è (Equazione 4):

  (4)

Qui, y_t=0 rappresenta il traffico normale e y_t =1 indica un'intrusione.

Preprocessing dei dati
La pipeline di preprocessing include i seguenti passaggi, che affrontano le sfide comuni di qualità dei dati e di sicurezza associate al traffico^{IoMT 20}:

Pulizia dei dati e gestione dei valori mancanti:
Un record veniva identificato come corrotto e rimosso prima dell'imputazione se soddisfava una delle seguenti condizioni esplicite: (i) tutti i campi di caratteristica nel record erano mancanti (cioè, l'intero record era nullo), oppure (ii) il record conteneva un valore non finito (infinito positivo o negativo) in qualsiasi campo numerico dopo il tipo coercizione. La seconda regola rimuove voci non valide come quelle prodotte dalla divisione per zero durante il calcolo delle caratteristiche di flusso (ad esempio, valori infiniti di portata derivanti da flussi a durata zero). Dopo la rimozione dei record corrotti, i valori mancanti rimanenti venivano imputati tramite la sostituzione media calcolata per caratteristica, per dataset e solo dalla partizione di addestramento; I mezzi risultanti venivano applicati ai set di addestramento, validazione e test per prevenire la fuga di informazioni. L'imputazione non era condizionata alla classe e le medie non venivano aggregate tra i dataset.

Deruoting temporale:
La denoising temporale è stata eseguita utilizzando un filtro a media mobile esponenziale per caratteristica (EMA) applicato lungo l'asse temporale. È stata utilizzata la forma ricorsiva (causale ) y_t = α·x_t + (1 − α)·y_t−1 , con fattore di levigatura α = 0,3, implementata tramite la funzione ewm di pandas con adjust=False. Ogni caratteristica è stata smussata in modo indipendente. Come filtro esponenziale (risposta infinita all'impulso), l'EMA non ha una finestra o una dimensione del kernel fissa; Il fattore di levigatura α è il singolo parametro che regola il grado di levigatura e la memoria effettiva del filtro.

Normalizzazione Min–Max:
La normalizzazione min–max è stata applicata per scalare ogni caratteristica nell'intervallo [0,1] usando la trasformazione x′=(x−min)/(max−min+ε), dove ε = 1 × 10⁻⁸. Le statistiche minime e massime venivano calcolate per caratteristica, per dataset e solo dalla partizione di addestramento; Queste statistiche di addestramento memorizzate venivano poi applicate per normalizzare i set di addestramento, validazione e test, prevenendo la fuga di informazioni nascoste. Durante l'inferenza, i valori delle caratteristiche che uscivano dal campo di addestramento venivano ritagliati all'intervallo [0,1].

Codifica delle caratteristiche categoriche:
Le caratteristiche categoriche venivano convertite in forma numerica tramite codifica di etichette. Questo era applicato a tutte le variabili categoriche: in UNSW-NB¹⁵, i campi proto, servizio e stato; in Bot-IoT, il proto campo; CICIDS2017 non contiene campi categorici tra le caratteristiche selezionate. La codifica era implementata con LabelEncoder per variabile.

Finestra temporale per l'apprendimento sequenziale:
Il flusso di caratteristiche preelaborato è stato segmentato in sequenze di lunghezza fissa usando una finestra scorrevole di lunghezza T = 20 passi temporali con un passo di s = 1. Ogni finestra generata è stata validata prima dell'inclusione. Una finestra veniva accettata solo se conteneva esattamente T = 20 passi temporali consecutivi e tutti i valori delle caratteristiche erano finiti. I flussi più brevi di T = 20 record non producevano finestre. Questa configurazione (T = 20, s = 1, sovrapposizione al 95%) è stata applicata in modo coerente in tutti gli esperimenti e dataset. L'intero flusso di lavoro di preprocessing è riassunto nell'Algoritmo 1 (File Supplementare 1).

L'obiettivo della pre-elaborazione è consentire una mappatura predittiva dalle sequenze di input alle etichette di intrusione (Equazione 5).

(5)

parametrizzato da θ, che prevede se un evento sia benigno o malevolo.

Selezione delle caratteristiche tramite AQU-IMF-RFE
La selezione delle caratteristiche è stata effettuata utilizzando AQU-IMF-RFE, un metodo ibrido che integra Mutual Information (MI), l'Aquila Optimizer (AO) e la Recursive Feature Elimination (RFE), introdotti nel nostro lavoro^{precedente 18}. Il metodo funziona in tre fasi. Nella prima fase, l'informazione reciproca tra ogni caratteristica e l'etichetta della classe viene calcolata per ottenere una classifica iniziale di rilevanza. Nella seconda fase, l'Aquila Optimizer esegue una ricerca globale sui sottoinsiemi di caratteristiche candidate utilizzando le sue quattro strategie di ottimizzazione. Nella terza fase, il sottoinsieme raffinato viene passato attraverso l'eliminazione delle caratteristiche ricorsive con una validazione incrociata a 10 volte utilizzando uno stimatore Random Forest (RF).

L'Aquila Optimizer era configurato con una popolazione di 100 persone, un massimo di 10 iterazioni, un fattore di sfruttamento di 0,1, un tasso di apprendimento di 0,1 e un fattore di attrazione di 0,005. Applicato indipendentemente a ciascun dataset, AQU-IMF-RFE ha mantenuto 14 funzionalità per UNSW-NB15, 24 per CICIDS2017 e 12 per Bot-IoT. Il pseudocodice completo è fornito nel File Supplementare 1, e i sottoinsiemi di caratteristiche selezionati sono elencati nella Tabella 4.

Tabella 4A. Caratteristiche selezionate mantenute per UNSW-NB15
S. No.	Caratteristiche	Tipo	Categoria
1	dur	Numerico (float)	Base
2	sbytes	Numerico (intero)	Base
3	Tasso	Numerico (float)	Base
4	dload	Numerico (float)	Base
5	sinpkt	Numerico (float)	Tempo
6	Dinpkt	Numerico (float)	Tempo
7	sjit	Numerico (float)	Tempo
8	TCPrtt	Numerico (float)	Tempo
9	Sinack	Numerico (float)	Tempo
10	ackdat	Numerico (float)	Tempo
11	Smean	Numerico (intero)	Contenuto
12	ct_srv_src	Numerico (intero)	Collegamento
13	ct_dst_src_ltm	Numerico (intero)	Collegamento
14	ct_srv_dst	Numerico (intero)	Collegamento
Tabella 4B. Caratteristiche selezionate mantenute per CICIDS2017
S. No.	Caratteristiche
1	Porto di destinazione
2	Durata del flusso
3	Lunghezza totale dei pacchetti forwardi
4	Lunghezza totale dei pacchetti al contrario
5	Lunghezza massima del pacchetto in volontà
6	Lunghezza massima del pacchetto all'indietro
7	Lunghezza dei pacchetti media a ritroso
8	Pacchetti di flusso
9	Tempo massimo di interarrivo del flusso
10	Tempo Avanti Totale Inter-Arrivo
11	Lunghezza del colpo di testa in avanti
12	Lunghezza dell'intestazione all'indietro
13	Pacchetti in avanti al secondo
14	Lunghezza massima del pacchetto
15	Media della lunghezza del pacchetto
16	Deviazione standard della lunghezza del pacchetto
17	Varianza della lunghezza dei pacchetti
18	Dimensione media del pacchetto
19	Dimensione media dei segmenti al contrario
20	Byte in avanti del sottoflusso
21	Byte all'indietro del sottoflusso
22	Byte iniziali della finestra in avanti
23	Bytes iniziali della finestra al contrario
24	Lunghezza media del pacchetto in avanti
Tabella 4C. Funzionalità selezionate mantenute per Bot-IoT
S. No.	Caratteristiche	Tipo
1	seq	Numerico
2	Mean	Numerico
3	StdDev	Numerico
4	min	Numerico
5	Max	Numerico
6	Srate	Numerico (float)
7	drate	Numerico (float)
8	N_IN_Conn_P_SrcIP	Numerico (intero)
9	N_IN_Conn_P_DstIP	Numerico (intero)
10	proto	Categorico (codificato)
11	state_number	Numerico (intero)
12	Tasso	Numerico (float)

Tabella 4: Caratteristiche selezionate dal metodo di selezione delle caratteristiche AQU-IMF-RFE. Questa tabella elenca i sottoinsiemi finali di caratteristiche selezionati dal framework di selezione delle caratteristiche AQU-IMF-RFE per i dataset UNSW-NB15, CICIDS2017 e Bot-IoT. Sono forniti nomi di funzionalità, tipi di dati e categorie funzionali dove applicabile.

Configurazione sperimentale
Tutti gli esperimenti sono stati condotti su un server Dell PowerEdge R740 dotato di processore Intel Xeon Silver 4214 che operava a una frequenza base di 2,20 GHz, con 12 core fisici, 24 thread logici, 16,5 MB di cache e una velocità Intel Ultra Path Interconnect (UPI) di 9,6 GT/s. Il server era configurato con 128 GB di RAM, un disco SSD (SSD) da 512 GB e funzionava su Microsoft Windows 11. Lo stack software comprendeva Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 e NumPy 2.4.4. Il livello blockchain è stato implementato sulla stessa workstation utilizzando una rete Ethereum PoA. La comunicazione tra IDS e blockchain veniva effettuata tramite JSON-RPC utilizzando il client go-ethereum (Geth) versione 1.13.15, il compilatore Solidity (solc) versione 0.8.19 per la compilazione e distribuzione degli smart contract e la libreria Web3.py versione 6.15.1. Su questa configurazione hardware e software venivano misurati i tempi di addestramento, la latenza di inferenza e la velocità di addestramento.

Architettura dei modelli e formazione
Il modello BiLSTM esteso costituisce la componente principale di rilevamento del framework, basandosi su approcci precedenti di rilevamento di intrusione basati sull'apprendimento sviluppati per gli ambienti^{IoMT 21}. Studi precedenti di rilevamento delle intrusioni hanno evidenziato sia l'importanza di bilanciare le prestazioni di rilevamento con la riduzione dei falsi^{allarmi 15} sia le sfide uniche nell'applicare metodi di apprendimento automatico al traffico di rete^{in evoluzione 16}. Le architetture collaborative di rilevamento intrusione su reti neurali hanno ulteriormente dimostrato il valore dell'apprendimento sequenziale profondo delle caratteristiche per il traffico di rete^{complesso 22}. Mentre i modelli standard BiLSTM catturano dipendenze temporali bidirezionali, il traffico IoMT mostra sia schemi di burst a breve termine sia dipendenze a lungo raggio causate da attacchi multistadio. Per affrontare questo problema, il modello proposto estende BiLSTM con estrazione di caratteristiche temporali, apprendimento temporale bidirezionale migliorato, connessioni residue e priorità temporale basata sull'attenzione. Le LSTM bidirezionali (BiLSTM) superano questa limitazione combinando stati nascosti avanti e indietro, consentendo una rappresentazione temporale più ricca dei modelli di traffico IoMT, come indicato nell'Algoritmo 2 (File Supplementare 1).

Sia la sequenza di input X^{(_{n j})} = {_{x 1} , x₂ , ... , x_T }, dove ogni x_t ∈ R^d è un vettore di caratteristiche preelaborato.

Estrazione di caratteristiche temporali:
Una convoluzione leggera monodimensionale viene applicata attraverso la dimensione temporale per enfatizzare anomalie temporali a corto raggio (Equazione 6):

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

Qui, φ(⋅) è una funzione di attivazione non lineare e le caratteristiche convolute u_t vengono inviate al BiLSTM.

Il livello Conv1D estrae schemi temporali a corto raggio prima della modellazione bidirezionale delle sequenze. I parametri completi di implementazione sono forniti nel File Supplementare 3B.

Apprendimento LSTM bidirezionale impilato:
Gli stati nascosti avanti e indietro sono calcolati come (Equazione 7):

(7)

La rappresentazione finale della BiLSTM è la concatenazione degli stati nascosti passati (avanti) e futuri (indietro) (Equazione 8).

(8)

Due strati BiLSTM impilati modellano dipendenze temporali bidirezionali. I parametri architettonici dettagliati sono forniti nel File Supplementare 3B. I dettagli sull'inizializzazione dei pesi sono forniti nel Supplementare File 3B.

Connessione residua e normalizzazione
Dopo la proiezione lineare a dimensioni corrispondenti, si applicano connessioni residue e normalizzazione degli strati (Equazione 9):

La proiezione residua e la normalizzazione degli strati allineano le rappresentazioni convoluzionali e BiLSTM prima dell'attenzione. I parametri dettagliati di implementazione sono forniti nel Supplementary File 3B.

Meccanismo di attenzione
Sebbene BiLSTM fornisca una solida modellazione temporale, non tutti i passi temporali contribuiscono in modo uguale alla previsione. Per enfatizzare timestamp critici (ad esempio, picchi anomali improvvisi), viene introdotto un meccanismo di attenzione. A ogni stato nascosto viene assegnato un punteggio di rilevanza α_t per aumentare la precisione del rilevamento (Equazione 10).

Qui, W_a è un parametro allenabile e i pesi di attenzione soddisfano

Il vettore di contesto c aggrega gli stati nascosti in base alla loro importanza appresa (Equazione 11):

Il meccanismo dell'attenzione aggrega le rappresentazioni temporali in un vettore contestuale. I parametri dettagliati di implementazione sono forniti nel Supplementary File 3B.

Livello di Output e Classificazione
Il vettore contesto aggregato viene passato attraverso uno strato completamente connesso seguito da un'attivazione sigmoidea per ottenere la previsione finale (Equazione 12):

Qui, W_c e b_c sono parametri addestrabili, e σ(·) è la funzione di attivazione sigmoide che mappa l'uscita all'intervallo [0,1]. Si applica una soglia per classificare il traffico come benigno () o intrusivo ().

La regolarizzazione del dropout e la soglia di classificazione fissa utilizzata durante l'inferenza sono descritte nel File Supplementare 3B.

L'architettura Extended BiLSTM è identica nei tre dataset; solo la dimensione delle caratteristiche di input differisce, assumendo valori di 14, 24 e 12 rispettivamente per UNSW-NB15, CICIDS2017 e Bot-IoT. Poiché il livello Conv1D mappa qualsiasi input -dimensionale a una rappresentazione fissa a 64 canali, tutti i livelli successivi sono indipendenti dal dataset, e solo la forma in input e il conteggio dei parametri Conv1D variano con . L'architettura completa livello per livello è riassunta nella Tabella 5, con i conteggi dei parametri espressi in termini di d; I totali risultanti sono rispettivamente 184.641, 186.561 e 184.257 parametri addestrabili per D = 14, D = 24 e D = 12.

S. No.	Livello (Tipo)	Forma di uscita	Parametri addestrabili	Funzione di attivazione
1	Input	(20, d)	0	—
2	Conv1D (64 filtri, dimensione del nucleo = 3, stesso imbottitura)	(20, 64)	192d + 64	ReLU
3	LSTM bidirezionale Layer 1 (64 unità per direzione)	(20, 128)	66,048	tanh / sigmoid
4	LSTM Bidirezionale Layer 2 (64 unità per direzione)	(20, 128)	98,816	tanh / sigmoid
5	Proiezione residua densa	(20, 128)	8,320	Lineare
6	Aggiunta residua	(20, 128)	0	—
7	Normalizzazione dello strato (asse = −1, ε = 1 × 10⁻³)	(20, 128)	256	—
8	Attenzione temporale (Wa ∈ R¹²⁸×¹)	128	128	Softmax
9	Strato Nascosto Denso	64	8,256	ReLU
10	Abbandono (p = 0,3)	64	0	—
11	Strato di uscita denso	1	65	Sigmoid

Tabella 5: Architettura strato per strato del modello di memoria estesa bidirezionale a breve termine a lungo termine. Questa tabella riassume l'architettura del modello proposto di Extended Bidirectional Long Short-Term Memory (BiLSTM), inclusi tipi di livelli, dimensioni di output, conteggi di parametri addestrabili e funzioni di attivazione.

Il software e l'ambiente computazionale utilizzati per tutti gli esperimenti sono riassunti nella Tabella 6.

Componente	Versione / Specifiche
Sistema operativo	Finestre
Piattaforma server	Dell PowerEdge
CPU	Processore a 64 core
RAM	128 GB
Stoccaggio	SSD da 512 GB
Python	3.12.7
NumPy	2.4.4
Panda	3.0.2
scikit-learn	1.8.0
TensorFlow / Keras	2.16.1
Web3 (client blockchain)	6.15.1
eth-account	0.1
Compilatore Solidity (solc)	0.8.19
go-ethereum (Geth)	1.13.15

Tabella 6: Software e ambiente computazionale utilizzati per l'implementazione e la valutazione del framework proposto. Questa tabella riassume le specifiche hardware, i componenti software, gli strumenti blockchain e i numeri di versione utilizzati per la pre-elaborazione dei dati, la selezione delle funzionalità, l'addestramento dei modelli, il deployment della blockchain e la valutazione delle prestazioni.

Decisione di intrusione e risposta automatica
Il rilevamento delle intrusioni negli ambienti sanitari è efficace solo se seguito da una risposta rapida e da una mitigazione. Il Livello di Rilevamento delle Intrusioni converte la probabilità prevista in una decisione. Formalmente, la decisione di intrusione al passo temporale t è rappresentata come segue (Equazione 13):

Qui, è la probabilità di intrusione prevista al tempo t e è la soglia di classificazione.

Una volta rilevata un'intrusione, il Livello di Rilevamento dell'Intrusione interagisce direttamente con il modulo blockchain, che esegue logging immutabile, mitigazione automatica e applicazione della sicurezza in loop chiuso. I dettagli degli eventi, inclusi informazioni sulla fonte, le destinazioni e le caratteristiche selezionate del traffico, vengono registrati in un nuovo blocco blockchain. Gli smart contract eseguono azioni di mitigazione in tempo reale come l'isolamento dei nodi e gli avvisi degli amministratori. Questa architettura a circuito chiuso permette ai risultati del rilevamento delle intrusioni di inserire direttamente nei meccanismi di prevenzione, minimizzando così la latenza di mitigazione. Pertanto, il Livello di Rilevamento di Intrusione funge da ponte tra il rilevamento temporale utilizzando il modello BiLSTM esteso e la risposta sicura tramite la tecnologia blockchain, completando la funzionalità end-to-end del framework proposto.

Logging Forense Basato su Blockchain
Sebbene il modello BiLSTM esteso consenta il rilevamento in tempo reale delle intrusioni, lo storage sicuro e l'audit verificabile degli eventi di intrusione sono altrettanto critici negli ambienti sanitari IoMT. I tradizionali meccanismi di registrazione centralizzato sono vulnerabili a manomissioni e compromettono la tracciabilità forense. Per affrontare questa limitazione, il framework proposto incorpora un modulo blockchain leggero che garantisce immutabilità, decentralizzazione e risposta automatizzata basata su smart contract.

Ogni evento di intrusione rilevato genera un blocco che viene aggiunto alla blockchain. Un blocco B_i è definito come segue (Equazione 14):

Qui, H_i è l'hash crittografico dei dati dell'evento, del timestamp e del risultato della previsione, T_i è il timestamp, D_i contiene caratteristiche selezionate dell'evento di intrusione, Si_gi è la firma digitale e PrevHash collega il blocco al blocco precedente, garantendo immutabilità.

Questo design garantisce la resistenza alla manomissione perché qualsiasi modifica di D_i o T_i modifica l'hash del blocco e rompe l'integrità della catena. Fornisce anche l'auditabilità perché tutte le anomalie rilevate sono memorizzate e verificabili in modo permanente. La mitigazione automatica è supportata da smart contract che eseguono azioni predefinite come l'isolamento dei nodi e gli avvisi degli amministratori. La decentralizzazione si ottiene attraverso più gateway IoMT che mantengono il registro distribuito, eliminando così un singolo punto di guasto.

La generazione di blocchi utilizza la funzione hash crittografica Keccak-256, la primitiva di hashing nativa dell'ambiente Ethereum/Solidity (invocata tramite keccak256 di Solidity). Per ogni blocco intrusione, l'hash del blocco viene calcolato come segue:

Qui, D_i è il digest della caratteristica dell'evento, T_i è il timestamp e PrevHash è l'hash del blocco precedente. I campi vengono concatenati utilizzando la codifica compatta di Solidity (abi.encodePacked) prima dell'hashing, producendo un digest a 256 bit.

Lo stesso calcolo Keccak-256 è utilizzato dalla routine di verifica della catena, che ricalcola ogni hash di blocco dai campi memorizzati e conferma che corrisponde al valore registrato, convalidando così l'integrità della catena. Keccak-256 è stato scelto perché è l'algoritmo standard di hashing resistente alle collisioni utilizzato nativamente negli smart contract Ethereum. Lo smart contract è stato sviluppato in Solidity e compilato utilizzando il compilatore Solidity (solc) versione 0.8.19. È stato distribuito su una rete privata Ethereum Proof-of-Authority (PoA) gestita con Geth versione 1.13.15. La rete blockchain era configurata con quattro nodi validatori utilizzando il protocollo di consenso Clique Proof-of-Authority, un ID di catena di 9848, un periodo di blocco di 5 s e un limite di gas di blocco di 30.000.000. La comunicazione tra il motore di rilevamento intrusioni BiLSTM Esteso e il livello blockchain è stata implementata utilizzando la libreria Web3.py versione 6.15.1 tramite l'interfaccia HTTP JSON-RPC.

Meccanismo di consenso del PoA
Poiché i sistemi IoMT sanitari sono altamente sensibili alla latenza, il framework proposto impiega un meccanismo di consenso PoA invece del costoso Proof-of-Work (PoW)²³, dal punto di vista computazionale. In PoA, un insieme fisso di nodi validatori affidabili, come gateway ospedalieri, autorizza le transazioni, fornendo sia efficienza che resilienza.

La complessità temporale della validazione dei blocchi sotto PoW può essere espressa come segue (Equazione 15):

Qui, la d rappresenta la difficoltà di estrazione.

Al contrario, la complessità temporale del consenso PoA è espressa come segue (Equazione 16):

perché la validazione richiede solo la verifica con firma digitale da parte di nodi validatori autorizzati.

Di conseguenza, PoA offre operazioni a bassa latenza adatte agli allerti medici in tempo reale, efficienza energetica evitando mining ad alto livello computazionale e resilienza contro un numero limitato di validatori dannosi. La rete PoA era configurata con quattro nodi validatori, e questa configurazione è rimasta fissa in tutti gli esperimenti per garantire misurazioni coerenti della latenza, valutazione delle prestazioni riproducibili e confronti equi tra tutti i dataset di benchmark.

Implementazione della blockchain e gestione degli smart contract
La componente blockchain è stata implementata su una rete Ethereum autorizzata che opera secondo il modello di consenso^{PoA 24}. La rete veniva gestita utilizzando il client go-ethereum (Geth) con il protocollo di consenso Clique^{PoA 25}, in cui un insieme di nodi validatori autorizzati (sealer) è responsabile della produzione e convalidazione dei blocchi. Lo smart contract di intrusione logging (IoMTIntrusionLedger) è stato scritto in Solidity e distribuito su questa rete, seguendo architetture di sicurezza IoT basate su blockchain per la gestione sicura e decentralizzata degli eventi²⁶. Solo gli account gateway autorizzati on-chain (tramite la funzione di controllo accessi del contratto) potevano inviare record di intrusione, in linea con le architetture smart-contract blockchain autorizzate per le applicazioni Internet delle^{Cose 27}. Il livello blockchain è stato implementato utilizzando il client go-ethereum (Geth) versione 1.13.15 per il funzionamento della rete PoA autorizzata, il compilatore Solidity (solc) versione 0.8.19 per la compilazione e distribuzione di smart contract e la libreria Web3.py versione 6.15.1 per la comunicazione tra IDS e la rete blockchain.

I parametri dettagliati di implementazione e configurazione della blockchain sono forniti nel File Supplementare 3C.

Ogni record di intrusione viene firmato digitalmente prima di essere messo nel registro, supportando l'auditabilità sanitaria basata su blockchain e la tenuta sicura dei registri^{forensi 28}. Le procedure di generazione e verifica della firma digitale, inclusa ECDSA sulla curva secp256k1^29,30, sono descritte nel Supplementary File 3D. Ogni gateway contiene una coppia di chiavi Ethereum costituita da una chiave privata a 256 bit (32 byte) e dalla corrispondente chiave pubblica, da cui deriva l'indirizzo del conto; la generazione delle chiavi segue la procedura standard di Ethereum, utilizzando una chiave privata casuale a 256 bit crittograficamente sicura, con la chiave pubblica ottenuta tramite moltiplicazione scalare SECP256K1. Per creare una firma, il client gateway calcola il digest della caratteristica evento D_i e lo firma con la sua chiave privata utilizzando il formato di firma dei messaggi EIP-191, generando una firma da 65 byte composta dai componenti r, s e v. La firma viene inviata insieme al registro dell'intrusione. La verifica viene effettuata on-chain tramite lo smart contract: utilizzando il precompilato EVM ecreep, il contratto recupera l'indirizzo del firmatario dal digest firmato e dalla firma e richiede che sia uguale all'indirizzo del gateway autorizzato che invia la transazione. Se l'indirizzo recuperato non corrisponde a un gateway autorizzato, la transazione viene rifiutata. Questo lega ogni voce del registro a un gateway autorizzato specifico e impedisce registri di intrusione non autorizzati o falsificati.

Gli smart contract vengono attivati automaticamente al rilevamento di intrusioni, garantendo una risposta in tempo reale senza necessità di interventi manuali (Equazione 17):

(17)

Il modulo blockchain opera in parallelo con il classificatore BiLSTM Esteso. Una volta rilevata un'anomalia: (i) l'evento viene etichettato e classificato dal BiLSTM, (ii) un blocco viene generato, firmato e aggiunto al registro blockchain, e (iii) i contratti intelligenti applicano politiche di risposta automatica.

Lo smart contract di logging delle intrusioni (IoMTIntrusionLedger) mantiene un registro solo appendibile dei blocchi di intrusione e un registro degli account gateway autorizzati, esponendo le funzioni riassunte nella Tabella 7. Il contratto impone due ruoli di accesso tramite modificatori: onlyAdmin (l'amministratore che distribuisce il deployment) e onlyGateway (account autorizzati a inviare record di intrusione). Lo stato consiste nella mappatura di autorizzazione del gateway, nell'array del registro dei blocchi e nella testa della catena corrente (l'hash del blocco più recente).

S. No.	Funzione / Componente	Tipo	Accesso	Logica
1	costruttore	Costruttore	—	Imposta il deployer come amministratore e lo autorizza come gateway iniziale.
2	setGateway(indirizzo, bool)	Funzione	onlyAdmin	Aggiunge o rimuove un account gateway autorizzato; emette GatewayUpdated.
3	recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate)	Funzione	onlyGateway	Calcola Hi = Keccak-256(Di ∥ Ti ∥ probabilità ∥ PrevHash); verifica la firma ECDSA del gateway su Di tramite ecrecover; aggiunge il blocco al registro; avanza la testa della catena; emette BlockCreated, opzionalmente NodeIsolated e AdminAlert. Restituisce Hi.
4	verifyChain()	Funzione di visualizzazione	Pubblico	Ricalcola l'hash di ogni blocco dai campi memorizzati e verifica il collegamento PrevHash; restituisce la verità solo se l'intera catena è coerente (rilevamento delle manomissioni).
5	ledgerLength()	Funzione di visualizzazione	Pubblico	Restituisce il numero di blocchi nel registro.
6	_recoverSigner(hash, sig)	Funzione interna	—	Divide la firma da 65 byte in (r, s, v) e recupera l'indirizzo di firma tramite la precompilazione ecreper.
7	BlockCreated / NodeIsolated / AdminAlert / GatewayUpdated	Eventi	—	Emessa per ascoltatori off-chain per guidare logging (logging di nodi), isolamento dei nodi, avvisi amministratori e aggiornamenti del registro gateway.
8	onlyAdmin / onlyGateway	Modificatori	—	Limitare le funzioni rispettivamente all'amministratore e ai gateway autorizzati.

Tabella 7: Funzioni, eventi e componenti di controllo accessi dello smart contract IoMTIntrusionLedger. Questa tabella riassume le principali funzioni, eventi e modificatori di controllo accessi implementati all'interno dello smart contract blockchain autorizzato. Questi componenti supportano l'autorizzazione dei gateway, la registrazione delle intrusioni, la verifica blockchain, la generazione di eventi e la mitigazione automatica.

La proprietà di immutabilità della blockchain deriva direttamente dall'Equazione 14, dove qualsiasi modifica ai dati degli eventi o ai timestamp invalida la catena hash. La blockchain garantisce quindi integrità, tracciabilità e revisione dei dati per i sistemi sanitari attraverso registri forensi immutabili. I registri di intrusione di pazienti e dispositivi rimangono invariati una volta memorizzati, ogni blocco si collega in modo sicuro al blocco precedente consentendo la ricostruzione cronologica degli eventi, e gli amministratori o i regolatori sanitari possono verificare gli incidenti di intrusione senza rischio di falsificazione.

Funzione di perdita e ottimizzazione dei modelli
Il modello BiLSTM Esteso proposto affronta il problema della classificazione binaria ovvero distinguere tra traffico normale e eventi di intrusione nelle reti IoMT. Per guidare il processo di addestramento, viene adottata una perdita binaria di entropia incrociata (BCE), molto adatta agli output probabilistici dallo strato di attivazione sigmoide. Per un dataset con N campioni, la perdita è definita come segue (Equazione 18):

(18)

Qui, è l'etichetta di verità fondamentale della i^esima sequenza di input (0 = benigno, 1 = intrusione), ed è la probabilità prevista di intrusione.

Il framework funziona come una pipeline di classificazione a due fasi. Il primo stadio esegue il rilevamento di intrusione binaria: il BiLSTM esteso produce un'uscita sigmoide e applica la soglia τ = 0,5 per classificare ogni finestra come benigna o intrusiva (Equazioni 12,13), addestrata con perdita binaria ponderata di entropia incrociata. Un secondo stadio può eseguire la categorizzazione degli attacchi, in cui finestre identificate come intrusioni vengono passate a un classificatore multiclasse che assegna la specifica categoria di attacco utilizzando uno strato di output softmax addestrato con entropia incrociata categorica. Il presente studio si concentra e valuta la fase di rilevamento binario. I due stadi condividono la stessa spina dorsale di estrazione delle caratteristiche Extended BiLSTM (Conv1D, BiLSTM, residuo, normalizzazione e livelli di attenzione); differiscono solo per il loro livello di output (sigmoid per la rilevazione e softmax per la categorizzazione) e per la corrispondente funzione di perdita. La fase di rilevamento binario e la fase di categorizzazione multiclasse sono state addestrate e valutate secondo le stesse partizioni dati, seed casuale e condizioni di addestramento descritte sopra.

Sebbene il traffico IoMT sia spesso squilibrato, una perdita binaria ponderata di entropia incrociata viene utilizzata per penalizzare la classificazione errata della classe minoritaria. I pesi di classe vengono calcolati usando il numero di campioni di intrusione N_p, il numero di campioni benigni N_n e il numero totale di campioni N (Equazioni 19,20):

La ponderazione garantisce che il modello non sia orientato verso la classe dominante di traffico benigno e rimanga sensibile a eventi di intrusione rari ma critici.

La perdita binaria ponderata per entropia incrociata è data come segue (Equazione 21):

(21)

L'addestramento veniva svolto utilizzando mini-lotti di dimensione 64. All'inizio di ogni epoca, i campioni di addestramento venivano mescolati casualmente prima di essere suddivisi in lotti, in modo che la composizione dei lotti variasse tra le epoche e il modello non vedesse esempi in un ordine fisso. I lotti non erano esplicitamente bilanciati o stratificati per classe; invece, ogni lotto rifletteva la distribuzione naturale delle classi dell'insieme di addestramento, e lo squilibrio di classe veniva affrontato attraverso la perdita binaria di entropia incrociata ponderata per classe (Equazioni 19–21). Il sottoinsieme di validazione riservato dalla partizione di addestramento rimaneva fisso tra epoche e non veniva inserito nei lotti di addestramento.

I pesi delle classi nella perdita di entropia binaria binaria ponderata non sono stati impostati manualmente, ma sono stati calcolati automaticamente per ciascun dataset a partire dai conteggi delle classi del set di addestramento secondo le Equazioni 19 e 20. Per il dataset UNSW-NB15, i pesi di classe risultanti erano per la classe normale e per la classe intrusione. Per il dataset CICIDS2017, i pesi di classe risultanti erano per la classe normale e per la classe intrusione. Per il dataset Bot-IoT (sottoinsieme del 5%), i pesi di classe risultanti erano per la classe normale e per la classe intrusione.

Strategia di addestramento e ottimizzazione
Il modello Extended BiLSTM è stato addestrato utilizzando mini-batch di dimensione B = 64 con perdita binaria ponderata di entropia incrociata, l'ottimizzatore Adam e stop precoce basato sulla perdita di validazione. L'addestramento era limitato a 50 epoche e si applicava una fermata anticipata con pazienza K = 5. Se la perdita di validazione non migliorava per cinque epoche consecutive, l'addestramento veniva interrotto e i pesi del modello venivano ripristinati a quelli dell'epoca con la perdita di validazione più bassa. Pertanto, 50 epoche rappresentavano il budget massimo per la formazione piuttosto che una durata fissa di addestramento. Per la regolarizzazione è stata applicata una probabilità di abbandono di 0,3. Le impostazioni architettoniche includevano 64 filtri Conv1D, 64 unità LSTM per direzione, una finestra di lunghezza T = 20 e un passo di s = 1. La strategia di addestramento adottata è riassunta nell'Algoritmo 3 (File Supplementare 1). Le equazioni di aggiornamento Adam utilizzate per l'ottimizzazione sono fornite nel File Supplementare 3A.

L'ottimizzatore Adam era configurato con un tasso di apprendimento di , un tasso di decadimento al primo momento (β₁) di 0,9, un tasso di decadimento al secondo momento (β₂) di 0,999 e una costante di stabilità numerica () di 1 × 10-7. Non sono state utilizzate opzioni di ottimizzatore aggiuntive e non è stato applicato decay di peso o clipping di gradiente.

Generazione di Allarmi e Mitigazione Automatica
La sola rilevazione è insufficiente nelle reti IoMT sensibili alla latenza, dove una risposta rapida è fondamentale per garantire la sicurezza del paziente. Il Livello di Generazione e Mitigazione degli Allarmi operativizza la decisione di intrusione presa dal modello BiLSTM Esteso e dal meccanismo di logging della blockchain. Se δ_t = 1, il modulo blockchain aggiunge un nuovo blocco contenente i dettagli dell'intrusione . Contemporaneamente, viene eseguito uno smart contract per attivare azioni di mitigazione (Equazione 22):

(12)

Qui, BlockCreation garantisce una registrazione forense immutabile dell'evento, NodeIsolation (_{n j}) mette in quarantena il nodo IoMT compromesso per prevenire ulteriori danni e AdminAlert fornisce notifiche in tempo reale agli amministratori di sistema. Per operare questa pipeline di risposta a doppio livello, il pseudocodice viene presentato nell'Algoritmo 4 (File Supplementare 1).

L'elaborazione degli eventi smart-contract e i meccanismi di risposta off-chain sono descritti nel File Supplementare 3E.

Ogni voce che viene compilata nel registro blockchain viene memorizzata come un record IntrusionBlock, i cui campi e formati dati sono elencati nella Tabella 8. Il registro è un array solo appendibile di questi record, e la testa attuale della catena memorizza l'hash del blocco aggiunto più recentemente.

S. No.	Campo	Tipo di Dati	Dimensioni	Descrizione
1	hashID	bytes32	32 byte	Block hash Hi = Keccak-256(Di ∥ Ti ∥ probabilità ∥ PrevHash)
2	Timestamp	uint256	32 byte	Tempo di creazione del blocco Ti (secondi dell'epoca Unix, dal timestamp del blocco)
3	nodeId	bytes32	32 byte	Identificatore del nodo IoMT nj
4	patientId	bytes32	32 byte	Identificatore paziente/dispositivo (metadati forensi)
5	attackClass	uint16	2 byte	Codice della categoria d'attacco (0 = Normale, 1 = DDoS, 2 = Spoofing, ...)
6	probabilitàBp	uint16	2 byte	Probabilità di intrusione prevista ŷ in punti base (0–10000, cioè 0,00–100,00%)
7	dataDigest	bytes32	32 byte	DigestD i delle caratteristiche selezionate dell'evento
8	Firma	Byte	Variabile (65 byte)	Firma ECDSA Sigi del digest degli eventi dal gateway (r, s, v)
9	prevHash	bytes32	32 byte	Hash del blocco precedente (PrevHash), collegando la catena
10	isolata	bool	1 byte	Se l'isolamento dei nodi sia stato attivato per questo record

Tabella 8: Struttura del record IntrusionBlock memorizzato nel registro blockchain. Questa tabella descrive i campi, i tipi di dati, le dimensioni di archiviazione e gli scopi dei record del registro blockchain utilizzati per memorizzare eventi di intrusione. La struttura supporta la verifica dell'integrità crittografica, la tracciabilità forense e i meccanismi di risposta automatica.

La latenza complessiva di mitigazione può essere espressa come la somma del ritardo di rilevamento (T_d) dal modello Extended BiLSTM e del ritardo di esecuzione della blockchain (T_b) (Equazione 23):

(23)

Analisi della complessità computazionale
L'efficienza del framework BiLSTM–Blockchain esteso proposto è determinata sia dal costo computazionale del modello BiLSTM sia dal sovraccarico introdotto dal modulo blockchain. Il framework proposto integra il rilevamento BiLSTM esteso con il logging blockchain per soddisfare i requisiti di sicurezza fondamentali della triade Confidentiality, Integrity, and Availability (CIA).

Sia la lunghezza della sequenza di input preprocessata T, la dimensione delle caratteristiche d e la dimensione nascosta della BiLSTM h.

Per ogni passo temporale, un BiLSTM elabora input di dimensione d con dimensione nascosta h. Poiché è bidirezionale (avanti + indietro) (Equazione 24):

) (24)

Qui, T è la lunghezza della sequenza (passi di tempo), d è la dimensione delle caratteristiche di input, h è la dimensione di stato nascosta

Il livello di attenzione calcola i pesi di importanza e aggrega stati nascosti con complessità (Equazione 25).

(25)

che è lineare sia nella lunghezza della sequenza T sia nella dimensione nascosta h.

La complessità complessiva di rilevamento per sequenza è quindi indicata come segue (Equazione 26):

(26)

dimostrando che la modellazione temporale domina il costo computazionale, mentre il meccanismo di attenzione introduce solo un leggero sovraccarico.

Per ogni evento di intrusione rilevato, la registrazione della blockchain esegue operazioni di hashing, firma e aggiunta di blocchi (Equazione 27):

(27)

Per N eventi di rilevamento intrusione, la complessità combinata diventa la seguente (Equazione 28):

(28)

che può essere semplificato come segue (Equazione 29):

(29)

Perché il sovraccarico della blockchain cresce linearmente con il numero di eventi e rimane trascurabile rispetto ai calcoli di elaborazione di sequenze.

La complessità computazionale è riassunta nelle Equazioni 24–29. L'interpretazione dettagliata è fornita nel File Supplementare 3F.

Results

I risultati sono organizzati in modo da rispecchiare i passaggi metodologici del Protocollo, con ogni sottosezione che riporta le osservazioni prodotte dal corrispondente passaggio.

Gestione dei dataset e configurazione sperimentale
I tre dataset benchmark sono stati analizzati indipendentemente e non fusi. Poiché UNSW-NB15, CICIDS2017 e Bot-IoT utilizzano schemi di funzionalità e convenzioni di etichettatura differenti, ogni dataset è stato preelaborato, formato in finestre e valutato separatamente utilizzando la propria divisione train/test 80:20. Il modello BiLSTM Esteso è stato addestrato e testato su ciascun dataset in modo indipendente, e le metriche di prestazione (accuratezza, precisione, richiamo e punteggio F1) sono riportate separatamente per ogni dataset. Questo protocollo di valutazione indipendente evita le incongruenze nello spazio delle caratteristiche che deriverebbero dalla combinazione di dataset eterogenei e consente di valutare la robustezza del framework proposto in tre distinti ambienti di rete.

Il modello BiLSTM-BC esteso proposto è stato addestrato e valutato utilizzando traffico normale e malevolo preprocessato estratto dai dataset CICIDS2017, UNSW-NB15 e Bot-IoT. I dati venivano suddivisi tramite una singola divisione stratificata del retenzibile. Il dataset UNSW-NB15 fornisce partizioni predefinite per l'addestramento e il test, utilizzate direttamente in questo studio. Per i restanti due dataset (CICIDS2017 e Bot-IoT), i campioni preprocessati a finestre sono stati suddivisi in set di addestramento e test utilizzando una suddivisione 80:20 con campionamento casuale stratificato (scikit-learn train_test_split, stratificato per etichetta di classe), preservando così il rapporto di classe benigno-intrusione tra le partizioni. All'interno del set di addestramento, un ulteriore 20% era riservato alla validazione (Keras validation_split), risultando in una partizione effettiva del 64% di addestramento, 16% di validazione e 20% di partizione del test. Il set di validazione veniva utilizzato per l'arresto anticipato. Un seed casuale fisso di 42 è stato applicato a scikit-learn, NumPy e TensorFlow per supportare la riproducibilità. La rete BiLSTM estesa è stata ottimizzata utilizzando l'ottimizzatore Adam con un tasso di apprendimento di 0,001, una dimensione di lotto di 64 e un massimo di 50 epoche di addestramento.

Risultati della selezione delle caratteristiche
Prima dell'addestramento del modello, la selezione delle caratteristiche veniva effettuata indipendentemente per ogni dataset utilizzando AQU-IMF-RFE, una procedura di eliminazione delle caratteristiche ricorsive guidata dall'Aquila Optimizer (AO) in cui le caratteristiche candidate venivano classificate in base alle loro informazioni reciproche (MI) con l'etichetta della classe ed eliminate iterativamente mentre l'Aquila Optimizer cercava il sottoinsieme ottimale delle caratteristiche. I campi identificatori (ad esempio, ID di flusso, indirizzi IP e numeri di porta) e i campi testuali delle categorie di attacco venivano esclusi prima della selezione delle caratteristiche per prevenire la fuga di informazioni. Questa procedura mantenne 14 funzionalità per UNSW-NB15, 24 per CICIDS2017 e 12 per Bot-IoT. L'elenco completo delle variabili di input selezionate, i loro tipi di dati e i loro dataset sorgente è fornito nella Tabella 4, e una descrizione ampliata di ciascuna caratteristica è inclusa nel Supplementary File 2.

Addestramento e convergenza
Durante l'addestramento, il modello ha dimostrato una convergenza stabile, con prestazioni sia di addestramento che di validazione che miglioravano man mano che i parametri della rete si avvicinavano ai valori ottimali. L'architettura layer per layer del modello BiLSTM Esteso proposto è riassunta nella Tabella 5, mentre il software e l'ambiente computazionale utilizzati per l'implementazione e la valutazione sono presentati nella Tabella 6. Le funzioni smart contract blockchain che supportano la registrazione delle intrusioni e la mitigazione automatica sono riassunte nella Tabella 7, e la struttura del record di intrusione blockchain è presentata nella Tabella 8. L'insieme completo di iperparametri di addestramento utilizzati in questo studio è riassunto nella Tabella 9, a supporto della riproducibilità del quadro proposto.

Iperparametro di addestramento	Valore
Tasso di apprendimento	0.001
Ottimizzatore	Adam
Dimensione del lotto	64
Epoche Massime	50
Funzione di attivazione dell'uscita	Sigmoid
Divisione dei test del treno	80:20, stratificato
Divisione di validazione	20% della partizione di addestramento
Seme casuale	42
Lunghezza della finestra di ingresso	20 passi temporali
Passato a finestra scorrevole	1
Filtri Conv1D	64
Dimensione del kernel Conv1D	3
Imbottitura Conv1D	Stessa cosa
Attivazione Conv1D	ReLU
Strati BiLSTM	2
Unità BiLSTM	64 unità per direzione
Dimensione di uscita BiLSTM	128
Attivazione LSTM	Tanh
Dimensione residua di proiezione	128
Pazienza che si ferma precocemente	5 epoche
Unità a strato nascosto denso	64
Attivazione densa dello strato nascosto	ReLU
Tasso di abbandono	0.3
Unità di uscita	1
Soglia di classificazione	0.5
Funzione di perdita	Entropia Binaria Incrociata Pesata (WBCE)

Tabella 9: Configurazione degli iperparametri utilizzata per l'addestramento del modello di memoria a lungo termine bidirezionale estesa. Questa tabella elenca i principali iperparametri di addestramento utilizzati durante lo sviluppo del modello di rilevamento intrusione Bidirectional Long Short-Term Memory (BiLSTM), inclusi impostazioni di ottimizzazione, funzione di attivazione, dimensione del lotto, durata dell'addestramento e funzione di perdita.

La Tabella 10 presenta le accuratezze di addestramento e validazione del modello proposto su 50 epoche, registrate a intervalli di 5 epoche. Il modello ha mostrato un rapido miglioramento durante le prime 10 epoche, raggiungendo accuratezze di addestramento e validazione rispettivamente del 96,0% e 95,5%. Oltre l'epoca 20, i guadagni di precisione divennero incrementali e entrambe le curve convergevano da vicino. All'epoca 50, il modello si stabilizzò al 99,1% di accuratezza nell'addestramento e al 98,5% di accuratezza di validazione, indicando un overfitting minimo e una forte performance di generalizzazione. La corrispondente curva di apprendimento è mostrata nella Figura 3, illustrando la progressione dell'accuratezza dell'addestramento e della validazione durante tutto il processo di ottimizzazione.

Epoca	Accuratezza dell'addestramento (%)	Accuratezza della Validazione (%)
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

Tabella 10: Accuratezza dell'addestramento e della validazione durante l'addestramento del modello di memoria a lungo termine bidirezionale esteso. Questa tabella riporta l'accuratezza dell'addestramento e della validazione misurata in epoche di addestramento selezionate durante l'ottimizzazione del modello Proposed Extended Bidirectional Long Short-Term Memory (BiLSTM). Questi valori sono stati utilizzati per generare la curva di convergenza di precisione mostrata nella Figura 3.

Figura 3. Precisione di addestramento e validazione del modello BiLSTM esteso. Grafico a linee che mostra l'accuratezza della classificazione durante l'addestramento del modello. L'asse x rappresenta le epoche di addestramento (1–50), mentre l'asse y rappresenta l'accuratezza della classificazione (%). I cerchi blu indicano l'accuratezza dell'addestramento, mentre i quadrati arancioni indicano l'accuratezza della validazione. Clicca qui per visualizzare una versione più grande di questa figura.

La Tabella 11 presenta i valori di perdita di addestramento e validazione registrati agli stessi intervalli di 5 epoche. Durante la fase iniziale di addestramento, la perdita di addestramento è diminuita da 0,64 a 0,28, mentre quella di validazione è diminuita da 0,67 a 0,31 entro la quinta epoca. Dopo l'epoca 20, il tasso di riduzione delle perdite divenne più graduale e entrambe le curve convergevano costantemente. All'epoca 50, la perdita di addestramento si stabilizzò a 0,08, mentre la perdita di validazione rimase vicina a 0,12, indicando solo una piccola differenza tra le due curve. Questa convergenza riflette un'ottimizzazione efficace, un overfitting limitato e una buona generalizzazione di dati prima inediti. Le corrispondenti curve di perdita di addestramento e validazione sono presentate nella Figura 4. L'efficienza computazionale dei modelli valutati, inclusa la latenza di inferenza e la produttività, è riassunta nella Tabella 12. L'analisi dettagliata di queste misurazioni è presentata più avanti nella sottosezione Efficienza computazionale.

Epoca	Perdita di allenamento	Perdita di validazione
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

Tabella 11: Perdita di addestramento e validazione durante l'addestramento del modello di memoria bidirezionale estesa a breve termine a lungo termine. Questa tabella riporta valori di perdita binaria di entropia incrociata ponderati per l'addestramento e la validazione degli ioni misurati in epoche di addestramento selezionate durante l'ottimizzazione del modello Proposed Bidirectional Long Short-Term Memory (BiLSTM). Questi valori sono stati utilizzati per generare la curva di convergenza di perdita mostrata nella Figura 4.

Figura 4. Perdita di addestramento e validazione del modello Extended BiLSTM. Grafico lineare che mostra la perdita di entropia incrociata binaria ponderata durante l'addestramento del modello. L'asse x rappresenta le epoche di addestramento (1–50), mentre l'asse y rappresenta i valori di perdita. I cerchi blu indicano la perdita durante l'allenamento, mentre i quadrati arancioni indicano la perdita di validazione. Clicca qui per visualizzare una versione più grande di questa figura.

Modello	Latenza (media ms/evento)	Throughput (Eventi/i mediati)
Albero decisionale	40	845
Macchina a vettore di supporto	75	670
LSTM	110	559
Proposta di Framework Esteso BiLSTM–Blockchain	135	320

Tabella 12: Confronto tra latenza e throughput dei modelli di rilevamento intrusioni. Questa tabella confronta la latenza di inferenza e la velocità di elaborazione tra modelli rappresentativi di rilevamento intrusione di machine learning e deep learning. La latenza viene riportata come millisecondi per evento e la velocità di trasmissione come eventi elaborati per secondo.

Prestazioni di rilevamento
La Tabella 13 presenta la valutazione comparativa del quadro proposto rispetto ai modelli convenzionali di ML e DL tra i tre dataset di riferimento. Il modello proposto ha raggiunto accuratezze del 98,9% su CICIDS2017, 95,9% su UNSW-NB15 e 98,8% su Bot-IoT, insieme ad alte sensibilità rispettivamente del 96,9%, 97,6% e 98,8%. Su CICIDS2017 e UNSW-NB15, il modello proposto ha raggiunto la massima accuratezza tra tutti i modelli valutati, mentre su Bot-IoT ha raggiunto la massima accuratezza (98,8%), eguagliata dalla base dell'Albero Decisionale (DT). Su Bot-IoT, il modello proposto ha superato leggermente la base LSTM (98,3%) e ha avuto prestazioni paragonabili alla base della Support Vector Machine (SVM) (98,7%); I margini di prestazione più piccoli in questo dataset riflettono il suo estremo squilibrio di classe, in cui il traffico benigno costituisce solo una frazione molto piccola del set di test. Nel complesso, il modello proposto ha mantenuto un forte equilibrio tra sensibilità e precisione, dimostrando una robusta performance di rilevamento di intrusioni su tutti i dataset e fornendo la valutazione più affidabile sui dataset di benchmark più bilanciati (CICIDS2017 e UNSW-NB15). I relativi confronti di accuratezza, precisione e richiamo tra dataset e modelli di base sono presentati nelle Figure 5–7.

Dataset	Modello	Sensibilità (%)	Specificità (%)	Accuratezza (%)	Precisione (%)	Richiamo (%)
CICIDS2017	BiLSTM–Blockchain Estesa Proposta	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 Estesa Proposta	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 Estesa Proposta	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

Tabella 13: Confronto delle prestazioni dei modelli di rilevamento intrusioni tra dataset di benchmark. Questa tabella confronta il framework proposto e i modelli di rilevamento di intrusioni di base sui dataset CICIDS2017, UNSW-NB15 e Bot-IoT utilizzando metriche di performance di sensibilità, specificità, accuratezza, precisione e richiamo.

Figura 5. Confronto di accuratezza tra dataset e modelli di machine learning/deep learning. Grafico a barre raggruppato che confronta l'accuratezza della classificazione (%) ottenuta da diversi modelli tra i dataset CICIDS2017, UNSW-NB15 e Bot-IoT. Le barre rappresentano il modello proposto, la Long Short-Term Memory (LSTM), la Support Vector Machine (SVM) e l'Albero Decisionale (DT). L'asse x rappresenta i dataset, mentre l'asse y rappresenta l'accuratezza della classificazione (%). Clicca qui per visualizzare una versione più grande di questa figura.

Figura 6. Confronto di precisione tra modelli di classificazione tra dataset di rilevamento intrusioni. Grafico a barre raggruppato che mostra la precisione (%) ottenuta da diversi modelli sui dataset CICIDS2017, UNSW-NB15 e Bot-IoT. L'asse x rappresenta i modelli di classificazione, mentre l'asse y rappresenta la precisione (%). LSTM, Memoria a Breve Termine Lungo; SVM, Macchina a Vettori di Supporto; DT, Albero delle Decisioni. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 7. Ricorda il confronto tra modelli di classificazione tra i dataset di rilevamento di intrusioni. Grafico a barre raggruppato che mostra il richiamo (%) ottenuto da diversi modelli sui dataset CICIDS2017, UNSW-NB15 e Bot-IoT. L'asse x rappresenta i modelli di classificazione, e l'asse y rappresenta il richiamo (%). LSTM, Memoria a Breve Termine Lungo; SVM, Macchina a Vettori di Supporto; DT, Albero delle Decisioni. Clicca qui per visualizzare una versione più grande di questa figura.

Per comprendere meglio il contributo di ciascun componente architettonico, è stato condotto uno studio di ablazione. I risultati, riassunti nella Tabella 14, mostrano che il meccanismo di attenzione ha migliorato la priorità temporale, i livelli residui e convoluzionali hanno migliorato l'estrazione delle caratteristiche e l'apprendimento stabilizzato, e l'integrazione blockchain ha fornito logging forense a prova di manomissione insieme a mitigazione automatica. Ogni miglioramento architettonico contribuiva incrementalmente a una maggiore precisione nel rilevamento riducendo al contempo le previsioni di falsi positivi.

Variante del modello	Accuratezza (%)	Precisione (%)	Richiamo (%)	F1-Score (%)	Tasso di falsi positivi (%)	Note
BiLSTM Semplice	97.5	93.9	93.3	93.67	1.47	Modello di base di rilevamento di intrusioni sequenziali
BiLSTM + Attenzione	98.04	95.18	94.85	95.01	1.18	Il meccanismo di attenzione dà priorità alle caratteristiche temporali informative
BiLSTM esteso (Residuo + Conv1D)	97.5	94.6	93.06	93.82	1.3	Le connessioni residue e gli strati convoluzionali migliorano l'estrazione delle caratteristiche temporali e la stabilità dell'addestramento
BiLSTM esteso + Blockchain	98.9	97.5	96.9	97.3	0.59	Framework completo con rilevamento intrusioni, registrazione immutabile e mitigazione automatica

Tabella 14: Studio di ablazione dei componenti architettonici nel framework proposto per il rilevamento delle intrusioni. Questa tabella riassume il contributo dei singoli componenti architettonici, inclusi meccanismi di attenzione, apprendimento residuo, estrazione convoluzionale di funzionalità e integrazione blockchain, alle prestazioni complessive del framework proposto.

Per ogni variante di ablazione, un singolo componente del quadro proposto veniva rimosso mentre tutte le condizioni rimanenti erano mantenute costanti. Lo stesso dataset, input preelaborati a finestre, identica divisione stratificata 80:20 train/test con partizionamento di validazione, seed casuale fisso (42), ottimizzatore (Adam), tasso di apprendimento (0,001), dimensione del batch (64), massimo di 50 epoche di addestramento, criterio di arresto precoce (pazienza = 5), tasso di dropout (0,3) e architettura di rete sono stati mantenuti in tutti gli esperimenti. Solo il componente in valutazione è stato modificato, assicurando così che le differenze di prestazioni osservate fossero attribuibili esclusivamente al componente rimosso.

Il quadro proposto manteneva un equilibrio favorevole tra precisione e richiamo rispetto ai modelli di base (LSTM, SVM e DT), dimostrando una migliore discriminazione dei modelli di attacco sottili senza aumentare sostanzialmente le previsioni di falsi positivi. Questa prestazione bilanciata si riflette nella differenza costantemente piccola tra i valori di precisione e di richiamo, indicando un alto punteggio F1 e una generalizzazione robusta su traffico di rete eterogeneo. I confronti tra precisione e richiamo sono presentati nelle Figure 6 e 7.

Rispetto alle basi rappresentative IDS, inclusi SVM, DT e LSTM, il framework proposto ha dimostrato un costante vantaggio prestazionale sui dataset benchmark con traffico benigno sufficiente. Il CICIDS2017, il modello proposto di BiLSTM–Blockchain Esteso ha raggiunto una precisione del 98,9%, superando i valori base LSTM (97,5%), DT (97,5%) e SVM (98,1%). Su UNSW-NB15, ha raggiunto una precisione del 95,9%, nuovamente la più alta tra i modelli valutati (LSTM 92,2%, SVM 94,1%, DT 94,8%). Su Bot-IoT, caratterizzato da un estremo squilibrio di classe con una classe benigna molto piccola, il modello proposto ha raggiunto una precisione del 98,8%, corrispondendo alla linea di base DT e superando leggermente quelle di LSTM (98,3%) e SVM (98,7%). I modelli tradizionali di apprendimento automatico mostravano una capacità relativamente limitata di modellare dipendenze temporali a lungo raggiunto, mentre l'LSTM migliorava l'apprendimento delle caratteristiche temporali; Tuttavia, nessuno di questi modelli di base forniva logging forense resistente alla manomissione o tracciabilità automatica degli eventi basata su blockchain. Integrando l'apprendimento residuo, un meccanismo di attenzione e il logging immutabile basato su blockchain con l'architettura BiLSTM estesa, il framework proposto combinava prestazioni competitive di rilevamento di intrusioni con una responsabilità forense verificabile oltre quella fornita dai metodi di base. Il componente blockchain registra ciascuno l'intrusione rilevata come una voce del registro immutabile contenente l'identificatore del blocco, il timestamp, i dati degli eventi criptati, l'hash crittografico e la firma digitale. Un esempio della struttura dei record blockchain è mostrato nella Figura 8. L'accuratezza comparativa e il tasso di errore tra i modelli valutati sono presentati rispettivamente nelle Figure 9 e 10, mentre la Figura 11 confronta i tempi di addestramento dei modelli valutati. Le metriche complessive di prestazione del quadro proposto, inclusi accuratezza, precisione, richiamo, punteggio F1 e tasso di falsi positivi, sono riassunte nella Figura 12, e il confronto combinato tra accuratezza e punteggio F1 è presentato nella Figura 13.

Figura 8. Esempio di record di intrusione blockchain generato dopo il rilevamento di intrusione. Esempio illustrativo di un record blockchain creato dopo il rilevamento di intrusioni. Il record contiene un identificatore di blocco, un identificatore paziente/dispositivo, timestamp, dati di eventi criptati, hash del blocco precedente, hash del blocco corrente e firma digitale. La struttura del record corrisponde alla rappresentazione della blockchain definita nell'Equazione 14. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 9. Confronto di accuratezza tra il framework proposto e i modelli di rilevamento intrusione di benchmark. Grafico a barre che confronta l'accuratezza della classificazione del framework proposto Extended BiLSTM–Blockchain con i modelli di rilevamento intrusioni di benchmark. L'asse x rappresenta i modelli di classificazione, e l'asse y rappresenta l'accuratezza della classificazione (%). LSTM, Memoria a Breve Termine Lungo; SVM, Macchina a Vettori di Supporto; DT, Albero delle Decisioni. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 10. Confronto del tasso di errore tra il framework proposto e i modelli di rilevamento intrusione di benchmark. Grafico a barre che mostra i tassi finali di errore ottenuti dal framework proposto Extended BiLSTM–Blockchain e dai modelli di rilevamento intrusione di benchmark. L'asse x rappresenta i modelli di classificazione, e l'asse y rappresenta il tasso di errore (%). Clicca qui per visualizzare una versione più grande di questa figura.

Figura 11. Confronto dei tempi di addestramento dei modelli di rilevamento intrusioni. Grafico a barre che mostra la durata dell'allenamento a parete di ciascun modello valutato. L'asse x rappresenta i modelli di classificazione, mentre l'asse y rappresenta il tempo di addestramento (secondi). I tempi di addestramento venivano misurati utilizzando l'ambiente di calcolo sperimentale descritto nel protocollo. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 12. Metriche di performance del framework proposto Extended BiLSTM–Blockchain. Grafico a barre che riassume le prestazioni del quadro proposto. Le metriche includono accuratezza, precisione, richiamo (tasso di rilevamento) e punteggio F1. Il tasso di falsi positivi (FPR = 0,59%) è inoltre riportato come annotazione nella figura. L'asse y rappresenta i valori di prestazione (%). FPR, tasso di falsi positivi. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 13. Comparazione di accuratezza e punteggi F1 tra modelli di rilevamento intrusioni. Grafico a barre raggruppato che confronta l'accuratezza della classificazione e il punteggio F1 tra i modelli valutati di rilevamento dell'intrusione. Le barre viola rappresentano precisione, mentre le barre verdi rappresentano il punteggio F1. L'asse x rappresenta i modelli di classificazione, e l'asse y rappresenta la prestazione (%). LSTM, Memoria a Breve Termine Lungo; SVM, Macchina a Vettori di Supporto; DT, Albero delle Decisioni. Clicca qui per visualizzare una versione più grande di questa figura.

La matrice di confusione ottenuta dalla fase di classificazione binaria è presentata nella Tabella 15 e visualizzata nella Figura 14. Ripartiti nei tre set di test di benchmark, il modello ha classificato correttamente 486.798 casi normali, con 4.916 campioni normali erroneamente classificati come intrusioni. Per la classe di intrusione, 877.494 istanze di intrusione sono state correttamente identificate, mentre 12.978 campioni di intrusione sono stati erroneamente classificati come normali. Questi risultati dimostrano un'elevata capacità discriminativa con relativamente pochi errori di classificazione, indicando prestazioni affidabili per il rilevamento di intrusioni binarie negli ambienti IoMT. L'accuratezza riportata, il punteggio F1, la latenza e la velocità corrispondono esclusivamente allo stadio di rilevamento dell'intrusione binaria valutato in questo studio.

Modello	Dataset	Dimensione del set di test	True Class	Normale previsto	Intrusione prevista	Totale (Vero)
BiLSTM Esteso Proposto - Blockchain	CICIDS 2017	566149	Normale	451946	2673	454619
			Intrusione	3426	108104	111530
			Totale (Previsto)	455372	110777	566149
	UNSW-NB 15	82332	Normale	34764	2236	37000
			Intrusione	1087	44245	45332
			Totale (Previsto)	35851	46481	82332
	Bot-IoT	733705	Normale	88	7	95
			Intrusione	8465	725145	733610
			Totale (Previsto)	8553	725152	733705
LSTM	CICIDS 2017	566149	Normale	447946	6673	454619
			Intrusione	7396	104134	111530
			Totale (Previsto)	455342	110807	566149
	UNSW-NB 15	82332	Normale	32765	4235	37000
			Intrusione	2153	43179	45332
			Totale (Previsto)	34918	47414	82332
	Bot-IoT	733705	Normale	85	10	95
			Intrusione	12465	721145	733610
			Totale (Previsto)	12550	721155	733705
SVM	CICIDS 2017	566149	Normale	449257	5362	454619
			Intrusione	5743	105787	111530
			Totale (Previsto)	455000	111149	566149
	UNSW-NB 15	82332	Normale	33729	3271	37000
			Intrusione	1568	43764	45332
			Totale (Previsto)	35297	47035	82332
	Bot-IoT	733705	Normale	84	11	95
			Intrusione	9465	724145	733610
			Totale (Previsto)	9549	724156	733705
DT	CICIDS 2017	566149	Normale	448697	5922	454619
			Intrusione	7743	103787	111530
			Totale (Previsto)	456440	109709	566149
	UNSW-NB 15	82332	Normale	34129	2871	37000
			Intrusione	1397	43935	45332
			Totale (Previsto)	35526	46806	82332
	Bot-IoT	733705	Normale	89	6	95
			Intrusione	8465	725145	733610
			Totale (Previsto)	8554	725151	733705

Tabella 15: Matrice di confusione del modello proposto di rilevamento intrusioni. Questa tabella presenta la matrice di confusione ottenuta dalla valutazione del modello proposto tramite test set. Le righe corrispondono a vere etichette di classe e le colonne corrispondono alle etichette di classe previste per le classi di traffico normale e intrusione.

Figura 14. Matrice di confusione del sistema proposto di rilevamento intrusione BiLSTM–Blockchain Esteso tra i dataset di benchmark. Matrici di confusione che mostrano i risultati di classificazione per i dataset CICIDS2017, UNSW-NB15 e Bot-IoT. Le righe corrispondono a etichette vere e le colonne corrispondono a etichette previste. I valori delle celle indicano il numero di istanze assegnate a ciascun risultato di classificazione. IDS, Sistema di Rilevamento Intrusioni. Clicca qui per visualizzare una versione più grande di questa figura.

La precisione per classe, il richiamo e i valori di punteggio F1 derivati dalla matrice di confusione sono riassunti nella Tabella 16. Un'elevata precisione indica che il quadro proposto raramente ha classificato erroneamente il traffico benigno come malevolo, riducendo così allerte inutili negli ambienti sanitari. Analogamente, i valori elevati di richiamo dimostrano una rilevazione efficace degli eventi di intrusione minimizzando gli attacchi mancati. I punteggi F1 costantemente forti in entrambe le classi confermano che il framework proposto ha raggiunto un compromesso equilibrato tra sensibilità di rilevamento e accuratezza della classificazione, supportandone l'idoneità per il rilevamento di intrusioni IoMT in tempo reale.

Classe	Precisione (%)	Richiamo (%)	F1-Score (%)
Normale	97.4	99	98.2
Intrusione	99.44	98.54	98.99
Media	98.42	98.77	98.59

Tabella 16: Metriche di performance per classe del modello proposto di rilevamento intrusione. Questa tabella riporta i valori di precisione, richiamo e punteggio F1 per classi normali e di intrusione, insieme alla media complessiva delle prestazioni ottenute durante la valutazione del set di test.

Efficienza computazionale
Le prestazioni in tempo reale sono state valutate utilizzando misurazioni temporali offline sulle finestre di test preprocessate piuttosto che in un ambiente di streaming live. Per ogni dataset, i campioni di test preprocessati a finestre venivano processati attraverso l'intera pipeline di rilevamento e logging blockchain, e il tempo di esecuzione del wall-clock veniva registrato. I confini temporali erano definiti come segue. La latenza di rilevamento (T_d) veniva misurata dall'istante immediatamente precedente alla chiamata di inferenza del modello fino a quando venivano restituite le probabilità previste. La latenza di mitigazione end-to-end (T_mitigation = T_d + T_b) è stata misurata dallo stesso punto di partenza fino al completamento della transazione finale di creazione di blocchi blockchain, con la componente di scrittura blockchain (T_b) calcolata come differenza tra le due misurazioni. La verifica del registro è stata eseguita dopo che il timer di mitigazione-latenza si era fermato ed è stata quindi esclusa dalla latenza segnalata.

La velocità di lavoro veniva calcolata come il numero totale di finestre elaborate diviso per il tempo di orologio a parete trascorso per un passaggio completo attraverso la partizione di test di ciascun dataset. La latenza per evento veniva ottenuta dividendo il corrispondente tempo trascorso per il numero totale di finestre elaborate. Il carico di lavoro consisteva nelle partizioni di test a finestra dei tre dataset benchmark, preservando le loro distribuzioni di classi benigne all'intrusione. Le finestre classificate come malevole sostenevano l'ulteriore sovraccarico di logging blockchain, inclusi il digest computing, la firma digitale e l'esecuzione di transazioni smart contract, mentre le finestre benigne sostenevano solo i costi di rilevamento.

Il confronto tra latenza e throughput tra i modelli rappresentativi di rilevamento dell'intrusione è presentato nella Tabella 12. I modelli convenzionali di apprendimento automatico, inclusi DT e SVM, hanno dimostrato una latenza di inferenza inferiore e un throughput superiore rispetto al framework di deep learning proposto. La base LSTM ha raggiunto prestazioni intermedie. Il framework Extended BiLSTM–Blockchain proposto operava con una latenza di rilevamento di circa 135 ms per evento e un throughput di circa 320 eventi/s sulla distribuzione Clique PoA a nodo singolo descritta nell'Experimental Setup. Queste misurazioni caratterizzano le prestazioni del prototipo a singolo validatore piuttosto che una valutazione della scalabilità multinode.

Oltre alla performance di inferenza, il tempo di addestramento di ciascun modello valutato è stato confrontato per valutare l'efficienza computazionale. Il tempo di addestramento è una considerazione importante per le applicazioni IoMT in tempo reale, dove è auspicabile un rapido deployment del modello. Come mostrato nella Figura 11, il DT ha raggiunto la latenza per evento più bassa (circa 40 ms) e il throughput più alto (circa 845 eventi/s), seguito dall'SVM (circa 75 ms, 670 eventi/s) e dall'LSTM (circa 110 ms, 559 eventi/s). Il framework Extended BiLSTM–Blockchain proposto ha mostrato la latenza più alta (circa 135 ms) e il throughput più basso (circa 320 event/s) tra i modelli valutati. Questo ulteriore costo computazionale deriva dall'architettura bidirezionale, dal meccanismo di attenzione temporale e dalla registrazione immutabile basata su blockchain, che insieme forniscono un migliorato apprendimento delle caratteristiche temporali e una tracciabilità forense a prova di manomissione. Sebbene questi componenti aumentino la latenza per evento, la velocità raggiunta rimane sufficiente per il monitoraggio delle intrusioni quasi in tempo reale negli ambienti IoMT.

Una valutazione completa della scalabilità che coinvolgeva più nodi validatori e vari carichi di transazione era al di là dell'ambito dell'attuale prototipo a singolo nodo. Valutare la velocità di trasmissione e la latenza come funzione del numero di validatori e del carico delle transazioni in condizioni controllate rappresenta una direzione importante per i futuri lavori volti a caratterizzare la scalabilità del framework in ambienti ospedalieri distribuiti più ampi.

Registrazione e mitigazione della blockchain
La Figura 8 illustra un esempio di record di intrusione blockchain. Ogni blocco memorizza in modo sicuro un'intrusione o una transazione di dati medici all'interno del registro blockchain registrando un identificatore unico di blocco (Block_ID), un identificatore di paziente o dispositivo (Patient_ID), un timestamp, dati di intrusione criptati, l'hash del blocco precedente, l'hash del blocco corrente e una firma digitale. Collettivamente, questi campi forniscono riservatezza, integrità, immutabilità, autenticazione e tracciabilità forense all'interno del framework proposto per il rilevamento di intrusioni BiLSTM–Blockchain Esteso.

Nel complesso, i risultati supportano l'ipotesi centrale secondo cui l'integrazione di un rilevatore di intrusioni BiLSTM esteso con attenzione potenziata con uno strato di logging basato su blockchain fornisce un rilevamento accurato, efficiente e a prova di manomissione per le reti IoMT. Il framework proposto ha raggiunto un'accuratezza complessiva del 98,71% e un punteggio F1 del 98,99%, superando costantemente i modelli di base valutati di machine learning e deep learning, mantenendo una convergenza stabile e evidenze minime di overfitting. Lo studio di ablazione ha dimostrato che ogni componente architettonico, inclusi i livelli convoluzionali e residui, il meccanismo di attenzione e l'integrazione blockchain, ha contribuito in modo incrementale alle prestazioni complessive di rilevamento e alle capacità forensi. Nel prototipo a singolo nodo, il framework ha mantenuto una latenza media di circa 135 ms per evento e un throughput di circa 320 eventi al secondo, fornendo una registrazione delle intrusioni immutabile e verificabile. Collettivamente, questi risultati supportano l'adeguatezza del framework integrato proposto per il rilevamento in tempo reale delle intrusioni e la registrazione forense sicura negli ambienti IoMT.

Disponibilità dei dati:
I dataset benchmark utilizzati in questo studio sono disponibili pubblicamente. Il dataset UNSW-NB15 è disponibile dal repository UNSW Canberra (https://research.unsw.edu.au/projects/unsw-nb15-dataset), il dataset CICIDS2017 è disponibile presso il Canadian Institute for Cybersecurity (https://www.unb.ca/cic/datasets/ids-2017.html) e il dataset Bot-IoT è disponibile presso il repository UNSW Canberra (https://research.unsw.edu.au/projects/bot-iot-dataset).

I materiali completi necessari per riprodurre lo studio sono forniti come file supplementari. Il File Supplementare 1 contiene il pseudocodice completo per la preelaborazione, selezione delle caratteristiche, addestramento dei modelli, rilevamento intrusioni, blockchain e smart contract descritti nel Protocollo. Il Supplementary File 2 contiene l'implementazione completa della pipeline di preprocessing dati, del modello BiLSTM esteso, degli script di addestramento e valutazione, del client blockchain, degli script di generazione di figure e della pipeline di esecuzione end-to-end. Il README allegato fornisce istruzioni passo dopo passo per riprodurre il flusso di lavoro, inclusa la preparazione del dataset, l'addestramento del modello, la valutazione, la generazione di figure e l'implementazione opzionale della blockchain. Il file requirements.txt allegato specifica le dipendenze del pacchetto Python necessarie per ricreare l'ambiente computazionale.

Figura	Tipo di figura	generato da
1	Diagramma architetturale concettuale	Software di disegno vettoriale
2	Diagramma di flusso dati a livello di implementazione	Software di disegno vettoriale
3	Curva di convergenza di precisione	Storia dell'addestramento (accuratezza dell'addestramento e della validazione per epoca)
4	Curva di convergenza delle perdite	Storia dell'addestramento (perdita di addestramento e validazione per epoca)
5	Grafico a barre di comparazione dell'accuratezza	Valori di accuratezza per modello
6	Grafico a barre di comparazione di precisione	Valori di precisione per modello
7	Richiamo il diagramma a barre comparativo	Valori di richiamo per modello
8	Diagramma della struttura a blocchi della blockchain	Struttura concettuale del record blockchain
9	Tabella di confronto dell'accuratezza	Valori di accuratezza per metodo
10	Tabella di confronto del tasso di errore	Valori del tasso di errore per metodo
11	Tabella comparativa dei tempi di allenamento	Durate di allenamento misurate
12	Tabella riepilogistica delle prestazioni	Valori di precisione, richiamo, accuratezza, punteggio F1 e tasso di falsi positivi proposti
13	Grafica di precisione e comparazione dei punteggi F1	Accuratezza per metodo e valori di punteggio F1
14	Matrice di confusione	Conteggi a matrice di confusione

Tabella 17: Fonti di dati utilizzate per generare i dati inclusi nello studio. Questa tabella riassume le fonti dati e i risultati computazionali utilizzati per generare ogni figura presentata nel manoscritto. I dati quantitativi venivano generati in modo programmativo a partire da storie di addestramento dei modelli, metriche di valutazione, output delle matrice di confusione e misurazioni delle prestazioni, mentre i diagrammi concettuali venivano creati utilizzando software di disegno vettoriale.

Fascicolo supplementare 1. Algoritmi e pseudocodice per il framework proposto per il rilevamento intrusione BiLSTM–Blockchain esteso. Questo file supplementare contiene il pseudocodice completo per la pipeline di preprocessing (Algoritmo 1), il rilevamento esteso di intrusioni BiLSTM (Algoritmo 2), l'addestramento del modello con stop precoce (Algoritmo 3), il rilevamento e la mitigazione delle intrusioni basate su blockchain (Algoritmo 4), la selezione delle caratteristiche AQU-IMF-RFE (Algoritmo 5) e la procedura di registrazione delle intrusioni smart-contract (Algoritmo 6). Clicca qui per scaricare questo file.

Fascicolo supplementare 2. Codice sorgente per il framework proposto per il rilevamento intrusione BiLSTM–Blockchain esteso. Questo file supplementare contiene l'implementazione completa della pipeline di pre-elaborazione, del modello BiLSTM esteso, dell'addestramento e della valutazione del modello, della pipeline di esecuzione end-to-end, del client blockchain e degli script di generazione delle figure necessari per riprodurre i risultati riportati. Clicca qui per scaricare questo file.

Fascicolo supplementare 3. Procedure dettagliate di implementazione e ottimizzazione per il framework proposto per il rilevamento intrusione BiLSTM–Blockchain esteso. Questo file supplementare fornisce dettagli di implementazione omessi dal Protocollo principale per brevità, inclusi (A) Ottimizzazione dell'addestramento BiLSTM estesa e formulazione matematica (obiettivo di addestramento, ottimizzazione Adam, stop precoce e configurazione degli iperparametri); (B) implementazione dettagliata di reti neurali (Conv1D, BiLSTM impilato, proiezione residua, meccanismo di attenzione, inizializzazione dei pesi, dropout e impostazioni di classificazione); (C) implementazione della blockchain e smart contract; (D) procedure di generazione e verifica della firma digitale; (E) elaborazione degli eventi tramite smart contract e flusso di lavoro di risposta automatizzata; e (F) interpretazione dell'analisi della complessità computazionale. Questi dettagli supportano la piena riproducibilità del quadro proposto mantenendo la leggibilità del Protocollo principale. Clicca qui per scaricare questo file.

README.
Istruzioni per riprodurre il flusso di lavoro proposto. Questo file fornisce istruzioni per l'installazione del software, preparazione del dataset, esecuzione dell'intera pipeline di elaborazione, addestramento del modello, valutazione, generazione di figure, implementazione della blockchain e linee guida sulla riproducibilità del framework proposto.

requirements.txt
Dipendenze software per la riproduzione dell'ambiente computazionale. Questo file elenca le dipendenze dei pacchetti Python e i requisiti di versione compatibile necessari per eseguire i componenti di preprocessing, addestramento del modello, valutazione, blockchain e visualizzazione del framework proposto.

Discussion

Il presente studio propone un framework integrato Extended BiLSTM–Blockchain per il rilevamento e la prevenzione delle intrusioni negli ambienti IoMT. I risultati dimostrano che il framework identifica efficacemente i modelli di intrusione nel traffico eterogeneo di rete IoMT combinando apprendimento temporale bidirezionale con logging forense basato su blockchain. L'architettura bidirezionale consente al modello di catturare sia dipendenze temporali in avanti che all'indietro all'interno del traffico di rete, ottenendo un'alta precisione (99,44%), un richiamo del 98,54% e un punteggio F1 del 98,99% per la classe di intrusione, mantenendo comunque un basso tasso di falsi positivi (circa 1,0%) rispetto ai modelli di rilevamento delle intrusioni di base valutati. A differenza delle architetture LSTM unidirezionali convenzionali o di baseline, che potrebbero non catturare dipendenze temporali a lungo raggio, il modello proposto riconosce in modo più efficace i modelli di traffico sequenziali, migliorando la discriminazione tra traffico di rete benigno e malevolo. Questi risultati supportano l'ipotesi dello studio secondo cui integrare un rilevatore Extended BiLSTM con attenzione potenziata con uno strato di logging blockchain migliora sia le prestazioni di rilevamento delle intrusioni sia la responsabilità forense.

Il quadro proposto può essere inserito in diverse direzioni di ricerca consolidate. Una linea di ricerca si concentra sul rilevamento di intrusioni potenziato per la selezione delle caratteristiche per sistemi IoMT, inclusi approcci basati su alberi e^{filtri 8}, rivelatori di apprendimento in ensemble⁹ e il nostro precedentemente riportato framework di selezione delle caratteristiche AQU-IMF-RFE¹⁸. Questi approcci migliorano la precisione del rilevamento attraverso la riduzione della dimensionalità, ma generalmente si basano su classificatori che non modellano esplicitamente le dipendenze temporali bidirezionali nel traffico di rete. Il framework proposto integra piuttosto che sostituire questi metodi utilizzando AQU-IMF-RFE¹⁸ per costruire uno spazio di funzionalità ottimizzato, sul quale l'Extended BiLSTM esegue il rilevamento di intrusioni temporali mentre il livello blockchain fornisce logging forense immutabile. Una seconda linea di ricerca impiega modelli di apprendimento delle sequenze per il rilevamento di intrusioni, inclusi le architetture BiLSTM potenziate^{dall'attenzione 7}, IDSs di rete basate su BiLSTM³¹ e approcci di reti neurali^{ricorrenti 32,33}. In linea con questi studi, i risultati attuali confermano il valore della modellazione temporale bidirezionale, con il BiLSTM esteso aumentato di attenzione che ha ottenuto punteggi F1 più alti rispetto alle basi LSTM e CNN valutate in questo studio. A differenza di questi modelli focalizzati sul rilevamento, tuttavia, il framework proposto incorpora anche la registrazione blockchain a prova di manomissione. Una terza direzione di ricerca esplora la sicurezza basata su blockchain per sistemi sanitari e IoT, inclusi architetture sanitarie abilitate blockchain e integrità^forense 28,34,35, controllo di accesso blockchain ^{autorizzato 36,37} e rilevamento di intrusioni federate guidato dalla blockchain per IoMT³⁸. Sebbene questi studi dimostrino il valore dell'immutabilità e dell'auditabilità, generalmente trattano la rilevazione delle intrusioni e la registrazione forense come processi separati o impiegano meccanismi di consenso più intensivi dal punto di vista computazionale. Al contrario, il framework proposto integra direttamente una blockchain PoA leggera e autorizzata con il rilevatore di intrusioni per fornire logging immutabile e mitigazione guidata dagli eventi, mantenendo al contempo un basso overhead computazionale. Rispetto ai recenti approcci di deep learning IoMT, tra cui il rilevamento di^{intrusioni basato su feature engineering 39} e l'apprendimento federato per l'IoT^{medico 40}, il contributo principale del presente studio è l'integrazione del rilevamento temporale bidirezionale con la tracciabilità forense basata su blockchain all'interno di un quadro unificato, piuttosto che i miglioramenti della sola precisione del rilevamento.

L'integrazione blockchain aggiunge importanti capacità di fiducia, responsabilità e forensi al quadro proposto. I record blockchain immutabili garantiscono che gli eventi di intrusione non possano essere modificati dopo la registrazione, supportando così la conformità normativa e l'audit forense negli ambienti sanitari. Ogni evento registrato memorizza identificatori di dispositivo, timestamp, hash crittografici e firme digitali che facilitano la verifica trasparente e la tracciabilità. Inoltre, il livello smart-contract consente una mitigazione automatizzata guidata dagli eventi generando flag di isolamento dei nodi e avvisi amministratori che vengono elaborati da un listener off-chain, riducendo così i tempi di risposta preservando un record auditabile di ogni evento di sicurezza. Nel complesso, queste capacità estendono il framework oltre il rilevamento convenzionale delle intrusioni, integrando rilevamento, logging sicuro e risposta automatica all'interno di un'unica architettura.

Devono essere riconosciute diverse limitazioni del presente studio. Metodologicamente, la valutazione del modello è stata effettuata utilizzando una singola divisione stratificata di hold-out con un seed casuale fisso (42) invece di ripetute validazioni incrociate o inizializzazioni multiple casuali. Gli iperparametri sono stati selezionati da valori predefiniti stabiliti piuttosto che tramite una procedura di ottimizzazione esaustiva. La valutazione sperimentale si è basata su tre dataset di benchmark pubblicamente disponibili (UNSW-NB15, CICIDS2017 e Bot-IoT)41,42,43, che, sebbene ampiamente accettati, rappresentano catture di traffico statico piuttosto che traffico di rete in continua evoluzione. Il loro squilibrio intrinseco di classe può anche influenzare le prestazioni del modello nonostante l'applicazione di un addestramento con i pesi di classe. Inoltre, l'architettura BiLSTM estesa contiene più parametri addestrabili e richiede tempi di addestramento più lunghi rispetto alle basi convenzionali del machine learning grazie alla sua struttura ricorrente bidirezionale e al meccanismo di attenzione. Sebbene la latenza di inferenza misurata supporti il deployment in tempo reale sulla workstation di valutazione, i requisiti computazionali e di memoria possono superare le capacità dei dispositivi edge IoMT con risorse limitate, rendendo più pratica la distribuzione a livello di gateway o basata su server. Il framework presuppone inoltre che il rilevamento delle intrusioni e la registrazione della blockchain avvengano presso nodi gateway affidabili e che i nodi validatori PoA autorizzati si comportino onestamente. Il logging della blockchain introduce una latenza media di conferma di circa 2 s, e la crescita del registro a lungo termine può diventare un problema di scalabilità nelle implementazioni su larga scala. L'assunzione del validatore affidabile è una caratteristica intrinseca delle blockchain PoA^{autorizzate 24,25}, mentre sfide più ampie alla sicurezza blockchain sono state esaminate^altrove. Di conseguenza, mitigare la collusione dei validatori tra le implementazioni multi-istituzionali rimane un tema importante per future indagini. Infine, sebbene le statistiche di preprocessing siano state derivate esclusivamente dalla partizione di addestramento per evitare la fuga di informazioni, l'uso di dataset di benchmark offline preprocessati invece del traffico di rete in tempo reale può sovrastimare la capacità pratica, e artefatti noti di etichettatura e campionamento all'interno dei dataset benchmark possono introdurre bias specifici per il dataset. Sebbene il meccanismo di attenzione offra un certo grado di interpretabilità, il quadro rimane in gran parte una scatola nera di deep learning, potenzialmente limitando la trasparenza per clinici e analisti di sicurezza che necessitano di più allerte interpretabili. Questa limitazione è coerente con le osservazioni riportate in precedenti indagini di rilevamento di intrusioni di deep^{learning 6,11,44}.

Esistono diverse opportunità per ampliare ulteriormente il quadro proposto. La validazione su banc di prova IoMT attivi o su reti ospedaliere operative fornirebbe ulteriori prove di prestazioni reali oltre ai dataset di benchmark offline. L'implementazione della blockchain potrebbe essere estesa dall'attuale prototipo a singolo nodo a una distribuzione multivalidator distribuita per consentire una valutazione completa della scalabilità. Le tecniche di compressione, potatura o quantizzazione dei modelli possono facilitare il deployment su dispositivi edge con risorse limitate. Ulteriori ricerche potrebbero anche includere l'apprendimento online per affrontare il concept drift e gli attacchi^{zero-day 45}, l'apprendimento federato per consentire la formazione collaborativa su modelli tra istituzioni sanitarie senza condividere dati sensibili^{dei pazienti 40}, e metodi di IA spiegabili per fornire allerti di intrusione più trasparenti per clinici e personale di cybersecurity.

Nel complesso, il framework proposto Extended BiLSTM–Blockchain dimostra una forte adattabilità, responsabilità forense e robuste prestazioni di rilevamento delle intrusioni. Integrando l'apprendimento temporale potenziato dall'attenzione con logging immutabile della blockchain e mitigazione automatica, il framework combina un'elevata accuratezza di rilevamento con una tracciabilità forense sicura e bassi tassi di falsi positivi. Questi risultati dimostrano il potenziale dell'approccio proposto come metodo pratico per garantire la sicurezza di ambienti IoMT in tempo reale, supportando al contempo audit affidabili e una risposta tempestiva alla sicurezza nei sistemi sanitari.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
AQU-IMF-RFE Feature Selection Module	Sviluppato internamente	N/A	Metodo di selezione delle caratteristiche ibrido che integra Mutual Information, Aquila Optimizer e Recursive Feature Elimination
Attention Layer	Sviluppato internamente (basato su Keras)	N/A	Meccanismo di attenzione temporale utilizzato per il ponderamento delle caratteristiche nel modello Extended BiLSTM
Bot-IoT Dataset	UNSW Canberra Cyber	N/A	Dataset di riferimento pubblico utilizzato per la valutazione del rilevamento delle intrusioni
CICIDS2017 Dataset	Canadian Institute for Cybersecurity	N/A	Dataset di riferimento pubblico per il rilevamento delle intrusioni
Ethereum Client (Geth)	Ethereum Foundation	1.13.15	Client blockchain utilizzato per distribuire e gestire la rete Proof-of-Authority
Extended BiLSTM Model	Sviluppato internamente	N/A	Modello di rilevamento delle intrusioni basato su deep learning che integra Conv1D, BiLSTM, apprendimento residuale e attenzione temporale
Jupyter Notebook	Project Jupyter	7.x	Ambiente interattivo utilizzato per l'implementazione, la sperimentazione e la visualizzazione dei risultati
NumPy	NumPy Developers	2.4.4	Libreria di calcolo numerico utilizzata per la pre-elaborazione e l'addestramento del modello
Pandas	Pandas Development Team	3.0.2	Libreria di elaborazione dei dati utilizzata per la pre-elaborazione e l'analisi dei dati
Proof-of-Authority Blockchain Network	Sviluppato internamente	N/A	Rete blockchain autorizzata utilizzata per la registrazione immutabile delle intrusioni e la mitigazione automatizzata
Python	Python Software Foundation	3.12.7	Lingua di programmazione utilizzata per la pre-elaborazione dei dati, lo sviluppo dei modelli, l'integrazione blockchain e la valutazione
Random Forest Estimator	Scikit-learn Developers	N/A	Classificatore Random Forest utilizzato per Recursive Feature Elimination (RFE)
Scikit-learn	Scikit-learn Developers	1.8.0	Libreria di apprendimento automatico utilizzata per la pre-elaborazione, la selezione delle caratteristiche e la valutazione del modello
Solidity Compiler (solc)	Solidity Team	0.8.19	Compilatore utilizzato per la compilazione e l'implementazione di smart contract
Solid-State Drive (SSD)	Dell	512 GB	Archiviazione utilizzata per i dataset, i modelli addestrati e il registro blockchain
System Memory (RAM)	Dell	128 GB	Memoria principale utilizzata durante la pre-elaborazione, l'addestramento del modello, l'esecuzione blockchain e la valutazione
TensorFlow	Google	2.16.1	Framework di apprendimento profondo utilizzato per implementare e addestrare il modello Extended BiLSTM
UNSW-NB15 Dataset	UNSW Canberra Cyber	N/A	Dataset di riferimento pubblico utilizzato per l'addestramento e la valutazione
Web3.py	Web3.py Developers	6.15.1	Interfaccia Python utilizzata per la comunicazione tra il sistema di rilevamento delle intrusioni e la rete blockchain
Windows Operating System	Microsoft	Windows 11	Sistema operativo utilizzato per tutti gli esperimenti
Workstation / Server	Dell	PowerEdge R740	Piattaforma di calcolo utilizzata per l'addestramento dei modelli, l'implementazione della blockchain e la valutazione