Control de peticiones multicast en el estándar IEC 61850

La comunicación multicast es ampliamente utilizada a nivel de procesos, ya que cumple con los requerimientos de funcionamiento y facilita la comunicación entre pares, donde el destino del mensaje no tiene que ser conocido por el remitente. Los mensajes multicast juegan un papel crucial en los sistemas de la red eléctrica. En la IEC 61850, utilizada para el diseño y configuración de la automática en una subestación, se definen dos protocolos multicast: Generic Object Oriented Substation Events (GOOSE) y Sampled Measured Value (SMV o SV). Estos protocolos sirven para recopilar información del estado de la red en tiempo real, actualizar el estado de los Intelligent Electric Devices (IED) y retrasmitir comandos de control.

La seguridad e integridad en estas comunicaciones se presenta como un reto en la red eléctrica, principalmente por las siguientes razones:

• El complejo diseño del sistema hace necesario integrar herramientas de configuración propietarias de diferentes fabricantes y, al mismo tiempo, implementar protocolos de seguridad estándar. Esta es una tarea compleja y propensa a errores en la disposición de claves y políticas de grupo. Una mala configuración podría desembocar en una violación de políticas de seguridad, como por ejemplo, la entrega de información sensible de datos a un dispositivo no legítimo.
• Varios requisitos impuestos por el Comité de Subestaciones del IEEE conllevan cambios en la latencia en los protocolos de seguridad. Existen mensajes que necesitan ser entregados en un corto espacio de tiempo, definido por las funcionalidades de una subestación, como los mensajes GOOSE, que tienen que entregarse en un plazo de entre 2 y 10 ms. El estándar IEC 62351-6 confía la autentificación de los mensajes GOOSE a través de firmas de clave pública, no garantizando los requisitos de tiempo debido a la latencia derivada de las firmas.
• Una gestión de claves factible e integrada es necesaria para la seguridad en el sistema multicast de la red eléctrica.
• Se necesita encontrar el equilibrio entre eficiencia, factibilidad y coste.

Dentro de una subestación eléctrica se pueden encontrar cientos de dispositivos IED, que se conectan vía Ethernet para transmitir datos y comandos de gestión entre ellos o al centro de control. La IEC 61850 proporciona una serie de pautas para implementar estas comunicaciones, las cuales, permiten un modelado de datos orientados a objetos para que, equipos como IED o RTU, transmitan información relacionada con funciones de supervisión y control.

- Funcionamiento de un sistema multicast -

Elementos de seguridad en un sistema multicast

Un sistema de seguridad multicast está formado por una serie de objetos de datos, un grupo de propietarios de datos, un conjunto de clientes de datos, publicadores, subscriptores y controladores. Los componentes que tienen relación con objetos de datos se denominan entidades, por lo que los propietarios y clientes de datos, entre otros, a su vez son entidades.

Hay cuatro tipos de entidades en el modelo multicast:

• Propietario de datos: entidad que posee o aloja una serie de objetos de datos. Cualquier dispositivo electrónico con acceso a un objeto de datos es un propietario.
• Cliente de datos: usuario que necesita un objeto de datos para su funcionamiento, como por ejemplo, un equipo eléctrico de maniobra.
• Publicador: publica los objetos de datos mediante multicast, como un relé protector que emite comandos a los interruptores. Un publicador no tiene por qué ser el propietario de los objetos de datos.
• Subscriptor: entidad que se subscribe a los objetos de datos de un publicador. Puede ser un interruptor que ejecuta los comandos que emite un relé. Una entidad puede ser un publicador y subscriptor al mismo tiempo, por ejemplo, un relé de protección que envía un comando TRIP se comporta como publicador, pero cuando se informa del estado de los interruptores se comporta como suscriptor.

En el modelo multicast existe la figura del controlador de grupo que proporciona membresía grupal y servicio de gestión de claves grupales. Las tareas que realiza son:

• Autorizar privilegios de acceso grupal basados en grupos de miembros derivadas de configuraciones del sistema.
• Generar, distribuir y actualizar claves de grupo compartidas.
• Revocar grupos de miembros basadas en cambios configuraciones.

Problemática con el modelo multicast de la IEC 61850

Existen una serie de problemas relacionados con los mensajes multicast que derivan en una serie de anomalías.

• Anomalía de propiedad: se produce cuando un publicador publica un grupo de datos que consiste en un conjunto de objetos de datos que no son de su propiedad. Esta anomalía sucede por ejemplo si un IED está configurado para coger atributos de datos que no son de su propiedad como parte de la carga útil del mensaje GOOSE.
• Publicación redundante: ocurre cuando un publicador publica un grupo de datos pero no hay entidad que la consuma o esté suscrita a ella. Existen dos tipos de publicación redundante:
  • Redundancia total: ningún objeto de datos es requerido por un consumidor.
  • Redundancia parcial: hay consumidores que utilizan algún objeto de datos.
• Anomalía de proveniencia: un suscriptor solicita suscribirse a un grupo de datos publicado por un publicador que ya no existe en el sistema. Esto podría ocurrir si se elimina o retira a un publicador del sistema.
• Insatisfacción de los datos: este tipo de anomalía aparece cuando un consumidor solicita una suscripción a un grupo de datos pero no hay publicación que provea todos los objetos de datos requeridos. Existen dos tipos de insatisfacción de datos:
  • Insatisfacción dura: uno o más objetos de datos en el grupo no están publicados por el publicador.
  • Insatisfacción blanda: uno o más objetos en el grupo no están publicados por el publicador en una publicación concreta, pero sí que se encuentran en otras publicaciones.

Diseño seguro del modelo multicast

Para detectar posibles fallos existen una serie de algoritmos que se basan en la comparación de una serie de claves. Estas claves son generadas por parte de todas las entidades implicadas en el sistema para detectar las anomalías y notificar el error cometido.

Una manera adecuada de conseguir un modelo multicast efectivo y seguro es mediante la implementación de un diseño denominado Security Extended Configuration, basado en:

• Requerimiento de credenciales para el intercambio de claves de grupo.
• Entidades de red adicionales, que facilitan la seguridad en las comunicaciones, como un servidor de clave de grupo.

Se establecen una serie de medidas en el diseño del modelo multicast, basadas en el protocolo Internet Protocol security (IPsec), para proteger los paquetes multicast:

• Política grupal, Group Policy Engine (GPE), que transforma el modelo multicast en una política de autorización de grupo y política de tráfico.
  • La política de autorización especifica qué entidad o IED puede unirse al grupo y compartir las claves del grupo. Es usado por los controladores de grupo para la gestión de pertenencia de grupo.
  • La política de tráfico se utiliza para hacer cumplir los servicios de seguridad en paquetes individuales, como la firma y verificación de firmas.
• Intercambio de claves de Internet, Group Internet Key Exchange (GIKE), es un protocolo que se utiliza para la autorización de pertenencia de grupo y gestión de claves de grupo.

Conclusión

Con el nuevo cambio a nivel global de la descentralización de la generación de la energía y la implantación de redes inteligentes o smart grid, se hace necesaria la optimización y seguridad en las subestaciones eléctricas. Muchas infraestructuras del sistema eléctrico se diseñaron hace décadas sin tener en cuenta vulnerabilidades y amenazas que actualmente presentan un problema para asegurar el suministro eléctrico.

Un diseño efectivo en el modelo multicast prevendría muchos de los problemas que el modelo IEC 61850 no tenía en cuenta cuando se redactó.