Rede de Memória Bidirecional Integrada a Blockchain de Curto Prazo para Detecção de Intrusões em Tempo Real na Internet de Saúde de Coisas Médicas

Resumo

Este protocolo descreve a implementação de um sistema de detecção de intrusões de memória bidirecional de curto prazo integrado em blockchain para redes da Internet das Coisas Médicas em saúde, permitindo detecção de ataques em tempo real, registro forense à prova de adulteração e mitigação automatizada.

Resumo

Ambientes de Internet das Coisas Médicas (IoMT) em saúde exigem sistemas de detecção de intrusões que não apenas identifiquem ciberataques com precisão, mas também ofereçam responsabilidade forense, auditoria e capacidades de resposta rápida. Abordagens convencionais de detecção de intrusão enfatizam principalmente o desempenho da classificação, oferecendo suporte limitado para registro de eventos à prova de adulteração e investigação pós-incidente. Este estudo apresenta uma estrutura de detecção de intrusões com consciência forense que integra uma rede Bidirecional Estendida de Memória de Curto Prazo (BiLSTM) com uma camada de blockchain com permissão para suportar detecção em tempo real, registro seguro e mitigação automatizada em sistemas IoMT de saúde. O protocolo combina pré-processamento de dados, seleção de recursos AQU-IMF-RFE, modelagem de sequências temporais, aprendizado baseado em atenção, conexões residuais e gravação de eventos baseada em blockchain. O modelo BiLSTM Estendido foi treinado e avaliado independentemente nos conjuntos de dados de referência UNSW-NB15, CICIDS2017 e Bot-IoT usando pré-processamento reproduzível, particionamento de dados estratificado e sementes aleatórias fixas. Eventos de intrusão detectados pelo modelo foram registrados em uma blockchain de Prova de Autoridade por meio de contratos inteligentes que permitiam registros imutáveis e ações de resposta automatizada. Os resultados experimentais demonstraram alto desempenho em detecção de intrusões com baixas taxas de falsos positivos em todos os conjuntos de dados avaliados, mantendo rastreabilidade forense e capacidade de resposta em tempo real. A camada blockchain fornecia registros de auditoria resistentes a adulteração e mitigação automatizada sem introduzir uma sobrecarga computacional proibitiva. Essas descobertas demonstram que a integração da detecção de intrusões baseada em deep learning com o logging forense habilitado por blockchain melhora a confiabilidade, responsabilidade e implantabilidade prática dos sistemas de cibersegurança em saúde.

Introdução

No sistema de saúde, a digitalização levou a uma nova era de serviços de saúde inteligentes, conectados e centrados no paciente. A infraestrutura médica moderna depende fortemente da comunicação em rede e da troca de dados entre sensores vestíveis, sistemas remotos de monitoramento de pacientes, prontuários eletrônicos de saúde (EHRs^)1,2 e plataformas inteligentes de diagnóstico. No entanto, essa interconectividade crescente também expande a superfície de ataque das redes de saúde, expondo-as a ameaças cibernéticas como vazamentos de dados, ransomware, ataques de negação de serviço distribuída (DDoS) e ataques^{man-in-the-middle 3}. Essas intrusões resultam em perdas financeiras substanciais e, mais importante, podem colocar em risco a segurança do paciente quando dados médicos sensíveis ou funcionalidades críticas de dispositivos são comprometidas.

A escala e complexidade dos sistemas da Internet das Coisas Médicas (IoMT) agravam ainda mais esses desafios de segurança. Redes modernas de saúde devem fornecer simultaneamente comunicação de baixa latência, alta confiabilidade e garantias robustas de segurança, requisitos que os mecanismos tradicionais de segurança frequentemente têm dificuldade em^{satisfazer 4}. O rápido crescimento do tráfego IoMT, caracterizado por fontes de dados heterogêneas, padrões de comunicação dinâmicos e exigências regulatórias rigorosas, como a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA) e o Regulamento Geral de Proteção de Dados (GDPR), exige sistemas inteligentes de detecção de intrusões (IDSs) capazes de alcançar altas taxas de detecção enquanto minimizam alarmes^{falsos 5}.

Em ambientes de saúde regulados, a detecção de intrusões não é apenas um requisito operacional, mas também uma função de responsabilização. Alertas de segurança podem acionar o isolamento do dispositivo, afetar a continuidade do cuidado e, posteriormente, se tornar alvo de auditorias, revisões regulatórias ou investigações legais. Consequentemente, um IDS IoMT eficaz deve fornecer detecção precisa em tempo real, decisões explicáveis que apoiem a triagem de incidentes e registros à prova de adulteração que garantam não repúdio e rastreabilidade^{forense 6}. Esse requisito desloca o objetivo da detecção de intrusões da classificação centrada em desempenho para uma governança de segurança centrada na confiança e na responsabilidade.

Técnicas de aprendizado profundo, particularmente redes de Memória de Curto Prazo Longo (LSTM) e Memória Bidirecional de Curto Prazo (BiLSTM), demonstraram forte capacidade em modelar dependências temporais dentro do tráfego de rede e detectar comportamentos anômalos⁷. No entanto, os IDSs baseados em BiLSTM existentes frequentemente sofrem com superajuste, atenção insuficiente a eventos temporais críticos e generalização limitada em dispositivos IoMT heterogêneos e ambientes de saúde. Além disso, as redes IoMT estão expostas a uma ampla gama de ameaças cibernéticas que afetam a Confidencialidade, Integridade e Disponibilidade (CIA) de dados e serviços médicos, conforme resumido na Tabela 1.

Tipo de Ataque	Contexto do IoMT	Dimensão da CIA Afetada	Impacto nos Sistemas de Saúde
Acesso NãoAutorizado 19	Exploração de mecanismos fracos de autenticação para acessar dispositivos de pacientes ou prontuários médicos	Confidencialidade, Integridade	Vazamento de dados e controle não autorizado de dispositivos médicos
Falsificação / Personificação19	Dispositivo malicioso imita um nó legítimo do IoMT	Integridade	Leituras falsas que podem levar a diagnósticos errados ou tratamentos inseguros
Escuta21	Interceptação de dados médicos não criptografados durante a transmissão	Confidencialidade	Violações de privacidade e exposição de informações sensíveis de pacientes
Manipulação de Dados / Exploits de Firmware19	Modificação do firmware do dispositivo ou dados de saúde transmitidos	Integridade	Diagnóstico incorreto ou decisões terapêuticas inadequadas
Ransomware20	Criptografia de dados de pacientes ou firmware de dispositivos médicos	Disponibilidade, Integridade	Bloqueio de sistemas críticos e atrasos no tratamento
Negação de Serviço (DoS) / Negação de Serviço Distribuída (DDoS)6	Sobrecarga de dispositivos médicos ou redes de saúde	Disponibilidade	Interrupção do serviço afetando sistemas de monitoramento e operações da unidade de terapia intensiva (UTI)
Ataques por CanalLateral 22	Extração de chaves criptográficas por meio de técnicas de temporização ou análise de energia	Confidencialidade	Comprometimento de dispositivos e roubo de chaves criptográficas

Tabela 1: Ataques cibernéticos comuns que afetam ambientes de saúde da Internet das Coisas Médicas. Esta tabela resume ataques cibernéticos representativos que têm como alvo sistemas da Internet das Coisas Médicas (IoMT), seu contexto operacional, as dimensões de segurança de Confidencialidade, Integridade e Disponibilidade (CIA) afetadas, e seu impacto potencial na prestação de serviços de saúde, segurança do paciente e operação de dispositivos médicos.

A tecnologia blockchain oferece várias vantagens que podem complementar a detecção de intrusões em ambientes IoMT. Como resumido na Tabela 2, blockchain permite o registro imutável de eventos para validação forense, facilita mitigação automatizada por meio de contratos inteligentes, remove pontos únicos de falha por meio de operações descentralizadas e apoia a conformidade com as regulamentações de proteção de dados em saúde mantendo trilhas de auditoria rastreáveis. Apesar desses benefícios, os mecanismos de segurança baseados em blockchain continuam subutilizados nos IDSs de saúde.

Característica	Descrição	Benefícios no Contexto da Saúde
Integridade dos Dados	Cada transação é criptograficamente hashada e vinculada ao bloco anterior	Garante a imutabilidade dos registros de pacientes e dispositivos
Detecção de Adulteração	Qualquer modificação nos dados armazenados altera o hash do bloco e invalida a cadeia	Permite detecção rápida de modificação não autorizada de registros
Controle de Acesso	Contratos inteligentes aplicam permissões e políticas de autorização pré-definidas	Restringe o acesso a informações sensíveis de saúde a usuários autorizados e dispositivos
Proveniência dos Dados	Cada evento é assinado digitalmente e com carimbo de data e hora	Apoia rastreabilidade forense, auditoria e conformidade regulatória
Consenso de Baixa Latência	O mecanismo de consenso Proof-of-Authority (PoA) permite validação rápida de transações com menor sobrecarga computacional do que a Proof-of-Work	Suporta registro de eventos quase em tempo real em ambientes críticos de saúde

Tabela 2: Benefícios da tecnologia blockchain para sistemas de detecção de intrusões na Internet das Coisas Médicas na saúde. Esta tabela resume as principais funcionalidades do blockchain e seus benefícios associados em ambientes de Internet das Coisas Médicas (IoMT) em saúde. As capacidades listadas suportam registros imutáveis, detecção de adulteração, controle de acesso, procedência de dados e mecanismos de consenso de baixa latência necessários para a detecção segura e auditável de intrusões.

Além da avaliação de desempenho, a integração com blockchain oferece proteção contra múltiplas ameaças de segurança em ambientes IoMT. A Tabela 3 resume os pontos fortes e limitações do blockchain nesse contexto, destacando ameaças que são efetivamente mitigadas, como manipulação e rejeição de dados, e ameaças que exigem salvaguardas adicionais. A camada blockchain suporta registro de baixa latência adequado para ambientes de saúde em tempo real, resiliência bizantina contra nós defeituosos ou maliciosos, e escalabilidade em redes hospitalares distribuídas e dispositivos IoMT.

Ameaça à Segurança	Resolvido pelo Blockchain?	Mecanismo	Notas
Manipulação de Dados27	Sim	Ligação de hash criptográfica	Qualquer modificação invalida a integridade da cadeia
Repudiação 26	Sim	Assinaturas digitais associadas a cada bloco	Previne a negação de eventos de intrusão registrados
FalhaCentralizada 25	Sim	Livro-razão distribuído mantido entre gateways autorizados	Elimina um único ponto de falha
Ataque Sybil24	Parcial	Consenso de Procuração Autorizado exigindo validadores confiáveis	Pode ser mitigado por meio da autorização de validador baseada em identidade
51% Ataque23	Parcial	Requer o comprometimento da maioria dos validadores autorizados	Menos provável em implantações privadas de blockchain PoA
Proveniência dos Dados26	Sim	Registros de eventos com carimbo de data e assinatura digital	Apoia rastreabilidade forense e conformidade regulatória

Tabela 3: Ameaças de segurança abordadas pela integração do blockchain em ambientes de Internet das Coisas Médicas em saúde. Esta tabela resume as principais ameaças de segurança relevantes para sistemas da Internet das Coisas Médicas (IoMT) e indica até que ponto a tecnologia blockchain mitiga cada ameaça. Os mecanismos de proteção subjacentes e as considerações de implementação são fornecidos para cada categoria de ameaça.

A maioria dos IDSs existentes depende de regras pré-definidas ou modelos leves de aprendizado^{de máquina 8,9}. Embora tais abordagens possam identificar padrões de ataque conhecidos, elas frequentemente têm dificuldades para lidar com a natureza dinâmica e em constante evolução das ameaças cibernéticas modernas. Eles são particularmente inadequados para garantir infraestruturas de saúde baseadas em IoMT em rápido crescimento, onde alarmes falsos, adaptabilidade limitada e baixa auditabilidade podem afetar significativamente a eficiência operacional. Sistemas baseados em regras frequentemente geram altas taxas de falsos positivos porque não conseguem distinguir de forma confiável anomalias benignas de ataques^{genuínos 9}. Modelos convencionais de aprendizado de máquina treinados com conjuntos de dados estáticos ou desatualizados, assim como as abordagens existentes de detecção de intrusões baseadas em deep learning, frequentemente falham em generalizar comportamentos emergentes de ataque, incluindo intrusões^{zero-day 10,11}. Além disso, as abordagens tradicionais de registro centralizado continuam vulneráveis a adulterações, limitando assim a confiabilidade das investigações forenses^{pós-incidente 12}. Muitas soluções IDS existentes também impõem um overhead computacional substancial, tornando-as difíceis de implantar em dispositivos e gateways IoMT com recursos^{limitados 13}. Como resultado, os ambientes IoMT em saúde continuam vulneráveis a ataques cibernéticos sofisticados e em múltiplas etapas. Enfrentar esses desafios exige uma estrutura inteligente, segura e eficiente em recursos, capaz de aprender padrões temporais de tráfego em tempo real, ao mesmo tempo em que garante confiabilidade forense e mitigação automática das ameaças detectadas.

Apesar dos avanços significativos em aprendizado de máquina e detecção de intrusões baseada em deep learning, permanecem várias lacunas críticas. Primeiro, muitos modelos IDS existentes são desenvolvidos e avaliados usando conjuntos de dados estáticos e, portanto, carecem de adaptabilidade a comportamentos de ataque em constante evolução. Segundo, embora arquiteturas avançadas de deep learning possam melhorar a precisão da detecção, elas frequentemente oferecem interpretabilidade limitada e falham em priorizar padrões de tráfego clinicamente importantes. Terceiro, e mais importante, os atuais frameworks de IDS geralmente não fornecem suporte intrínseco para confiabilidade forense, auditabilidade ou manutenção de registros imutável, capacidades essenciais para conformidade regulatória, investigação de incidentes e responsabilidade legal nos sistemas de saúde.

Embora os mecanismos de registro baseados em blockchain ofereçam integridade e transparência dos dados, raramente são integrados de forma coesa com modelos avançados de detecção de intrusões baseados em deep learning em ambientes IoMT sensíveis à latência. Estudos existentes normalmente focam em melhorar o desempenho da detecção sem abordar a integridade forense ou em mecanismos de segurança baseados em blockchain sem incorporar detecção avançada de anomalias temporais. Consequentemente, permanece uma lacuna significativa no desenvolvimento de uma estrutura unificada capaz de fornecer simultaneamente detecção de intrusões espaço-temporais em tempo real, registro forense à prova de adulteração, mitigação automatizada e implantação prática em ambientes IoMT de saúde heterogêneos e com recursos limitados.

Motivado por esses desafios, este estudo visa desenvolver uma estrutura de detecção de intrusões que aprimore as redes BiLSTM por meio de mecanismos de atenção e camadas personalizadas para melhorar a priorização de características temporais, integre tecnologia blockchain para registro de intrusões seguro e verificável e resposta automatizada, e opere de forma eficiente em ambientes de IoMT em tempo real em saúde. Hipotetizamos que integrar uma arquitetura BiLSTM Estendida aprimorada com atenção com registros forenses baseados em blockchain e mecanismos automatizados de mitigação aumentará a eficácia da detecção de intrusões, ao mesmo tempo em que proporciona a auditoriabilidade, confiabilidade e responsabilidade necessárias em ambientes de saúde regulados.

Este trabalho aborda uma lacuna fundamental na pesquisa de segurança do IoMT ao tratar a detecção de intrusões como um problema de responsabilidade forense, e não apenas como um problema de classificação. A estrutura proposta integra detecção impulsionada por inteligência artificial (IA), registro imutável de eventos e mecanismos automatizados de resposta em uma arquitetura unificada que apoia a segurança clínica, conformidade regulatória e confiança operacional. A crescente adoção de dispositivos IoMT e infraestruturas de saúde conectadas à nuvem tornou as redes de saúde alvos atraentes para ataques cibernéticos, incluindo ransomware, manipulação de dados, acesso não autorizado e ataques de negação de serviço que ameaçam a confidencialidade, integridade e disponibilidade das informações dos pacientes. O framework BiLSTM–Blockchain Estendido proposto estabelece um processo de segurança em circuito fechado que conecta a detecção de ataques diretamente à validação forense e mitigação automatizada.

As principais contribuições deste estudo são cinquenta. Primeiro, um modelo de detecção de intrusões temporais clinicamente alinhado é desenvolvido estendendo uma arquitetura BiLSTM convencional com aprendizado temporal bidirecional, conexões residuais, mecanismos de atenção e camadas personalizadas para melhorar a detecção de padrões complexos de ataque no tráfego da rede de saúde. Segundo, uma camada de segurança leve baseada em blockchain está integrada ao modelo BiLSTM Estendido para fornecer registros imutáveis, seguros e à prova de adulteração de eventos de intrusão e ações do sistema. Terceiro, um pipeline IDS em tempo real de ponta a ponta é desenvolvido para ambientes de saúde, permitindo análise de tráfego ao vivo e previsão de intrusões com baixa latência e alta precisão. Quarto, o framework proposto é avaliado de forma abrangente usando três conjuntos de dados de referência públicos disponíveis, a saber: UNSW-NB15, CICIDS2017 e Bot-IoT. Por fim, a arquitetura foi projetada como uma estrutura de edge cloud escalável e extensível, adequada para implantação prática em redes de saúde, infraestruturas médicas e aplicações de e-saúde.

Ao combinar as capacidades de aprendizado temporal das redes BiLSTM Estendidas com a confiança e imutabilidade proporcionadas pela tecnologia blockchain, a estrutura proposta oferece um IDS seguro e confiável, adaptado às necessidades em evolução de cibersegurança dos ambientes de saúde. A estrutura preenche lacunas críticas na segurança das redes de saúde e estabelece uma base para uma adoção mais ampla da integração de IA e blockchain na proteção de infraestruturas críticas de saúde.

Protocolo

Todos os experimentos foram conduzidos exclusivamente usando conjuntos de dados de intrusão de rede de referência públicos (UNSW-NB15, CIC-IDS-2017 e Bot-IoT), que contêm registros de tráfego de rede sem informações pessoais ou médicas identificáveis. Os conjuntos de dados foram usados de acordo com suas respectivas licenças e termos de uso. Como não houve participantes humanos, amostras de pacientes ou dados pessoais identificáveis envolvidos, não foi necessário aprovação ética institucional nem consentimento informado.

Visão geral do Quadro Proposto
Esta seção apresenta a proposta de estrutura de detecção e prevenção de intrusão em duas camadas para proteger ambientes IoMT. A estrutura integra uma rede BiLSTM Estendida para detecção de intrusões espaço-temporais com uma camada de blockchain leve para registro à prova de adulteração e mitigação automatizada. Ao contrário das abordagens convencionais de IDS, que focam exclusivamente na precisão da detecção, a arquitetura proposta é projetada para suportar simultaneamente detecção em tempo real, responsabilidade forense e conformidade regulatória, requisitos essenciais em sistemas de saúde. O fluxo de trabalho geral e a arquitetura do framework de detecção de intrusão BiLSTM–Blockchain proposto para redes IoMT são ilustrados na Figura 1.

Figura 1. Arquitetura do framework proposto de detecção de intrusão BiLSTM–Blockchain estendido para redes da Internet das Coisas Médicas. Representação esquemática da estrutura proposta mostrando os fluxos de trabalho de treinamento e implantação. No fluxo de trabalho de treinamento, dispositivos da Internet das Coisas Médicas (IoMT) geram tráfego de rede que passa por pré-processamento de dados e engenharia de recursos antes de serem analisados pelo modelo Bidirecional de Memória Prolongada de Curto Prazo (BiLSTM) com atenção temporal. Os parâmetros do modelo são otimizados por meio de computação da função de perda e treinamento iterativo. No fluxo de trabalho de implantação, o modelo treinado realiza a detecção de intrusão de acordo com a função de decisão definida na Equação 13. Eventos de intrusão detectados são encaminhados para o módulo blockchain, onde são realizados registros imutáveis, isolamento de nós e geração de alertas por parte dos administradores. BiLSTM, Memória Bidirecional de Curto Prazo Longo; IoMT, Internet das Coisas Médicas. Por favor, clique aqui para ver uma versão ampliada desta figura.

Dispositivos IoMT geram fluxos de dados heterogêneos compostos por tráfego de rede, metadados de dispositivos e sinais relacionados ao paciente. Tais entradas brutas são frequentemente ruidosas, redundantes e inconsistentes, tornando-as inadequadas para treinamento direto do modelo. Portanto, um pipeline de pré-processamento é aplicado para garantir a qualidade e a estrutura dos dados antes de introduzi-los no modelo BiLSTM Estendido. O pseudocódigo detalhado de pré-processamento é fornecido no Algoritmo 1 (Arquivo Suplementar 1), que descreve o pipeline de pré-processamento aplicado aos fluxos de dados IoMT antes do treinamento BiLSTM Estendido (pseudocódigo no Arquivo Suplementar 1; implementação no Arquivo Suplementar 2). A arquitetura completa do BiLSTM Estendido está resumida no Algoritmo 2 (Arquivo Suplementar 1).

Fluxo de Trabalho de Reprodução End-To-End
O estudo completo pode ser reproduzido usando os passos abaixo. Software e hardware estão listados na Configuração Experimental, e o código suplementar cobre cada etapa.

Obtenha os conjuntos de dados → baixe o UNSW-NB15. Use os arquivos UNSW_NB15_training-set.csv e UNSW_NB15_testing-set.csv. Baixe CICIDS2017. Use os cinco arquivos diurnos do Machine LearningCSV (de segunda a sexta-feira). Baixe Bot-IoT. Use os arquivos de subconjunto de 5 % UNSW_2018_IoT_Botnet_Full5pc_1_to_4. Estudos anteriores de detecção de intrusão geralmente se baseavam em conjuntos de dados de referência como KDD Cup 99¹⁴; no entanto, este estudo utiliza os conjuntos de dados mais recentes UNSW-NB15, CICIDS2017 e Bot-IoT para representar melhor o tráfego de rede contemporâneo. Processe cada conjunto de dados separadamente. O conjunto de dados UNSW-NB15 está disponível na Universidade de New South Wales em https://research.unsw.edu.au/projects/unsw-nb15-dataset (última modificação: 8 de fevereiro de 2024). O conjunto de dados CICIDS2017 está disponível no Instituto Canadense de Cibersegurança em https://www.unb.ca/cic/datasets/ids-2017.html (lançado: julho de 2017). O conjunto de dados Bot-IoT está disponível na Universidade de New South Wales em https://research.unsw.edu.au/projects/bot-iot-dataset (última modificação: 5 de fevereiro de 2024). Todos os conjuntos de dados foram acessados em maio de 2025 para este estudo.

Pré-processar os dados → remover registros corrompidos. Preencha valores faltantes usando meios de conjunto de treinamento. Aplique a redução de ruído EMA (α = 0,3). Normalize as características para [0,1] usando estatísticas do conjunto de treinamento. Códigos de etiqueta e códigos categóricos. Construa janelas deslizantes (T = 20, passada = 1). Essas etapas de pré-processamento suportam uma detecção robusta de intrusões ao reduzir o ruído e melhorar a qualidade das representações do tráfego de rede para IDSs baseados em aprendizado de máquina^15,16.

Selecione características (AQU-IMF-RFE) → Classifique características por informação mútua. Refinar com o Aquila Optimizer. Aplicar RFE de Floresta Aleatória com validação cruzada 10 vezes. Mantenha os recursos finais. Essa estratégia híbrida de seleção de características segue o conceito mais amplo de combinar técnicas complementares de detecção de^{intrusões 17} e é implementada usando a estrutura AQU-IMF-RFE desenvolvida em nosso trabalho^{anterior 18}.

Treine o modelo → Para cada conjunto de dados, os dados foram particionados aleatoriamente em conjuntos de treinamento (80%) e de teste (20%) usando uma semente aleatória fixa de 42. Vinte por cento da partição de treinamento foi ainda reservada como conjunto de validação. Construa o BiLSTM Estendido. Treine usando perda binária ponderada de entropia cruzada e o otimizador Adam (taxa de aprendizado = 0,001, tamanho do lote = 64, máximo de 50 épocas, com parada antecipada). Salve o modelo treinado. O uso de modelos de aprendizado profundo temporal é bem adequado para tráfego heterogêneo do^{IoMT 19}. O fluxo completo de treinamento do modelo está resumido no Algoritmo 3 (Arquivo Suplementar 1). Os pesos finais das classes foram calculados automaticamente a partir das distribuições de classes do conjunto de treinamento de acordo com as Equações 19 e 20. Os pesos de classe resultantes foram os seguintes: UNSW-NB15: , ; CICIDS2017: , ; e Bot-IoT (subconjunto de 5%): , . O grande valor de w_n para o conjunto de dados Bot-IoT reflete a severa sub-representação de amostras benignas na partição de treinamento do subconjunto de 5%.

Implante a blockchain → inicie a cadeia de Prova de Autoridade (PoA). Implante o contrato inteligente e anote seu endereço. Autorize as contas do gateway. Execute o cliente de modo que cada intrusão detectada seja registrada e acione isolamento e alertas. O fluxo completo de detecção, registro de blockchain e mitigação é resumido no Algoritmo 4 (Arquivo Suplementar 1). A camada blockchain foi implementada usando o cliente go-ethereum (Geth) versão 1.13.15 para operar a rede PoA com permissões, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca web3.py versão 6.15.1 para comunicação entre o IDS e a rede blockchain.

Avalie → teste o modelo no conjunto de teste estendido. Calcule precisão, precisão, recall, pontuação F1 e taxa de falsos positivos. Gravar latência e throughput. Verifique a integridade do livro-razão da blockchain. O fluxo completo de avaliação é resumido no Algoritmo 5 (Arquivo Suplementar 1). A latência de detecção (T_d) foi medida imediatamente antes da chamada de inferência do modelo até o momento em que as probabilidades previstas foram retornadas. A latência de mitigação de ponta a ponta (T_d +_{T b}) foi medida do mesmo ponto de partida até a conclusão da transação correspondente de criação de blocos na blockchain. A taxa de transferência foi calculada como o número total de janelas de teste pré-processadas processadas pelo pipeline completo de detecção e registro dividido pelo tempo de relógio de parede decorrido necessário para uma única passagem completa pelo conjunto de testes de cada conjunto de dados. A carga de trabalho consistia nas partições de teste janelas, preservando a distribuição original benigna para intrusão. Janelas maliciosas também geravam a sobrecarga de registro de blockchain, enquanto janelas inofensivas assumiam apenas o custo de detecção de intrusões.

Gerar figuras e tabelas → plotar as curvas de precisão e perda, matriz de confusão e gráficos de avaliação comparativa. Construa as tabelas de comparação. O fluxo completo de geração de figuras e tabelas está resumido no Algoritmo 6 (Arquivo Suplementar 1). O código-fonte completo desenvolvido sob medida usado para gerar todas as figuras e tabelas é fornecido no Arquivo Suplementar 2. Em particular, o script figures.py reproduz as figuras do manuscrito diretamente dos resultados experimentais salvos (por exemplo, histórico de treinamento e arquivos de matriz de confusão), enquanto os scripts restantes geram os dados processados e métricas de desempenho usadas para construir as tabelas reportadas.

A Figura 2 mostra o fluxo de dados em nível de implementação entre os módulos IDS e blockchain. A BiLSTM Estendida produz uma decisão por janela (Equação 13); em uma classificação maliciosa, o cliente gateway constrói e assina uma transação e a submete via web3/JSON-RPC ao smart contract PoA, que adiciona um bloco ligado por hash (Equação 14) ao livro contámbulo imutável e emite eventos (BlockCreated, NodeIsolated e AdminAlert) que acionam o isolamento do nó e alertas de administrador.

Figura 2. Interação em nível de implementação entre módulos de detecção de intrusão e blockchain. Diagrama de fluxo de trabalho ilustrando a comunicação entre o sistema de detecção de intrusão e os componentes da blockchain. O modelo BiLSTM Estendido classifica cada janela de entrada e aplica a regra de decisão definida na Equação 13. Quando uma intrusão é detectada, o cliente gateway gera e assina uma transação que é transmitida por Web3.py/JSON-RPC para o contrato inteligente Proof-of-Authority (PoA). O contrato adiciona um bloco ligado por hash ao livro-razão imutável de acordo com a Equação 14 e emite eventos BlockCreated, NodeIsolated e AdminAlert que acionam ações de contenção e notificação. IDS, Sistema de Detecção de Intrusões; BiLSTM, Memória Bidirecional de Curto Prazo Longo; Procuração, Prova de Autoridade; JSON-RPC, Notação de Objetos em JavaScript–Chamada de Procedimento Remoto. Por favor, clique aqui para ver uma versão ampliada desta figura.

Representação dos Dados
Vamos considerar R como o fluxo bruto de tráfego do IoMT. Após o pré-processamento, cada registro bruto é mapeado em um vetor de características d-dimensional normalizado (Equação 1):

(1)

Aqui, f (⋅) é a função de transformação de características que mapeia registros brutos em um vetor de características normalizado em d dimensões. Seja a rede IoMT composta por um conjunto de nós (Equação 2):

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

Cada nó _{n j} ∈ R produz um fluxo de dados em série temporal (Equação 3):

(3)

Aqui, x_t é o vetor de características no tempo t, com d características (por exemplo, tamanho do pacote, tipo de protocolo, endereço de origem/destino) comumente observadas no tráfego de redes de saúde da Internet das^{Coisas 19}. O conjunto de rótulos correspondente é (Equação 4):

  (4)

Aqui, y_t=0 representa o tráfego normal e y_t =1 denota uma intrusão.

Pré-processamento de dados
O pipeline de pré-processamento inclui as seguintes etapas, que abordam desafios comuns de qualidade de dados e segurança associados ao tráfego^{IoMT 20}:

Limpeza de Dados e Tratamento de Valor Faltante:
Um registro era identificado como corrompido e removido antes da imputação se satisfesse qualquer uma das seguintes condições explícitas: (i) todos os campos de características no registro estavam faltando (ou seja, o registro inteiro era nulo), ou (ii) o registro continha um valor não finito (infinito positivo ou negativo) em qualquer campo numérico após coerção do tipo. A segunda regra remove entradas inválidas, como aquelas produzidas por divisão por zero durante o cálculo de características de fluxo (por exemplo, valores infinitos de vazão decorrentes de fluxos de duração zero). Após a remoção dos registros corrompidos, os valores restantes ausentes foram imputados por meio da substituição média calculada por característica, por conjunto de dados e apenas da partição de treinamento; Os meios resultantes foram aplicados aos conjuntos de treinamento, validação e teste para evitar vazamento de informações. A imputação não foi condicional à classe, e as médias não foram agrupadas entre conjuntos de dados.

Redução de ruído temporal:
A redução de ruído temporal foi realizada usando um filtro de média móvel exponencial por característica (EMA) aplicado ao longo do eixo temporal. A forma recursiva (causal ) y_t = α·x_t + (1 − α)·y_t−1 foi usada, com fator de suavização α = 0,3, implementada via a função ewm do pandas com ajustar=Falso. Cada característica foi suavizada de forma independente. Como um filtro exponencial (resposta infinita ao impulso), a EMA não possui janela fixa ou tamanho de kernel; O fator de suavização α é o único parâmetro que governa o grau de suavização e a memória efetiva do filtro.

Normalização Min–Max:
A normalização min–max foi aplicada para escalar cada característica até a faixa [0,1] usando a transformação x′=(x−min)/(max−min+ε), onde ε = 1 × 10⁻⁸. As estatísticas mínima e máxima eram calculadas por característica, por conjunto de dados e apenas a partir da partição de treinamento; Essas estatísticas de treinamento armazenadas foram então aplicadas para normalizar os conjuntos de treinamento, validação e teste, prevenindo o vazamento de informações ocultas. Durante a inferência, valores de características que ficam fora do alcance de treinamento foram reduzidos ao intervalo [0,1].

Codificação de Características Categóricas:
As características categóricas eram convertidas para forma numérica usando codificação de rótulos. Isso foi aplicado a todas as variáveis categóricas: no UNSW-NB¹⁵, os campos proto, serviço e estado; no Bot-IoT, o campo proto; CICIDS2017 não contém campos categóricos entre as características selecionadas. A codificação foi implementada com o LabelEncoder ajustado por variável.

Janelas Temporais para Aprendizado Sequencial:
O fluxo de características pré-processado foi segmentado em sequências de comprimento fixo usando uma janela deslizante de comprimento T = 20 passos de tempo com um passo de s = 1. Cada janela gerada foi validada antes da inclusão. Uma janela era aceita apenas se ela contivesse exatamente T = 20 passos de tempo consecutivos e todos os valores das características fossem finitos. Fluxos menores que T = 20 registros não produziam janelas. Essa configuração (T = 20, s = 1, 95% de sobreposição) foi aplicada de forma consistente em todos os experimentos e conjuntos de dados. O fluxo completo de pré-processamento é resumido no Algoritmo 1 (Arquivo Suplementar 1).

O objetivo do pré-processamento é permitir um mapeamento preditivo das sequências de entrada para rótulos de intrusão (Equação 5).

(5)

parametrizado por θ, isso prevê se um evento é benigno ou malicioso.

Seleção de Recursos Usando AQU-IMF-RFE
A seleção de características foi realizada usando AQU-IMF-RFE, um método híbrido que integra Informação Mútua (MI), o Aquila Optimizer (AO) e a Eliminação de Características Recursivas (RFE), introduzido em nosso trabalho^{anterior 18}. O método opera em três etapas. Na primeira etapa, a informação mútua entre cada característica e o rótulo da classe é calculada para obter uma classificação inicial de relevância. Na segunda etapa, o Aquila Optimizer realiza uma busca global sobre subconjuntos de características candidatos usando suas quatro estratégias de otimização. No terceiro estágio, o subconjunto refinado é passado por Eliminação de Características Recursivas com validação cruzada 10 vezes usando um estimador de Floresta Aleatória (RF).

O Aquila Optimizer foi configurado com um tamanho populacional de 100, um máximo de 10 iterações, um fator de exploração de 0,1, uma taxa de aprendizado de 0,1 e um fator de atração de 0,005. Aplicado independentemente a cada conjunto de dados, AQU-IMF-RFE manteve 14 recursos para o UNSW-NB15, 24 para CICIDS2017 e 12 para Bot-IoT. O pseudocódigo completo é fornecido no Arquivo Suplementar 1, e os subconjuntos de características selecionados estão listados na Tabela 4.

Tabela 4A. Recursos Selecionados Retidos para o UNSW-NB15
S. Não.	Característica	Tipo	Categoria
1	dur	Numérico (float)	Básico
2	sbytes	Numérico (inteiro)	Básico
3	Taxa	Numérico (float)	Básico
4	dload	Numérico (float)	Básico
5	sinpkt	Numérico (float)	Tempo
6	Dinpkt	Numérico (float)	Tempo
7	Sjit	Numérico (float)	Tempo
8	TCPrtt	Numérico (float)	Tempo
9	Sinaca	Numérico (float)	Tempo
10	ackdat	Numérico (float)	Tempo
11	smean	Numérico (inteiro)	Conteúdo
12	ct_srv_src	Numérico (inteiro)	Conexão
13	ct_dst_src_ltm	Numérico (inteiro)	Conexão
14	ct_srv_dst	Numérico (inteiro)	Conexão
Tabela 4B. Características selecionadas mantidas para CICIDS2017
S. Não.	Característica
1	Porto de destino
2	Duração do Fluxo
3	Comprimento total dos pacotes forwarding
4	Comprimento Total dos Pacotes Reversos
5	Comprimento Máximo de Pacote Encaminhado
6	Comprimento Máximo de Pacote Reverso
7	Média do Comprimento dos Pacotes Invertido
8	Pacotes de Fluxo
9	Tempo Máximo de Inter-Chegada do Fluxo
10	Total de Tempo Inter-Chegada Avançado
11	Comprimento do cabeceio para frente
12	Comprimento do cabeçalho invertido
13	Pacotes Diretos por Segundo
14	Comprimento Máximo do Pacote
15	Média do Comprimento do Pacote
16	Desvio padrão do comprimento do pacote
17	Variância do comprimento do pacote
18	Tamanho médio do pacote
19	Tamanho médio dos segmentos para trás
20	Bytes Diretos do Subfluxo
21	Subfluxo de bytes retroativos
22	Bytes iniciais da janela encaminhados
23	Bytes iniciais da janela ao contrário
24	Média do comprimento do pacote para frente
Tabela 4C. Recursos Selecionados Retidos para Bot-IoT
S. Não.	Característica	Tipo
1	seq	Numeric
2	Média	Numeric
3	StdDev	Numeric
4	min	Numeric
5	Max	Numeric
6	srate	Numérico (float)
7	drate	Numérico (float)
8	N_IN_Conn_P_SrcIP	Numérico (inteiro)
9	N_IN_Conn_P_DstIP	Numérico (inteiro)
10	Proto	Categórico (codificado)
11	state_number	Numérico (inteiro)
12	Taxa	Numérico (float)

Tabela 4: Recursos selecionados pelo método de seleção de características AQU-IMF-RFE. Esta tabela lista os subconjuntos finais de características selecionados pelo framework de seleção de características AQU-IMF-RFE para os conjuntos de dados UNSW-NB15, CICIDS2017 e Bot-IoT. Nomes de características, tipos de dados e categorias funcionais são fornecidos quando aplicável.

Configuração Experimental
Todos os experimentos foram realizados em um servidor Dell PowerEdge R740 equipado com um processador Intel Xeon Silver 4214 operando em uma frequência base de 2,20 GHz, com 12 núcleos físicos, 24 threads lógicas, 16,5 MB de cache e uma velocidade Intel Ultra Path Interconnect (UPI) de 9,6 GT/s. O servidor estava configurado com 128 GB de RAM, um SSD de estado sólido (SSD) de 512 GB e operava no Microsoft Windows 11. A pilha de software compreendia Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 e NumPy 2.4.4. A camada blockchain foi implementada na mesma estação de trabalho usando uma rede Ethereum PoA. A comunicação entre o IDS e a blockchain era realizada via JSON-RPC usando o cliente go-ethereum (Geth) versão 1.13.15, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca Web3.py versão 6.15.1. O tempo de treinamento reportado, a latência de inferência e o throughput foram medidos nessa configuração de hardware e software.

Arquitetura e Treinamento em Modelos
O modelo BiLSTM Estendido constitui o componente central de detecção do framework, baseando-se em abordagens anteriores de detecção de intrusão baseadas em aprendizado desenvolvidas para ambientes^{IoMT 21}. Estudos anteriores de detecção de intrusão destacaram tanto a importância de equilibrar o desempenho da detecção com a redução de falso^{alarme 15} quanto os desafios únicos de aplicar métodos de aprendizado de máquina ao tráfego de rede^{em evolução 16}. Arquiteturas colaborativas de detecção de intrusão em redes neurais demonstraram ainda o valor do aprendizado profundo de características sequencialmente para tráfego complexo^{de rede 22}. Enquanto modelos BiLSTM padrão capturam dependências temporais bidirecionais, o tráfego IoMT apresenta tanto padrões de rajada de curto prazo quanto dependências de longo alcance causadas por ataques multiestágio. Para resolver isso, o modelo proposto estende o BiLSTM com extração de características temporais, aprendizado temporal bidirecional aprimorado, conexões residuais e priorização temporal baseada em atenção. LSTMs bidirecionais (BiLSTM) superam essa limitação ao combinar estados ocultos para frente e para trás, permitindo uma representação temporal mais rica dos padrões de tráfego IoMT, conforme apresentado no Algoritmo 2 (Arquivo Suplementar 1).

Seja a sequência de entrada X^(n_j) = {_{x 1} , x₂ , ... , x_T }, onde cada x_t ∈ R^d é um vetor de características pré-processado.

Extração de Características Temporais:
Uma convolução leve unidimensional é aplicada ao longo da dimensão temporal para enfatizar anomalias temporais de curto alcance (Equação 6):

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

Aqui, φ(⋅) é uma função de ativação não linear e as características convolutórias u_t são alimentadas para o BiLSTM.

A camada Conv1D extrai padrões temporais de curto alcance antes da modelagem de sequência bidirecional. Parâmetros completos de implementação são fornecidos no Arquivo Suplementar 3B.

Aprendizado LSTM Bidirecional Empilhado:
Os estados ocultos para frente e para trás são calculados como (Equação 7):

(7)

A representação final da BiLSTM é a concatenação de estados ocultos passados (para frente) e futuros (para trás) (Equação 8).

(8)

Duas camadas BiLSTM empilhadas modelam dependências temporais bidirecionais. Parâmetros arquitetônicos detalhados são fornecidos no Arquivo Suplementar 3B. Os detalhes da inicialização dos pesos são fornecidos no Arquivo Suplementar 3B.

Conexão residual e normalização
Após projeção linear para dimensões correspondentes, conexões residuais e normalização de camadas são aplicadas (Equação 9):

Projeção residual e normalização de camadas alinham as representações convolucionais e de características BiLSTM antes da atenção. Parâmetros detalhados de implementação são fornecidos no Arquivo Suplementar 3B.

Mecanismo de Atenção
Embora o BiLSTM forneça uma modelagem temporal forte, nem todos os passos de tempo contribuem igualmente para a previsão. Para enfatizar carimbos de tempo críticos (por exemplo, picos anômalos repentinos), é introduzido um mecanismo de atenção. Cada estado oculto recebe uma pontuação de relevância α_t para aumentar a precisão da detecção (Equação 10).

Aqui, W_a é um parâmetro treinável e os pesos de atenção satisfazem

O vetor de contexto c agrega os estados ocultos com base em sua importância aprendida (Equação 11):

O mecanismo de atenção agrega representações temporais em um vetor de contexto. Parâmetros detalhados de implementação são fornecidos no Arquivo Suplementar 3B.

Camada de Saída e Classificação
O vetor de contexto agregado é passado por uma camada totalmente conexa, seguido por uma ativação sigmoide para obter a previsão final (Equação 12):

Aqui, W_c e b_c são parâmetros treináveis, e σ(·) é a função de ativação sigmoide que mapeia a saída para o intervalo [0,1]. Um limiar é aplicado para classificar o tráfego como benigno () ou intrusivo ().

A regularização de abandono e o limiar fixo de classificação usado durante a inferência são descritos no Arquivo Suplementar 3B.

A arquitetura Extended BiLSTM é idêntica entre os três conjuntos de dados; apenas a dimensão da característica de entrada difere, assumindo valores de 14, 24 e 12 para UNSW-NB15, CICIDS2017 e Bot-IoT, respectivamente. Como a camada Conv1D mapeia qualquer entrada de dimensão para uma representação fixa de 64 canais, todas as camadas subsequentes são independentes do conjunto de dados, e apenas a forma de entrada e a contagem de parâmetros Conv1D variam com . A arquitetura completa camada por camada está resumida na Tabela 5, com as contagens de parâmetros expressas em termos de d; Os totais resultantes são 184.641, 186.561 e 184.257 parâmetros treináveis para D = 14, D = 24 e D = 12, respectivamente.

S. Não.	Camada (Tipo)	Forma de Saída	Parâmetros Treináveis	Função de Ativação
1	Entrada	(20, d)	0	—
2	Conv1D (64 filtros, tamanho do núcleo = 3, mesmo preenchimento de volume)	(20, 64)	192d + 64	ReLU
3	Camada 1 de LSTM bidirecional (64 unidades por direção)	(20, 128)	66,048	tanh / sigmoid
4	Camada 2 de LSTM bidirecional (64 unidades por direção)	(20, 128)	98,816	tanh / sigmoid
5	Projeção Residual Densa	(20, 128)	8,320	Linear
6	Adição Residual	(20, 128)	0	—
7	Normalização de Camada (eixo = −1, ε = 1 × 10⁻³)	(20, 128)	256	—
8	Atenção Temporal (Wa ∈ R¹²⁸×¹)	128	128	Softmax
9	Camada Densa Oculta	64	8,256	ReLU
10	Desistência (p = 0,3)	64	0	—
11	Camada de Saída Densa	1	65	Sigmoide

Tabela 5: Arquitetura camada por camada do modelo de Memória Bidirecional Estendida de Curto Prazo Longo. Esta tabela resume a arquitetura do modelo proposto de Memória Bidirecional Estendida de Curto Prazo (BiLSTM), incluindo tipos de camadas, dimensões de saída, contagens de parâmetros treináveis e funções de ativação.

O software e o ambiente computacional usados para todos os experimentos são resumidos na Tabela 6.

Componente	Versão / Especificação
Sistema Operacional	Janelas
Plataforma de Servidor	Dell PowerEdge
CPU	Processador de 64 núcleos
RAM	128 GB
Armazenamento	SSD de 512 GB
Python	3.12.7
NumPy	2.4.4
Pandas	3.0.2
scikit-learn	1.8.0
TensorFlow / Keras	2.16.1
Web3 (cliente blockchain)	6.15.1
conta eth-	0.1
Compilador de Solidity (solc)	0.8.19
go-ethereum (Geth)	1.13.15

Tabela 6: Software e ambiente computacional usados para implementação e avaliação do framework proposto. Esta tabela resume as especificações de hardware, componentes de software, ferramentas de blockchain e números de versão usados para pré-processamento de dados, seleção de recursos, treinamento de modelos, implantação de blockchain e avaliação de desempenho.

Decisão de Intrusão e Resposta Automatizada
A detecção de intrusão em ambientes de saúde só é eficaz se seguida de resposta rápida e mitigação. A Camada de Detecção de Intrusão converte a probabilidade prevista em uma decisão. Formalmente, a decisão de intrusão no passo temporal t é representada da seguinte forma (Equação 13):

Aqui, é a probabilidade prevista de intrusão no tempo t e é o limiar de classificação.

Uma vez detectada uma intrusão, a Camada de Detecção de Intrusão se conecta diretamente com o módulo blockchain, que realiza registro imutável, mitigação automatizada e aplicação de segurança em circuito fechado. Detalhes do evento, incluindo informações de origem, informações de destino e recursos de tráfego selecionados, são registrados em um novo bloco blockchain. Contratos inteligentes executam ações de mitigação em tempo real, como isolamento de nós e alertas de administradores. Essa arquitetura em malha fechada permite que os resultados da detecção de intrusão sejam direcionados diretamente para os mecanismos de prevenção, minimizando assim a latência de mitigação. Assim, a Camada de Detecção de Intrusão serve como a ponte entre a detecção temporal usando o modelo BiLSTM Estendido e a resposta segura usando tecnologia blockchain, completando a funcionalidade de ponta a ponta do framework proposto.

Registro Forense Baseado em Blockchain
Embora o modelo BiLSTM Estendido permita a detecção de intrusões em tempo real, armazenamento seguro e auditoria verificável de eventos de intrusão são igualmente críticos em ambientes de saúde IoMT. Mecanismos tradicionais de registro centralizado são vulneráveis a manipulações e comprometem a rastreabilidade forense. Para enfrentar essa limitação, o framework proposto incorpora um módulo blockchain leve que garante imutabilidade, descentralização e resposta automatizada baseada em contratos inteligentes.

Cada evento de intrusão detectado gera um bloco que é adicionado à blockchain. Um bloco B_i é definido da seguinte forma (Equação 14):

Aqui, H_i é o hash criptográfico dos dados do evento, carimbo de tempo e resultado da previsão, T_i é o carimbo de tempo, D_i contém características selecionadas do evento de intrusão, Si_gi é a assinatura digital, e PrevHash vincula o bloco ao bloco anterior, garantindo imutabilidade.

Esse design garante resistência a adulteração porque qualquer modificação de D_i ou T_i altera o hash do bloco e quebra a integridade da cadeia. Também oferece auditoria porque todas as anomalias detectadas são armazenadas permanentemente e verificáveis. A mitigação automatizada é suportada por meio de contratos inteligentes que executam ações pré-definidas, como isolamento de nós e alertas de administrador. A descentralização é alcançada por meio de múltiplos gateways IoMT mantendo o livro-razão distribuído, eliminando assim um único ponto de falha.

A geração de blocos utiliza a função de hash criptográfico Keccak-256, a primitiva nativa de hash do ambiente Ethereum/Solidity (invocada através do keccak256 do Solidity). Para cada bloco de intrusão, o hash do bloco é calculado da seguinte forma:

Aqui, D_i é o resumo da característica do evento, T_i é o carimbo de tempo, e PrevHash é o hash do bloco anterior. Os campos são concatenados usando a codificação compactamente compacta do Solidity (abi.encodePacked) antes do hash, produzindo um digest de 256 bits.

O mesmo cálculo do Keccak-256 é usado pela rotina de verificação em cadeia, que recalcula cada hash de bloco a partir de seus campos armazenados e confirma que ele corresponde ao valor registrado, validando assim a integridade da cadeia. O Keccak-256 foi selecionado porque é o algoritmo padrão de hashing resistente a colisões usado nativamente dentro dos contratos inteligentes Ethereum. O contrato inteligente foi desenvolvido em Solidity e compilado usando o compilador Solidity (solc) versão 0.8.19. Foi implantado em uma rede privada Ethereum Proof-of-Authority (PoA) operada usando a versão 1.13.15 do Geth. A rede blockchain foi configurada com quatro nós validadores usando o protocolo de consenso Clique Proof-of-Authority, um ID de cadeia de 9848, um período de bloco de 5 s e um limite de gás de bloco de 30.000.000. A comunicação entre o motor de detecção de intrusões BiLSTM Estendido e a camada blockchain foi implementada usando a biblioteca Web3.py versão 6.15.1 através da interface HTTP JSON-RPC.

Mecanismo de Consenso do Ponto de Interesse
Como os sistemas IoMT em saúde são altamente sensíveis à latência, o framework proposto emprega um mecanismo de consenso PoA em vez do caro Proof-of-Work (PoW)²³, que é computacionalmente caro. No PoA, um conjunto fixo de nós validadores confiáveis, como gateways hospitalares, autoriza transações, proporcionando tanto eficiência quanto resiliência.

A complexidade temporal da validação de blocos sob PoW pode ser expressa da seguinte forma (Equação 15):

Aqui, d representa a dificuldade de mineração.

Em contraste, a complexidade temporal do consenso PoA é dada da seguinte forma (Equação 16):

porque a validação requer apenas verificação por assinatura digital por nós validadores autorizados.

Como resultado, o PoA oferece operação de baixa latência adequada para alertas médicos em tempo real, eficiência energética ao evitar mineração computacionalmente intensiva e resiliência contra um número limitado de validadores maliciosos. A rede PoA foi configurada com quatro nós validadores, e essa configuração foi mantida fixa durante todos os experimentos para garantir medições consistentes de latência, avaliação de desempenho reproduzível e comparação justa entre todos os conjuntos de dados de benchmark.

Implementação de Blockchain e Operação de Contratos Inteligentes
O componente blockchain foi implementado em uma rede Ethereum autorizada operando sob o modelo de consenso^{PoA 24}. A rede era executada usando o cliente go-ethereum (Geth) com o protocolo de consenso Clique^{PoA 25}, no qual um conjunto de nós validadores autorizados (sealer) é responsável por produzir e validar blocos. O contrato inteligente de logging de intrusões (IoMTIntrusionLedger) foi escrito em Solidity e implantado nessa rede, seguindo arquiteturas de segurança IoT baseadas em blockchain para gerenciamento de eventos descentralizado^{e seguro 26}. Apenas contas de gateway autorizadas on-chain (via a função de controle de acesso do contrato) podiam enviar registros de invasão, consistentes com arquiteturas de contratos inteligentes de blockchain autorizadas para aplicações da^{Internet das Coisas 27}. A camada blockchain foi implementada usando o cliente go-ethereum (Geth) versão 1.13.15 para operar a rede PoA com permissões, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca Web3.py versão 6.15.1 para comunicação entre o IDS e a rede blockchain.

Parâmetros detalhados de implantação e configuração da blockchain são fornecidos no Arquivo Suplementar 3C.

Cada registro de intrusão é assinado digitalmente antes de ser registrado no livro-caixa, apoiando a auditabilidade em saúde baseada em blockchain e a manutenção segura de registros^{forenses 28.} Procedimentos de geração e verificação de assinatura digital, incluindo ECDSA sobre a curva secp256k1^29,30, são descritos no Arquivo Suplementar 3D. Cada gateway possui um par de chaves Ethereum consistindo em uma chave privada de 256 bits (32 bytes) e a chave pública correspondente, da qual seu endereço de conta é derivado; a geração de chaves segue o procedimento padrão do Ethereum, usando uma chave privada aleatória de 256 bits criptograficamente segura, com a chave pública obtida pela multiplicação escalar secp256k1. Para criar uma assinatura, o cliente gateway calcula o digest de recurso de evento D_i e o assina com sua chave privada usando o formato de assinatura de mensagens EIP-191, produzindo uma assinatura de 65 bytes composta pelos componentes r, s e v. A assinatura é enviada junto com o registro de intrusão. A verificação é realizada on-chain pelo contrato inteligente: usando a pré-compilação EVM ecreach, o contrato recupera o endereço do signatário a partir do digest e da assinatura assinados e exige que ele seja igual ao endereço do gateway autorizado que enviou a transação. Se o endereço recuperado não corresponder a um gateway autorizado, a transação é rejeitada. Isso vincula cada entrada do livro maior a um gateway autorizado específico e impede registros de intrusões não autorizadas ou falsificadas.

Contratos inteligentes são acionados automaticamente após a detecção de intrusão, garantindo resposta em tempo real sem necessidade de intervenção manual (Equação 17):

(17)

O módulo blockchain opera em paralelo com o classificador BiLSTM Estendido. Uma vez detectada uma anomalia: (i) o evento é rotulado e classificado pelo BiLSTM, (ii) um bloco é gerado, assinado e anexado ao livro-razão da blockchain, e (iii) contratos inteligentes aplicam políticas de resposta automática.

O contrato inteligente de registro de intrusões (IoMTIntrusionLedger) mantém um livro-razão apenas anexo dos blocos de intrusão e um registro de contas de gateway autorizadas, além de expor as funções resumidas na Tabela 7. O contrato impõe dois papéis de acesso por meio de modificadores: onlyAdmin (o administrador que faz a implantação) e onlyGateway (contas autorizadas a enviar registros de intrusão). O estado consiste no mapeamento de autorização do gateway, no array do bloco-razão e na cabeça atual da cadeia (o hash do bloco mais recente).

S. Não.	Função / Componente	Tipo	Acesso	Lógica
1	construtor	Construtor	—	Define o deployer como administrador e o autoriza como gateway inicial.
2	setGateway (endereço, bool)	Função	onlyAdmin	Adiciona ou remove uma conta de gateway autorizada; emite GatewayUpdated.
3	recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate)	Função	onlyGateway	Calcula Hi = Keccak-256(Di ∥ Ti ∥ probabilidade ∥ PrevHash); verifica a assinatura ECDSA do gateway em Di via ecrecover; anexa o bloco ao livro-caixa; avança a cabeça da corrente; emite BlockCreated, opcionalmente NodeIsolated e AdminAlert. Retorna Hi.
4	verifyChain()	Função de visualização	Público	Recalcula o hash de cada bloco a partir de seus campos armazenados e verifica a ligação PrevHash; retorna verdadeiro apenas se toda a cadeia for consistente (detecção de adulteração).
5	ledgerLength()	Função de visualização	Público	Retorna o número de blocos no livro-razão (ledger).
6	_recoverSigner(hash, sig)	Função Interna	—	Divide a assinatura de 65 bytes em (r, s, v) e recupera o endereço de assinatura via pré-compilação ecreole.
7	BlockCreated / NodeIsolated / AdminAlert / GatewayAtualizado	Eventos	—	Emitido para ouvintes off-chain para registrar drives, isolamento de nós, alertas de administrador e atualizações do registro do gateway.
8	onlyAdmin / onlyGateway	Modificadores	—	Restringa funções ao administrador e aos gateways autorizados, respectivamente.

Tabela 7: Funções, eventos e componentes de controle de acesso do contrato inteligente IoMTIntrusionLedger. Esta tabela resume as principais funções, eventos e modificadores de controle de acesso implementados dentro do contrato inteligente da blockchain com permissão. Esses componentes suportam autorização de gateways, registro de intrusões, verificação de blockchain, geração de eventos e mitigação automatizada.

A propriedade de imutabilidade da blockchain decorre diretamente da Equação 14, onde qualquer modificação em dados de eventos ou carimbos de data invalida a cadeia de hash. Assim, o blockchain oferece integridade dos dados, rastreabilidade e auditabilidade para sistemas de saúde por meio de registros forenses imutáveis. Os registros de intrusão de pacientes e dispositivos permanecem inalterados após armazenados, cada bloco se conecta de forma segura ao bloco anterior, permitindo a reconstrução cronológica de eventos, e administradores ou reguladores de saúde podem verificar incidentes de intrusão sem risco de falsificação.

Função de Perda e Otimização de Modelos
O modelo BiLSTM Estendido proposto aborda o problema de classificação binária de distinguir entre eventos normais de tráfego e intrusão em redes IoMT. Para orientar o processo de treinamento, é adotada uma perda binária de entropia cruzada (BCE), que é bem adequada para saídas probabilísticas da camada de ativação sigmoide. Para um conjunto de dados com N amostras, a perda é definida da seguinte forma (Equação 18):

(18)

Aqui, é o rótulo de verdade fundamental da ^i-ésima sequência de entrada (0 = benigno, 1 = intrusão), e é a probabilidade prevista de intrusão.

A estrutura opera como uma linha de classificação em duas etapas. O primeiro estágio realiza a detecção de intrusão binária: o BiLSTM Estendido produz uma saída sigmoide e aplica o limiar τ = 0,5 para classificar cada janela como benigna ou intrusiva (Equações 12,13), treinada com perda binária ponderada de entropia cruzada. Um segundo estágio pode realizar categorização de ataques, na qual janelas identificadas como intrusões são passadas para um classificador multiclasse que atribui a categoria específica de ataque usando uma camada softmax de saída treinada com entropia cruzada categórica. O presente estudo foca e avalia a etapa de detecção binária. Os dois estágios compartilham a mesma espinha dorsal de extração de características do BiLSTM Estendido (Conv1D, BiLSTM, camadas residuais, de normalização e de atenção); Eles diferem apenas em sua camada de saída (sigmoid para detecção e softmax para categorização) e na função de perda correspondente. A fase de detecção binária e a etapa de categorização multiclasse foram treinadas e avaliadas sob as mesmas partições de dados, sementes aleatórias e condições de treinamento descritas acima.

Embora o tráfego IoMT seja frequentemente desequilibrado, uma perda binária ponderada de entropia cruzada é usada para penalizar a classificação incorreta da classe minoritária. Os pesos de classe são calculados usando o número de amostras de intrusão N_p, o número de amostras benignas N_n e o número total de amostras N (Equações 19,20):

A ponderação garante que o modelo não seja tendencioso para a classe dominante de tráfego benigno e permaneça sensível a eventos raros, porém críticos, de intrusão.

A perda binária ponderada de entropia cruzada é dada da seguinte forma (Equação 21):

(21)

O treinamento foi realizado usando mini-lotes do tamanho 64. No início de cada época, as amostras de treinamento eram embaralhadas aleatoriamente antes de serem particionadas em lotes, de modo que a composição em lotes variava entre épocas e o modelo não via exemplos em ordem fixa. Os lotes não eram explicitamente balanceados ou estratificados por classe; em vez disso, cada lote refletia a distribuição natural de classes do conjunto de treinamento, e o desequilíbrio de classes era tratado por meio da perda binária de entropia cruzada ponderada por classe (Equações 19–21). O subconjunto de validação reservado da partição de treinamento permaneceu fixo entre épocas e não foi embaralhado nos lotes de treinamento.

Os pesos das classes na perda binária ponderada de entropia cruzada não foram definidos manualmente, mas foram calculados automaticamente para cada conjunto de dados a partir das contagens de classes do conjunto de treinamento, de acordo com as Equações 19 e 20. Para o conjunto de dados UNSW-NB15, os pesos de classe resultantes foram para a classe normal e para a classe de intrusão. Para o conjunto de dados CICIDS2017, os pesos resultantes da classe normal e da classe de intrusão. Para o conjunto de dados Bot-IoT (subconjunto de 5%), os pesos resultantes da classe normal e da classe de intrusão.

Estratégia de Treinamento e Otimização
O modelo BiLSTM Estendido foi treinado usando mini-lotes de tamanho B = 64 com perda binária ponderada de entropia cruzada, o otimizador Adam e parada precoce baseada na perda de validação. O treinamento foi limitado a 50 épocas, e a parada precoce foi aplicada com paciência K = 5. Se a perda de validação não melhorasse por cinco épocas consecutivas, o treinamento era interrompido e os pesos do modelo eram restaurados para aqueles da época com menor perda de validação. Assim, 50 épocas representavam o orçamento máximo de treinamento em vez de uma duração fixa de treinamento. Uma probabilidade de abandono de 0,3 foi aplicada para regularização. Os ajustes arquitetônicos incluíam 64 filtros Conv1D, 64 unidades LSTM por direção, um comprimento de janela de T = 20 e uma passada de s = 1. A estratégia de treinamento adotada é resumida no Algoritmo 3 (Arquivo Suplementar 1). As equações de atualização Adam usadas para otimização são fornecidas no Arquivo Suplementar 3A.

O otimizador Adam foi configurado com uma taxa de aprendizado de , uma taxa de decaimento no primeiro momento (β₁) de 0,9, uma taxa de decaimento no segundo momento (β₂) de 0,999 e uma constante de estabilidade numérica () de 1 × 10-7. Nenhuma opção adicional de otimizador foi utilizada, e nenhum decaimento de peso ou clipping de gradiente foi aplicado.

Geração de Alertas e Mitigação Automatizada
A detecção sozinha é insuficiente em redes IoMT sensíveis à latência, onde a resposta rápida é crítica para garantir a segurança do paciente. A Camada de Geração e Mitigação de Alertas operacionaliza a decisão de intrusão tomada pelo modelo BiLSTM Estendido e pelo mecanismo de registro da blockchain. Se δ_t = 1, o módulo blockchain adiciona um novo bloco contendo os detalhes da intrusão . Simultaneamente, um contrato inteligente é executado para acionar ações de mitigação (Equação 22):

(12)

Aqui, o BlockCreation garante um registro forense imutável do evento, o NodeIsolation (n_j) coloca o nó IoMT comprometido para evitar danos adicionais, e o AdminAlert entrega notificações em tempo real aos administradores do sistema. Para operar esse pipeline de resposta de camadas duplas, o pseudocódigo é apresentado no Algoritmo 4 (Arquivo Suplementar 1).

Processamento de eventos por smart contract e mecanismos de resposta off-chain são descritos no Arquivo Suplementar 3E.

Cada entrada comprometida no livro-razão da blockchain é armazenada como um registro IntrusionBlock, cujos campos e formatos de dados estão listados na Tabela 8. O livro razão é um array apenas anexo desses registros, e a cabeça atual da cadeia armazena o hash do bloco adicionado mais recentemente.

S. Não.	Campo	Tipo de Dado	Tamanho	Descrição
1	hashId	bytes32	32 bytes	Hash do bloco Hi = Keccak-256(Di ∥ Ti ∥ probabilidade ∥ PrevHash)
2	Carimbo de tempo	uint256	32 bytes	Tempo de criação de bloco Ti (segundos de época Unix, a partir do carimbo de tempo do bloco)
3	nodeId	bytes32	32 bytes	Identificador do nó IoMT nj
4	pacienteId	bytes32	32 bytes	Identificador de paciente/dispositivo (metadados forenses)
5	Classe de ataque	uint16	2 bytes	Código da categoria de ataque (0 = Normal, 1 = DDoS, 2 = Falsificação, ...)
6	probabilidadeBp	uint16	2 bytes	Probabilidade de intrusão prevista ŷ em pontos base (0–10000, ou seja, 0,00–100,00%)
7	dataDigest	bytes32	32 bytes	Resumo Di dos eventos selecionados se destaca
8	assinatura	Bytes	Variável (65 bytes)	Assinatura ECDSA Sigi do digest de eventos pelo gateway (r, s, v)
9	prevHash	bytes32	32 bytes	Hash do bloco anterior (PrevHash), ligando a cadeia
10	isolado	bool	1 byte	Se o isolamento de nó foi acionado para esse registro

Tabela 8: Estrutura do registro IntrusionBlock armazenado no livro-razão da blockchain. Esta tabela descreve os campos, tipos de dados, tamanhos de armazenamento e propósitos dos registros do livro razão da blockchain usados para armazenar eventos de intrusão. A estrutura suporta verificação de integridade criptográfica, rastreabilidade forense e mecanismos automáticos de resposta.

A latência total de mitigação pode ser expressa como a soma do atraso de detecção (T_d) do modelo BiLSTM Estendido e do atraso de execução da blockchain (T_b) (Equação 23):

(23)

Análise de Complexidade Computacional
A eficiência do framework BiLSTM–Blockchain Estendido proposto é determinada tanto pelo custo computacional do modelo BiLSTM quanto pelo overhead introduzido pelo módulo blockchain. A estrutura proposta integra a detecção Estendida de BiLSTM com registro em blockchain para satisfazer os requisitos centrais de segurança da tríade de Confidencialidade, Integridade e Disponibilidade (CIA).

Seja o comprimento da sequência de entrada pré-processada T, a dimensão de característica d, e a dimensão oculta do BiLSTM h.

Para cada passo de tempo, um BiLSTM processa entrada de dimensão d com tamanho oculto h. Como é bidirecional (para frente + para trás) (Equação 24):

) (24)

Aqui, T é o comprimento da sequência (passos de tempo), d é a dimensão de característica de entrada, h é a dimensão de estado oculto

A camada de atenção calcula pesos de importância e agrega estados ocultos com complexidade (Equação 25).

(25)

que é linear tanto na sequência de comprimento T quanto na dimensão oculta h.

A complexidade total de detecção por sequência é, portanto, dada da seguinte forma (Equação 26):

(26)

demonstrando que a modelagem temporal domina o custo computacional, enquanto o mecanismo de atenção introduz apenas um overhead leve.

Para cada evento de intrusão detectado, o registro da blockchain realiza operações de hash, assinatura e anexação de blocos (Equação 27):

(27)

Para N eventos de detecção de intrusão, a complexidade combinada torna-se a seguinte (Equação 28):

(28)

que pode ser simplificado da seguinte forma (Equação 29):

(29)

porque o overhead da blockchain cresce linearmente com o número de eventos e permanece negligenciável em comparação com os cálculos de processamento de sequências.

A complexidade computacional é resumida nas Equações 24–29. A interpretação detalhada é fornecida no Arquivo Suplementar 3F.

Resultados

Os resultados são organizados para espelhar as etapas metodológicas do Protocolo, com cada subseção relatando as observações produzidas pelo passo correspondente.

Manuseio de conjuntos de dados e configuração experimental
Os três conjuntos de dados de referência foram analisados de forma independente, e não fundidos. Como UNSW-NB15, CICIDS2017 e Bot-IoT usam esquemas de características e convenções de rotulagem diferentes, cada conjunto de ...

Discussão

O presente estudo propõe uma estrutura integrada de BiLSTM–Blockchain Estendida para detecção e prevenção de intrusões em ambientes IoMT. Os resultados demonstram que a estrutura identifica efetivamente padrões de intrusão no tráfego heterogêneo da rede IoMT ao combinar aprendizado temporal bidirecional com registro forense baseado em blockchain. A arquitetura bidirecional permite que o modelo capture tanto dependências temporais para frente quanto para trás dentro do tráfego de rede, re...

Materiais

Lista de materiais utilizados neste artigo

Nome	Empresa	Número de catálogo	Comentários
AQU-IMF-RFE Feature Selection Module	Self-developed	N/A	Método híbrido de seleção de características que integra Informação Mútua, Optimizer Aquila e Eliminação Recursiva de Características
Attention Layer	Self-developed (Keras-based)	N/A	Mecanismo de atenção temporal usado para ponderação de características no modelo Extended BiLSTM
Bot-IoT Dataset	UNSW Canberra Cyber	N/A	Conjunto de dados de referência público usado para avaliação de detecção de intrusão
CICIDS2017 Dataset	Canadian Institute for Cybersecurity	N/A	Conjunto de dados de referência público para detecção de intrusão
Ethereum Client (Geth)	Ethereum Foundation	1.13.15	Cliente de blockchain usado para implantar e operar a rede Proof-of-Authority
Extended BiLSTM Model	Self-developed	N/A	Modelo de detecção de intrusão de aprendizado profundo que integra Conv1D, BiLSTM, aprendizado residual e atenção temporal
Jupyter Notebook	Project Jupyter	7.x	Ambiente interativo usado para implementação, experimentação e visualização de resultados
NumPy	NumPy Developers	2.4.4	Biblioteca de computação numérica usada para pré-processamento e treinamento de modelos
Pandas	Pandas Development Team	3.0.2	Biblioteca de processamento de dados usada para pré-processamento e análise de dados
Proof-of-Authority Blockchain Network	Self-developed	N/A	Rede blockchain autorizada usada para registro imutável de intrusões e mitigação automatizada
Python	Python Software Foundation	3.12.7	Linguagem de programação usada para pré-processamento de dados, desenvolvimento de modelos, integração com blockchain e avaliação
Random Forest Estimator	Scikit-learn Developers	N/A	Classificador Random Forest usado para Eliminação Recursiva de Características (RFE)
Scikit-learn	Scikit-learn Developers	1.8.0	Biblioteca de aprendizado de máquina usada para pré-processamento, seleção de características e avaliação de modelos
Solidity Compiler (solc)	Solidity Team	0.8.19	Compilador usado para compilação e implantação de contratos inteligentes
Solid-State Drive (SSD)	Dell	512 GB	Armazenamento usado para conjuntos de dados, modelos treinados e registro blockchain
System Memory (RAM)	Dell	128 GB	Memória principal usada durante pré-processamento, treinamento de modelos, execução de blockchain e avaliação
TensorFlow	Google	2.16.1	Framework de aprendizado profundo usado para implementar e treinar o modelo Extended BiLSTM
UNSW-NB15 Dataset	UNSW Canberra Cyber	N/A	Conjunto de dados de referência público usado para treinamento e avaliação
Web3.py	Web3.py Developers	6.15.1	Interface Python usada para comunicação entre o sistema de detecção de intrusão e a rede blockchain
Windows Operating System	Microsoft	Windows 11	Sistema operacional usado para todos os experimentos
Workstation / Server	Dell	PowerEdge R740	Plataforma de computação usada para treinamento de modelos, implantação de blockchain e avaliação