Un enlace ICCP o IEC 104 con TLS según IEC 62351-3 necesita autenticación mutua: el servidor y el cliente presentan cada uno un certificado firmado por una autoridad en la que ambos confían. El orden es siempre el mismo: la autoridad crea su llave y su certificado; cada extremo crea su llave privada y una solicitud de firma; la autoridad firma; y cada parte comprueba que llave, solicitud y certificado corresponden entre sí antes de instalarlos.
Qué se necesita en un enlace seguro
Un enlace ICCP (TASE.2) o IEC 104 protegido con TLS según IEC 62351-3 usa certificados X.509. La norma exige autenticación mutua: el cliente y el servidor presentan cada uno un certificado. Fija además los algoritmos, la longitud mínima de las claves y cómo se maneja la revocación. Para ICCP, la parte IEC 62351-4 define los perfiles de aplicación y de transporte. Cómo envía ICCP sus datos con transfer sets y reporte por excepción se detalla en ICCP: eventos por excepción y transfer sets.
Qué es un certificado y qué contiene está en certificado X.509 y solicitud CSR para IED. Esta guía cubre el otro lado: en qué orden se genera todo para un enlace de dos extremos.
Los tres juegos de archivos
Un enlace con autenticación mutua involucra tres identidades:
| Identidad | Qué genera | Qué conserva en secreto | Qué entrega |
|---|---|---|---|
| Autoridad certificadora (CA) | Su propia llave y su certificado | Su llave privada | Su certificado, a servidor y cliente |
| Servidor (la estación controlada, o el servidor ICCP que responde) | Llave privada y solicitud de firma | Su llave privada | La solicitud, a la CA |
| Cliente (el maestro, o el servidor ICCP que inicia) | Llave privada y solicitud de firma | Su llave privada | La solicitud, a la CA |
En un entorno de prueba, las tres identidades pueden estar en el mismo computador. En un entorno real, las llaves privadas del servidor y del cliente se generan en cada extremo, y la autoridad es la de la empresa o la que ambas partes acordaron.
El orden de los pasos
- La CA crea su llave privada (RSA de 2048 bits en el ejemplo habitual de laboratorio) y comprueba que está bien formada.
- La CA crea su certificado autofirmado. Es el certificado raíz. Se convierte a formato DER si algún equipo lo pide así.
- El servidor crea su llave privada, protegida con una contraseña. La contraseña queda bajo custodia de la entidad, en una bóveda de contraseñas y no en el mismo equipo.
- El servidor crea su solicitud de firma (CSR) a partir de su llave. La solicitud lleva el nombre del equipo y su llave pública, pero no su llave privada.
- La CA firma la solicitud y emite el certificado del servidor, con un plazo de validez (365 días en el ejemplo de laboratorio).
- Se comprueba que el certificado, la solicitud y la llave privada corresponden entre sí (ver abajo).
- Se repite lo mismo para el cliente: llave, solicitud, firma por la misma CA, comprobación.
- Se instalan: en el servidor, su llave, su certificado y el certificado de la CA; en el cliente, su llave, su certificado y el certificado de la CA.
El certificado de la CA es lo que cada extremo usa para validar al otro: si el certificado que presenta la contraparte no fue firmado por esa CA, la conexión se rechaza.
La comprobación que evita la mayoría de los fallos
Un certificado, su solicitud y su llave privada comparten el mismo módulo, el valor matemático que las une. Una forma de comprobarlo es calcular una huella del módulo de cada archivo y confirmar que las tres coinciden. Si una difiere, el certificado no pertenece a esa llave: el equipo lo rechazará o la conexión TLS no se establecerá.
Esta comprobación se hace antes de instalar en los equipos. Un error aquí se manifiesta después como un «fallo de handshake» difícil de interpretar.
Formatos que piden los equipos
| Formato | Contenido | Uso habitual |
|---|---|---|
| PEM | Texto, con encabezados de inicio y fin | Servidores, herramientas de línea de comandos, muchos gateways |
| DER (.cer) | Binario | Equipos y herramientas de ingeniería que lo piden así |
La conversión entre ambos no altera el contenido. Cada fabricante indica cuál acepta en el manual del equipo; hay que leerlo antes de generar nada.
Buenas prácticas para un enlace real
- Llaves protegidas con contraseña, y esa contraseña en un gestor autorizado. Nunca en el correo ni en el chat.
- Una CA propia o acordada, no una llave suelta autofirmada por cada equipo, cuando hay más de dos equipos en el enlace.
- Plazo de validez conocido y con aviso de vencimiento: un certificado vencido tumba el enlace de un día para otro.
- Hora sincronizada en ambos extremos: un reloj atrasado hace que un certificado válido parezca aún no vigente. Ver sincronización de tiempo en subestaciones.
- Revocación: definir cómo se retira un certificado comprometido, como pide IEC 62351-3. La gestión del ciclo de vida a escala está en PKI en subestaciones, IEC 62351-9.
- Verificar con una captura que el tráfico, que antes se leía en claro, ahora va cifrado.
Los fallos más comunes
- Certificados firmados por una CA que el otro extremo no tiene instalada.
- Llave y certificado de pares distintos.
- Un solo extremo con certificado, cuando el enlace exige autenticación mutua.
- Certificado vencido o con la fecha del equipo desajustada.
- Formato equivocado (PEM donde el equipo espera DER).
¿Necesita montar certificados para su enlace?
En Tiza Group preparamos los certificados y configuramos TLS en enlaces ICCP, IEC 104 y DNP3 con centros de control, y los probamos con captura de tráfico, dentro de nuestro servicio de ciberseguridad de subestaciones y plantas y de integración SCADA y gateways. Qué incluye cada bloque de conformidad de ICCP, del 1 al 5, está en ICCP: bloques de conformidad 1 al 5 y qué hace cada uno.
Guías relacionadas
- Certificado X.509 y solicitud CSR para IED
- PKI en subestaciones, IEC 62351-9
- IEC 62351-4: seguridad de MMS y TASE.2
- IEC 104 y DNP3 seguros: TLS e IEC 62351-3 y -5
- ICCP / TASE.2 (IEC 60870-6): enlace entre centros de control
- NERC CIP-012: comunicaciones entre centros de control
- ICCP: eventos por excepción y transfer sets
- ICCP: bloques de conformidad 1 al 5 y qué hace cada uno
- ICCP: canal de comunicación y asociación entre centros
Referencias
- IEC 62351-3, perfiles que incluyen TCP/IP: TLS con certificados X.509 y autenticación mutua.
- IEC 62351-4, perfiles que incluyen MMS y derivados (ICCP, IEC 61850-8-1).
- IETF RFC 5280, perfil de certificados X.509 y de listas de revocación.
Preguntas frecuentes
¿Por qué un enlace ICCP o IEC 104 con TLS necesita dos certificados?
Porque IEC 62351-3 pide autenticación mutua. El cliente y el servidor deben presentar cada uno un certificado. Así el servidor sabe que el maestro es quien dice ser, y el maestro sabe que habla con el equipo correcto.
¿Qué se entrega a la otra parte: la llave o el certificado?
Solo el certificado, y el de la autoridad que lo firmó. La llave privada nunca sale del equipo ni de quien la generó. Si el servidor y el cliente son de entidades distintas, cada una instala el certificado de la autoridad de la otra, o uno común.
¿Qué es el archivo con extensión .cer o .crt y en qué formato está?
Es el certificado. Se guarda en formato PEM, que es texto, o en DER, que es binario. Algunos equipos aceptan solo uno de los dos; por eso se convierte de uno a otro sin modificar su contenido.