20. Nov 2021
Actualmente, la comunicación y el procesamiento de datos son difícilmente concebibles sin considerar los aspectos de seguridad. De hecho, los sistemas de comunicación inseguros se están volviendo inaceptables rápidamente. El camino ya ha sido mostrado por Internet, con el conocido protocolo 'http' de 1991 que ha sido reemplazado en gran parte por la variante cifrada 'https'. Por cierto, un año antes que http, el sistema KNX se lanzó en 1990 con el nombre EIB.
Incluso en los edificios, ya no se puede pasar por alto la necesidad de tener una comunicación segura. En la actualidad, a pesar de los informes de falsificación, puede haber poca evidencia concreta de daños reales por parte de los piratas informáticos, pero es probable que sus esfuerzos aumenten, por lo que es necesario contrarrestar los peligros potenciales para la infraestructura técnica.
Asegurando KNX
Como una asociación de fabricantes, la Asociación KNX abrazó el tema de la seguridad en una etapa temprana bajo el título ‘KNX Secure'. La especificación e implementación tomó varios años; una de las principales razones es la complejidad del protocolo KNX, por lo que el direccionamiento de grupo, que es esencial para todo el sistema KNX, es un gran desafío para el cifrado seguro.
A principios de 2019, tanto el sistema como las especificaciones de prueba se consideraron estables y fueron aprobados por KNX Association Technical Board. Además, la Asociación KNX invirtió grandes esfuerzos al implementar el tema de seguridad en el ETS, el software de instalación central para KNX. Las herramientas de prueba para el desarrollo de dispositivos KNX Secure también se ampliaron como corresponde, y los productos KNX Secure certificados ya están disponibles.
De esta forma, ahora que KNX Secure es una realidad, veamos con más detalle sus dos variantes, a saber, KNX Data Secure y KNX IP Secure.
KNX Data Secure
KNX Data Secure tiene como objetivo asegurar la comunicación a nivel de telegrama. Se puede utilizar independientemente del medio KNX tanto para la puesta en marcha como para la comunicación en tiempo de ejecución.
La Asociación KNX se fijó el siguiente objetivo: ‘seguridad desde el principio'. Esto significa que incluso la primera descarga a dispositivos por parte del ETS está encriptada desde el principio. Para este propósito, cada dispositivo se entrega con una FDSK (Factory Default Setup Key en inglés, o clave de configuración predeterminada de fábrica) individual para el firmware, que ETS debe conocer antes de programar. La principal información se asigna junto con el número de serie del dispositivo en un código QR y se imprime en el dispositivo. El código puede ser escaneado y evaluado por el ETS utilizando una cámara de PC o portátil o mediante una aplicación móvil. También es posible la entrada a través de un teclado.
Dado que la llave del dispositivo puede ser conocida por otros, el ETS la reemplaza con la 'llave de herramienta', es decir, una llave para la programación. Esta clave también se genera individualmente para cada dispositivo.
Se necesitan más claves para los telegramas de grupo. Para una máxima seguridad, se utiliza una clave separada para cada dirección de grupo. El cifrado evita que los datos sean monitoreados. Al mismo tiempo, un código de autorización en el telegrama asegura que solo los dispositivos autorizados puedan participar en la comunicación.
Un ataque bien conocido a los sistemas es el llamado 'ataque de reproducción'. El atacante utiliza telegramas que escucha y vuelve a enviar más tarde sin poder interpretarlos él mismo. Para evitar este escenario, cada telegrama contiene un número de telegrama que el respectivo remitente asigna consecutivamente. El receptor solo puede aceptar telegramas que tengan un número superior al telegrama que recibió por última vez de esta estación. Debido a la longitud de 6 bytes de este número, es prácticamente imposible que haya un desbordamiento es prácticamente imposible y se interpreta como un error.
Instalaciones de seguridad mixtas
Dado que no se espera que todos los dispositivos requeridos estén disponibles como una variante segura a corto plazo, es importante que la comunicación segura e insegura se pueda combinar en una instalación. La propiedad segura se define a nivel de grupo. Si dos objetos de grupo que soportan la seguridad están conectados, el ETS propone un enlace seguro. Sin embargo, si solo un objeto se encuentra en un grupo sin seguridad, todo el grupo debe comunicarse de manera insegura.
Los diferentes objetos de comunicación de un dispositivo pueden tener diferentes propiedades de seguridad. Por tanto, es posible, por ejemplo, que los telegramas de conmutación estén cifrados para un actuador de conmutación, pero los mensajes de respuesta se envíen sin cifrar para mostrarlos en la visualización. La seguridad también se podría utilizar caso por caso para un actuador de persianas con lamas. Esto significa que las persianas con lamas se pueden controlar sin protección, mientras que los dispositivos de apertura de ventanas solo aceptan telegramas encriptados.
Otro escenario es el cifrado solo en segmentos parciales de la instalación, como un segmento KNX RF, para el que el cifrado es un requisito importante. Al mismo tiempo, los telegramas también deberían poder enviarse a dispositivos KNX Twisted Pair (TP) convencionales. La solución para este requisito en KNX es el 'Secure Proxy'. Este es un módulo de software que se implementa en un acoplador. En el ejemplo anterior, se implementa en el acoplador KNX RF/TP. Secure Proxy traduce la comunicación segura desde el lado de la radio en telegramas no seguros en KNX TP y viceversa. Sin embargo, Secure Proxy también se puede implementar en acopladores de línea (TP/TP), por ejemplo, para conectar líneas externas seguras a una red KNX interna no segura.
KNX IP Secure
KNX IP Secure sigue un enfoque alternativo, pero se basa en los mismos métodos de cifrado que KNX Data Secure. KNX IP Secure es un enfoque pragmático basado en la suposición de que existe un punto de ataque a nivel de IP. Mientras que se supone que KNX Twisted Pair es relativamente seguro como un medio puramente local ubicado en la pared, la comunicación IP a menudo está conectada a Internet y, por lo tanto, puede ser atacada de forma remota.
KNX IP Secure protege la comunicación KNX IP mientras que la comunicación en KNX TP permanece desencriptada. La principal ventaja de este enfoque es que los dispositivos e instalaciones KNX TP existentes pueden seguir utilizándose sin cambios. Solo se deben reemplazar los dispositivos KNX IP, es decir, esencialmente las interfaces KNX IP y los enrutadores KNX IP.
KNX IP incluye el protocolo de enrutamiento que se utiliza para backbones IP, pero también representa el medio KNX IP. Por otro lado, el protocolo de tunnelling se utiliza para permitir que un cliente (por ejemplo, ETS) acceda a una línea TP a través de IP. Mientras que los enrutadores KNX IP generalmente implementan ambos protocolos, las interfaces KNX IP solo admiten la función de tunnelling.
El grado de diferencia de las dos aplicaciones de KNX IP indicará el grado de diferencia de las respectivas extensiones de seguridad. Con el protocolo Secure Routing, que se basa en UDP Multidifusión, se utiliza una clave común para cifrar todas las comunicaciones de enrutamiento IP KNX. Una característica especial es el contador de telegramas durante el enrutamiento. Esto se basa en el tiempo y, por lo tanto, representa una marca de tiempo que permite detectar telegramas obsoletos. La hora común del sistema se sincroniza continuamente entre los dispositivos.
Con el protocolo de tunnelling, el cliente y el dispositivo KNX IP (KNXnet/servidor IP) primero establecen un canal seguro utilizando el método llamado Diffie-Hellmann. Solo entonces se transfieren el ID de usuario y la contraseña. Una nueva característica de KNX Secure Tunneling es la posibilidad de establecer la conexión con TCP. Además de la opción de acceder a una línea de bus, el tunnelling también permite programar dispositivos KNX IP muy rápidamente.
KNX Secure desde el punto de vista del fabricante
KNX Secure es sin duda un desafío para los fabricantes. En la mayoría de los casos, la expansión de los dispositivos KNX existentes con KNX Secure no será posible sin cambiar el hardware, ya que aumentan los requisitos de memoria disponible y potencia informática. La asignación e impresión de claves también deben implementarse como código QR en producción.
También surgen nuevos requisitos para los fabricantes de software para KNX, por ejemplo, visualizaciones. Ya no es suficiente importar o ingresar las direcciones de grupo del proyecto. Incluso el conocimiento de las claves utilizadas no es suficiente para enviar telegramas de grupo cifrados. Más bien, cada participante debe darse a conocer a todos los dispositivos a los que debe acceder. En la actualidad, esto solo es posible, y es probable que siga siendo, a través del ETS. Hoy en día, para la mayoría de los dispositivos disponibles en el mercado que no se pueden poner en funcionamiento utilizando el ETS, es probable que el camino hacia un sistema de comunicación KNX seguro sea un desafío, aunque manejable.
Dr.-Ing. Thomas Weinzierl es el CEO de Weinzierl Engineering GmbH, fabricante de productos KNX y proveedor de una gama completa de servicios de prueba y desarrollo de hardware y software.