Red de Memoria Bidireccional Integrada en Blockchain a Corto Plazo para la Detección de Intrusiones en Tiempo Real en el Internet de las Cosas Médicas en la Salud

Summary

Este protocolo describe la implementación de un sistema de detección de intrusiones de memoria bidireccional a corto plazo integrado en blockchain para redes sanitarias del Internet de las Cosas Médicas, que permite la detección de ataques en tiempo real, registro forense a prueba de manipulaciones y mitigación automatizada.

Abstract

Los entornos de Internet de las Cosas Médicas (IoMT) en la salud requieren sistemas de detección de intrusiones que no solo identifiquen ciberataques con precisión, sino que también proporcionen responsabilidad forense, auditabilidad y capacidades de respuesta rápida. Los enfoques convencionales de detección de intrusiones enfatizan principalmente el rendimiento de la clasificación, ofreciendo un soporte limitado para el registro de eventos a prueba de manipulaciones e investigación posterior al incidente. Este estudio presenta un marco de detección de intrusiones consciente de la forense que integra una red Bidireccional Extendida de Memoria a Corto Plazo (BiLSTM) con una capa de blockchain autorizada para soportar detección en tiempo real, registro seguro y mitigación automatizada en sistemas IoMT sanitarios. El protocolo combina preprocesamiento de datos, selección de características AQU-IMF-RFE, modelado temporal de secuencias, aprendizaje basado en atención, conexiones residuales y registro de eventos basado en blockchain. El modelo BiLSTM Extendido fue entrenado y evaluado de forma independiente en los conjuntos de datos de referencia UNSW-NB15, CICIDS2017 y Bot-IoT utilizando preprocesamiento reproducible, partición estratificada de datos y semillas aleatorias fijas. Los eventos de intrusión detectados por el modelo se registraron en una blockchain de Prueba de Autoridad mediante contratos inteligentes que permitieron un registro inmutable y acciones de respuesta automatizadas. Los resultados experimentales demostraron un alto rendimiento en la detección de intrusiones con bajas tasas de falsos positivos en todos los conjuntos de datos evaluados, manteniendo al mismo tiempo la trazabilidad forense y la capacidad de respuesta en tiempo real. La capa blockchain proporcionaba registros de auditoría resistentes a manipulaciones y mitigación automatizada sin introducir una sobrecarga computacional prohibitiva. Estos hallazgos demuestran que integrar la detección de intrusiones basada en aprendizaje profundo con el registro forense habilitado por blockchain mejora la fiabilidad, la responsabilidad y la facilidad práctica de desplegue de los sistemas de ciberseguridad sanitaria.

Introduction

En el sistema sanitario, la digitalización ha dado paso a una nueva era de servicios de salud inteligentes, conectados y centrados en el paciente. La infraestructura médica moderna depende en gran medida de la comunicación en red y el intercambio de datos entre sensores portátiles, sistemas de monitorización remota de pacientes, historiales electrónicos de salud (EHR^)1,2 y plataformas inteligentes de diagnóstico. Sin embargo, esta creciente interconectividad también amplía la superficie de ataque de las redes sanitarias, exponiéndolas a amenazas cibernéticas como brechas de datos, ransomware, ataques de denegación de servicio distribuida (DDoS) y ataques^{man-in-the-middle 3}. Estas intrusiones resultan en pérdidas financieras sustanciales y, lo que es más importante, pueden poner en peligro la seguridad del paciente cuando se ven comprometidos datos médicos sensibles o funcionalidades críticas de dispositivos.

La escala y complejidad de los sistemas de Internet de las Cosas Médicas (IoMT) agravan aún más estos desafíos de seguridad. Las redes sanitarias modernas deben proporcionar simultáneamente comunicación de baja latencia, alta fiabilidad y garantías de seguridad robustas, requisitos que los mecanismos de seguridad tradicionales a menudo tienen dificultades para^cumplir. El rápido crecimiento del tráfico del IoMT, caracterizado por fuentes de datos heterogéneas, patrones de comunicación dinámicos y estrictos requisitos regulatorios como la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA) y el Reglamento General de Protección de Datos (RGPD), requiere sistemas inteligentes de detección de intrusiones (IDS) capaces de alcanzar altas tasas de detección minimizando las falsas^{alarmas 5}.

En entornos sanitarios regulados, la detección de intrusiones no es solo un requisito operativo, sino también una función de responsabilidad. Las alertas de seguridad pueden desencadenar el aislamiento del dispositivo, afectar la continuidad del cuidado y, posteriormente, ser objeto de auditorías, revisiones regulatorias o investigaciones legales. En consecuencia, un IDS efectivo del IoMT debe proporcionar una detección precisa en tiempo real, decisiones explicables que apoyen la triaje de incidentes y registros a prueba de manipulación que garanticen la no repudiación y la trazabilidad^{forense 6}. Este requisito desplaza el objetivo de la detección de intrusiones de una clasificación centrada en el rendimiento hacia una gobernanza de seguridad centrada en la confianza y la rendición de cuentas.

Las técnicas de aprendizaje profundo, especialmente las redes de Memoria a Corto Plazo Largo (LSTM) y Memoria Bidireccional a Corto Plazo (BiLSTM), han demostrado una gran capacidad para modelar dependencias temporales dentro del tráfico de red y detectar comportamientos^{anómalos 7}. No obstante, los IDS basados en BiLSTM existentes suelen sufrir un sobreajuste, poca atención a eventos temporales críticos y una generalización limitada en dispositivos IoMT heterogéneos y entornos sanitarios. Además, las redes IoMT están expuestas a una amplia gama de amenazas cibernéticas que afectan a la Confidencialidad, Integridad y Disponibilidad (CIA) de los datos y servicios médicos, como se resume en la Tabla 1.

Tipo de ataque	Contexto de IoMT	Dimensión de la CIA afectada	Impacto en los sistemas sanitarios
Acceso noautorizado 19	Explotación de mecanismos de autenticación débiles para acceder a dispositivos de pacientes o historiales médicos	Confidencialidad, integridad	Fuga de datos y control no autorizado de dispositivos médicos
Suplantación /Suplantación 19	Un dispositivo malicioso imita un nodo legítimo de IoMT	Integridad	Lecturas erróneas que pueden llevar a un diagnóstico erróneo o a un tratamiento inseguro
Escuchando 21	Intercepción de datos médicos no cifrados durante la transmisión	Confidencialidad	Violaciones de privacidad y exposición de información sensible de pacientes
Manipulación de datos / Exploits de firmware19	Modificación del firmware del dispositivo o datos sanitarios transmitidos	Integridad	Diagnóstico incorrecto o decisiones terapéuticas inapropiadas
Ransomware20	Cifrado de datos de pacientes o firmware de dispositivos médicos	Disponibilidad, Integridad	Cierre de sistemas críticos y retrasos en el tratamiento
Denegación de Servicio (DoS) / Denegación de Servicio Distribuida (DDoS)6	Sobrecarga de dispositivos médicos o redes sanitarias	Disponibilidad	Interrupciones en el servicio que afectan a los sistemas de monitorización y a las operaciones de las unidades de cuidados intensivos (UCI)
Ataques por CanalLateral 22	Extracción de claves criptográficas mediante técnicas de temporización o análisis de potencia	Confidencialidad	Compromiso de dispositivo y robo de claves criptográficas

Tabla 1: Ciberataques comunes que afectan a los entornos sanitarios del Internet de las Cosas Médicas. Esta tabla resume los ciberataques representativos que tienen como objetivo los sistemas del Internet de las Cosas Médicas (IoMT), su contexto operativo, las dimensiones de seguridad de Confidencialidad, Integridad y Disponibilidad (CIA) afectadas, y su posible impacto en la prestación de servicios sanitarios, la seguridad del paciente y el funcionamiento de dispositivos médicos.

La tecnología blockchain ofrece varias ventajas que pueden complementar la detección de intrusiones en entornos IoMT. Como se resume en la Tabla 2, blockchain permite un registro inmutable de eventos para la validación forense, facilita la mitigación automatizada mediante contratos inteligentes, elimina puntos únicos de fallo mediante operaciones descentralizadas y apoya el cumplimiento de las normativas de protección de datos sanitarios manteniendo rastreos de auditoría rastreables. A pesar de estos beneficios, los mecanismos de seguridad basados en blockchain siguen estando infrautilizados en los IDS sanitarios.

Característica	Descripción	Beneficios en el contexto sanitario
Integridad de los datos	Cada transacción está hasheada criptográficamente y vinculada al bloque anterior	Garantiza la inmutabilidad de los registros de pacientes y dispositivos
Detección de manipulaciones	Cualquier modificación de los datos almacenados modifica el hash de bloques y invalida la cadena	Permite la detección rápida de modificaciones no autorizadas de registros
Control de acceso	Los contratos inteligentes hacen cumplir permisos y políticas de autorización predefinidos	Restringe el acceso a información sanitaria sensible a usuarios y dispositivos autorizados
Procedencia de los datos	Cada evento está firmado digitalmente y con marca de tiempo	Apoya la trazabilidad forense, auditoría y cumplimiento normativo
Consenso de baja latencia	El mecanismo de consenso de Prueba de Autoridad (PoA) permite la validación rápida de transacciones con menor sobrecarga computacional que la Prueba de Trabajo	Soporta el registro de eventos casi en tiempo real en entornos sanitarios críticos

Tabla 2: Beneficios de la tecnología blockchain para la atención sanitaria Sistemas de detección de intrusiones en Internet de las Cosas Médicas. Esta tabla resume las principales características de la blockchain y sus beneficios asociados en entornos sanitarios de Internet de las Cosas Médicas (IoMT). Las capacidades listadas soportan el registro inmutable, detección de manipulaciones, control de acceso, procedencia de datos y mecanismos de consenso de baja latencia necesarios para una detección de intrusiones segura y auditable.

Más allá de la evaluación del rendimiento, la integración blockchain proporciona protección frente a múltiples amenazas de seguridad en entornos IoMT. La Tabla 3 resume las fortalezas y limitaciones de la blockchain en este contexto, destacando amenazas que se mitigan eficazmente, como la manipulación y la repudiación de datos, y amenazas que requieren salvaguardas adicionales. La capa blockchain soporta registro de baja latencia adecuado para entornos sanitarios en tiempo real, resiliencia bizantina frente a nodos defectuosos o maliciosos, y escalabilidad a través de redes hospitalarias distribuidas y dispositivos IoMT.

Amenaza de seguridad	¿Abordado por blockchain?	Mecanismo	Notas
Manipulación de datos27	Sí	Enlace hash criptográfico	Cualquier modificación invalida la integridad de la cadena
Repudio 26	Sí	Firmas digitales asociadas a cada bloque	Previene la negación de eventos de intrusión registrados
FallaCentralizada 25	Sí	Libro mayor distribuido mantenido entre pasarelas autorizadas	Elimina un único punto de fallo
Ataque Sybil24	Parcial	Consenso podarial autorizado que requiere validadores de confianza	Puede mitigarse mediante la autorización del validador basada en identidad
51% Ataque23	Parcial	Requiere la concesión de la mayoría de los validadores autorizados	Menos probable en despliegues privados de blockchain de puntos de interés
Proveniencia de datos26	Sí	Registros de eventos con marca de tiempo y firmados digitalmente	Apoya la trazabilidad forense y el cumplimiento normativo

Tabla 3: Amenazas de seguridad abordadas por la integración de blockchain en entornos sanitarios de Internet de las Cosas Médicas. Esta tabla resume las principales amenazas de seguridad relevantes para los sistemas del Internet de las Cosas Médicas (IoMT) e indica hasta qué punto la tecnología blockchain mitiga cada amenaza. Se proporcionan los mecanismos de protección subyacentes y las consideraciones de implementación para cada categoría de amenaza.

La mayoría de los IDS existentes dependen de reglas predefinidas o de modelos ligeros de aprendizaje^{automático 8,9}. Aunque estos enfoques pueden identificar patrones de ataque conocidos, a menudo tienen dificultades para hacer frente a la naturaleza dinámica y cambiante de las amenazas cibernéticas modernas. Son especialmente inadecuados para asegurar infraestructuras sanitarias basadas en IoMT de rápido crecimiento, donde las falsas alarmas, la limitada adaptabilidad y la mala auditabilidad pueden afectar significativamente la eficiencia operativa. Los sistemas basados en reglas suelen generar altas tasas de falsos positivos porque no pueden distinguir de forma fiable anomalías benignas de ataques^{genuinos 9}. Los modelos convencionales de aprendizaje automático entrenados con conjuntos de datos estáticos o obsoletos, así como los enfoques existentes de detección de intrusiones basados en aprendizaje profundo, a menudo no generalizan los comportamientos emergentes de ataque, incluyendo las intrusiones de día^{cero 10,11}. Además, los enfoques tradicionales de registro centralizado siguen siendo vulnerables a la manipulación, limitando así la fiabilidad de las investigaciones forenses posteriores al^incidente. Muchas soluciones IDS existentes también imponen una carga computacional considerable, lo que dificulta su despliegue en dispositivos y gateways IoMT con recursos^{limitados 13}. Como resultado, los entornos IoMT sanitarios siguen siendo vulnerables a ciberataques sofisticados y de varias etapas. Abordar estos desafíos requiere un marco inteligente, seguro y eficiente en recursos para la detección de intrusiones, capaz de aprender patrones temporales de tráfico en tiempo real, asegurando simultáneamente la fiabilidad forense y la mitigación automática de amenazas detectadas.

A pesar de los avances significativos en el aprendizaje automático y la detección de intrusiones basada en aprendizaje profundo, persisten varias lagunas críticas. En primer lugar, muchos modelos IDS existentes se desarrollan y evalúan utilizando conjuntos de datos estáticos y, por tanto, carecen de adaptabilidad a comportamientos de ataque en constante evolución. En segundo lugar, aunque las arquitecturas avanzadas de aprendizaje profundo pueden mejorar la precisión de la detección, a menudo ofrecen una interpretabilidad limitada y no priorizan patrones de tráfico clínicamente importantes. Tercero, y lo más importante, los marcos actuales de IDS generalmente no proporcionan un soporte intrínseco para la fiabilidad, la auditabilidad o la conservación inmutable de registros, capacidades esenciales para el cumplimiento regulatorio, la investigación de incidentes y la rendición de cuentas legal en los sistemas sanitarios.

Aunque los mecanismos de registro basados en blockchain proporcionan integridad y transparencia de datos, rara vez se integran de forma coherente con modelos avanzados de detección de intrusiones basados en aprendizaje profundo en entornos IoMT sensibles a la latencia. Los estudios existentes suelen centrarse en mejorar el rendimiento de detección sin abordar la integridad forense o en mecanismos de seguridad basados en blockchain sin incorporar detección avanzada de anomalías temporales. En consecuencia, persiste una carencia significativa en el desarrollo de un marco unificado capaz de ofrecer simultáneamente detección de intrusiones espacio-temporales en tiempo real, registro forense a prueba de manipulaciones, mitigación automatizada y despliegue práctico en entornos sanitarios IoMT heterogéneos y con recursos limitados.

Motivado por estos desafíos, este estudio pretende desarrollar un marco de detección de intrusiones que mejore las redes BiLSTM mediante mecanismos de atención y capas personalizadas para una priorización temporal de características mejorada, integre tecnología blockchain para un registro de intrusiones seguro y verificable y respuesta automatizada, y opere de forma eficiente en entornos IoMT sanitarios en tiempo real. Planteamos la hipótesis de que integrar una arquitectura BiLSTM Extendida con mayor atención con registros forenses basados en blockchain y mecanismos automatizados de mitigación mejorará la eficacia de la detección de intrusiones, proporcionando simultáneamente la auditabilidad, fiabilidad y responsabilidad requeridas en entornos sanitarios regulados.

Este trabajo aborda una laguna fundamental en la investigación en seguridad del IoMT al tratar la detección de intrusiones como un problema de responsabilidad forense en lugar de únicamente como un problema de clasificación. El marco propuesto integra la detección impulsada por inteligencia artificial (IA), el registro inmutable de eventos y mecanismos de respuesta automatizados en una arquitectura unificada que apoya la seguridad clínica, el cumplimiento normativo y la confianza operativa. La creciente adopción de dispositivos IoMT e infraestructuras sanitarias conectadas a la nube ha convertido a las redes sanitarias en objetivos atractivos para ciberataques, incluyendo ransomware, manipulación de datos, accesos no autorizados y ataques de denegación de servicio que amenazan la confidencialidad, integridad y disponibilidad de la información de los pacientes. El marco propuesto de BiLSTM–Blockchain Extendido establece un proceso de seguridad en bucle cerrado que conecta la detección de ataques directamente con la validación forense y la mitigación automatizada.

Las principales contribuciones de este estudio son cinco. En primer lugar, se desarrolla un modelo clínicamente alineado de detección de intrusiones temporales extendiendo una arquitectura BiLSTM convencional con aprendizaje temporal bidireccional, conexiones residuales, mecanismos de atención y capas personalizadas para mejorar la detección de patrones de ataque complejos en el tráfico de redes sanitarias. En segundo lugar, una capa de seguridad ligera basada en blockchain está integrada con el modelo BiLSTM Extendido para proporcionar un registro inmutable, seguro e inviolable de eventos de intrusións y acciones del sistema. En tercer lugar, se desarrolla una pipeline IDS en tiempo real de extremo a extremo para entornos sanitarios, que permite análisis de tráfico en tiempo real y predicción de intrusiones con baja latencia y alta precisión. En cuarto lugar, el marco propuesto se evalúa de forma exhaustiva utilizando tres conjuntos de datos de referencia disponibles públicamente, a saber: UNSW-NB15, CICIDS2017 y Bot-IoT. Finalmente, la arquitectura está diseñada como un marco de edge cloud escalable y extensible, adecuado para su despliegue práctico en redes sanitarias, infraestructuras médicas y aplicaciones de e-health.

Al combinar las capacidades de aprendizaje temporal de las redes BiLSTM Extendidas con la confianza e inmutabilidad proporcionadas por la tecnología blockchain, el marco propuesto ofrece un IDS seguro y fiable, adaptado a los requisitos cambiantes de ciberseguridad de los entornos sanitarios. El marco cubre brechas críticas en la seguridad de las redes sanitarias y sienta una base para una adopción más amplia de la integración de IA y blockchain en la protección de infraestructuras sanitarias críticas.

Protocol

Todos los experimentos se realizaron exclusivamente utilizando conjuntos de datos de intrusión de red de referencia disponibles públicamente (UNSW-NB15, CIC-IDS-2017 y Bot-IoT), que contienen registros de tráfico de red sin información personal o médica identificable. Los conjuntos de datos se utilizaron de acuerdo con sus respectivas licencias y términos de uso. Dado que no se implicaron participantes humanos, muestras de pacientes ni datos personales identificables, no se requirió la aprobación ética institucional ni el consentimiento informado.

Resumen del marco propuesto
Esta sección presenta el marco propuesto de detección y prevención de intrusiones de doble capa para asegurar entornos IoMT. El marco integra una red BiLSTM Extendida para la detección de intrusiones espacio-temporales con una capa ligera de blockchain para registro a prueba de manipulaciones y mitigación automatizada. A diferencia de los enfoques convencionales de IDS que se centran únicamente en la precisión de la detección, la arquitectura propuesta está diseñada para soportar simultáneamente la detección en tiempo real, la responsabilidad forense y el cumplimiento normativo, que son requisitos esenciales en los sistemas sanitarios. El flujo de trabajo general y la arquitectura del marco propuesto de detección de intrusiones BiLSTM–Blockchain para redes IoMT se ilustran en la Figura 1.

Figura 1. Arquitectura del marco propuesto de detección de intrusiones BiLSTM–Blockchain extendido para redes del Internet de las Cosas Médicas. Representación esquemática del marco propuesto mostrando los flujos de trabajo de formación y despliegue. En el flujo de trabajo de entrenamiento, los dispositivos del Internet de las Cosas Médicas (IoMT) generan tráfico de red que pasa por preprocesamiento de datos e ingeniería de características antes de ser analizado por el modelo Bidireccional Extendido de Memoria a Corto Plazo (BiLSTM) con atención temporal. Los parámetros del modelo se optimizan mediante cálculo de la función de pérdida y entrenamiento iterativo. En el flujo de trabajo de despliegue, el modelo entrenado realiza la detección de intrusiones según la función de decisión definida en la Ecuación 13. Los eventos de intrusión detectados se envían al módulo blockchain, donde se realizan registros inmutables, aislamiento de nodos y generación de alertas por parte del administrador. BiLSTM, Memoria Bidireccional a Corto Plazo a Corto Plazo; IoMT, Internet de las cosas médicas. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Los dispositivos IoMT generan flujos de datos heterogéneos que consisten en tráfico de red, metadatos de dispositivos y señales relacionadas con el paciente. Estas entradas en bruto suelen ser ruidosas, redundantes e inconsistentes, lo que las hace inadecuadas para el entrenamiento directo del modelo. Por ello, se aplica una tubería de preprocesamiento para asegurar la calidad y estructura de los datos antes de introducirlos en el modelo BiLSTM Extendido. El pseudocódigo detallado de preprocesamiento se proporciona en el Algoritmo 1 (Archivo Suplementario 1), que describe la cadena de preprocesamiento aplicada a los flujos de datos IoMT antes del entrenamiento BiLSTM Extendido (pseudocódigo en el Archivo Suplementario 1; implementación en el Archivo Suplementario 2). La arquitectura completa de BiLSTM Extendido se resume en el Algoritmo 2 (Archivo Suplementario 1).

Flujo de trabajo de reproducción de extremo a extremo
El estudio completo puede reproducirse siguiendo los pasos siguientes. El software y el hardware se listan en la Configuración Experimental, y el código suplementario cubre cada paso.

Obtén los conjuntos de datos → descarga UNSW-NB15. Usa los archivos UNSW_NB15_training-set.csv y UNSW_NB15_testing-set.csv. Descarga CICIDS2017. Utiliza los cinco archivos de día de MachineLearningCSV (de lunes a viernes). Descargar Bot-IoT. Usa los archivos del 5% de subconjuntos UNSW_2018_IoT_Botnet_Full5pc_1_to_4. Los estudios anteriores de detección de intrusiones se basaban habitualmente en conjuntos de datos de referencia como KDD Cup 99¹⁴; sin embargo, este estudio utiliza los conjuntos de datos más recientes de UNSW-NB15, CICIDS2017 y Bot-IoT para representar mejor el tráfico de red contemporáneo. Procesa cada conjunto de datos por separado. El conjunto de datos UNSW-NB15 está disponible en la Universidad de Nueva Gales del Sur en https://research.unsw.edu.au/projects/unsw-nb15-dataset (última modificación: 8 de febrero de 2024). El conjunto de datos CICIDS2017 está disponible en el Instituto Canadiense de Ciberseguridad en https://www.unb.ca/cic/datasets/ids-2017.html (publicado: julio de 2017). El conjunto de datos Bot-IoT está disponible en la Universidad de Nueva Gales del Sur en https://research.unsw.edu.au/projects/bot-iot-dataset (última modificación: 5 de febrero de 2024). Todos los conjuntos de datos fueron consultados en mayo de 2025 para este estudio.

Preprocesar los datos → eliminar registros corruptos. Rellenar los valores faltantes usando medios de conjunto de entrenamiento. Aplicar reducción de ruido EMA (α = 0,3). Normalizar características a [0,1] usando estadísticas de conjuntos de entrenamiento. Campos categóricos codificados por etiqueta. Construye ventanas correderas (T = 20, zancada = 1). Estos pasos de preprocesamiento apoyan una detección robusta de intrusiones reduciendo el ruido y mejorando la calidad de las representaciones del tráfico de red para los IDS basados en aprendizaje^{automático 15,16}.

Seleccionar características (AQU-IMF-RFE) → Clasificar características por información mutua. Refina con el Aquila Optimizer. Aplicar RFE en Random Forest con validación cruzada de 10 veces. Conserva las características finales. Esta estrategia híbrida de selección de características sigue el concepto más amplio de combinar técnicas complementarias de detección de^{intrusiones 17} y se implementa utilizando el marco AQU-IMF-RFE desarrollado en nuestro trabajo^{anterior 18}.

Entrenar el modelo → Para cada conjunto de datos, los datos se particionaron aleatoriamente en conjuntos de entrenamiento (80%) y de prueba (20%) usando una semilla aleatoria fija de 42. El veinte por ciento de la partición de entrenamiento se reservaba además como conjunto de validación. Construye el BiLSTM extendido. Entrena usando pérdida binaria ponderada de entropía cruzada y el optimizador Adam (tasa de aprendizaje = 0,001, tamaño del lote = 64, máximo de 50 épocas, con parada temprana). Salva el modelo entrenado. El uso de modelos de aprendizaje profundo temporal es muy adecuado para tráfico heterogéneo de^{IoMT 19}. El flujo de trabajo completo de entrenamiento de modelos se resume en el Algoritmo 3 (Archivo Suplementario 1). Los pesos finales de las clases se calcularon automáticamente a partir de las distribuciones de clases del conjunto de entrenamiento según las Ecuaciones 19 y 20. Los pesos de clase resultantes fueron los siguientes: UNSW-NB15: , ; CICIDS2017: , ; y Bot-IoT (subconjunto del 5%): , . El gran valor de w_n para el conjunto de datos Bot-IoT refleja la grave infrarrepresentación de muestras benignas en la partición de entrenamiento del subconjunto del 5%.

Desplegar la blockchain → iniciar la cadena de Prueba de Autoridad (PoA). Despliega el contrato inteligente y apunta su dirección. Autoriza las cuentas de la pasarela. Ejecuta el cliente para que cada intrusión detectada se registre y active aislamiento y alertas. El flujo de trabajo completo de detección, registro de blockchain y mitigación se resume en el Algoritmo 4 (Archivo Suplementario 1). La capa blockchain se implementó utilizando el cliente go-ethereum (Geth) versión 1.13.15 para operar la red PoA con permisos, el compilador Solidity (solc) versión 0.8.19 para la compilación y despliegue de contratos inteligentes, y la biblioteca de web3.py versión 6.15.1 para la comunicación entre el IDS y la red blockchain.

Evalúa → prueba el modelo en el conjunto de pruebas extendido. Calcular la precisión, la exactitud, la recuperación, la puntuación F1 y la tasa de falsos positivos. Graba latencia y rendimiento. Verifica la integridad del libro de cuentas de la blockchain. El flujo de trabajo completo de evaluación se resume en el Algoritmo 5 (Archivo Suplementario 1). La latencia de detección (T_d) se midió desde inmediatamente antes de la llamada de inferencia del modelo hasta el momento en que se devolvieron las probabilidades predichas. La latencia de mitigación de extremo a extremo (T_d +_{T b}) se midió desde el mismo punto de partida hasta la finalización de la correspondiente transacción de creación de bloques en blockchain. El rendimiento se calculaba como el número total de ventanas de prueba preprocesadas procesadas por la pipeline completa de detección y registro dividido por el tiempo de reloj de pared transcurrido para un único pase completo a través del conjunto de pruebas de cada conjunto de datos. La carga de trabajo consistía en las particiones de prueba en ventanas mientras se mantenía la distribución original de clases benignas a intrusión. Las ventanas maliciosas también conllevaban la sobrecarga de registro de blockchain, mientras que las ventanas benignas solo implicaban el coste de detección de intrusiones.

Generar cifras y tablas → Graficar las curvas de precisión y pérdida, la matriz de confusión y los gráficos de evaluación comparativa. Construye las tablas comparativas. El flujo de trabajo completo de generación de figuras y tablas se resume en el Algoritmo 6 (Archivo Suplementario 1). El código fuente completo y desarrollado a medida utilizado para generar todas las figuras y tablas se proporciona en el Archivo Suplementario 2. En particular, el figures.py script reproduce las cifras del manuscrito directamente a partir de los resultados experimentales guardados (por ejemplo, historial de entrenamiento y archivos de matriz de confusión), mientras que los scripts restantes generan los datos procesados y las métricas de rendimiento utilizadas para construir las tablas reportadas.

La Figura 2 es el flujo de datos a nivel de implementación entre los módulos IDS y blockchain. La BiLSTM extendida produce una decisión por ventana (Ecuación 13); en una clasificación maliciosa, el cliente gateway construye y firma una transacción y la envía a través de web3/JSON-RPC al contrato inteligente PoA, que añade un bloque vinculado por hash (Ecuación 14) al libro mayor inmutable y emite eventos (BlockCreated, NodeIsolated y AdminAlert) que activan el aislamiento de nodos y alertas de administrador.

Figura 2. Interacción a nivel de implementación entre la detección de intrusiones y los módulos blockchain. Diagrama de flujo de trabajo que ilustra la comunicación entre el sistema de detección de intrusiones y los componentes de blockchain. El modelo BiLSTM extendido clasifica cada ventana de entrada y aplica la regla de decisión definida en la Ecuación 13. Cuando se detecta una intrusión, el cliente gateway genera y firma una transacción que se transmite a través de Web3.py/JSON-RPC al contrato inteligente de Prueba de Autoridad (PoA). El contrato añade un bloque enlazado por hash al libro mayor inmutable según la Ecuación 14 y emite eventos BlockCreated, NodeIsolated y AdminAlert que activan acciones de contención y notificación. IDS, Sistema de Detección de Intrusiones; BiLSTM, Memoria Bidireccional a Corto Plazo a Corto Plazo; Poder notarial, Prueba de Autoridad; JSON-RPC, Notación de Objetos JavaScript–Llamada a procedimiento remoto. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Representación de datos
Consideremos R como el flujo bruto de tráfico de IoMT. Tras el preprocesamiento, cada registro en bruto se mapea en un vector de características normalizado de dimensión d (Ecuación 1):

(1)

Aquí, f (⋅) es la función de transformación de características que mapea los registros en bruto en un vector de características normalizado en d dimensiones. Sea la red IoMT formada por un conjunto de nodos (Ecuación 2):

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

Cada nodo_{n j} ∈ R produce un flujo de datos en serie temporal (Ecuación 3):

(3)

Aquí, x_t es el vector de características en el tiempo t, con d características (por ejemplo, tamaño de paquete, tipo de protocolo, dirección de origen/destino) comúnmente observadas en el tráfico de redes sanitarias del Internet de^{las Cosas 19}. El conjunto de etiquetas correspondiente es (Ecuación 4):

  (4)

Aquí, y_t=0 representa el tráfico normal y _{y t} =1 denota una intrusión.

Preprocesamiento de datos
La cadena de preprocesamiento incluye los siguientes pasos, que abordan los desafíos comunes de calidad de datos y seguridad asociados con el tráfico^{IoMT 20}:

Limpieza de datos y gestión de valores perdidos:
Un registro se identificaba como corrupto y eliminaba antes de la imputación si cumplía alguna de las siguientes condiciones explícitas: (i) faltaban todos los campos de características del registro (es decir, el registro completo era nulo), o (ii) el registro contenía un valor no finito (infinito positivo o negativo) en cualquier campo numérico tras coerción del tipo. La segunda regla elimina entradas inválidas, como las producidas por división por cero durante el cálculo de características de flujo (por ejemplo, valores infinitos de caudal derivados de flujos de duración cero). Tras la eliminación de registros corruptos, los valores restantes faltantes se imputaban mediante la sustitución media calculada por característica, por conjunto de datos y solo desde la partición de entrenamiento; Los medios resultantes se aplicaban a los conjuntos de entrenamiento, validación y prueba para evitar fugas de información. La imputación no era condicional a clase, y las medias no se agrupaban entre conjuntos de datos.

Reducción de ruido temporal:
La reducción temporal de ruido se realizó utilizando un filtro de media móvil exponencial (EMA) por característica aplicado a lo largo del eje temporal. Se utilizó la forma recursiva (causal ) y_t = α·x_t + (1 − α)·y_t−1 , con factor de suavizado α = 0,3, implementada mediante la función ewm de pandas con adjust=False. Cada característica se suavizaba de forma independiente. Como filtro exponencial (respuesta infinita al impulso), la EMA no tiene un tamaño fijo de ventana o núcleo; El factor de suavizado α es el único parámetro que regula el grado de suavizado y la memoria efectiva del filtro.

Normalización Min–Max:
Se aplicó la normalización min–max para escalar cada característica al rango [0,1] usando la transformación x′=(x−min)/(max−min+ε), donde ε = 1 × 10⁻⁸. Las estadísticas mínima y máxima se calculaban por característica, por conjunto de datos y solo desde la partición de entrenamiento; Estas estadísticas de entrenamiento almacenadas se aplicaban para normalizar los conjuntos de entrenamiento, validación y prueba, evitando la filtración de información oculta. Durante la inferencia, los valores de características que quedaban fuera del rango de entrenamiento se recortaban al intervalo [0,1].

Codificación de características categóricas:
Las características categóricas se convirtieron a forma numérica mediante codificación de etiquetas. Esto se aplicó a todas las variables categóricas: en UNSW-NB¹⁵, los campos proto, servicio y estado; en Bot-IoT, el protocampo; CICIDS2017 no contiene campos categóricos entre las características seleccionadas. La codificación se implementaba con LabelEncoder ajustado por variable.

Ventanas temporales para aprendizaje secuencial:
El flujo de características preprocesado se segmentó en secuencias de longitud fija usando una ventana deslizante de longitud T = 20 pasos de tiempo con una zancada de s = 1. Cada ventana generada fue validada antes de su inclusión. Una ventana solo se aceptaba si contenía exactamente T = 20 pasos de tiempo consecutivos y todos los valores de las características eran finitos. Los flujos más cortos que T = 20 registros no producían ventanas. Esta configuración (T = 20, s = 1, 95% de solapamiento) se aplicó de forma consistente en todos los experimentos y conjuntos de datos. El flujo de trabajo completo de preprocesamiento se resume en el Algoritmo 1 (Archivo Suplementario 1).

El objetivo del preprocesamiento es permitir un mapeo predictivo de secuencias de entrada a etiquetas de intrusión (Ecuación 5).

(5)

parametrizado por θ, que predice si un evento es benigno o malicioso.

Selección de características usando AQU-IMF-RFE
La selección de características se realizó usando AQU-IMF-RFE, un método híbrido que integra Información Mutua (MI), el Aquila Optimizer (AO) y la Eliminación de Características Recursivas (RFE), introducido en nuestro trabajo^{previo 18}. El método funciona en tres etapas. En la primera etapa, se calcula la información mutua entre cada característica y la etiqueta de clase para obtener una clasificación inicial de relevancia. En la segunda etapa, el Aquila Optimizer realiza una búsqueda global sobre subconjuntos de características candidatas utilizando sus cuatro estrategias de optimización. En la tercera etapa, el subconjunto refinado pasa por la eliminación de características recursivas con validación cruzada de 10 veces usando un estimador de Bosque Aleatorio (RF).

El Aquila Optimizer estaba configurado con un tamaño de población de 100 personas, un máximo de 10 iteraciones, un factor de explotación de 0,1, una tasa de aprendizaje de 0,1 y un factor de atracción de 0,005. Aplicado de forma independiente a cada conjunto de datos, AQU-IMF-RFE conservó 14 características para UNSW-NB15, 24 para CICIDS2017 y 12 para Bot-IoT. El pseudocódigo completo se proporciona en el Archivo Suplementario 1, y los subconjuntos de características seleccionados se listan en la Tabla 4.

Tabla 4A. Características seleccionadas conservadas para UNSW-NB15
S. No.	Característica	Tipo	Categoría
1	dur	Numérico (flotante)	Básico
2	sbytes	Numérico (entero)	Básico
3	Índice	Numérico (flotante)	Básico
4	dload	Numérico (flotante)	Básico
5	sinpkt	Numérico (flotante)	Tiempo
6	DINPKT	Numérico (flotante)	Tiempo
7	Sjit	Numérico (flotante)	Tiempo
8	TCPRTTT	Numérico (flotante)	Tiempo
9	synack	Numérico (flotante)	Tiempo
10	ackdat	Numérico (flotante)	Tiempo
11	Smean	Numérico (entero)	Contenido
12	ct_srv_src	Numérico (entero)	Conexión
13	ct_dst_src_ltm	Numérico (entero)	Conexión
14	ct_srv_dst	Numérico (entero)	Conexión
Tabla 4B. Características seleccionadas conservadas para CICIDS2017
S. No.	Característica
1	Puerto de destino
2	Duración del flujo
3	Longitud total de los paquetes hacia adelante
4	Longitud total de los paquetes hacia atrás
5	Longitud máxima de paquete redirigido
6	Longitud máxima de paquete hacia atrás
7	Media de la longitud de los paquetes hacia atrás
8	Paquetes de flujo
9	Tiempo máximo de interllegada del flujo
10	Total de tiempo entre llegadas hacia adelante
11	Longitud del cabezazo hacia delante
12	Longitud del cabecero hacia atrás
13	Paquetes directos por segundo
14	Longitud máxima de paquete
15	Media de la longitud del paquete
16	Desviación estándar de longitud de paquete
17	Variación de longitud de paquetes
18	Tamaño medio del paquete
19	Tamaño medio de segmentos hacia atrás
20	Bytes directos de subflujo
21	Subflujo de bytes hacia atrás
22	Bytes iniciales de ventana hacia adelante
23	Bytes iniciales de ventana hacia atrás
24	Media de la longitud de los paquetes hacia adelante
Tabla 4C. Características seleccionadas conservadas para Bot-IoT
S. No.	Característica	Tipo
1	Sig.	Numérico
2	media	Numérico
3	StdDev	Numérico
4	min	Numérico
5	Max	Numérico
6	srate	Numérico (flotante)
7	drate	Numérico (flotante)
8	N_IN_Conn_P_SrcIP	Numérico (entero)
9	N_IN_Conn_P_DstIP	Numérico (entero)
10	proto	Categórico (codificado)
11	state_number	Numérico (entero)
12	Índice	Numérico (flotante)

Tabla 4: Características seleccionadas por el método de selección de características AQU-IMF-RFE. Esta tabla muestra los subconjuntos finales de características seleccionados por el marco de selección de características AQU-IMF-RFE para los conjuntos de datos UNSW-NB15, CICIDS2017 y Bot-IoT. Se proporcionan nombres de características, tipos de datos y categorías funcionales cuando corresponde.

Montaje experimental
Todos los experimentos se realizaron en un servidor Dell PowerEdge R740 equipado con un procesador Intel Xeon Silver 4214 que operaba a una frecuencia base de 2,20 GHz, con 12 núcleos físicos, 24 hilos lógicos, 16,5 MB de caché y una velocidad Intel Ultra Path Interconnect (UPI) de 9,6 GT/s. El servidor estaba configurado con 128 GB de RAM, una unidad SSD de estado sólido (SSD) de 512 GB y funcionaba con Microsoft Windows 11. La pila de software comprendía Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 y NumPy 2.4.4. La capa blockchain se implementó en la misma estación de trabajo usando una red PoA Ethereum. La comunicación entre el IDS y la blockchain se realizaba mediante JSON-RPC utilizando la versión 1.13.15 del cliente go-ethereum (Geth), la versión 0.8.19 del compilador Solidity (solc) para la compilación y despliegue de contratos inteligentes, y la biblioteca de Web3.py versión 6.15.1. Se midieron el tiempo de entrenamiento reportado, la latencia de inferencia y el rendimiento en esta configuración de hardware y software.

Arquitectura y formación de modelos
El modelo BiLSTM Extendido constituye el componente central de detección del marco, basándose en enfoques previos de detección de intrusiones basados en aprendizaje desarrollados para entornos^{IoMT 21}. Estudios anteriores de detección de intrusiones destacaron tanto la importancia de equilibrar el rendimiento de detección con la reducción de falsas^{alarmas 15} como los desafíos únicos de aplicar métodos de aprendizaje automático al tráfico de red^{en evolución 16}. Las arquitecturas colaborativas de detección de intrusiones en redes neuronales han demostrado además el valor del aprendizaje secuencial profundo de características para el tráfico de red^{complejo 22}. Mientras que los modelos estándar de BiLSTM capturan dependencias temporales bidireccionales, el tráfico IoMT presenta tanto patrones de ráfagas a corto plazo como dependencias a largo plazo causadas por ataques multietapa. Para abordar esto, el modelo propuesto extiende BiLSTM con extracción de características temporales, aprendizaje temporal bidireccional mejorado, conexiones residuales y priorización temporal basada en la atención. Los LSTM bidireccionales (BiLSTM) superan esta limitación combinando estados ocultos hacia adelante y hacia atrás, permitiendo una representación temporal más rica de los patrones de tráfico IoMT, como se indica en el Algoritmo 2 (Archivo Suplementario 1).

Sea la secuencia de entrada X^(n_j) = {_{x 1} , x₂ , ... , x_T }, donde cada x_t ∈ R^d es un vector de características preprocesado.

Extracción de características temporales:
Se aplica una convolución ligera unidimensional a lo largo de la dimensión temporal para enfatizar anomalías temporales a corto alcance (Ecuación 6):

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

Aquí, φ(⋅) es una función de activación no lineal y las características convolucionadas u_t se alimentan a la BiLSTM.

La capa Conv1D extrae patrones temporales de corto alcance antes del modelado bidireccional de secuencias. Los parámetros completos de implementación se proporcionan en el Archivo Suplementario 3B.

Aprendizaje LSTM bidireccional apilado:
Los estados ocultos hacia adelante y hacia atrás se calculan como (Ecuación 7):

(7)

La representación final de BiLSTM es la concatenación de estados ocultos pasados (hacia adelante) y futuros (hacia atrás) (Ecuación 8).

(8)

Dos capas BiLSTM apiladas modelan dependencias temporales bidireccionales. Los parámetros arquitectónicos detallados se proporcionan en el Archivo Suplementario 3B. Los detalles de inicialización de pesos se proporcionan en el Archivo Suplementario 3B.

Conexión residual y normalización
Tras la proyección lineal a dimensiones de coincidencia, se aplican conexiones residuales y normalización de capas (Ecuación 9):

La proyección residual y la normalización de capas alinean las representaciones convolucionales y BiLSTM antes de la atención. Los parámetros detallados de implementación se proporcionan en el Archivo Suplementario 3B.

Mecanismo de atención
Aunque BiLSTM proporciona un modelado temporal sólido, no todos los pasos temporales contribuyen por igual a la predicción. Para enfatizar marcas temporales críticas (por ejemplo, picos anómalos repentinos), se introduce un mecanismo de atención. A cada estado oculto se le asigna una puntuación de relevancia α_t para mejorar la precisión de detección (Ecuación 10).

Aquí, W_a es un parámetro entrenó y los pesos de atención satisfacen

El vector de contexto c agrega los estados ocultos según su importancia aprendida (Ecuación 11):

El mecanismo de atención agrega representaciones temporales en un vector de contexto. Los parámetros detallados de implementación se proporcionan en el Archivo Suplementario 3B.

Capa de salida y clasificación
El vector de contexto agregado se pasa a través de una capa totalmente conexa seguida de una activación sigmoide para obtener la predicción final (Ecuación 12):

Aquí, W_c y b_c son parámetros entreables, y σ(·) es la función de activación sigmoide que asigna la salida al intervalo [0,1]. Se aplica un umbral para clasificar el tráfico como benigno () o intrusivo ().

La regularización de abandono y el umbral fijo de clasificación utilizado durante la inferencia se describen en el Archivo Suplementario 3B.

La arquitectura BiLSTM extendida es idéntica en los tres conjuntos de datos; solo la dimensión de la característica de entrada difiere, tomando valores de 14, 24 y 12 para UNSW-NB15, CICIDS2017 y Bot-IoT, respectivamente. Debido a que la capa Conv1D mapea cualquier entrada de dimensión a una representación fija de 64 canales, todas las capas posteriores son independientes del conjunto de datos, y solo la forma de entrada y el conteo de parámetros Conv1D varían con . La arquitectura completa capa por capa se resume en la Tabla 5, con los conteos de parámetros expresados en términos de d; Los totales resultantes son 184.641, 186.561 y 184.257 parámetros entreenables para D = 14, D = 24 y D = 12, respectivamente.

S. No.	Capa (tipo)	Forma de salida	Parámetros entreenables	Función de activación
1	Entrada	(20, d)	0	—
2	Conv1D (64 filtros, tamaño del núcleo = 3, mismo relleno)	(20, 64)	192d + 64	ReLU
3	Capa 1 de LSTM bidireccional (64 unidades por dirección)	(20, 128)	66,048	tanh / sigmoide
4	LSTM bidireccional Capa 2 (64 unidades por dirección)	(20, 128)	98,816	tanh / sigmoide
5	Proyección residual densa	(20, 128)	8,320	Lineal
6	Adición residual	(20, 128)	0	—
7	Normalización de capas (eje = −1, ε = 1 × 10⁻³)	(20, 128)	256	—
8	Atención temporal (Wa ∈ R¹²⁸×¹)	128	128	Softmax
9	Capa oculta densa	64	8,256	ReLU
10	Abandono (p = 0,3)	64	0	—
11	Capa de salida densa	1	65	Sigmoide

Tabla 5: Arquitectura capa por capa del modelo de memoria bidireccional extendida a corto plazo. Esta tabla resume la arquitectura del modelo propuesto de Memoria Bidireccional Extendida a Corto Plazo (BiLSTM), incluyendo tipos de capas, dimensiones de salida, conteos de parámetros entreenables y funciones de activación.

El software y el entorno computacional utilizados para todos los experimentos se resumen en la Tabla 6.

Componente	Versión / Especificación
Sistema operativo	Windows
Plataforma de Servidor	Dell PowerEdge
CPU	Procesador de 64 núcleos
RAM	128 GB
Almacenamiento	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
cuenta eth	0.1
Compilador Solidity (solc)	0.8.19
Go-ethereum (Geth)	1.13.15

Tabla 6: Software y entorno computacional utilizados para la implementación y evaluación del marco propuesto. Esta tabla resume las especificaciones de hardware, componentes de software, herramientas blockchain y números de versión utilizados para el preprocesamiento de datos, selección de características, entrenamiento de modelos, despliegue de blockchain y evaluación del rendimiento.

Decisión de intrusión y respuesta automatizada
La detección de intrusiones en entornos sanitarios solo es efectiva si va acompañada de una respuesta rápida y una mitigación. La Capa de Detección de Intrusiones convierte la probabilidad predicha en una decisión. Formalmente, la decisión de intrusión en el paso de tiempo t se representa de la siguiente manera (Ecuación 13):

Aquí, es la probabilidad de intrusión predicha en el tiempo t y es el umbral de clasificación.

Una vez detectada una intrusión, la Capa de Detección de Intrusiones se conecta directamente con el módulo blockchain, que realiza registros inmutables, mitigación automatizada y aplicación de seguridad en bucle cerrado. Los detalles del evento, incluyendo información de origen, información de destino y características de tráfico seleccionadas, se registran en un nuevo bloque blockchain. Los contratos inteligentes ejecutan acciones de mitigación en tiempo real como aislamiento de nodos y alertas de administrador. Esta arquitectura de lazo cerrado permite que los resultados de detección de intrusiones se alimenten directamente en los mecanismos de prevención, minimizando así la latencia de mitigación. Así, la Capa de Detección de Intrusiones sirve como puente entre la detección temporal utilizando el modelo BiLSTM Extendido y la respuesta segura mediante tecnología blockchain, completando la funcionalidad de extremo a extremo del marco propuesto.

Registro forense basado en blockchain
Aunque el modelo BiLSTM extendido permite la detección de intrusiones en tiempo real, el almacenamiento seguro y la auditoría verificable de los eventos de intrusións son igualmente críticos en entornos sanitarios IoMT. Los mecanismos tradicionales de registro centralizado son vulnerables a manipulaciones y comprometen la trazabilidad forense. Para abordar esta limitación, el marco propuesto incorpora un módulo de blockchain ligero que garantiza inmutabilidad, descentralización y respuesta automatizada basada en contratos inteligentes.

Cada evento de intrusión detectado genera un bloque que se añade a la blockchain. Un bloque B_i se define de la siguiente manera (Ecuación 14):

Aquí, H_i es el hash criptográfico de los datos del evento, la marca de tiempo y el resultado de predicción, T_i es la marca de tiempo, D_i contiene características seleccionadas del evento de intrusión, Si_gi es la firma digital, y PrevHash vincula el bloque al bloque anterior, asegurando la inmutabilidad.

Este diseño garantiza la resistencia a la manipulación porque cualquier modificación de D_i o T_i modifica el hash del bloque y rompe la integridad de la cadena. También proporciona auditabilidad porque todas las anomalías detectadas se almacenan de forma permanente y son verificables. La mitigación automatizada se apoya mediante contratos inteligentes que ejecutan acciones predefinidas como aislamiento de nodos y alertas para administradores. La descentralización se logra mediante múltiples gateways IoMT que mantienen el libro mayor distribuido, eliminando así un único punto de fallo.

La generación de bloques utiliza la función hash criptográfica Keccak-256, la primitiva nativa de hash del entorno Ethereum/Solidity (invocada a través de keccak256 de Solidity). Para cada bloque de intrusión, el hash del bloque se calcula de la siguiente manera:

Aquí, D_i es el resumen de la característica del evento, T_i es la marca de tiempo y PrevHash es el hash del bloque anterior. Los campos se concatenan usando la codificación compactamente empaquetada de Solidity (abi.encodePacked) antes de hacer hash, produciendo un digest de 256 bits.

El mismo cálculo Keccak-256 es utilizado por la rutina de verificación de cadena, que recalcula cada hash de bloque desde sus campos almacenados y confirma que coincide con el valor registrado, validando así la integridad de la cadena. Keccak-256 fue seleccionado porque es el algoritmo estándar de hashing resistente a colisiones utilizado de forma nativa dentro de los contratos inteligentes de Ethereum. El contrato inteligente fue desarrollado en Solidity y compilado usando el compilador Solidity (solc) versión 0.8.19. Se desplegó en una red privada Ethereum Proof-of-Authority (PoA) operada con Geth versión 1.13.15. La red blockchain estaba configurada con cuatro nodos validadores usando el protocolo de consenso Clique Proof-of-Authority, un ID de cadena de 9848, un periodo de bloque de 5 s y un límite de gas de bloque de 30.000.000. La comunicación entre el motor de detección de intrusiones BiLSTM extendido y la capa blockchain se implementó usando la biblioteca Web3.py versión 6.15.1 a través de la interfaz HTTP JSON-RPC.

Mecanismo de Consenso del Poder PoA
Dado que los sistemas IoMT sanitarios son altamente sensibles a la latencia, el marco propuesto emplea un mecanismo de consenso PoA en lugar de una costosa Prueba de Trabajo (PoW⁾²³, que es computacionalmente costosa. En PoA, un conjunto fijo de nodos validadores de confianza, como las pasarelas hospitalarias, autorizan las transacciones, proporcionando tanto eficiencia como resiliencia.

La complejidad temporal de la validación por bloques bajo PoW puede expresarse de la siguiente manera (Ecuación 15):

Aquí, d representa la dificultad de minería.

En cambio, la complejidad temporal del consenso PoA se expresa de la siguiente manera (Ecuación 16):

porque la validación solo requiere la verificación de firma digital por parte de nodos validadores autorizados.

Como resultado, PoA proporciona un funcionamiento de baja latencia adecuado para alertas médicas en tiempo real, eficiencia energética al evitar minería computacionalmente intensiva y resiliencia frente a un número limitado de validadores maliciosos. La red PoA se configuró con cuatro nodos validadores, y esta configuración se mantuvo fija durante todos los experimentos para garantizar mediciones de latencia consistentes, evaluación reproducible del rendimiento y una comparación justa entre todos los conjuntos de datos de referencia.

Implementación de blockchain y operación de contratos inteligentes
El componente blockchain se implementó en una red Ethereum autorizada que operaba bajo el modelo de consenso^{PoA 24}. La red se ejecutaba usando el cliente go-ethereum (Geth) con el protocolo de consenso Clique^{PoA 25}, en el que un conjunto de nodos validadores autorizados (selladores) son responsables de producir y validar bloques. El contrato inteligente de registro de intrusiones (IoMTIntrusionLedger) fue escrito en Solidity y desplegado en esta red, siguiendo arquitecturas de seguridad IoT basadas en blockchain para la gestión segura y descentralizada de eventos²⁶. Solo las cuentas de pasarela autorizadas on-chain (a través de la función de control de acceso del contrato) podían enviar registros de intrusión, de acuerdo con las arquitecturas de contratos inteligentes de blockchain autorizadas para aplicaciones del Internet^{de las Cosas 27}. La capa blockchain se implementó utilizando la versión 1.13.15 del cliente go-ethereum (Geth) para operar la red PoA con permisos, el compilador Solidity (solc) versión 0.8.19 para la compilación y despliegue de contratos inteligentes, y la biblioteca de Web3.py versión 6.15.1 para la comunicación entre el IDS y la red blockchain.

Los parámetros detallados de despliegue y configuración de la blockchain se proporcionan en el Archivo Suplementario 3C.

Cada registro de intrusións se firma digitalmente antes de ser registrado en el libro mayor, apoyando la auditoría sanitaria basada en blockchain y el mantenimiento seguro de registros^{forenses 28}. Los procedimientos de generación y verificación de firma digital, incluyendo ECDSA sobre la curva secp256k1 ^29,30, se describen en el Archivo Suplementario 3D. Cada puerta de enlace contiene un par de claves de Ethereum que consiste en una clave privada de 256 bits (32 bytes) y la clave pública correspondiente, de la cual se deriva la dirección de su cuenta; la generación de claves sigue el procedimiento estándar de Ethereum, utilizando una clave privada aleatoria de 256 bits criptográficamente segura, con la clave pública obtenida mediante multiplicación escalar secp256k1. Para crear una firma, el cliente gateway calcula el digest de la característica de evento D_i y lo firma con su clave privada usando el formato de firma de mensajes EIP-191, produciendo una firma de 65 bytes compuesta por los componentes r, s y v. La firma se presenta junto con el registro de intrusión. La verificación se realiza en cadena mediante el contrato inteligente: usando la precompilación EVM ecreEQuest, el contrato recupera la dirección del firmante del digest y la firma firmados y requiere que sea igual a la dirección de la pasarela autorizada que presenta la transacción. Si la dirección recuperada no coincide con una pasarela autorizada, la transacción es rechazada. Esto vincula cada entrada del libro mayor a una pasarela autorizada específica y evita registros de intrusiones no autorizadas o falsificadas.

Los contratos inteligentes se activan automáticamente al detectar intrusiones, asegurando una respuesta en tiempo real sin necesidad de intervención manual (Ecuación 17):

(17)

El módulo blockchain opera en paralelo con el clasificador BiLSTM Extendido. Una vez detectada una anomalía: (i) el evento es etiquetado y clasificado por el BiLSTM, (ii) se genera, firma y añade un bloque al libro mayor de la blockchain, y (iii) los contratos inteligentes aplican políticas de respuesta automática.

El contrato inteligente de registro de intrusiones (IoMTIntrusionLedger) mantiene un libro mayor solo de anexos de bloques de intrusións y un registro de cuentas de pasarela autorizadas, y expone las funciones resumidas en la Tabla 7. El contrato impone dos roles de acceso mediante modificadores: onlyAdmin (el administrador que despliega) y onlyGateway (cuentas autorizadas a enviar registros de intrusión). El estado consiste en el mapeo de autorización de la pasarela, el array del libro mayor de bloques y la cabeza de cadena actual (el hash del bloque más reciente).

S. No.	Función / Componente	Tipo	Acceso	Lógica
1	constructor	Constructor	—	Establece al desplegador como administrador y lo autoriza como la puerta de enlace inicial.
2	setGateway(dirección, bool)	Función	onlyAdmin	Añade o elimina una cuenta de gateway autorizada; emite GatewayUpdated.
3	recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate)	Función	onlyGateway	Calcula Hi = Keccak-256(Di ∥ Ti ∥ probabilidad ∥ PrevHash); verifica la firma ECDSA de la pasarela en Di mediante ecrecover; añade el bloque al libro mayor; avanza la cabeza de la cadena; emite BlockCreated, opcionalmente NodeIsolated y AdminAlert. DevuelveH i.
4	verifyChain()	Función de visualización	Público	Recalcula el hash de cada bloque desde sus campos almacenados y comprueba el enlace PrevHash; devuelve true solo si toda la cadena es consistente (detección de manipulaciones).
5	ledgerLength()	Función de visualización	Público	Devuelve el número de bloques en el libro mayor.
6	_recoverSigner(hash, firm)	Función interna	—	Divide la firma de 65 bytes en (r, s, v) y recupera la dirección de firma mediante la precompilación ecrequed.
7	BlockCreated / NodeIsolated / AdminAlert / GatewayUpdated	Eventos	—	Emitido para que los oyentes fuera de cadena puedan gestionar el registro, aislamiento de nodos, alertas de administrador y actualizaciones del registro de gateway.
8	onlyAdmin / onlyGateway	Modificadores	—	Restringir funciones al administrador y a las pasarelas autorizadas, respectivamente.

Tabla 7: Funciones, eventos y componentes de control de acceso del contrato inteligente IoMTIntrusionLedger. Esta tabla resume las funciones principales, eventos y modificadores de control de acceso implementados dentro del contrato inteligente blockchain autorizado. Estos componentes soportan la autorización de pasarela, registro de intrusiones, verificación de blockchain, generación de eventos y mitigación automatizada.

La propiedad de inmutabilidad de la blockchain se deduce directamente de la Ecuación 14, donde cualquier modificación en los datos de eventos o marcas de tiempo invalida la cadena hash. De este modo, la blockchain proporciona integridad de los datos, trazabilidad y capacidad de auditoría para los sistemas sanitarios mediante registros forenses inmutables. Los registros de intrusiones de pacientes y dispositivos permanecen sin cambios una vez almacenados, cada bloque se vincula de forma segura al bloque anterior permitiendo la reconstrucción cronológica de eventos, y los administradores o reguladores sanitarios pueden verificar incidentes de intrusións sin riesgo de falsificación.

Función de pérdida y optimización del modelo
El modelo BiLSTM Extendido propuesto aborda el problema de clasificación binaria de distinguir entre tráfico normal y eventos de intrusión en redes IoMT. Para guiar el proceso de entrenamiento, se adopta una pérdida binaria de entropía cruzada (BCE), que es muy adecuada para salidas probabilísticas de la capa de activación sigmoide. Para un conjunto de datos con N muestras, la pérdida se define de la siguiente manera (Ecuación 18):

(18)

Aquí, es la etiqueta de verdad fundamental de la i^ésima secuencia de entrada (0 = benigno, 1 = intrusión), y es la probabilidad predicha de intrusión.

El marco funciona como una cadena de clasificación en dos etapas. La primera etapa realiza la detección de intrusiones binarias: el BiLSTM extendido produce una salida sigmoide y aplica el umbral τ = 0,5 para clasificar cada ventana como benigna o intrusiva (Ecuaciones 12,13), entrenada con pérdida cruzada binaria ponderada. Una segunda etapa puede realizar la categorización de ataques, en la que ventanas identificadas como intrusiones se pasan a un clasificador multiclase que asigna la categoría específica de ataque usando una capa de salida softmax entrenada con entropía cruzada categórica. El presente estudio se centra y evalúa la etapa de detección binaria. Las dos etapas comparten la misma columna vertebral de extracción de características de BiLSTM extendida (Conv1D, BiLSTM, capas residual, de normalización y de atención); solo difieren en su capa de salida (sigmoide para detección y softmax para categorización) y en la función de pérdida correspondiente. La etapa de detección binaria y la etapa de categorización multiclase fueron entrenadas y evaluadas bajo las mismas particiones de datos, semillas aleatorias y condiciones de entrenamiento descritas anteriormente.

Aunque el tráfico IoMT suele estar desequilibrado, se utiliza una pérdida binaria ponderada de entropía cruzada para penalizar la clasificación errónea de la clase minoritaria. Los pesos de clase se calculan usando el número de muestras de intrusión N_p, el número de muestras benignas N_n y el número total de muestras N (Ecuaciones 19,20):

La ponderación asegura que el modelo no esté sesgado hacia la clase dominante de tráfico benigno y permanezca sensible a eventos de intrusión, raros pero críticos.

La pérdida ponderada de entropía cruzada binaria se da de la siguiente manera (Ecuación 21):

(21)

El entrenamiento se realizaba utilizando mini-lotes de tamaño 64. Al inicio de cada época, las muestras de entrenamiento se barajaban aleatoriamente antes de particionarse en lotes, de modo que la composición por lotes variaba entre épocas y el modelo no veía ejemplos en un orden fijo. Los lotes no estaban explícitamente equilibrados ni estratificados por clase; en cambio, cada lote reflejaba la distribución natural de clases del conjunto de entrenamiento, y el desequilibrio de clases se abordaba mediante la pérdida binaria ponderada por clase cruzada (Ecuaciones 19–21). El subconjunto de validación reservado de la partición de entrenamiento permaneció fijo entre épocas y no se barajó en los lotes de entrenamiento.

Los pesos de clase en la pérdida de entropía cruzada binaria ponderada no se establecieron manualmente, sino que se calcularon automáticamente para cada conjunto de datos a partir de los conteos de clases del conjunto de entrenamiento según las Ecuaciones 19 y 20. Para el conjunto de datos UNSW-NB15, los pesos de clase resultantes correspondían a la clase normal y a la clase de intrusión. Para el conjunto de datos CICIDS2017, los pesos resultantes de la clase normal y de la clase de intrusión. Para el conjunto de datos Bot-IoT (subconjunto del 5%), los pesos resultantes de la clase normal y de la clase de intrusión.

Estrategia de entrenamiento y optimización
El modelo BiLSTM extendido se entrenó usando mini-lotes de tamaño B = 64 con pérdida de entropía cruzada binaria ponderada, el optimizador Adam y parada temprana basada en la pérdida de validación. El entrenamiento se limitó a 50 épocas y se aplicó una parada temprana con paciencia K = 5. Si la pérdida de validación no mejoraba durante cinco épocas consecutivas, el entrenamiento se detenía y los pesos del modelo se restauraban a los de la época con la menor pérdida de validación. Así, 50 épocas representaban el presupuesto máximo de formación en lugar de una duración fija de entrenamiento. Se aplicó una probabilidad de abandono de 0,3 para la regularización. Los ajustes arquitectónicos incluían 64 filtros Conv1D, 64 unidades LSTM por dirección, una longitud de ventana de T = 20 y una zancada de s = 1. La estrategia de entrenamiento adoptada se resume en el Algoritmo 3 (Archivo Suplementario 1). Las ecuaciones de actualización de Adam utilizadas para optimización se proporcionan en el Archivo Suplementario 3A.

El optimizador Adam estaba configurado con una tasa de aprendizaje de , una tasa de decaimiento en el primer momento (β₁) de 0,9, una tasa de decaimiento en el segundo momento (β₂) de 0,999 y una constante de estabilidad numérica () de 1 × ^10-7. No se usaron opciones adicionales de optimizador, ni se aplicó decaimiento de peso ni recorte de gradiente.

Generación de alertas y mitigación automatizada
La detección por sí sola es insuficiente en redes IoMT sensibles a la latencia, donde la respuesta rápida es crítica para garantizar la seguridad del paciente. La Capa de Generación y Mitigación de Alertas operacionaliza la decisión de intrusión tomada por el modelo BiLSTM Extendido y el mecanismo de registro blockchain. Si δ_t = 1, el módulo blockchain añade un nuevo bloque que contiene los detalles de la intrusión . Simultáneamente, se ejecuta un contrato inteligente para activar acciones de mitigación (Ecuación 22):

(12)

Aquí, BlockCreation garantiza un registro forense inmutable del evento, NodeIsolation (_{n j}) pone en cuarentena el nodo IoMT comprometido para evitar daños mayores, y AdminAlert entrega notificaciones en tiempo real a los administradores del sistema. Para operar esta cadena de respuesta de doble capa, el pseudocódigo se presenta en el Algoritmo 4 (Archivo Suplementario 1).

El procesamiento de eventos por contratos inteligentes y los mecanismos de respuesta fuera de cadena se describen en el Archivo Suplementario 3E.

Cada entrada comprometida en el libro mayor de la blockchain se almacena como un registro IntrusionBlock, cuyos campos y formatos de datos se listan en la Tabla 8. El libro mayor es un array de solo añadir de estos registros, y el cabezal de cadena actual almacena el hash del bloque añadido más recientemente.

S. No.	Campo	Tipo de datos	Tamaño	Descripción
1	hashId	bytes32	32 bytes	Hash de bloque Hi = Keccak-256(Di ∥ Ti ∥ probabilidad ∥ PrevHash)
2	Marca temporal	uint256	32 bytes	Tiempo de creación del bloque Ti (segundos de época Unix, desde la marca temporal del bloque)
3	nodeId	bytes32	32 bytes	Identificador del nodo IoMT nj
4	pacienteId	bytes32	32 bytes	Identificador de paciente/dispositivo (metadatos forenses)
5	Clase ataque	uint16	2 bytes	Código de categoría de ataque (0 = Normal, 1 = DDoS, 2 = Suplantación, ...)
6	probabilidadBp	uint16	2 bytes	Probabilidad de intrusión predicha ŷ en puntos base (0–10000, es decir, 0,00–100,00%)
7	dataDigest	bytes32	32 bytes	ResumenD i de las características seleccionadas del evento
8	Firma	Bytes	Variable (65 bytes)	Firma ECDSA Sigi del digest de eventos por la pasarela (r, s, v)
9	prevHash	bytes32	32 bytes	Hash del bloque anterior (PrevHash), enlazando la cadena
10	aislado	bool	1 byte	Si se activó el aislamiento de nodos para este registro

Tabla 8: Estructura del registro IntrusionBlock almacenado en el libro mayor de la blockchain. Esta tabla describe los campos, tipos de datos, tamaños de almacenamiento y propósitos de los registros del libro mayor de blockchain utilizados para almacenar eventos de intrusión. La estructura soporta la verificación de integridad criptográfica, la trazabilidad forense y mecanismos de respuesta automatizada.

La latencia total de mitigación puede expresarse como la suma del retardo de detección (T_d) del modelo BiLSTM Extendido y el retraso de ejecución de la blockchain (T_b) (Ecuación 23):

(23)

Análisis de Complejidad Computacional
La eficiencia del marco propuesto de BiLSTM–Blockchain extendido está determinada tanto por el coste computacional del modelo BiLSTM como por la sobrecarga introducida por el módulo blockchain. El marco propuesto integra la detección BiLSTM Extendida con el registro de blockchain para satisfacer los requisitos de seguridad básicos de la tríada de Confidencialidad, Integridad y Disponibilidad (CIA).

Sea la longitud de la secuencia de entrada preprocesada T, la dimensión de características d y la dimensión oculta de la BiLSTM h.

Para cada paso de tiempo, una BiLSTM procesa entradas de dimensión d con tamaño oculto h. Dado que es bidireccional (adelante + atrás) (Ecuación 24):

) (24)

Aquí, T es la longitud de la secuencia (pasos de tiempo), d es la dimensión de característica de entrada, h es la dimensión de estado oculta

La capa de atención calcula pesos de importancia y agrega estados ocultos con complejidad (Ecuación 25).

(25)

que es lineal tanto en la longitud de secuencia T como en la dimensión oculta h.

Por tanto, la complejidad total de detección por secuencia se da de la siguiente manera (Ecuación 26):

(26)

demostrando que el modelado temporal domina el coste computacional, mientras que el mecanismo de atención introduce solo una sobrecarga ligera.

Por cada evento de intrusión detectado, el registro de blockchain realiza operaciones de hashing, firma y anexión de bloques (Ecuación 27):

(27)

Para N eventos de detección de intrusión, la complejidad combinada es la siguiente (Ecuación 28):

(28)

que puede simplificarse de la siguiente manera (Ecuación 29):

(29)

porque la sobrecarga de la blockchain crece linealmente con el número de eventos y sigue siendo insignificante en comparación con los cálculos de procesamiento de secuencias.

La complejidad computacional se resume en las Ecuaciones 24–29. La interpretación detallada se proporciona en el Archivo Suplementario 3F.

Results

Los resultados están organizados para reflejar los pasos metodológicos del Protocolo, con cada subsección informando de las observaciones producidas por el paso correspondiente.

Manejo de conjuntos de datos y configuración experimental
Los tres conjuntos de datos de referencia se analizaron de forma independiente en lugar de fusionarse. Debido a que UNSW-NB15, CICIDS2017 y Bot-IoT utilizan esquemas de características y convenciones de etiquetado diferentes, cada conjunto de datos fue preprocesado, en ventana y evaluado por separado usando su propio 80:20 división tren/prueba. El modelo BiLSTM extendido fue entrenado y probado en cada conjunto de datos de forma independiente, y las métricas de rendimiento (precisión, exactitud, recuerdo y puntuación F1) se informan por separado para cada conjunto de datos. Este protocolo de evaluación independiente evita las inconsistencias en el espacio de características que surgirían al combinar conjuntos de datos heterogéneos y permite evaluar la robustez del marco propuesto en tres entornos de red distintos.

El modelo propuesto de BiLSTM-BC extendido fue entrenado y evaluado utilizando tráfico normal y malicioso preprocesado extraído de los conjuntos de datos CICIDS2017, UNSW-NB15 y Bot-IoT. Los datos se particionaban mediante una única división estratificada de retención. El conjunto de datos UNSW-NB15 proporciona particiones predefinidas de entrenamiento y prueba, que se utilizaron directamente en este estudio. Para los dos conjuntos de datos restantes (CICIDS2017 y Bot-IoT), las muestras preprocesadas en ventanas se dividieron en conjuntos de entrenamiento y prueba usando una división 80:20 con muestreo aleatorio estratificado (scikit-learn train_test_split, estratificado por etiqueta de clase), preservando así la proporción benigna-intrusión-clase entre las particiones. Dentro del conjunto de entrenamiento, se reservó un 20% adicional para la validación (Keras validation_split), resultando en una partición efectiva del 64% de entrenamiento, 16% de validación y 20% de pruebas. El conjunto de validación se utilizaba para la parada temprana. Se aplicó una semilla aleatoria fija de 42 a scikit-learn, NumPy y TensorFlow para apoyar la reproducibilidad. La red BiLSTM Extendida se optimizó usando el optimizador Adam con una tasa de aprendizaje de 0,001, un tamaño de lote de 64 y un máximo de 50 épocas de entrenamiento.

Resultados de la selección de características
Antes del entrenamiento del modelo, la selección de características se realizaba de forma independiente para cada conjunto de datos utilizando AQU-IMF-RFE, un procedimiento de eliminación de características recursivas guiado por Aquila Optimizer (AO) en el que las características candidatas se clasificaban según su información mutua (MI) con la etiqueta de clase y se eliminaban iterativamente mientras el Aquila Optimizer buscaba el subconjunto óptimo de características. Los campos de identificador (por ejemplo, IDs de flujo, direcciones IP y números de puerto) y los campos de categoría de ataque textual se excluyeron antes de la selección de características para evitar fugas de información. Este procedimiento conservó 14 características para UNSW-NB15, 24 para CICIDS2017 y 12 para Bot-IoT. La lista completa de variables de entrada seleccionadas, sus tipos de datos y sus conjuntos de datos fuente se proporciona en la Tabla 4, y una descripción ampliada de cada característica se incluye en el Archivo Suplementario 2.

Formación y convergencia
Durante el entrenamiento, el modelo demostró convergencia estable, mejorando el rendimiento tanto del entrenamiento como del validador a medida que los parámetros de la red se acercaban a sus valores óptimos. La arquitectura capa por capa del modelo BiLSTM Extendido propuesto se resume en la Tabla 5, mientras que el software y el entorno computacional utilizados para la implementación y evaluación se presentan en la Tabla 6. Las funciones de contratos inteligentes de blockchain que soportan el registro de intrusiones y la mitigación automatizada se resumen en la Tabla 7, y la estructura del registro de intrusiones blockchain se presenta en la Tabla 8. El conjunto completo de hiperparámetros de entrenamiento utilizados en este estudio se resume en la Tabla 9, apoyando la reproducibilidad del marco propuesto.

Hiperparámetro de entrenamiento	Valor
Ritmo de aprendizaje	0.001
Optimizador	Adam
Tamaño del lote	64
Épocas Máximas	50
Función de activación de salida	Sigmoide
División de prueba de tren	80:20, estratificado
División de validación	20% de la partición de entrenamiento
Semilla aleatoria	42
Longitud de ventana de entrada	20 pasos de tiempo
Zancada con ventana deslizante	1
Filtros Conv1D	64
Tamaño del núcleo Conv1D	3
Relleno Conv1D	Igual
Activación Conv1D	ReLU
Capas BiLSTM	2
Unidades BiLSTM	64 unidades por dirección
Dimensión de salida de BiLSTM	128
Activación de LSTM	Tanh
Dimensión residual de proyección	128
Paciencia para parar temprano	5 épocas
Unidades densas de capa oculta	64
Activación densa en capas ocultas	ReLU
Tasa de abandono	0.3
Unidades de salida	1
Umbral de clasificación	0.5
Función de pérdida	Entropía Cruzada Binaria Ponderada (WBCE)

Tabla 9: Configuración de hiperparámetros utilizada para entrenar el modelo de Memoria Bidireccional Extendida a Corto Plazo. Esta tabla enumera los principales hiperparámetros de entrenamiento utilizados durante el desarrollo del modelo de detección de intrusiones Bidireccional Bidireccional a Corto Plazo (BiLSTM), incluyendo ajustes de optimización, función de activación, tamaño del lote, duración del entrenamiento y función de pérdida.

La Tabla 10 presenta las precisiones de entrenamiento y validación del modelo propuesto a lo largo de 50 épocas, registradas en intervalos de 5 épocas. El modelo mostró una mejora rápida durante las primeras 10 épocas, logrando precisiones de entrenamiento y validación del 96,0% y 95,5%, respectivamente. Más allá de la época 20, las ganancias de precisión se volvieron incrementales y ambas curvas convergieron estrechamente. Para la época 50, el modelo se estabilizó con un 99,1% de precisión en el entrenamiento y un 98,5% de validación, lo que indica un sobreajuste mínimo y un fuerte rendimiento de generalización. La curva de aprendizaje correspondiente se muestra en la Figura 3, ilustrando la progresión de la precisión del entrenamiento y la validación a lo largo del proceso de optimización.

Época	Precisión del entrenamiento (%)	Precisión de validación (%)
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

Tabla 10: Precisión de entrenamiento y validación durante el entrenamiento del modelo de memoria bidireccional extendida a corto plazo. Esta tabla informa de la precisión del entrenamiento y validación medida en épocas seleccionadas durante la optimización del modelo Propuesto de Memoria Bidireccional Extendida a Corto Plazo (BiLSTM). Estos valores se utilizaron para generar la curva de convergencia de precisión mostrada en la Figura 3.

Figura 3. Precisión de entrenamiento y validación del modelo BiLSTM Extendido. Gráfico de líneas que muestra la precisión de clasificación durante el entrenamiento del modelo. El eje x representa épocas de entrenamiento (1–50), y el eje y representa la precisión de clasificación (%). Los círculos azules indican la precisión del entrenamiento, y los cuadrados naranjas indican la precisión de validación. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

La Tabla 11 presenta los valores de pérdida de entrenamiento y validación registrados en los mismos intervalos de 5 épocas. Durante la fase inicial de entrenamiento, la pérdida de entrenamiento disminuyó de 0,64 a 0,28, mientras que la pérdida de validación disminuyó de 0,67 a 0,31 en la época 5. Tras la época 20, la tasa de reducción de pérdidas se volvió más gradual y ambas curvas convergieron de forma constante. Para la época 50, la pérdida de entrenamiento se estabilizó en 0,08, mientras que la pérdida de validación se mantuvo cercana en 0,12, indicando solo una pequeña diferencia entre ambas curvas. Esta convergencia refleja una optimización efectiva, un sobreajuste limitado y una buena generalización de datos inéditos. Las curvas de pérdida correspondientes de entrenamiento y validación se presentan en la Figura 4. La eficiencia computacional de los modelos evaluados, incluyendo la latencia de inferencia y el rendimiento, se resume en la Tabla 12. El análisis detallado de estas mediciones se presenta más adelante en la subsección de eficiencia computacional.

Época	Pérdida de entrenamientos	Pérdida de validación
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

Tabla 11: Pérdida de entrenamiento y validación durante el entrenamiento del modelo de memoria bidireccional extendida a corto plazo. Esta tabla informa de los valores de pérdida binaria ponderada por entropía cruzada ponderados en el entrenamiento y validación de iones medidos en épocas seleccionadas durante la optimización del modelo Propuesto de Memoria Bidireccional Extendida a Corto Plazo (BiLSTM). Estos valores se utilizaron para generar la curva de convergencia de pérdidas mostrada en la Figura 4.

Figura 4. Pérdida de entrenamiento y validación del modelo BiLSTM extendido. Gráfico de líneas que muestra la pérdida de entropía cruzada binaria ponderada durante el entrenamiento del modelo. El eje x representa las épocas de entrenamiento (1–50), y el eje y representa los valores de pérdida. Los círculos azules indican la pérdida de entrenamiento, y los cuadrados naranjas indican la pérdida de validación. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Modelo	Latencia (Promedio de ms/evento)	Rendimiento (Promediado de eventos)
Árbol de Decisión	40	845
Máquina de Vectores de Soporte	75	670
LSTM	110	559
Marco Propuesto de BiLSTM–Blockchain Extendido	135	320

Tabla 12: Comparación de latencia y rendimiento de modelos de detección de intrusiones. Esta tabla compara la latencia de inferencia y el rendimiento de procesamiento entre modelos representativos de detección de intrusiones de aprendizaje automático y aprendizaje profundo. La latencia se informa como milisegundos por evento y el rendimiento se reporta como eventos procesados por segundo.

Rendimiento de detección
La Tabla 13 presenta la evaluación comparativa del marco propuesto frente a los modelos convencionales de línea base de ML y DL en los tres conjuntos de datos de referencia. El modelo propuesto alcanzó precisiones del 98,9% en CICIDS2017, 95,9% en UNSW-NB15 y 98,8% en Bot-IoT, junto con altas sensibilidades de 96,9%, 97,6% y 98,8%, respectivamente. En CICIDS2017 y UNSW-NB15, el modelo propuesto alcanzó la mayor precisión entre todos los modelos evaluados, mientras que en Bot-IoT logró la mayor precisión (98,8%), igualada por la línea base del Árbol de Decisión (DT). En Bot-IoT, el modelo propuesto superó ligeramente la línea base LSTM (98,3%) y tuvo un rendimiento comparable a la línea base de la Máquina de Vectores de Soporte (SVM) (98,7%); Los márgenes de rendimiento más pequeños en este conjunto reflejan su extremo desequilibrio de clases, en el que el tráfico benigno constituye solo una fracción muy pequeña del conjunto de pruebas. En general, el modelo propuesto mantuvo un fuerte equilibrio entre sensibilidad y precisión, demostrando un rendimiento robusto en la detección de intrusiones en todos los conjuntos de datos mientras proporcionaba la evaluación más fiable en los conjuntos de datos de referencia más equilibrados (CICIDS2017 y UNSW-NB15). Las comparaciones correspondientes de precisión, exactitud y recuerdo entre conjuntos de datos y modelos de referencia se presentan en las Figuras 5–7.

Conjunto de datos	Modelo	Sensibilidad (%)	Especificidad (%)	Precisión (%)	Precisión (%)	Revocación (%)
CICIDS2017	BiLSTM–Blockchain Propuesta	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 Propuesta	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 Propuesta	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

Tabla 13: Comparación de rendimiento de modelos de detección de intrusiones entre conjuntos de datos de referencia. Esta tabla compara el marco propuesto y los modelos de detección de intrusiones en los conjuntos de datos CICIDS2017, UNSW-NB15 y Bot-IoT utilizando métricas de rendimiento de sensibilidad, especificidad, precisión, precisión y recuerdo.

Figura 5. Comparación de precisión entre conjuntos de datos y modelos de aprendizaje automático/aprendizaje profundo. Gráfico de barras agrupado que compara la precisión de clasificación (%) obtenida por diferentes modelos a través de los conjuntos de datos CICIDS2017, UNSW-NB15 y Bot-IoT. Las barras representan el modelo propuesto, Memoria a Corto Plazo Largo (LSTM), Máquina de Vectores de Soporte (SVM) y Árbol de Decisión (DT). El eje x representa conjuntos de datos, y el eje y representa la precisión de clasificación (%). Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 6. Comparación precisa de modelos de clasificación entre conjuntos de datos de detección de intrusiones. Gráfico de barras agrupado que muestra la precisión (%) obtenida por diferentes modelos en los conjuntos de datos CICIDS2017, UNSW-NB15 y Bot-IoT. El eje x representa los modelos de clasificación y el eje y la precisión (%). LSTM, Memoria a Corto Plazo Largo; SVM, Máquina de Vectores de Soporte; DT, árbol de decisión. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 7. Recuerda la comparación de modelos de clasificación entre conjuntos de datos de detección de intrusiones. Gráfico de barras agrupado que muestra la memoria (%) obtenida por diferentes modelos en los conjuntos de datos CICIDS2017, UNSW-NB15 y Bot-IoT. El eje x representa los modelos de clasificación y el eje y representa el recuerdo (%). LSTM, Memoria a Corto Plazo Largo; SVM, Máquina de Vectores de Soporte; DT, árbol de decisión. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Para comprender mejor la contribución de cada componente arquitectónico, se realizó un estudio de ablación. Los resultados, resumidos en la Tabla 14, muestran que el mecanismo de atención mejoró la priorización temporal, las capas residual y convolucional mejoraron la extracción de características y estabilizó el aprendizaje, y la integración blockchain proporcionó un registro forense a prueba de manipulaciones junto con mitigación automatizada. Cada mejora arquitectónica contribuyó de forma incremental a una mayor precisión en la detección mientras reducía las predicciones de falsos positivos.

Variante de modelo	Precisión (%)	Precisión (%)	Revocación (%)	F1-Puntuación (%)	Tasa de falsos positivos (%)	Notas
BiLSTM Pura	97.5	93.9	93.3	93.67	1.47	Modelo base de detección de intrusiones secuenciales
BiLSTM + Atención	98.04	95.18	94.85	95.01	1.18	El mecanismo de atención prioriza las características temporales informativas
BiLSTM extendido (Residual + Conv1D)	97.5	94.6	93.06	93.82	1.3	Las conexiones residuales y las capas convolucionales mejoran la extracción temporal de características y la estabilidad del entrenamiento
BiLSTM extendido + Blockchain	98.9	97.5	96.9	97.3	0.59	Marco completo con detección de intrusiones, registro inmutable y mitigación automatizada

Tabla 14: Estudio de ablación de componentes arquitectónicos en el marco propuesto de detección de intrusiones. Esta tabla resume la contribución de los componentes arquitectónicos individuales, incluyendo mecanismos de atención, aprendizaje residual, extracción de características convolucionales e integración blockchain, al rendimiento global del marco propuesto.

Para cada variante de ablación, se eliminó un único componente del marco propuesto mientras que todas las condiciones restantes se mantuvieron constantes. El mismo conjunto de datos, entradas preprocesadas en ventana, división estratificada tren/prueba idéntica de 80:20 con partición de validación, semilla aleatoria fija (42), optimizador (Adam), tasa de aprendizaje (0,001), tamaño del lote (64), máximo de 50 épocas de entrenamiento, criterio de parada temprana (paciencia = 5), tasa de abandono (0,3) y arquitectura de red se mantuvieron en todos los experimentos. Solo se modificó el componente bajo evaluación, asegurando así que las diferencias de rendimiento observadas fueran atribuibles únicamente al componente eliminado.

El marco propuesto mantuvo un equilibrio favorable entre precisión y recuerdo en comparación con los modelos de referencia (LSTM, SVM y DT), demostrando una mejor discriminación de patrones de ataque sutiles sin aumentar sustancialmente las predicciones de falsos positivos. Este rendimiento equilibrado se refleja en la diferencia consistentemente pequeña entre los valores de precisión y de recuerdo, lo que indica una puntuación F1 alta y una generalización robusta a través de tráfico de red heterogéneo. Las comparaciones de precisión y recuerdo se presentan en las Figuras 6 y 7.

En comparación con las líneas base representativas de IDS, incluyendo SVM, DT y LSTM, el marco propuesto demostró una ventaja de rendimiento consistente en los conjuntos de datos de referencia con suficiente tráfico benigno. En CICIDS2017, el modelo propuesto de BiLSTM–Blockchain extendido alcanzó una precisión del 98,9%, superando las líneas base de LSTM (97,5%), DT (97,5%) y SVM (98,1%). En UNSW-NB15, alcanzó una precisión del 95,9%, nuevamente la más alta entre los modelos evaluados (LSTM 92,2%, SVM 94,1%, DT 94,8%). En Bot-IoT, caracterizado por un desequilibrio extremo de clase con una clase benigna muy pequeña, el modelo propuesto alcanzó una precisión del 98,8%, igualando la línea base de DT y superando marginalmente las líneas base LSTM (98,3%) y SVM (98,7%). Los modelos tradicionales de aprendizaje automático mostraban una capacidad comparativamente limitada para modelar dependencias temporales a largo alcance, mientras que el LSTM mejoró el aprendizaje temporal de características; Sin embargo, ninguno de estos modelos base proporcionaba registro forense resistente a manipulaciones ni trazabilidad automatizada de eventos basada en blockchain. Al integrar el aprendizaje residual, un mecanismo de atención y el registro inmutable basado en blockchain con la arquitectura BiLSTM Extendida, el marco propuesto combinaba un rendimiento competitivo de detección de intrusiones con una responsabilidad forense verificable más allá de la proporcionada por los métodos base. El componente blockchain registra la intrusión detectada como una entrada inmutable del libro mayor que contiene el identificador de bloque, la marca de tiempo, los datos de eventos cifrados, el hash criptográfico y la firma digital. Un ejemplo de la estructura de registros blockchain se muestra en la Figura 8. La precisión comparativa y la tasa de error entre los modelos evaluados se presentan en las Figuras 9 y 10, respectivamente, mientras que la Figura 11 compara los tiempos de entrenamiento de los modelos evaluados. Las métricas generales de rendimiento del marco propuesto, incluyendo precisión, precisión, recuerdo, puntuación F1 y tasa de falsos positivos, se resumen en la Figura 12, y la comparación combinada de precisión y puntuación F1 se presenta en la Figura 13.

Figura 8. Ejemplo de registro de intrusión en blockchain generado tras la detección de intrusión. Ejemplo ilustrativo de un registro blockchain creado tras la detección de intrusión. El registro contiene un identificador de bloque, identificador de paciente/dispositivo, marca de tiempo, datos de eventos cifrados, hash del bloque anterior, hash del bloque actual y firma digital. La estructura de registros corresponde a la representación de blockchain definida en la Ecuación 14. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 9. Comparación de precisión entre el marco propuesto y los modelos de detección de intrusiones de referencia. Gráfico de barras que compara la precisión de clasificación del propuesto marco BiLSTM–Blockchain extendido con modelos de detección de intrusiones de referencia. El eje x representa los modelos de clasificación y el eje y representa la precisión de la clasificación (%). LSTM, Memoria a Corto Plazo Largo; SVM, Máquina de Vectores de Soporte; DT, árbol de decisión. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 10. Comparación de tasas de error entre el marco propuesto y los modelos de detección de intrusiones de referencia. Gráfico de barras que muestra las tasas finales de error obtenidas por el marco propuesto Extended BiLSTM–Blockchain y los modelos de detección de intrusiones en benchmarks. El eje x representa los modelos de clasificación y el eje y representa la tasa de error (%). Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 11. Comparación de tiempo de entrenamiento de modelos de detección de intrusiones. Gráfico de barras que muestra la duración del entrenamiento con reloj de pared de cada modelo evaluado. El eje x representa los modelos de clasificación y el eje y el tiempo de entrenamiento (segundos). Los tiempos de entrenamiento se midieron utilizando el entorno de computación experimental descrito en el protocolo. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 12. Métricas de rendimiento del propuesto marco Extended BiLSTM–Blockchain. Gráfico de barras que resume el rendimiento del marco propuesto. Las métricas incluyen precisión, exactitud, recall (tasa de detección) y puntuación F1. La tasa de falsos positivos (FPR = 0,59%) se indica además como una anotación dentro de la figura. El eje y representa los valores de rendimiento (%). FPR, tasa de falsos positivos. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 13. Comparación de precisión y puntuaciones F1 entre modelos de detección de intrusión. Gráfico de barras agrupado que compara la precisión de la clasificación y la puntuación F1 entre los modelos evaluados de detección de intrusión. Las barras moradas representan la precisión y las verdes la puntuación F1. El eje x representa los modelos de clasificación y el eje y representa el rendimiento (%). LSTM, Memoria a Corto Plazo Largo; SVM, Máquina de Vectores de Soporte; DT, árbol de decisión. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

La matriz de confusión obtenida en la etapa de clasificación binaria se presenta en la Tabla 15 y se visualiza en la Figura 14. Agrupados en los tres conjuntos de pruebas de referencia, el modelo clasificó correctamente 486.798 instancias normales, con 4.916 muestras normales erróneamente clasificadas como intrusiones. Para la clase de intrusión, se identificaron correctamente 877.494 instancias de intrusión, mientras que 12.978 muestras de intrusiones fueron clasificadas erróneamente como normales. Estos resultados demuestran una alta capacidad discriminativa con relativamente pocos errores de clasificación, lo que indica un rendimiento fiable para la detección de intrusiones binarias en entornos IoMT. La precisión reportada, la puntuación F1, la latencia y el rendimiento corresponden exclusivamente a la etapa de detección de intrusiones binarias evaluada en este estudio.

Modelo	Conjunto de datos	Tamaño del conjunto de pruebas	True Class	Normal predicha	Intrusión prevista	Total (Verdadero)
BiLSTM Extendido Propuesto - Blockchain	CICIDS 2017	566149	Normal	451946	2673	454619
			Intrusión	3426	108104	111530
			Total (Predicho)	455372	110777	566149
	UNSW-NB 15	82332	Normal	34764	2236	37000
			Intrusión	1087	44245	45332
			Total (Predicho)	35851	46481	82332
	Bot-IoT	733705	Normal	88	7	95
			Intrusión	8465	725145	733610
			Total (Predicho)	8553	725152	733705
LSTM	CICIDS 2017	566149	Normal	447946	6673	454619
			Intrusión	7396	104134	111530
			Total (Predicho)	455342	110807	566149
	UNSW-NB 15	82332	Normal	32765	4235	37000
			Intrusión	2153	43179	45332
			Total (Predicho)	34918	47414	82332
	Bot-IoT	733705	Normal	85	10	95
			Intrusión	12465	721145	733610
			Total (Predicho)	12550	721155	733705
SVM	CICIDS 2017	566149	Normal	449257	5362	454619
			Intrusión	5743	105787	111530
			Total (Predicho)	455000	111149	566149
	UNSW-NB 15	82332	Normal	33729	3271	37000
			Intrusión	1568	43764	45332
			Total (Predicho)	35297	47035	82332
	Bot-IoT	733705	Normal	84	11	95
			Intrusión	9465	724145	733610
			Total (Predicho)	9549	724156	733705
DT	CICIDS 2017	566149	Normal	448697	5922	454619
			Intrusión	7743	103787	111530
			Total (Predicho)	456440	109709	566149
	UNSW-NB 15	82332	Normal	34129	2871	37000
			Intrusión	1397	43935	45332
			Total (Predicho)	35526	46806	82332
	Bot-IoT	733705	Normal	89	6	95
			Intrusión	8465	725145	733610
			Total (Predicho)	8554	725151	733705

Tabla 15: Matriz de confusión del modelo propuesto de detección de intrusión. Esta tabla presenta la matriz de confusión obtenida a partir de la evaluación por conjunto de pruebas del modelo propuesto. Las filas corresponden a etiquetas de clase verdaderas y las columnas corresponden a etiquetas de clase predichas para clases de tráfico normal e intrusión.

Figura 14. Matrices de confusión del propuesto sistema de detección de intrusiones BiLSTM–Blockchain extendido a través de los conjuntos de datos de referencia. Matrices de confusión que muestran los resultados de clasificación para los conjuntos de datos CICIDS2017, UNSW-NB15 y Bot-IoT. Las filas corresponden a etiquetas verdaderas y las columnas a etiquetas predichas. Los valores de las celdas indican el número de instancias asignadas a cada resultado de clasificación. IDS, Sistema de Detección de Intrusiones. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

La precisión por clase, el recuerdo y los valores de puntuación F1 derivados de la matriz de confusión se resumen en la Tabla 16. La alta precisión indica que el marco propuesto rara vez clasificó erróneamente el tráfico benigno como malicioso, reduciendo así alertas innecesarias en entornos sanitarios. De manera similar, los altos valores de recall demuestran una detección efectiva de eventos de intrusión, minimizando los ataques fallidos. Las puntuaciones F1 consistentemente fuertes en ambas clases confirman que el marco propuesto logró un equilibrio equilibrado entre sensibilidad de detección y precisión de clasificación, apoyando su idoneidad para la detección de intrusiones IoMT en tiempo real.

Clase	Precisión (%)	Revocación (%)	F1-Score (%)
Normal	97.4	99	98.2
Intrusión	99.44	98.54	98.99
Promedio	98.42	98.77	98.59

Tabla 16: Métricas de rendimiento por clase del modelo propuesto de detección de intrusiones. Esta tabla informa sobre la precisión, la memoria y los valores de puntuación F1 para las clases normales e intrusiones, junto con el rendimiento medio global obtenido durante la evaluación del conjunto de pruebas.

Eficiencia computacional
El rendimiento en tiempo real se evaluó utilizando mediciones de temporización offline en las ventanas de prueba preprocesadas en lugar de un entorno de transmisión en directo. Para cada conjunto de datos, las muestras de prueba preprocesadas en ventana se procesaron a través de toda la cadena de detección y registro de blockchain, y se registró el tiempo de ejecución del reloj de pared. Los límites temporales se definieron de la siguiente manera. La latencia de detección (T_d) se medía desde el instante inmediatamente anterior a la llamada de inferencia del modelo hasta que se devolvían las probabilidades predichas. Se midió la latencia de mitigación de extremo a extremo (T_mitigation = T_d + T_b) desde el mismo punto de partida hasta la finalización de la transacción final de creación de bloques de blockchain, calculando el componente de escritura de blockchain (T_b) como la diferencia entre ambas mediciones. La verificación del libro mayor se realizaba después de que el temporizador de mitigación-latencia se detuviera y, por tanto, se excluía de la latencia reportada.

El rendimiento se calculaba dividido como el número total de ventanas procesadas por el tiempo de reloj de pared transcurrido necesario para completar la partición de prueba de cada conjunto de datos. La latencia por evento se obtenía dividiendo el tiempo transcurrido correspondiente por el número total de ventanas procesadas. La carga de trabajo consistía en las particiones de prueba en ventana de los tres conjuntos de datos de referencia, preservando sus distribuciones de clases benignas a la intrusión. Las ventanas clasificadas como maliciosas soportaban la carga adicional de registro de blockchain, incluyendo computación digest, firma digital y ejecución de transacciones de contratos inteligentes, mientras que las ventanas benignas solo asumían el coste de detección.

La comparación de latencia y rendimiento entre los modelos representativos de detección de intrusiones se presenta en la Tabla 12. Los modelos convencionales de aprendizaje automático, incluyendo DT y SVM, demostraron menor latencia de inferencia y mayor rendimiento que el marco propuesto de aprendizaje profundo. La línea base del LSTM alcanzó un rendimiento intermedio. El marco propuesto de BiLSTM–Blockchain extendido operaba con una latencia de detección de aproximadamente 135 ms por evento y un rendimiento de aproximadamente 320 eventos/s en el despliegue de Clique PoA de un solo nodo descrito en la Configuración Experimental. Estas mediciones caracterizan el rendimiento del prototipo de validador único en lugar de una evaluación de escalabilidad multinodo.

Además del rendimiento de inferencia, se comparó el tiempo de entrenamiento de cada modelo evaluado para evaluar la eficiencia computacional. El tiempo de entrenamiento es una consideración importante para aplicaciones IoMT en tiempo real, donde es deseable un despliegue rápido de modelos. Como se muestra en la Figura 11, la DT alcanzó la menor latencia por evento (aproximadamente 40 ms) y el mayor rendimiento (aproximadamente 845 eventos/s), seguida por la SVM (aproximadamente 75 ms, 670 eventos/s) y la LSTM (aproximadamente 110 ms, 559 eventos/s). El marco propuesto de BiLSTM–Blockchain Extendido mostró la latencia más alta (aproximadamente 135 ms) y el menor rendimiento (aproximadamente 320 eventos/s) entre los modelos evaluados. Este coste computacional adicional proviene de la arquitectura bidireccional, el mecanismo de atención temporal y el registro inmutable basado en blockchain, que juntos proporcionan un aprendizaje mejorado de características temporales y una trazabilidad forense a prueba de manipulaciones. Aunque estos componentes aumentan la latencia por evento, el rendimiento alcanzado sigue siendo suficiente para la monitorización de intrusiones casi en tiempo real en entornos IoMT.

Una evaluación integral de escalabilidad que involucraba múltiples nodos validadores y cargas de transacciones variables estaba fuera del alcance del prototipo actual de un solo nodo. Evaluar el rendimiento y la latencia como función del número de validadores y la carga de transacciones bajo condiciones controladas representa una dirección importante para futuros trabajos que caracterizan la escalabilidad del marco en entornos hospitalarios distribuidos de mayor tamaño.

Registro y mitigación de blockchain
La Figura 8 ilustra un ejemplo de registro de intrusión en blockchain. Cada bloque almacena de forma segura una intrusión o transacción de datos médicos dentro del libro mayor de la blockchain registrando un identificador de bloque único (Block_ID), identificador de paciente o dispositivo (Patient_ID), marca de tiempo, datos de intrusións cifrados, el hash del bloque anterior, el hash del bloque actual y una firma digital. En conjunto, estos campos proporcionan confidencialidad, integridad, inmutabilidad, autenticación y trazabilidad forense dentro del propuesto marco de detección de intrusiones BiLSTM–Blockchain extendido.

En conjunto, los resultados apoyan la hipótesis central de que integrar un detector de intrusiones BiLSTM Extendido con mayor atención con una capa de registro basada en blockchain proporciona una detección de intrusiones precisa, eficiente y a prueba de manipulaciones para redes IoMT. El marco propuesto logró una precisión global del 98,71% y una puntuación F1 del 98,99%, superando de forma constante los modelos de referencia evaluados por aprendizaje automático y aprendizaje profundo, manteniendo una convergencia estable y evidencia mínima de sobreajuste. El estudio de ablación demostró que cada componente arquitectónico, incluyendo las capas convolucional y residual, el mecanismo de atención y la integración con blockchain, contribuyó de forma incremental al rendimiento global de detección y a la capacidad forense. En el prototipo de un solo nodo, el framework mantenía una latencia media de aproximadamente 135 ms por evento y un rendimiento de aproximadamente 320 eventos por segundo, proporcionando un registro de intrusiones inmutable y verificable. En conjunto, estos hallazgos respaldan la idoneidad del marco integrado de detección y blockchain propuesto para la detección de intrusiones en tiempo real y el registro forense seguro en entornos IoMT.

Disponibilidad de datos:
Los conjuntos de datos de referencia utilizados en este estudio están disponibles públicamente. El conjunto de datos UNSW-NB15 está disponible en el repositorio UNSW Canberra (https://research.unsw.edu.au/projects/unsw-nb15-dataset), el conjunto de datos CICIDS2017 está disponible en el Instituto Canadiense de Ciberseguridad (https://www.unb.ca/cic/datasets/ids-2017.html), y el conjunto de datos Bot-IoT está disponible en el repositorio UNSW Canberra (https://research.unsw.edu.au/projects/bot-iot-dataset).

Los materiales completos necesarios para reproducir el estudio se proporcionan como archivos complementarios. El Archivo Suplementario 1 contiene el pseudocódigo completo para los algoritmos de preprocesamiento, selección de características, entrenamiento de modelos, detección de intrusiones, blockchain y contratos inteligentes descritos en el Protocolo. El Archivo Suplementario 2 contiene la implementación completa de la cadena de preprocesamiento de datos, el modelo BiLSTM extendido, scripts de entrenamiento y evaluación, cliente blockchain, scripts de generación de figuras y pipeline de ejecución de extremo a extremo. El README que lo acompaña proporciona instrucciones paso a paso para reproducir el flujo de trabajo, incluyendo la preparación de conjuntos de datos, entrenamiento de modelos, evaluación, generación de figuras y despliegue opcional de blockchain. El archivo requirements.txt adjunto especifica las dependencias de los paquetes en Python necesarias para recrear el entorno computacional.

Figura	Tipo de figura	Generado de
1	Diagrama de arquitectura conceptual	Software de dibujo vectorial
2	Diagrama de flujo de datos a nivel de implementación	Software de dibujo vectorial
3	Curva de convergencia de precisión	Historial de formación (precisión de entrenamiento y validación por época)
4	Curva de convergencia de pérdidas	Historial de formación (pérdida de entrenamiento y validación por época)
5	Gráfico de barras comparativas de precisión	Valores de precisión por modelo
6	Gráfico de barras comparativos de precisión	Valores de precisión por modelo
7	Gráfico comparativo de barras de recuerdo	Valores de recuerdo por modelo
8	Diagrama de estructura de bloques de blockchain	Estructura conceptual de registros blockchain
9	Tabla comparativa de precisión	Valores de precisión por método
10	Tabla comparativa de tasas de error	Valores de tasa de error por método
11	Tabla comparativa de tiempos de entrenamiento	Duración de entrenamiento medida
12	Gráfico resumen de actuaciones	Valores de precisión del modelo propuesto, recuerdo, exactitud, puntuación F1 y tasa de falsos positivos
13	Tabla comparativa de precisión y puntuaciones F1	Precisión por método y valores de puntuación F1
14	Matriz de confusión	Conteos de matrices de confusión

Tabla 17: Fuentes de datos utilizadas para generar cifras incluidas en el estudio. Esta tabla resume las fuentes de datos y los resultados computacionales utilizados para generar cada figura presentada en el manuscrito. Las cifras cuantitativas se generaron programáticamente a partir de historiales de entrenamiento de modelos, métricas de evaluación, salidas de matrices de confusión y mediciones de rendimiento, mientras que los diagramas conceptuales se crearon utilizando software de dibujo vectorial.

Archivo suplementario 1. Algoritmos y pseudocódigo para el marco propuesto de detección de intrusiones BiLSTM–Blockchain. Este archivo suplementario contiene el pseudocódigo completo para la tubería de preprocesamiento (Algoritmo 1), la detección extendida de intrusiones BiLSTM (Algoritmo 2), el entrenamiento del modelo con parada temprana (Algoritmo 3), la detección y mitigación de intrusiones basada en blockchain (Algoritmo 4), la selección de características AQU-IMF-RFE (Algoritmo 5) y el procedimiento de registro de intrusiones de contratos inteligentes (Algoritmo 6). Por favor, haga clic aquí para descargar este archivo.

Archivo suplementario 2. Código fuente para el propuesto marco de detección de intrusiones BiLSTM–Blockchain extendido. Este archivo suplementario contiene la implementación completa de la tubería de preprocesamiento, el modelo BiLSTM extendido, el entrenamiento y evaluación del modelo, la tubería de ejecución de extremo a extremo, el cliente blockchain y los scripts de generación de figuras necesarios para reproducir los resultados reportados. Por favor, haga clic aquí para descargar este archivo.

Archivo suplementario 3. Procedimientos detallados de implementación y optimización para el marco propuesto de detección de intrusiones BiLSTM–Blockchain. Este archivo suplementario proporciona detalles de implementación omitidos del Protocolo principal por brevedad, incluyendo (A) Optimización extendida del entrenamiento BiLSTM y formulación matemática (objetivo de entrenamiento, optimización Adam, parada temprana y configuración de hiperparámetros); (B) implementación detallada de redes neuronales (Conv1D, BiLSTM apilado, proyección residual, mecanismo de atención, inicialización de pesos, dropout y ajustes de clasificación); (C) despliegue de blockchain e implementación de contratos inteligentes; (D) procedimientos de generación y verificación de firmas digitales; (E) procesamiento de eventos por contratos inteligentes y flujo de trabajo automatizado de respuesta; y (F) interpretación del análisis de complejidad computacional. Estos detalles apoyan la completa reproducibilidad del marco propuesto, manteniendo la legibilidad del Protocolo principal. Por favor, haga clic aquí para descargar este archivo.

README.
Instrucciones para reproducir el flujo de trabajo propuesto. Este archivo proporciona instrucciones de instalación de software, preparación de conjuntos de datos, ejecución de toda la cadena de procesamiento, entrenamiento de modelos, evaluación, generación de figuras, despliegue de blockchain y orientación de reproducibilidad para el marco propuesto.

requirements.txt
Dependencias de software para reproducir el entorno computacional. Este archivo enumera las dependencias de los paquetes Python y los requisitos de versiones compatibles necesarios para ejecutar los componentes de preprocesamiento, entrenamiento de modelos, evaluación, blockchain y visualización del marco propuesto.

Discussion

El presente estudio propone un marco integrado de BiLSTM–Blockchain extendido para la detección y prevención de intrusiones en entornos IoMT. Los resultados demuestran que el marco identifica eficazmente los patrones de intrusión en tráfico heterogéneo de redes IoMT combinando aprendizaje temporal bidireccional con registro forense basado en blockchain. La arquitectura bidireccional permite al modelo capturar dependencias temporales tanto hacia adelante como hacia atrás dentro del tráfico de red, resultando en una alta precisión (99,44%), un recuerdo del 98,54% y una puntuación F1 del 98,99% para la clase de intrusión, manteniendo una tasa baja de falsos positivos (aproximadamente el 1,0%) en comparación con los modelos de detección de intrusiones de referencia evaluados. A diferencia de las arquitecturas convencionales unidireccionales o de línea base, que pueden no capturar dependencias temporales de largo alcance, el modelo propuesto reconoce de forma más eficaz los patrones de tráfico secuencial, mejorando la discriminación entre tráfico de red benigno y malicioso. Estos hallazgos apoyan la hipótesis del estudio de que integrar un detector BiLSTM Extendido con mayor atención con una capa de registro blockchain mejora tanto el rendimiento en la detección de intrusiones como la responsabilidad forense.

El marco propuesto puede situarse dentro de varias líneas de investigación establecidas. Una línea de investigación se centra en la detección de intrusiones mejorada por selección de características para sistemas IoMT, incluyendo enfoques basados en árboles y^{filtros 8}, detectores de aprendizaje en conjunto⁹ y nuestro marco de selección de características AQU-IMF-RFE previamente^{reportado 18}. Estos enfoques mejoran la precisión de detección mediante la reducción de dimensionalidad, pero generalmente se basan en clasificadores que no modelan explícitamente las dependencias temporales bidireccionales en el tráfico de red. El marco propuesto complementa en lugar de reemplazar estos métodos utilizando AQU-IMF-RFE¹⁸ para construir un espacio de características optimizado, sobre el cual el BiLSTM extendido realiza la detección de intrusiones temporales mientras que la capa blockchain proporciona registros forenses inmutables. Una segunda línea de investigación emplea modelos de aprendizaje por secuencias para la detección de intrusiones, incluyendo las arquitecturas BiLSTM mejoradas por atención⁷, IDSs de redes basadas en BiLSTM³¹ y enfoques recurrentes de redes^{neuronales 32,33}. En consonancia con estos estudios, los presentes hallazgos confirman el valor de la modelización temporal bidireccional, con la BiLSTM extendida aumentada de atención alcanzando puntuaciones F1 más altas que las líneas de base LSTM y CNN evaluadas en este estudio. Sin embargo, a diferencia de estos modelos centrados en la detección, el marco propuesto también incorpora el registro de blockchain a prueba de manipulación. Una tercera línea de investigación explora la seguridad basada en blockchain para sistemas sanitarios y IoT, incluyendo arquitecturas sanitarias habilitadas por blockchain e integridad^forense 28,34,35, control de acceso a blockchain ^{autorizado 36,37} y detección de intrusiones federadas impulsadas por blockchain para IoMT³⁸. Aunque estos estudios establecen el valor de la inmutabilidad y la auditabilidad, generalmente tratan la detección de intrusiones y el registro forense como procesos separados o emplean mecanismos de consenso más intensivos computacionalmente. En cambio, el marco propuesto integra una blockchain PoA ligera y autorizada directamente con el detector de intrusiones para proporcionar un registro inmutable y mitigación basada en eventos, manteniendo una baja sobrecarga computacional. En comparación con los enfoques recientes de aprendizaje profundo de IoMT, incluyendo la detección de intrusiones basada en ingeniería^{de características 39} y el aprendizaje federado para IoT médico⁴⁰, la principal contribución del presente estudio es la integración de la detección temporal bidireccional con la trazabilidad forense basada en blockchain dentro de un marco unificado, en lugar de mejorar únicamente la precisión de la detección.

La integración blockchain añade importantes capacidades de confianza, responsabilidad y forenses al marco propuesto. Los registros inmutables de la blockchain aseguran que los eventos de intrusión no puedan modificarse tras la grabación, apoyando así el cumplimiento normativo y la auditoría forense en entornos sanitarios. Cada evento registrado almacena identificadores de dispositivos, marcas de tiempo, hashes criptográficos y firmas digitales que facilitan una verificación y trazabilidad transparentes. Además, la capa de contratos inteligentes permite una mitigación automatizada basada en eventos generando banderas de aislamiento de nodos y alertas de administrador que son procesadas por un oyente fuera de la cadena, reduciendo así el tiempo de respuesta y preservando un registro auditable de cada evento de seguridad. En conjunto, estas capacidades amplían el marco más allá de la detección convencional de intrusiones al integrar la detección, el registro seguro y la respuesta automatizada dentro de una única arquitectura.

Deben reconocerse varias limitaciones del presente estudio. Metodológicamente, la evaluación del modelo se realizó mediante una única división estratificada de retención con una semilla aleatoria fija (42) en lugar de validaciones cruzadas repetidas o múltiples inicializaciones aleatorias. Los hiperparámetros se seleccionaron a partir de valores predeterminados establecidos en lugar de mediante un procedimiento exhaustivo de optimización. La evaluación experimental se basó en tres conjuntos de datos de referencia públicos (UNSW-NB15, CICIDS2017 y Bot-IoT)41,42,43, que, aunque ampliamente aceptados, representan capturas de tráfico estáticas en lugar de tráfico de red en constante evolución. Su desequilibrio inherente de clases también puede influir en el rendimiento del modelo a pesar de la aplicación de entrenamiento ponderado por clase. Además, la arquitectura BiLSTM extendida contiene más parámetros entreenables y requiere tiempos de entrenamiento más largos que las líneas base convencionales de aprendizaje automático debido a su estructura bidireccional recurrente y mecanismo de atención. Aunque la latencia de inferencia medida permite el despliegue en tiempo real en la estación de trabajo de evaluación, los requisitos computacionales y de memoria pueden superar las capacidades de los dispositivos edge IoMT con recursos limitados, haciendo que el despliegue a nivel de gateway o basado en servidor sea más práctico. El marco además asume que la detección de intrusiones y el registro de blockchain ocurren en nodos de acceso confiables y que los nodos validadores de PoA con permisos se comportan de forma honesta. El registro de blockchain introduce una latencia media de confirmación de aproximadamente 2 s, y el crecimiento a largo plazo del libro mayor puede convertirse en una preocupación de escalabilidad en despliegues a gran escala. La suposición de validador confiable es una característica inherente de las blockchains PoA^{autorizadas 24,25}, mientras que los desafíos más amplios de seguridad blockchain se han revisado en otros^lugares. En consecuencia, mitigar la colusión de validadores en despliegues multiinstitucionales sigue siendo un tema importante para futuras investigaciones. Por último, aunque las estadísticas de preprocesamiento se derivaron exclusivamente de la partición de entrenamiento para evitar fugas de información, el uso de conjuntos de datos de referencia preprocesados fuera de línea en lugar de tráfico de red en tiempo real puede sobreestimar el rendimiento práctico, y artefactos conocidos de etiquetado y muestreo dentro de los conjuntos de datos de referencia pueden introducir sesgos específicos de cada conjunto. Aunque el mecanismo de atención proporciona cierto grado de interpretabilidad, el marco sigue siendo en gran medida una caja negra de aprendizaje profundo, lo que podría limitar la transparencia para clínicos y analistas de seguridad que requieren alertas más interpretables. Esta limitación es coherente con las observaciones reportadas en encuestas anteriores de detección de intrusiones de aprendizaje^{profundo 6,11,44}.

Existen varias oportunidades para ampliar aún más el marco propuesto. La validación en bancadas de pruebas IoMT en vivo o en redes hospitalarias operativas proporcionaría evidencia adicional del rendimiento real más allá de los conjuntos de datos de referencia offline. La implementación de blockchain podría ampliarse del prototipo actual de un solo nodo a un despliegue multivalidador distribuido para permitir una evaluación integral de la escalabilidad. Las técnicas de compresión, poda o cuantización de modelos pueden facilitar el despliegue en dispositivos de borde con recursos limitados. Investigaciones adicionales también podrían incorporar aprendizaje online para abordar la deriva de conceptos y ataques de día^{cero 45}, aprendizaje federado para permitir la formación colaborativa de modelos entre instituciones sanitarias sin compartir datos sensibles^{de pacientes 40}, y métodos explicables de IA para proporcionar alertas de intrusións más transparentes para clínicos y personal de ciberseguridad.

En conjunto, el marco propuesto de BiLSTM–Blockchain Extendido demuestra una fuerte adaptabilidad, responsabilidad forense y un robusto rendimiento en detección de intrusiones. Al integrar aprendizaje temporal potenciado por atención con registro inmutable de blockchain y mitigación automatizada, el marco combina alta precisión en la detección con trazabilidad forense segura y bajas tasas de falsos positivos. Estos hallazgos demuestran el potencial del enfoque propuesto como un método práctico para asegurar entornos IoMT en tiempo real, al tiempo que apoyan auditorías fiables y una respuesta oportuna de seguridad en los sistemas sanitarios.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
AQU-IMF-RFE Feature Selection Module	Autodesarrollado	N/A	Método híbrido de selección de características que integra Información Mutua, Aquila Optimizer y Eliminación Recursiva de Características
Attention Layer	Autodesarrollado (basado en Keras)	N/A	Mecanismo de atención temporal utilizado para ponderación de características en el modelo Extended BiLSTM
Bot-IoT Dataset	UNSW Canberra Cyber	N/A	Conjunto de datos de referencia pública utilizado para evaluación de detección de intrusiones
CICIDS2017 Dataset	Instituto Canadiense para la Ciberseguridad	N/A	Conjunto de datos de detección de intrusiones de referencia pública
Ethereum Client (Geth)	Fundación Ethereum	1.13.15	Cliente de blockchain utilizado para desplegar y operar la red Proof-of-Authority
Extended BiLSTM Model	Autodesarrollado	N/A	Modelo de detección de intrusiones de aprendizaje profundo que integra Conv1D, BiLSTM, aprendizaje residual y atención temporal
Jupyter Notebook	Project Jupyter	7.x	Entorno interactivo utilizado para la implementación, experimentación y visualización de resultados
NumPy	Desarrolladores de NumPy	2.4.4	Biblioteca de computación numérica utilizada para preprocesamiento y entrenamiento de modelos
Pandas	Equipo de Desarrollo de Pandas	3.0.2	Biblioteca de procesamiento de datos utilizada para preprocesamiento y análisis de datos
Proof-of-Authority Blockchain Network	Autodesarrollado	N/A	Red blockchain autorizada utilizada para registro inmutable de intrusiones y mitigación automatizada
Python	Fundación de Software Python	3.12.7	Lenguaje de programación utilizado para preprocesamiento de datos, desarrollo de modelos, integración de blockchain y evaluación
Random Forest Estimator	Desarrolladores de Scikit-learn	N/A	Clasificador Random Forest utilizado para Eliminación Recursiva de Características (RFE)
Scikit-learn	Desarrolladores de Scikit-learn	1.8.0	Biblioteca de aprendizaje automático utilizada para preprocesamiento, selección de características y evaluación de modelos
Solidity Compiler (solc)	Equipo de Solidity	0.8.19	Compilador utilizado para la compilación y despliegue de contratos inteligentes
Solid-State Drive (SSD)	Dell	512 GB	Almacenamiento utilizado para conjuntos de datos, modelos entrenados y libro mayor blockchain
System Memory (RAM)	Dell	128 GB	Memoria principal utilizada durante el preprocesamiento, entrenamiento de modelos, ejecución de blockchain y evaluación
TensorFlow	Google	2.16.1	Framework de aprendizaje profundo utilizado para implementar y entrenar el modelo Extended BiLSTM
UNSW-NB15 Dataset	UNSW Canberra Cyber	N/A	Conjunto de datos de referencia pública utilizado para entrenamiento y evaluación
Web3.py	Desarrolladores de Web3.py	6.15.1	Interfaz de Python utilizada para la comunicación entre el sistema de detección de intrusiones y la red blockchain
Windows Operating System	Microsoft	Windows 11	Sistema operativo utilizado para todos los experimentos
Workstation / Server	Dell	PowerEdge R740	Plataforma de cómputo utilizada para el entrenamiento de modelos, despliegue de blockchain y evaluación