ÍNDICE
1.Introducción9
1.1.Descripción y ámbito de aplicación de la presente política9
1.2.Definiciones y siglas11
1.3.Participantes de la PKI13
1.3.1.Introducción13
1.3.2.Autoridad de la política de certificación de los STI-C16
1.3.3.Gestor de la lista de confianza17
1.3.4.Auditor de la PKI autorizado17
1.3.5.Punto de contacto STI-C (CPOC)17
1.3.6.Roles operativos18
1.4.Utilización de los certificados18
1.4.1.Ámbitos de utilización aplicables18
1.4.2.Límites de responsabilidad19
1.5.Administración de la política de certificación19
1.5.1.Actualización de las CPS de las CA que figuran en la ECTL19
1.5.2.Procedimientos de aprobación de la CPS20
2.Responsabilidades de publicación y repositorio20
2.1.Métodos para la publicación de información sobre certificados20
2.2.Temporalidad o frecuencia de la publicación21
2.3.Repositorios21
2.4.Controles de acceso a los repositorios21
2.5.Publicación de la información sobre certificados22
2.5.1.Publicación de la información sobre certificados por el TLM22
2.5.2.Publicación de la información sobre certificados por las CA22
3.Identificación y autenticación23
3.1.Nomenclatura23
3.1.1.Tipos de nombre23
3.1.1.1.Nombres de TLM, CA raíz, EA y AA23
3.1.1.2.Nombres de las entidades finales23
3.1.1.3.Identificación de los certificados23
3.1.2.Necesidad de que los nombres sean significativos23
3.1.3.Anonimato y pseudonimia de las entidades finales23
3.1.4.Normas para interpretar varios formatos de nombres23
3.1.5.Unicidad de los nombres24
3.2.Validación inicial de la identidad24
3.2.1.Método para demostrar la posesión de la clave privada24
3.2.2.Autenticación de la identidad de una organización24
3.2.2.1.Autenticación de la identidad de la organización de CA raíz24
3.2.2.2.Autenticación de la identidad de la organización del TLM25
3.2.2.3.Autenticación de la identidad de la organización de CA subordinada25
3.2.2.4.Autenticación de la organización suscriptora de entidades finales26
3.2.3.Autenticación de una entidad individual26
3.2.3.1.Autenticación de una entidad individual de TLM/CA26
3.2.3.2.Autenticación de la identidad del suscriptor de las estaciones STI-C27
3.2.3.3.Autenticación de la identidad de las estaciones STI-C27
3.2.4.Información no verificada sobre el suscriptor27
3.2.5.Validación de la autoridad27
3.2.5.1.Validación del TLM y de las CA raíz , EA y AA27
3.2.5.2.Validación de los suscriptores de estaciones STI-C28
3.2.5.3.Validación de las estaciones STI-C28
3.2.6.Criterios de interoperabilidad28
3.3.Identificación y autenticación de las solicitudes de renovación de claves28
3.3.1.Identificación y autenticación de las solicitudes de renovación de claves de rutina28
3.3.1.1.Certificados de TLM28
3.3.1.2.Certificados de CA raíz28
3.3.1.3.Renovación de certificados o de las claves de certificados de EA/AA28
3.3.1.4.Credenciales de inscripción de las entidades finales29
3.3.1.5.Tiques de autorización de las entidades finales29
3.3.2.Identificación y autenticación de las solicitudes de renovación de claves tras una revocación29
3.3.2.1.Certificados de CA29
3.3.2.2.Credenciales de inscripción de las entidades finales29
3.3.2.3.Solicitudes de autorización de las entidades finales29
3.4.Identificación y autenticación de las solicitudes de revocación29
3.4.1.Certificados de CA raíz/EA/AA29
3.4.2.Credenciales de inscripción de estaciones STI-C30
3.4.3.Tiques de autorización de estaciones STI-C30
4.Requisitos operativos para el ciclo de vida de los certificados30
4.1.Solicitud de certificado30
4.1.1.Quién puede presentar una solicitud de certificado30
4.1.1.1.CA raíz30
4.1.1.2.TLM31
4.1.1.3.EA y AA31
4.1.1.4.Estación STI-C31
4.1.2.Proceso y responsabilidades de inscripción31
4.1.2.1.CA raíz31
4.1.2.2.TLM32
4.1.2.3.EA y AA32
4.1.2.4.Estación STI-C32
4.2.Tramitación de las solicitudes de certificado33
4.2.1.Realización de las funciones de identificación y autenticación33
4.2.1.1.Identificación y autenticación de las CA raíz33
4.2.1.2.Identificación y autenticación del TLM33
4.2.1.3.Identificación y autenticación de la EA y la AA33
4.2.1.4.Identificación y autenticación del suscriptor de EE34
4.2.1.5.Tiques de autorización34
4.2.2.Aprobación o denegación de las solicitudes de certificado34
4.2.2.1.Aprobación o denegación de certificados de CA raíz34
4.2.2.2.Aprobación o denegación del certificado de TLM34
4.2.2.3.Aprobación o denegación de certificados de EA y AA34
4.2.2.4.Aprobación o denegación de EC34
4.2.2.5.Aprobación o denegación de AT35
4.2.3.Plazo para procesar la solicitud de certificado35
4.2.3.1.Solicitud de certificado de CA raíz35
4.2.3.2.Solicitud de certificado de TLM35
4.2.3.3.Solicitud de certificado de EA y AA35
4.2.3.4.Solicitud de EC35
4.2.3.5.Solicitud de AT35
4.3.Emisión de certificados35
4.3.1.Acciones de la CA durante la emisión de certificados35
4.3.1.1.Emisión de certificados de CA raíz35
4.3.1.2.Emisión de certificados de TLM36
4.3.1.3.Emisión de certificados de EA y AA36
4.3.1.4.Emisión de EC36
4.3.1.5.Emisión de AT36
4.3.2.Notificación de la CA al suscriptor sobre la emisión de certificados36
4.4.Aceptación de certificados37
4.4.1.Forma en la que se acepta el certificado37
4.4.1.1.CA raíz37
4.4.1.2.TLM37
4.4.1.3.EA y AA37
4.4.1.4.Estación STI-C37
4.4.2.Publicación del certificado37
4.4.3.Notificación de la emisión del certificado37
4.5.Uso del par de claves y del certificado37
4.5.1.Uso de las claves privadas y de los certificados37
4.5.1.1.Uso de las claves privadas y de los certificados por el TLM37
4.5.1.2.Uso de las claves privadas y de los certificados por las CA raíz37
4.5.1.3.Uso de las claves privadas y de los certificados por las EA y AA37
4.5.1.4.Uso de las claves privadas y de los certificados por la entidad final38
4.5.2.Uso de las claves privadas y de los certificados por la parte confiante38
4.6.Renovación de certificados38
4.7.Renovación de claves de los certificados38
4.7.1.Circunstancias para la renovación de las claves de un certificado38
4.7.2.Quién puede solicitar una renovación de claves38
4.7.2.1.CA raíz38
4.7.2.2.TLM38
4.7.2.3.EA y AA38
4.7.2.4.Estación STI-C39
4.7.3.Proceso de renovación de claves39
4.7.3.1.Certificado de TLM39
4.7.3.2.Certificado de CA raíz39
4.7.3.3.Certificados de EA y AA39
4.7.3.4.Certificados de estación STI-C40
4.8.Modificación de certificados40
4.9.Revocación y suspensión de certificados40
4.10.Servicios de situación de certificados40
4.10.1.Características operativas40
4.10.2.Disponibilidad del servicio40
4.10.3.Características opcionales40
4.11.Fin de la suscripción40
4.12.Custodia y recuperación de claves40
4.12.1.Suscriptor40
4.12.1.1.Qué par de claves puede custodiarse40
4.12.1.2.Quién puede presentar una solicitud de recuperación40
4.12.1.3.Proceso y responsabilidades de recuperación40
4.12.1.4.Identificación y autenticación40
4.12.1.5.Aprobación o denegación de las solicitudes de recuperación40
4.12.1.6.Acciones KEA y KRA durante la recuperación del par de claves41
4.12.1.7.Disponibilidad de KEA y KRA41
4.12.2.Política y prácticas de encapsulación y recuperación de claves de sesión41
5.Controles operativos, de instalaciones y de gestión41
5.1.Controles físicos41
5.1.1.Ubicación física y construcción41
5.1.1.1.CA raíz, CPOC y TLM41
5.1.1.2.EA/AA42
5.1.2.Acceso físico42
5.1.2.1.CA raíz, CPOC y TLM42
5.1.2.2.EA/AA43
5.1.3.Alimentación eléctrica y aire acondicionado43
5.1.4.Exposición al agua43
5.1.5.Prevención y protección contra incendios44
5.1.6.Gestión de soportes44
5.1.7.Eliminación de residuos44
5.1.8.Copias de seguridad fuera de las instalaciones44
5.1.8.1.CA raíz, CPOC y TLM44
5.1.8.2.EA/AA45
5.2.Controles de procedimiento45
5.2.1.Roles de confianza45
5.2.2.Número de personas necesarias por tarea45
5.2.3.Identificación y autenticación para cada rol46
5.2.4.Roles que requieren separación de funciones46
5.3.Controles de personal47
5.3.1.Requisitos relativos a las cualificaciones, la experiencia y la autorización47
5.3.2.Procedimientos de comprobación de antecedentes47
5.3.3.Requerimientos de formación48
5.3.4.Requerimientos y frecuencia de actualización de la formación48
5.3.5.Frecuencia y secuencia de rotación de tareas48
5.3.6.Sanciones por actuaciones no autorizadas48
5.3.7.Requisitos para los contratistas independientes49
5.3.8.Documentación proporcionada al personal49
5.4.Procedimientos de registro de auditoría49
5.4.1.Tipos de eventos que cada CA debe registrar y notificar49
5.4.2.Frecuencia de tratamiento de los registros50
5.4.3.Período de conservación de los registros de auditoría50
5.4.4.Protección de los registros de auditoría51
5.4.5.Procedimientos de respaldo de los registros de auditoría51
5.4.6.Sistema de recogida de información de auditoría (interno o externo)51
5.4.7.Notificación al sujeto causa del evento51
5.4.8.Análisis de vulnerabilidades51
5.5.Archivo de registros52
5.5.1.Tipos de registros archivados52
5.5.2.Período de conservación del archivo53
5.5.3.Protección del archivo53
5.5.4.Archivo y almacenamiento del sistema53
5.5.5.Requisitos relativos al sellado de tiempo de los registros54
5.5.6.Sistema de compilación de archivos (interno o externo)54
5.5.7.Procedimientos para obtener y verificar la información de los archivos54
5.6.Cambio de claves de los elementos del modelo de confianza STI-C54
5.6.1.TLM54
5.6.2.CA raíz54
5.6.3.Certificado de EA/AA54
5.6.4.Auditor55
5.7.Recuperación en caso de comprometimiento y catástrofe55
5.7.1.Tratamiento de incidentes y comprometimientos55
5.7.2.Corrupción de recursos informáticos, software o datos56
5.7.3.Procedimientos en caso de comprometimiento de claves privadas de entidades56
5.7.4.Capacidad de continuidad de las actividades después de una catástrofe56
5.8.Cese y transferencia57
5.8.1.TLM57
5.8.2.CA raíz57
5.8.3.EA/AA58
6.Controles técnicos de seguridad58
6.1.Generación e instalación de pares de claves58
6.1.1.TLM, CA raíz, EA y AA58
6.1.2.EE: estación STI-C móvil58
6.1.3.EE: estación STI-C fija59
6.1.4.Requisitos criptográficos59
6.1.4.1.Longitud de los algoritmos y de las claves: algoritmos de firma59
6.1.4.2.Longitud de los algoritmos y de las claves: algoritmos de cifrado para la inscripción y la autorización60
6.1.4.3.Criptoagilidad61
6.1.5.Almacenamiento seguro de claves privadas61
6.1.5.1.Nivel de CA raíz, CA subordinada y TLM61
6.1.5.2.Entidad final62
6.1.6.Copia de seguridad de claves privadas63
6.1.7.Destrucción de claves privadas63
6.2.Datos de activación63
6.3.Controles de seguridad informática63
6.4.Controles técnicos del ciclo de vida63
6.5.Controles de seguridad de las redes63
7.Perfiles de los certificados, CRL y CTL63
7.1.Perfil de certificado63
7.2.Validez del certificado64
7.2.1.Certificados de pseudónimos65
7.2.2.Tiques de autorización para estaciones STI-C fijas65
7.3.Revocación de certificados65
7.3.1.Revocación de certificados de CA, EA y AA65
7.3.2.Revocación de las credenciales de inscripción66
7.3.3.Revocación de los tiques de autorización66
7.4.Lista de revocación de certificados66
7.5.Lista de confianza de certificación europea66
8.Auditoría de conformidad y otras evaluaciones66
8.1.Temas cubiertos por la auditoría y base de auditoría66
8.2.Frecuencia de las auditorías67
8.3.Identidad y cualificaciones del auditor67
8.4.Relación del auditor con la entidad auditada67
8.5.Medidas adoptadas como resultado de una deficiencia68
8.6.Comunicación de los resultados68
9.Otras disposiciones68
9.1.Tasas68
9.2.Responsabilidad financiera69
9.3.Confidencialidad de la información empresarial69
9.4.Plan de privacidad69
10.Referencias69
ANEXO III
1.Introducción
1.1.Descripción y ámbito de aplicación de la presente política
La presente política de certificación define el modelo europeo de confianza de los STI-C basado en la infraestructura de clave pública (PKI) dentro del ámbito del sistema de la UE para la gestión de credenciales de seguridad de los STI-C (EU CCMS). Asimismo, define los requisitos relativos a la gestión de los certificados de clave pública para las solicitudes de STI-C por parte de las entidades emisoras, así como el uso de dichos certificados por parte de las entidades finales en Europa. En su nivel más alto, la PKI está compuesta por un conjunto de autoridades de certificación (CA) raíz «habilitadas» a raíz de que el gestor de la lista de confianza (TLM) haya incorporado sus certificados en la lista de confianza de certificación europea (ECTL), emitida y publicada por la entidad TLM central (véanse los epígrafes 1.2 y 1.3).
La presente política es vinculante para todas las entidades que participen en el sistema de confianza STI-C en Europa, y contribuye a la evaluación del nivel de confianza que puede establecerse en la información recibida por cualquier receptor de un mensaje autenticado por un certificado de entidad final de la PKI. Para permitir la evaluación de la confianza en los certificados facilitados por el EU CCMS, la presente política establece un conjunto vinculante de requisitos para el funcionamiento de la entidad TLM central y la elaboración y gestión de la ECTL. Por consiguiente, el presente documento regula los aspectos relacionados con la ECTL que se exponen a continuación:
identificación y autenticación de los principales que obtengan roles en la PKI para el TLM, incluidas las declaraciones de los privilegios asignados a cada rol;
requisitos mínimos de las prácticas locales de seguridad para el TLM, incluidos los controles físicos, de personal y de procedimiento;
requisitos mínimos de las prácticas técnicas de seguridad para el TLM, en particular la seguridad informática, la seguridad de la red y los controles de ingeniería de los módulos criptográficos;
requisitos mínimos para las prácticas operativas del TLM, en particular el registro de nuevos certificados de CA raíz, las bajas temporales o permanentes de las CA raíz inscritas, y la publicación y distribución de actualizaciones de la ECTL;
perfil de la ECTL, en particular los campos de datos obligatorios y opcionales de la ECTL, los algoritmos criptográficos que deben utilizarse, el formato exacto de la ECTL y recomendaciones para el procesamiento de la ECTL;
gestión del ciclo de vida de los certificados ECTL, en particular la distribución, activación, expiración y revocación de los certificados ECTL;
gestión de la revocación de la confianza de las CA raíz, cuando proceda.
Dado que la fiabilidad de la ECTL no depende únicamente de la ECLT en sí, sino también en gran medida de las CA raíz que componen la PKI y sus CA subordinadas, esta política también establece requisitos mínimos obligatorios para todas las CA participantes (CA raíz y CA subordinadas). Los ámbitos de los requisitos son los siguientes:
identificación y autenticación de los principales que obtengan roles PKI (por ejemplo, responsable de la seguridad, responsable de la privacidad, administrador de la seguridad, administrador del directorio y usuario final), lo que incluye una exposición de las funciones, responsabilidades y privilegios asignados a cada rol;
gestión de claves, en particular algoritmos aceptables y obligatorios de firma de certificados y firma de datos, y períodos de validez de los certificados;
requisitos mínimos para prácticas de seguridad local, lo que incluye controles físicos, de personal y de procedimiento;
requisitos mínimos para prácticas de seguridad técnica como la seguridad informática, la seguridad de la red y los controles de ingeniería de los módulos criptográficos;
requisitos mínimos para las prácticas operativas de las CA, EA (autoridades de inscripción), AA (autoridades de autorización) y entidades finales, en particular los aspectos relacionados con el registro, las bajas (es decir, la eliminación de la lista), la revocación, el comprometimiento de claves, la destitución por causa justificada, la actualización de certificados, las prácticas de auditoría y la no divulgación de información relativa a la privacidad;
perfil de certificados y de lista de revocación de certificados (CRL), incluidos los formatos, los algoritmos aceptables, los campos de datos obligatorios y opcionales y sus rangos de valor válidos, y cómo se espera que los verificadores tramiten los certificados;
funciones de supervisión, presentación de informes, alerta y restablecimiento periódicos de las entidades del modelo de confianza STI-C a fin de establecer un funcionamiento seguro, incluso en caso de comportamiento indebido.
Además de estos requisitos mínimos, las entidades que gestionan las CA raíz y las CA subordinadas pueden decidir sus propios requisitos adicionales y establecerlos en las correspondientes declaraciones de prácticas de certificación (CPS), siempre y cuando no sean contrarias a los requisitos establecidos en la política de certificación. Véase el epígrafe 1.5 para obtener más información sobre el modo en que se auditan y publican las CPS.
La CP también indica los fines para los que pueden usarse las CA raíz, las CA subordinadas y los certificados emitidos por ellas. Establece las responsabilidades asumidas por:
el TLM;
cada una de las CA raíz cuyos certificados figuren en la ECTL;
las CA subordinadas (EA y AA) de las CA raíz;
cada miembro u organización que sea responsable de una de las entidades del modelo de confianza STI-C o la gestione.
La CP también define las obligaciones correspondientes a:
el TLM;
cada una de las CA raíz cuyos certificados figuren en la ECTL;
cada CA subordinada certificada por una CA raíz;
todas las entidades finales;
cada miembro u organización que sea responsable de una de las entidades del modelo de confianza STI-C o la gestione.
Para terminar, la CP establece los requisitos relativos a la documentación de limitaciones de las responsabilidades y obligaciones en la CPS de cada CA raíz cuyos certificados figuren en la ECTL.
La presente CP está en consonancia con el marco de la política y las prácticas de certificación adoptado por el Grupo Especial sobre Ingeniería de Internet (IETF) [3].
1.2.Definiciones y siglas
Serán aplicables las definiciones de los documentos de referencia [2], [3] y [4].
AA
|
autoridad de autorización
|
AT
|
tique de autorización
|
CA
|
autoridad de certificación
|
CP
|
política de certificación
|
CPA
|
autoridad de la política de certificación de los STI-C
|
CPOC
|
punto de contacto STI-C
|
CPS
|
declaración de prácticas de certificación
|
CRL
|
lista de revocación de certificados
|
EA
|
autoridad de inscripción
|
EC
|
credencial de inscripción
|
ECIES
|
esquema de cifrado integrado de curva elíptica
|
EE
|
entidad final (es decir, una estación STI-C)
|
ECTL
|
lista de confianza de certificación europea
|
EU CCMS
|
sistema de la UE para la gestión de credenciales de seguridad de los STI-C
|
RGPD
|
Reglamento General de Protección de Datos
|
HSM
|
módulo de seguridad hardware
|
PKI
|
infraestructura de clave pública
|
RA
|
autoridad de registro
|
CA subordinada
|
EA y AA
|
TLM
|
gestor de la lista de confianza
|
Glosario
solicitante
|
Persona física o jurídica que solicita un certificado (o su renovación). Una vez que se haya creado el certificado inicial (inicialización), el solicitante pasará a ser suscriptor.
En el caso de los certificados emitidos a entidades finales, el suscriptor (solicitante de certificado) es la entidad que controla o gestiona/mantiene la entidad final para la que se emite el certificado, aunque la que envíe la solicitud de certificado sea la entidad final.
|
autoridad de autorización
|
En el presente documento, «autoridad de autorización» (AA) se refiere no solo a la función específica de AA, sino también a la entidad jurídica u operativa que la gestiona.
|
autoridad de certificación
|
La autoridad de certificación (CA) se refiere al conjunto de la autoridad de certificación raíz, la autoridad de inscripción y la autoridad de autorización.
|
modelo de confianza STI-C
|
El modelo de confianza STI-C se encarga de establecer una relación de confianza entre las estaciones STI-C. Se implementa mediante el uso de una PKI compuesta por las CA raíz, el CPOC, el TLM, las EA, las AA y una red segura.
|
criptoagilidad
|
Capacidad de las entidades del modelo de confianza STI-C de adaptar la CP a los cambios en el entorno o a los nuevos requisitos futuros, por ejemplo, mediante cambios a lo largo del tiempo de los algoritmos criptográficos y de la longitud de la clave.
|
módulo criptográfico
|
Elemento basado en hardware seguro dentro del cual se generan o almacenan claves, se generan números aleatorios y se firman o cifran datos.
|
autoridad de inscripción
|
En el presente documento, «autoridad de inscripción» (EA) se refiere no solo a la función específica de EA, sino también a la entidad jurídica u operativa que la gestiona.
|
participantes de la PKI
|
Entidades del modelo de confianza STI-C, es decir, el TLM, las CA raíz, las EA, las AA y las estaciones STI-C.
|
renovación de claves
|
|
repositorio
|
El repositorio se usa para almacenar certificados e información sobre certificados facilitada por las entidades del modelo de confianza STI-C, tal y como se define en el epígrafe 2.3.
|
autoridad de certificación raíz
|
En el presente documento, «autoridad de certificación (CA) raíz» se refiere no solo a la función específica de CA, sino también a la entidad jurídica u operativa que la gestiona.
|
sujeto
|
La persona física, dispositivo, sistema, unidad o persona jurídica identificados en un certificado como el sujeto, es decir, el suscriptor o un dispositivo que este controla y maneja.
|
suscriptor
|
Persona física o jurídica a quien se emite un certificado y que está legalmente vinculada por un acuerdo de suscriptor o de condiciones de uso.
|
acuerdo de suscriptor
|
Acuerdo entre la CA y el solicitante/suscriptor que especifica los derechos y responsabilidades de las partes.
|
1.3.Participantes de la PKI
1.3.1.Introducción
Los participantes de la PKI tienen un rol en la PKI definido por la presente política. A menos que esté explícitamente prohibido, los participantes pueden asumir varios roles al mismo tiempo. Se les puede prohibir asumir roles específicos al mismo tiempo para evitar conflictos de interés o para garantizar la separación de funciones.
Los participantes también pueden delegar partes de su rol a otras entidades como parte de un contrato de servicios. Por ejemplo, cuando se proporciona información sobre la situación de revocación mediante la CRL, la CA también es la emisora de la CRL, pero puede delegar la responsabilidad de la emisión de CRL a una entidad diferente.
Los roles de la PKI son los siguientes:
roles de autoridad, es decir, cada rol es instanciado por una única entidad;
roles operativos, es decir, cada rol puede ser instanciado por una o más entidades.
Por ejemplo, el rol de CA raíz puede ser ejercido por una entidad comercial, un grupo de interés común, una organización internacional o una organización europea.
La figura 1 muestra la arquitectura del modelo de confianza STI-C basada en [2]. Aquí se describe brevemente la arquitectura, pero los elementos principales se describen con más detalle en los epígrafes 1.3.2 a 1.3.6.
La CPA nombra al TLM, que es por lo tanto una entidad de confianza para todos los participantes de la PKI. La CPA aprueba la operación de la CA raíz y confirma que el TLM puede confiar en las CA raíz. El TLM emite la ECTL que proporciona confianza en las CA raíz aprobadas a todos los participantes de la PKI. La CA raíz emite certificados a la EA y a la AA, proporcionando así confianza en su operación. La EA emite certificados de inscripción a las estaciones STI-C emisoras y retransmisoras (como entidades finales), proporcionando así confianza en su operación. La AA emite AT a las estaciones STI-C sobre la base de la confianza en la EA.
La estación STI-C receptora y retransmisora (como parte retransmisora) puede confiar en otras estaciones STI-C, ya que los AT son emitidos por una AA en la que confía una CA raíz, en la que confían a su vez el TLM y la CPA.
Nótese que la figura 1 solo describe el nivel de CA raíz del modelo de confianza STI-C. La información sobre las capas inferiores se facilita en los epígrafes siguientes de la presente CP o en la CPS de las CA raíz específicas.
La figura 2 proporciona una visión general de los flujos de información entre los participantes de la PKI. Los puntos verdes indican los flujos que requieren comunicaciones de máquina a máquina. Los flujos de información en rojo tienen requisitos definidos en materia de seguridad.
El modelo de confianza STI-C se basa en una arquitectura de CA raíz múltiple, en la que los certificados de la CA raíz se transmiten periódicamente (como se indica más abajo) al punto de contacto central (CPOC) mediante un protocolo de seguridad (por ejemplo, certificados de enlace) definidos por el CPOC.
Las CA raíz pueden ser gestionadas por una organización estatal o privada. La arquitectura del modelo de confianza STI-C contiene al menos una CA raíz (la CA raíz de la Unión con el mismo nivel que las demás CA raíz). Las entidades participantes en el modelo de confianza STI-C que no desean establecer su propia CA raíz delegan en la CA raíz de la Unión. El CPOC transmite los certificados de la CA raíz recibidos al TLM, que es el encargado de recopilar y firmar la lista de certificados de CA raíz y enviarlos de nuevo al CPOC, que los pone a disposición del público (véase más abajo).
Las relaciones de confianza entre las entidades del modelo de confianza STI-C se describen en las figuras, cuadros y secciones siguientes.
Figura 1: Arquitectura del modelo de confianza STI-C
Figura 2: Flujos de información del modelo de confianza STI-C
Identificador del flujo
|
Desde
|
A
|
Contenido
|
Referencia
|
1)
|
CPA
|
TLM
|
aprobación de la solicitud de la CA raíz
|
8
|
2)
|
CPA
|
TLM
|
información sobre la revocación de la CA raíz
|
8.5
|
3)
|
CPA
|
CA raíz
|
actualizaciones de la CP
|
1.5
|
4)
|
CPA
|
CA raíz
|
aprobación/denegación del formulario de solicitud de la CA raíz o de la solicitud de modificación de la CPS o del proceso de auditoría
|
8.5, 8.6
|
5)
|
TLM
|
CPA
|
notificación de modificación de la ECTL
|
4, 5.8.1
|
6)
|
TLM
|
CPOC
|
certificado de TLM
|
4.4.2
|
7)
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
8)
|
CPOC
|
TLM
|
información del certificado de CA raíz
|
4.3.1.1
|
9)
|
CPOC
|
TLM
|
revocación del certificado de CA raíz
|
7.3
|
10)
|
CPOC
|
todas las entidades finales
|
certificado de TLM
|
4.4.2
|
11)
|
CA raíz
|
CPOC
|
información del certificado de CA raíz
|
4.3.1.1
|
12)
|
CA raíz
|
CPOC
|
revocación del certificado de CA raíz
|
7.3
|
13)
|
CA raíz
|
auditor
|
encargo de auditoría
|
8
|
14)
|
CA raíz
|
CPA
|
formulario de solicitud de la CA raíz — solicitud inicial
|
4.1.2.1
|
15)
|
CA raíz
|
CPA
|
formulario de solicitud de la CA raíz — modificaciones de la CPS
|
1.5.1
|
16)
|
CA raíz
|
CPA
|
formulario de solicitud de la CA raíz — informe de auditoría
|
8.6
|
17)
|
CA raíz
|
CPA
|
informes de incidentes de la CA raíz, incluida la revocación de una CA subordinada (EA, AA)
|
Anexo III, 7.3.1
|
18)
|
CA raíz
|
EA
|
respuesta de certificado de EA
|
4.2.2.3
|
19)
|
CA raíz
|
AA
|
respuesta de certificado de AA
|
4.2.2.3
|
20)
|
CA raíz
|
Todos
|
certificado EA/AA, CRL
|
4.4.2
|
21)
|
EA
|
CA raíz
|
solicitud de certificado de EA
|
4.2.2.3
|
22)
|
EA
|
estación STI-C
|
respuesta de credencial de inscripción
|
4.3.1.4
|
23)
|
EA
|
AA
|
respuesta de autorización
|
4.2.2.5
|
24)
|
AA
|
CA raíz
|
solicitud de certificado de AA
|
4.2.2.3
|
25)
|
AA
|
EA
|
solicitud de autorización
|
4.2.2.5
|
26)
|
AA
|
estación STI-C
|
respuesta de tique de autorización
|
4.3.1.5
|
27)
|
EA
|
CA raíz
|
presentación de solicitud
|
4.1.2.3
|
28)
|
AA
|
CA raíz
|
presentación de solicitud
|
4.1.2.3
|
29)
|
CA raíz
|
EA
|
respuesta
|
4.12 y 4.2.1
|
30)
|
CA raíz
|
AA
|
respuesta
|
4.12 y 4.2.1
|
31)
|
estación STI-C
|
EA
|
solicitud de credencial de inscripción
|
4.2.2.4
|
32)
|
estación STI-C
|
AA
|
solicitud de tique de autorización
|
4.2.2.5
|
33)
|
fabricante / operador
|
EA
|
registro
|
4.2.1.4
|
34)
|
fabricante / operador
|
EA
|
desactivación
|
7.3
|
35)
|
EA
|
fabricante / operador
|
respuesta
|
4.2.1.4
|
36)
|
auditor
|
CA raíz
|
informe
|
8.1
|
37)
|
todos
|
CPA
|
solicitudes de modificación de la CP
|
1.5
|
38)
|
TLM
|
CPA
|
formulario de solicitud
|
4.1.2.2
|
39)
|
CPA
|
TLM
|
aprobación/denegación
|
4.1.2.2
|
40)
|
TLM
|
CPA
|
informe de auditoría
|
4.1.2.2
|
Cuadro 1:
Descripción detallada de los flujos de información en el modelo de confianza STI-C
1.3.2.Autoridad de la política de certificación de los STI-C
1)La autoridad de la política de certificación de los STI-C (CPA) está compuesta por representantes de partes interesadas públicas y privadas (por ejemplo, Estados miembros, fabricantes de vehículos, etc.) que participan en el modelo de confianza STI-C. Es responsable de dos subroles:
1)gestión de la política de certificación, lo que incluye:
aprobar la CP vigente y las futuras solicitudes de modificación de la CP;
decidir sobre el análisis de las solicitudes y recomendaciones de modificación de la CP presentadas por otros participantes o entidades de la PKI;
decidir sobre la publicación de nuevas versiones de la CP;
2)gestión de las autorizaciones PKI, en particular:
definir, decidir y publicar los procedimientos de aprobación de la CPS y de auditoría de la CA (denominados conjuntamente «procedimientos de aprobación de la CA»);
autorizar al CPOC a que opere y presente informes periódicamente;
autorizar al TLM a que opere y presente informes periódicamente;
aprobar la CPS de la CA raíz, si está en consonancia con la CP válida común;
examinar los informes de auditoría del auditor de la PKI acreditado para todas las CA raíz;
notificar al TLM la lista de las CA raíz aprobadas o no aprobadas y sus certificados sobre la base de los informes de aprobación de las CA raíz y los informes de operaciones regulares recibidos.
2)El representante autorizado de la CPA será el responsable de autenticar al representante autorizado del TLM y aprobar el formulario de solicitud del proceso de inscripción del TLM. La CPA es responsable de autorizar al TLM a que opere, como se menciona en la presente sección.
1.3.3.Gestor de la lista de confianza
3)El TLM es una entidad única designada por la CPA.
4)El TLM se encarga de:
gestionar la ECTL de conformidad con la CP válida común, y presentar periódicamente informes de actividad a la CPA para el funcionamiento global seguro del modelo de confianza STI-C;
recibir certificados de CA raíz procedentes del CPOC;
incluir certificados de CA raíz en la ECTL y excluirlos de ella tras la notificación de la CPA;
firmar la ECTL;
transmitir periódica y oportunamente la ECTL al CPOC.
1.3.4.Auditor de la PKI autorizado
5)El auditor de la PKI autorizado se encarga de:
efectuar u organizar auditorías de CA raíz, TLM y CA subordinadas;
distribuir el informe de auditoría (de una auditoría inicial o periódica) a la CPA, según los requisitos del epígrafe 8; el informe de auditoría debe incluir las recomendaciones del auditor de la PKI acreditado;
notificar a la entidad que gestiona la CA raíz la ejecución satisfactoria o fallida de una auditoría inicial o periódica de las CA subordinadas;
evaluar el cumplimiento de la presente CP por parte de las CPS.
1.3.5.Punto de contacto STI-C (CPOC)
6)El CPOC es una entidad única designada por la CPA. El representante autorizado de la CPA es el responsable de autenticar al representante autorizado del CPOC y aprobar el formulario de solicitud del proceso de inscripción del CPOC. La CPA es responsable de autorizar al CPOC a operar como se especifica en el presente epígrafe.
7)El CPOC se encarga de:
establecer y contribuir al intercambio seguro de información entre todas las entidades del modelo de confianza STI-C de manera eficiente y rápida;
examinar las solicitudes y recomendaciones de cambios de procedimiento presentadas por otros participantes del modelo de confianza (por ejemplo, las CA raíz);
transmitir certificados de la CA raíz al TLM;
publicar el ancla de confianza común (clave pública vigente y certificado de enlace del TLM);
publicar la ECTL.
En el epígrafe 7 figura información pormenorizada sobre la ECTL.
1.3.6.Roles operativos
8)Las siguientes entidades definidas en [2] cumplen un rol operativo, definido en el documento RFC 3647:
Elemento funcional
|
Rol PKI ([3] y [4])
|
Rol detallado ([2])
|
autoridad de certificación raíz
|
CA/RA (autoridad de registro)
|
Proporciona a la EA y a la AA la prueba de que pueden emitir EC o AT
|
autoridad de inscripción
|
suscriptor de una CA raíz / sujeto de un certificado de EA
CA/RA
|
Autentica una estación STI-C y le otorga acceso a las comunicaciones STI
|
autoridad de autorización
|
suscriptor de una CA raíz / sujeto de un certificado de AA
CA/RA
|
Proporciona a una estación STI-C una prueba de autoridad de que puede usar servicios STI específicos
|
estación STI-C emisora
|
sujeto de un certificado de entidad final (EE) (EC)
|
Adquiere derechos procedentes de la EA para acceder a las comunicaciones STI
Negocia derechos procedentes de la AA para invocar servicios de STI
Envía mensajes de salto único y mensajes de difusión retransmitidos
|
estación STI-C retransmisora
|
parte retransmisora/sujeto de un certificado de EE
|
Recibe el mensaje difundido por la estación STI-C emisora y lo reenvía a la estación STI-C receptora, de ser necesario
|
estación STI-C receptora
|
parte retransmisora
|
Recibe mensajes de difusión de la estación STI-C emisora o retransmisora
|
fabricante
|
suscriptor de la EA
|
Instala la información necesaria para la gestión de la seguridad en la estación STI-C en la producción
|
operador
|
suscriptor de la EA/AA
|
Instala y actualiza la información necesaria para la gestión de la seguridad en la estación STI-C durante el funcionamiento
|
Cuadro 2: Roles operativos
Nota: de conformidad con [4], se usan diferentes términos en la presente CP para el «suscriptor» que establece un contrato con la CA para la emisión de certificados y el «sujeto» al que se aplica el certificado. Los suscriptores son las entidades que tienen una relación contractual con una CA. Los sujetos son las entidades a las que se aplica el certificado. Las EA/AA son suscriptoras y sujetos de la CA raíz y pueden solicitar certificados de EA/AA. Las estaciones STI-C son sujetos y pueden solicitar certificados de entidad final.
9)Autoridades de registro:
La EA ejercerá la función de autoridad de registro para las entidades finales. Solamente un suscriptor autenticado y autorizado puede registrar nuevas entidades (estaciones STI-C) en una EA. Las CA raíz correspondientes ejercerán el rol de autoridad de registro para las EA y las AA.
1.4.Utilización de los certificados
1.4.1.Ámbitos de utilización aplicables
10)Los certificados emitidos en el marco de la presente CP están destinados a utilizarse para validar firmas digitales en el contexto de la comunicación STI-C, de conformidad con la arquitectura de referencia de [2].
11)Los perfiles de los certificados incluidos en [5] determinan los usos de los certificados para el TLM, las CA raíz, las EA, las AA y las entidades finales.
1.4.2.Límites de responsabilidad
12)Los certificados no están destinados ni autorizados a ser utilizados en:
circunstancias que infrinjan, incumplan o contravengan cualquier ley, reglamento (como el RGPD), decreto u orden gubernamental vigentes;
circunstancias que incumplan, contravengan o infrinjan los derechos de los demás;
incumplimiento de la presente CP o del acuerdo de suscriptor pertinente;
cualquier circunstancia en la que su uso pudiera provocar directamente la muerte, daños personales o daños medioambientales graves (por ejemplo, por fallo en el funcionamiento de instalaciones nucleares, en la comunicación o la navegación aeronáutica, o en los sistemas de control de armas);
circunstancias que contravengan los objetivos generales de una mayor seguridad vial y un transporte por carretera más eficiente en Europa.
1.5.Administración de la política de certificación
1.5.1.Actualización de las CPS de las CA que figuran en la ECTL
13)Cada CA raíz que figure en la ECTL publicará su propia CPS, que deberá ser conforme con la presente política. Una CA raíz puede añadir requisitos adicionales, pero se asegurará de que todos los requisitos de la presente CP se cumplan en todo momento.
14)Cada CA raíz que figure en la ECTL establecerá un proceso de modificación adecuado para su documento de CPS. Las características principales del proceso de modificación se documentarán en la parte pública de la CPS.
15)Los procesos de modificación garantizarán que todas las modificaciones de la presente CP se analicen detenidamente y, de ser necesario para cumplir con la CP modificada, que la CPS se actualice dentro del plazo establecido en la etapa de aplicación del proceso de modificación de la CP. En particular, el proceso de modificación integrará procedimientos de modificación de emergencia que aseguren la aplicación oportuna de las modificaciones de la CP importantes para la seguridad.
16)El proceso de modificación incluirá medidas adecuadas para verificar que todas las modificaciones de la CPS cumplen la CP. Cualquier modificación de las CPS se documentará claramente. Antes de la aplicación de una nueva versión de una CPS, un auditor de la PKI acreditado debe confirmar su conformidad con la CP.
17)La CA raíz notificará a la CPA, como mínimo, la información siguiente relativa a cualquier modificación que se introduzca en la CPS:
una descripción exacta de la modificación;
la razón de la modificación;
un informe del auditor de la PKI acreditado en el que se confirme la conformidad con la CP;
los datos de contacto de la persona responsable de la CPS;
calendario previsto de aplicación.
1.5.2.Procedimientos de aprobación de la CPS
18)Antes de iniciar sus operaciones, las futuras CA raíz presentarán sus CPS a un auditor de PKI acreditado como parte de un encargo de auditoría de conformidad (flujo 13) y a la CPA para su aprobación (flujo 15).
19)Las CA raíz presentarán las modificaciones de sus CPS a un auditor de PKI acreditado como parte de un encargo de auditoría de conformidad (flujo 13) y a la CPA para su aprobación (flujo 15) antes de que dichas modificaciones entren en vigor.
20)Las EA/AA presentarán sus CPS o modificaciones en sus CPS a la CA raíz, que podrá encargar un certificado de conformidad a un organismo nacional o una entidad privada responsable de la aprobación de las EA/AA, como se define en los epígrafes4.1.2 y 8.
21)El auditor de la PKI acreditado evaluará la CPS de conformidad con el epígrafe 8.
22)El auditor de la PKI acreditado comunicará los resultados de la evaluación de la CPS como parte del informe de auditoría, tal y como se establece en el epígrafe 8.1. La CPS será aceptada o rechazada como parte del informe de auditoría a que se refieren los epígrafes 8.5 y 8.6.
2.Responsabilidades de publicación y repositorio
2.1.Métodos para la publicación de información sobre certificados
23)La información sobre certificados puede publicarse con arreglo al epígrafe 2.5:
de manera periódica; o
en respuesta a la solicitud de una de las entidades participantes.
En cada caso, se aplican diferentes grados de urgencia para la publicación y, por lo tanto, diferentes calendarios, pero las entidades deben estar preparadas para ambas modalidades.
24)La publicación periódica de la información sobre certificados posibilita que se determine una fecha límite máxima de actualización de la información sobre certificados para todos los nodos de la red STI-C. La frecuencia de publicación de toda la información sobre certificados se establece en el epígrafe 2.2.
25)A petición de las entidades que participan en la red STI-C, cualquiera de los participantes puede empezar a publicar información sobre certificados en cualquier momento y, según su rango, solicitar un conjunto vigente de información sobre certificados a fin de convertirse en un nodo de plena confianza de la red STI-C. El objetivo de dicha publicación es, principalmente, poner al día a las entidades sobre el estado general actual de la información sobre certificados en la red y permitirles comunicar sobre una base de confianza hasta la próxima publicación periódica de la información.
26)Una CA raíz también puede iniciar la publicación de la información sobre certificados en cualquier momento, mediante el envío de un conjunto actualizado de certificados a todos los «miembros suscritos» de la red STI-C que sean receptores regulares de dicha información. Esto contribuye al funcionamiento de las CA y les permite dirigirse a los miembros entre las fechas regulares y programadas para la publicación de los certificados.
27)El epígrafe 2.5 establece el mecanismo y todos los procedimientos para publicar los certificados de CA raíz y la ECTL.
28)El CPOC publicará los certificados de CA raíz (tal como figuran en la ECTL y destinados al consumo público), el certificado de TLM y la ECTL que emita.
29)Las CA raíz publicarán sus certificados EA/AA y sus CRL, y podrán utilizar los tres mecanismos mencionados aquí para publicarlos para sus miembros suscritos y las partes confiantes, adoptando todas las medidas necesarias para garantizar la transmisión segura, tal como se indica en el epígrafe 4.
2.2.Temporalidad o frecuencia de la publicación
30)Los requisitos relativos al calendario de publicación de los certificados y las CRL deben determinarse a la luz de los diversos factores de limitación de los nodos de los STI-C, con el objetivo general de operar una «red de confianza» y publicar actualizaciones lo más rápidamente posible destinadas a todas las estaciones STI-C participantes.
Para la publicación periódica de información actualizada sobre certificados (por ejemplo, cambios en la composición de la ECTL o de la CRL), se requiere un período máximo de tres meses para el funcionamiento seguro de la red STI-C.
Las CA raíz publicarán sus certificados de CA y las CRL lo antes posible tras su emisión.
Para la publicación de la CRL, se usará el repositorio de la CA raíz.
Además, las CPS de cada CA especificarán el plazo dentro del cual se publicará un certificado después de que la CA lo emita.
En este epígrafe se especifica únicamente el momento o la frecuencia de la publicación periódica. Los medios de conectividad para actualizar las estaciones STI-C con la ECTL y las CRL en el plazo de una semana a partir de su publicación (en condiciones normales de funcionamiento, por ejemplo, con cobertura de telefonía móvil, vehículo en servicio real, etc.) se aplicarán de conformidad con los requisitos del presente documento.
2.3.Repositorios
31)Los requisitos sobre la estructura del repositorio para el almacenamiento de los certificados y sobre qué información es facilitada por las entidades de la red STI-C, en el caso de las entidades individuales, son los siguientes:
en general, cada CA raíz debería utilizar un repositorio de la información sobre sus propios certificados EA/AA y su CRL actualmente activos a fin de publicar certificados para los demás participantes de la PKI (por ejemplo, un servicio de directorio basado en el LDAP). El repositorio de cada CA raíz aceptará todos los controles de acceso (epígrafe 2.4) y temporalidades de transmisión (epígrafe 2.2) necesarios para cada método de distribución de la información relacionada con los STI-C;
el repositorio del TLM (que almacena la ECTL y los certificados de TLM publicados por el CPOC, por ejemplo) debería basarse en un mecanismo de publicación capaz de garantizar las temporalidades de transmisión establecidas en el epígrafe 2.2 para cada método de distribución.
Aunque no se definen los requisitos de las AA, deben aceptar los mismos niveles de seguridad que las otras entidades y estos deben declararse en sus CPS.
2.4.Controles de acceso a los repositorios
32)Los requisitos relativos al control de acceso a los repositorios de información sobre certificados deberán cumplir al menos las normas generales de tratamiento seguro de la información que se describen en la norma ISO/IEC 27001, así como los requisitos del epígrafe 4. Además, reflejarán las necesidades de seguridad del proceso que se han de establecer para las diferentes etapas del proceso en la publicación de la información sobre certificados.
Esto incluye la implementación del repositorio para los certificados de TLM y la ECTL en el TLM/CPOC. Cada CA u operador de repositorio aplicará controles de acceso en relación con todas las entidades STI-C y partes externas para al menos tres niveles diferentes (por ejemplo, niveles público, restringido a las entidades STI-C, y de CA raíz), a fin de impedir que entidades no autorizadas añadan, modifiquen o supriman entradas del repositorio.
Los mecanismos exactos del control de acceso de cada entidad deberían formar parte de las CPS respectivas.
Para cada CA raíz, los repositorios de la EA y de la AA cumplirán los mismos requisitos en materia de procedimientos de control de acceso, independientemente del lugar o de la relación contractual con el proveedor de servicios que gestione el repositorio.
Como punto de partida para los niveles de control de acceso, cada CA raíz u operador de repositorio debería proporcionar al menos tres niveles diferentes (por ejemplo, niveles público, restringido a las entidades de STI-C, y de CA).
2.5.Publicación de la información sobre certificados
2.5.1.Publicación de la información sobre certificados por el TLM
33)El TLM del ámbito de confianza STI-C común europeo publicará la siguiente información a través del CPOC:
todos los certificados de TLM válidos para el siguiente período de funcionamiento (certificado vigente y de enlace, si se dispone de él);
información sobre el punto de acceso para que el repositorio del CPOC facilite la lista firmada de CA raíz (ECTL);
punto de información general para la ECTL y la implantación de los STI-C.
2.5.2.Publicación de la información sobre certificados por las CA
34)Las CA raíz del ámbito de confianza STI-C común europeo publicarán la siguiente información:
certificados de CA raíz (actualmente válidos) emitidos (certificados vigentes y con la clave correctamente renovada, incluido un certificado de enlace), en el repositorio mencionado en el epígrafe 2.3;
todas las entidades EA y AA válidas, con su identificador de operador y su período de funcionamiento previsto;
certificados de CA emitidos en los repositorios a que se hace referencia en el epígrafe 2.3;
las CRL de todos los certificados de CA revocados que comprendan las EA y AA subordinadas;
información sobre el punto de acceso de la CA raíz a la información de la CRL y la CA.
Toda la información sobre certificados se clasificará según tres niveles de confidencialidad, y los documentos destinados al público en general deben estar a disposición del público sin restricciones.
3.Identificación y autenticación
3.1.Nomenclatura
3.1.1.Tipos de nombre
3.1.1.1.Nombres de TLM, CA raíz, EA y AA
35)El nombre del certificado de TLM consistirá en un atributo único subject_name con el valor reservado «EU_TLM».
36)El nombre de la CA raíz consistirá en un atributo único subject_name con un valor asignado por la CPA. La unicidad de los nombres es responsabilidad exclusiva de la CPA, y el TLM mantendrá el registro de nombres de CA raíz previa notificación de la CPA (aprobación, revocación/supresión de una CA raíz). Los nombres de los sujetos que figuran en los certificados están limitados a 32 bytes. Cada CA raíz propone su nombre a la CPA en el formulario de solicitud (flujo 14). La CPA se encarga de comprobar la unicidad del nombre. Si el nombre no es único, se rechaza el formulario de solicitud (flujo 4).
37)El nombre de cada certificado EA/AA puede consistir en un atributo único subject_name con un valor generado por el emisor del certificado. La CA raíz emisora tiene la responsabilidad exclusiva de la unicidad de los nombres.
38)Los certificados de EA y AA no usarán nombres que excedan los 32 bytes, ya que los subject_name de los certificados están limitados a 32 bytes.
39)Los AT no contendrán ningún nombre.
3.1.1.2.Nombres de las entidades finales
40)A cada estación STI-C se le asignarán dos tipos de identificador único:
un identificador canónico que se almacena en el registro inicial de la estación STI-C bajo la responsabilidad del fabricante; contendrá una subcadena que identifique al fabricante o al operador, de manera que este identificador pueda ser único;
un subject_name, que puede ser parte de la EC de la estación STI-C, bajo la responsabilidad de la EA.
3.1.1.3.Identificación de los certificados
41)Los certificados que se ajusten al formato de [5] se identificarán computando un valor HashedId8, tal como se define en [5] .
3.1.2.Necesidad de que los nombres sean significativos
No hay disposiciones.
3.1.3.Anonimato y pseudonimia de las entidades finales
42)La AA garantizará que se establezca la pseudonimia de una estación STI-C proporcionando a la estación STI-C unos AT que no contengan ningún nombre o información que pueda vincular el sujeto a su verdadera identidad.
3.1.4.Normas para interpretar varios formatos de nombres
No hay disposiciones.
3.1.5.Unicidad de los nombres
43)Los nombres del TLM, las CA raíz, las EA, las AA y los identificadores canónicos de las estaciones STI-C serán únicos.
44)El TLM garantizará, en el proceso de registro de una CA raíz determinada en la ECTL, que su identificador de certificado (HashedId8) sea único. La CA raíz garantizará, en el proceso de emisión, que el identificador de certificado (HashedId8) de cada CA subordinada sea único.
45)El HashedId8 de un EC será único dentro de la CA emisora, mientras que el HashedId8 de un AT no tiene por qué ser único.
3.2.Validación inicial de la identidad
3.2.1.Método para demostrar la posesión de la clave privada
46)La CA raíz demostrará que posee legítimamente la clave privada correspondiente a la clave pública en el certificado autofirmado. El CPOC comprobará esta prueba.
47)La EA/AA demostrará que posee legítimamente la clave privada correspondiente a la clave pública que debe incluirse en el certificado. La CA raíz comprobará esta prueba.
48)La posesión de una nueva clave privada (para renovación de claves) se demostrará mediante la firma de la solicitud con la nueva clave privada (firma interna) seguida de la generación de una firma externa sobre la solicitud firmada con la clave privada válida vigente (para garantizar la autenticidad de la petición). El solicitante enviará la solicitud de certificado firmada a la CA emisora a través de una comunicación segura. La CA emisora comprobará que la firma digital del solicitante que figura en el mensaje de solicitud fue creada usando la clave privada correspondiente a la clave pública adjunta a la solicitud de certificado. La CA raíz especificará qué solicitudes y respuestas de certificado acepta en su CPS.
3.2.2.Autenticación de la identidad de una organización
3.2.2.1.Autenticación de la identidad de la organización de CA raíz
49)En los formularios de solicitud a la CPA (flujo 14), la CA raíz proporcionará la identidad de la organización y la información de registro, compuesta de lo siguiente:
nombre de la organización;
dirección de correos;
dirección de correo electrónico;
nombre de la persona de contacto en la organización;
número de teléfono;
huella digital (valor hash SHA 256) del certificado de CA raíz en forma impresa;
información criptográfica (es decir, algoritmos criptográficos y longitud de las claves) en el certificado de CA raíz;
todos los permisos que se permite a la CA raíz usar y pasar a las CA subordinadas.
50)La CPA comprobará la identidad de la organización y otra información de registro facilitada por el solicitante del certificado para la inclusión de un certificado de CA raíz en la ECTL.
51)La CPA recopilará evidencias directas, o una atestación procedente de una fuente apropiada y autorizada, de la identidad (por ejemplo, el nombre) y, si procede, cualquier atributo específico de los sujetos para los que se emite un certificado. Las evidencias podrán presentarse en papel o en formato electrónico.
52)La identidad del sujeto será verificada en el momento del registro mediante los medios apropiados y de conformidad con la presente política de certificación.
53)En cada solicitud de certificado, se presentará la evidencia de:
el nombre completo de la entidad organizativa (organización privada, entidad estatal o entidad no comercial);
el registro reconocido a nivel nacional u otros atributos que puedan utilizarse, en la medida de lo posible, para distinguir la entidad organizativa de otras con el mismo nombre.
Las normas expuestas arriba se basan en el documento TS 102 042 [4]: La CA garantizará que la evidencia de la identificación del suscriptor y el sujeto, así como la exactitud de sus nombres y datos asociados, se sometan a un examen adecuado como parte del servicio definido o, cuando proceda, se determinen mediante examen de las atestaciones procedentes de fuentes adecuadas y autorizadas, y de que las solicitudes de certificados sean exactas, autorizadas y completas de conformidad con la atestación o las evidencias recabadas.
3.2.2.2.Autenticación de la identidad de la organización del TLM
54)La organización que gestione el TLM deberá aportar evidencias de la identificación y exactitud del nombre y los datos asociados a fin de permitir una verificación adecuada en la creación inicial y en la renovación de claves del certificado TLM.
55)La identidad del sujeto será verificada en el momento de la creación del certificado o de la renovación de claves mediante los medios apropiados y de conformidad con la presente CP.
56)La evidencia de la organización se facilitará como se especifica en el epígrafe 3.2.2.1.
3.2.2.3.Autenticación de la identidad de la organización de CA subordinada
57)La CA raíz comprobará la identidad de la organización y otra información de registro facilitada por los solicitantes de certificados de CA subordinada (EA/AA).
58)Como mínimo, la CA raíz:
determinará que la organización existe usando al menos un servicio o una base de datos de prueba de identidad de un tercero, o bien documentación organizativa emitida o archivada por el organismo estatal pertinente o la autoridad reconocida que confirme la existencia de la organización;
usará el correo postal o un procedimiento comparable para pedir al solicitante del certificado que confirme determinada información sobre la organización, que ha autorizado la solicitud de certificado y que la persona que presenta la solicitud en nombre del solicitante está autorizada a hacerlo. Cuando un certificado incluya el nombre de una persona como representante autorizado de la organización, también confirmará que esa persona es su empleada y que la ha autorizado a actuar en su nombre.
59)Los procedimientos de validación para emitir certificados de CA se documentarán en una CPS de la CA raíz.
3.2.2.4.Autenticación de la organización suscriptora de entidades finales
60)Antes de que el suscriptor de entidades finales (fabricante/operador) pueda registrarse en una EA de confianza para que sus entidades finales puedan enviar solicitudes de certificado EC, la EA:
comprobará la identidad de la organización suscriptora y otra información de registro proporcionada por el solicitante del certificado;
comprobará que el tipo de estación STI-C (es decir, el producto concreto basado en la marca, modelo y versión de la estación STI-C) cumple todos los criterios de evaluación de la conformidad.
61)Como mínimo, la EA:
determinará que la organización existe usando al menos un servicio o una base de datos de prueba de identidad de un tercero, o bien documentación organizativa emitida o archivada por el organismo estatal pertinente o la autoridad reconocida que confirme la existencia de la organización;
usará el correo postal o un procedimiento comparable para pedir al solicitante del certificado que confirme determinada información sobre la organización, que ha autorizado la solicitud de certificado y que la persona que presenta la solicitud en su nombre está autorizada a hacerlo. Cuando un certificado incluya el nombre de una persona como representante autorizado de la organización, también confirmará que esa persona es su empleada y que la ha autorizado a actuar en su nombre.
62)Los procedimientos de validación para el registro de una estación STI-C por su suscriptor se documentarán en una CPS de la EA.
3.2.3.Autenticación de una entidad individual
3.2.3.1.Autenticación de una entidad individual de TLM/CA
63)Para la autenticación de una entidad individual (persona física) identificada en asociación con una persona jurídica o entidad organizativa (por ejemplo, el suscriptor), se aportarán evidencias de lo siguiente:
nombre completo del sujeto (apellidos y nombre, en consonancia con la legislación aplicable y las prácticas nacionales de identificación);
fecha y lugar de nacimiento, referencia a un documento de identidad reconocido a nivel nacional u otros atributos del suscriptor que puedan usarse, en la medida de lo posible, para distinguir a la persona de otras con el mismo nombre;
nombre completo y condición jurídica de la persona jurídica u otras entidades organizativas asociadas (por ejemplo, el suscriptor);
cualquier información de registro pertinente (por ejemplo, registro de la empresa) de la persona jurídica u otra entidad organizativa asociada;
evidencia de que el sujeto está asociado con la persona jurídica u otra entidad organizativa.
Las evidencias podrán presentarse en papel o en formato electrónico.
64)Para verificar su identidad, el representante autorizado de una CA raíz, EA, AA o suscriptor facilitará documentación que demuestre que trabaja para la organización (certificado de autorización). Además, presentará un documento de identidad oficial.
65)Para el proceso inicial de inscripción (flujo 31/32), un representante de la EA/AA facilitará a la CA raíz correspondiente toda la información necesaria (véase el epígrafe 4.1.2).
66)El personal de la CA raíz verificará la identidad del representante del solicitante del certificado y todos los documentos asociados, aplicando los requisitos de «personal de confianza», según lo establecido en el epígrafe 5.2.1. (El proceso de validación de la información sobre la solicitud y la generación del certificado por la CA raíz los llevarán a cabo «personas de confianza» de la CA raíz, bajo una supervisión doble, como mínimo, ya que son operaciones sensibles en el sentido del epígrafe 5.2.2).
3.2.3.2.Autenticación de la identidad del suscriptor de las estaciones STI-C
67)Los suscriptores están representados por usuarios finales autorizados en la organización, que están registrados en las EA y AA emisoras. Estos usuarios finales designados por organizaciones (fabricantes u operadores) demostrarán su identidad y autenticidad antes de:
registrar la EE en su EA correspondiente, incluidos su clave pública canónica, su identificador canónico (identificador único) y los permisos de conformidad con la EE;
registrarse en la AA y aportar la prueba de un acuerdo de suscriptor que puede enviarse a la EA.
3.2.3.3.Autenticación de la identidad de las estaciones STI-C
68)Las EE que sean sujetos de EC se autenticarán a sí mismas cuando soliciten EC (flujo 31) usando su clave privada canónica para la autenticación inicial. La EA verificará la autenticación utilizando la clave pública canónica correspondiente a la EE. Las claves públicas canónicas de las EE se transmiten a la EA antes de que se ejecute la solicitud inicial, por un canal seguro entre el fabricante o el operador de la estación STI-C y la EA (flujo 33).
69)Las EE que sean sujetos de AT se autenticarán a sí mismas cuando soliciten AT (flujo 32) usando su clave privada de inscripción única. La AA transmitirá la firma a la EA (flujo 25) para su validación; la EA la validará y confirmará el resultado a la AA (flujo 23).
3.2.4.Información no verificada sobre el suscriptor
No hay disposiciones.
3.2.5.Validación de la autoridad
3.2.5.1.Validación del TLM y de las CA raíz , EA y AA
70)Cada organización identificará en la CPS al menos un representante (por ejemplo, un responsable de seguridad) encargado de solicitar nuevos certificados y renovaciones. Se aplicarán las normas de nomenclatura del epígrafe 3.2.3.
3.2.5.2.Validación de los suscriptores de estaciones STI-C
71)Al menos una persona física responsable de registrar las estaciones STI-C en una EA (por ejemplo, un responsable de la seguridad) deberá ser conocida y aprobada por la EA (véase el epígrafe 3.2.3).
3.2.5.3.Validación de las estaciones STI-C
72)Los suscriptores de estaciones STI-C podrán registrar estaciones STI-C en una EA específica (flujo 33) siempre y cuando estén autenticados en esa EA.
Cuando la estación STI-C esté registrada en una EA con un identificador canónico único y una clave pública canónica, puede solicitar una EC utilizando una solicitud firmada con la clave privada canónica relacionada con la clave pública canónica registrada previamente.
3.2.6.Criterios de interoperabilidad
73)Para la comunicación entre las estaciones STI-C y las EA (o AA), la estación STI-C será capaz de establecer una comunicación segura con las EA (o AA), es decir, de llevar a cabo funciones de autenticación, confidencialidad e integridad, tal como se especifica en [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1]. La EA y la AA aceptarán esta comunicación segura.
74)La EA y la AA aceptarán las solicitudes y las respuestas de certificado que se ajusten a lo dispuesto en [1], que establece un protocolo seguro de solicitud/respuesta AT que permite el anonimato del solicitante con respecto a la AA y la separación de funciones entre la AA y la EA. Pueden utilizarse otros protocolos, siempre que se aplique [1]. Para evitar la divulgación de la identidad a largo plazo de las estaciones STI-C, la comunicación entre una estación STI-C móvil y una EA será confidencial (por ejemplo, los datos de comunicación estarán cifrados de extremo a extremo).
75)La AA enviará una solicitud de validación de la autorización (flujo 25) por cada solicitud de autorización que reciba de un sujeto de certificado EE. La EA validará esta solicitud respecto a:
la condición de la EE en la EA;
la validez de la firma;
los identificadores de aplicación STI (ITS-AID) y permisos solicitados;
la situación de la prestación de servicios de la AA al suscriptor.
3.3.Identificación y autenticación de las solicitudes de renovación de claves
3.3.1.Identificación y autenticación de las solicitudes de renovación de claves de rutina
3.3.1.1.Certificados de TLM
76)El TLM genera un par de claves y dos certificados: un certificado autofirmado y un certificado de enlace a los que se hace referencia en el epígrafe 7.
3.3.1.2.Certificados de CA raíz
No aplicable.
3.3.1.3.Renovación de certificados o de las claves de certificados de EA/AA
77)Antes de la expiración de un certificado de EA/AA, la EA/AA solicitará un nuevo certificado (flujo 21/24) para mantener la continuidad de uso del certificado. La EA/AA generará un nuevo par de claves para sustituir el par de claves que expira y firmará la solicitud de renovación de claves que contenga la nueva clave pública con la clave privada válida vigente («renovación de claves»). La EA o la AA genera un nuevo par de claves y firma la solicitud con la nueva clave privada (firma interna) para demostrar que posee la nueva clave privada. La solicitud completa se firma (por encima) con la clave privada válida vigente (firma externa) para garantizar la integridad y la autenticidad de la solicitud. Si se utiliza un par de claves de cifrado y descifrado, deberá demostrarse la posesión de las claves privadas de descifrado (para una descripción detallada de la renovación de claves, véase el epígrafe 4.7.3.3).
78)El método de identificación y autenticación para la renovación de claves de rutina es el mismo que para la emisión inicial de una validación inicial del certificado de CA raíz, como se indica en el epígrafe 3.2.2.
3.3.1.4.Credenciales de inscripción de las entidades finales
79)Antes de la expiración de un EC vigente, la EE solicitará un nuevo certificado (flujo 31) para mantener la continuidad de uso del certificado. La EE generará un nuevo par de claves para sustituir el par de claves que expira y solicitará un nuevo certificado que contenga la nueva clave pública; la solicitud se firmará con la clave privada válida vigente de la EC.
80)La EE puede firmar la solicitud con la clave privada que se acaba de crear (firma interna) para demostrar que posee la nueva clave privada. Después, la solicitud completa se firma (por encima) con la clave privada válida vigente (firma externa) y se cifra con destino a la EA receptora como se especifica en [1], para garantizar la confidencialidad, la integridad y la autenticidad de la solicitud. Pueden utilizarse otros protocolos, siempre que se aplique [1].
3.3.1.5.Tiques de autorización de las entidades finales
81)La renovación de claves de certificados para los AT se basa en el mismo proceso que la autorización inicial, como se define en [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
3.3.2.Identificación y autenticación de las solicitudes de renovación de claves tras una revocación
3.3.2.1.Certificados de CA
82)La autenticación de una organización de CA para renovar las claves de certificados de CA raíz, EA y AA tras una revocación se tramita del mismo modo que la emisión inicial de un certificado de CA, tal como se establece en el epígrafe 3.2.2.
3.3.2.2.Credenciales de inscripción de las entidades finales
83)La autenticación de una EE para renovar las claves de un certificado de EC tras una revocación se tramita del mismo modo que la emisión inicial de un certificado de EE, tal como se establece en el epígrafe 3.2.2.
3.3.2.3.Solicitudes de autorización de las entidades finales
No se aplica, ya que los AT no se revocan.
3.4.Identificación y autenticación de las solicitudes de revocación
3.4.1.Certificados de CA raíz/EA/AA
84)Las solicitudes de supresión de un certificado de CA raíz de la ECTL serán autenticadas por la CA raíz al TLM (flujos 12 y 9). Las solicitudes de revocación de un certificado EA/AA serán autenticadas por la CA raíz correspondiente y la propia CA subordinada.
85)Entre los procedimientos aceptables para la autenticación de las solicitudes de revocación de un suscriptor figuran los siguientes:
un mensaje escrito y firmado en papel de correspondencia de empresa enviado por el suscriptor que solicita la revocación, con referencia al certificado que debe revocarse;
una comunicación con el suscriptor que ofrezca garantías razonables de que la persona u organización que solicita la revocación es de hecho el suscriptor. Dependiendo de las circunstancias, dicha comunicación podrá realizarse por uno o varios de los siguientes medios: correo electrónico, correo postal o servicio de mensajería.
3.4.2.Credenciales de inscripción de estaciones STI-C
86)El suscriptor de estaciones STI-C puede revocar la EC de una estación STI-C registrada anteriormente en una EA (flujo 34). El suscriptor solicitante creará una solicitud de revocación de una estación STI-C determinada o de una lista de estaciones STI-C. La EA autenticará la solicitud de revocación antes de su tramitación y confirmará la revocación de las estaciones STI-C y de sus EC.
87)La EA puede revocar la EC de una estación STI-C de conformidad con el epígrafe 7.3.
3.4.3.Tiques de autorización de estaciones STI-C
88)Debido a que los AT no se revocan, su validez estará limitada a un período específico. Los diferentes períodos de validez aceptables en la presente política de certificación se especifican en el epígrafe 7.
4.Requisitos operativos para el ciclo de vida de los certificados
4.1.Solicitud de certificado
89)El presente epígrafe establece los requisitos de las solicitudes iniciales de emisión de certificados.
90)El término «solicitud de certificado» se refiere a los siguientes procesos:
registro y establecimiento de una relación de confianza entre el TLM y la CPA;
registro y establecimiento de una relación de confianza entre la CA raíz y la CPA y el TLM, lo que incluye la inclusión del primer certificado de CA raíz en la ECTL;
registro y establecimiento de una relación de confianza entre la EA/AA y la CA raíz, lo que incluye la emisión de un nuevo certificado de EA/AA;
registro de la estación STI-C en la EA por parte del fabricante/operador;
solicitud de EC/AT por parte de la estación STI-C.
4.1.1.Quién puede presentar una solicitud de certificado
4.1.1.1.CA raíz
91)Las CA raíz generan sus propios pares de claves y emiten sus certificados raíz ellas mismas. Las CA raíz pueden presentar una solicitud de certificado mediante su representante designado (flujo 14).
4.1.1.2.TLM
92)El TLM genera su propio par de claves y emite su certificado él mismo. La creación inicial del certificado de TLM será tramitada por un representante de la organización del TLM bajo el control de la CPA.
4.1.1.3.EA y AA
93)Un representante autorizado de la EA o de la AA puede presentar la solicitud de certificado de CA subordinada (EA o AA) al representante autorizado de la CA raíz que corresponda (flujo 27/28).
4.1.1.4.Estación STI-C
94)Los suscriptores registrarán cada estación STI-C en la EA de conformidad con el epígrafe 3.2.5.3.
95)Cada estación STI-C registrada en la EA puede enviar solicitudes de EC (flujo 31).
96)Cada estación STI-C puede enviar solicitudes de AT (flujo 32) sin solicitar ninguna interacción del suscriptor. Antes de solicitar un AT, las estaciones STI-C deberán tener una EC.
4.1.2.Proceso y responsabilidades de inscripción
97)Solamente los Estados miembros en los que se encuentran las organizaciones pueden conceder permisos para las CA raíz y las CA subordinadas que emiten certificados para fines especiales (estatales), es decir, estaciones STI-C móviles y fijas especiales.
4.1.2.1.CA raíz
98)Tras ser auditadas (flujos 13 y 36, epígrafe 8), las CA raíz pueden solicitar a la CPA la inclusión de sus certificados en la ECTL (flujo 14). El proceso de inscripción se basa en un formulario de solicitud manual firmado que el representante autorizado de la CA raíz entregará físicamente a la CPA y que contiene, como mínimo, la información que figura en los epígrafes 3.2.2.1, 3.2.3 y 3.2.5.1.
99)El formulario de solicitud de la CA raíz estará firmado por su representante autorizado.
100)Además del formulario de solicitud, el representante autorizado de la CA raíz proporcionará a la CPA una copia de la CPS de la CA raíz (flujo 15) y su informe de auditoría para su aprobación (flujo 16). En caso de aprobación positiva, la CPA genera y envía un certificado de conformidad al CPOC/TLM y a la CA raíz correspondiente.
101)El representante autorizado de la CA raíz presentará entonces al CPOC/TLM su formulario de solicitud (que contiene la huella del certificado autofirmado), el identificador oficial y una prueba de la autorización. El certificado autofirmado será entregado por vía electrónica al CPOC/TLM. El CPOC/TLM verificará todos los documentos y el certificado autofirmado.
102)Si las verificaciones son positivas, el TLM añadirá el certificado de CA raíz a la ECTL basándose en la notificación procedente de la CPA (flujos 1 y 2). En la CPS del TLM se describe el procedimiento detallado.
103)Debería ser posible un procedimiento adicional para obtener la aprobación de la CPS y del informe de auditoría de una CA raíz en un organismo oficial de países específicos.
4.1.2.2.TLM
104)Tras ser auditado, el TLM puede inscribirse ante la CPA. El proceso de inscripción se basa en un formulario de solicitud manual firmado que el representante autorizado del TLM entregará físicamente a la CPA (flujo 38) y que contiene, como mínimo, la información que figura en epígrafes 3.2.2.2 y 3.2.3.
105)El formulario de solicitud del TLM será firmado por su representante autorizado.
106)En primer lugar, el TLM genera su certificado autofirmado y lo transmite de forma segura a la CPA. Después, el TLM entrega a la CPA su formulario de solicitud (que contiene la huella del certificado autofirmado), un ejemplar de su CPS, un identificador oficial, una prueba de autorización y su informe de auditoría (flujo 40). La CPA comprobará todos los documentos y el certificado autofirmado. Si la verificación de todos los documentos, del certificado autofirmado y de la huella es positiva, la CPA confirmará el proceso de inscripción enviando su aprobación al TLM y al CPOC (flujo 39). La CPA almacenará la información de la solicitud enviada por el TLM. El certificado de TLM se emite entonces a través del CPOC.
4.1.2.3.EA y AA
107)Durante el proceso de inscripción, la EA/AA presentará los documentos pertinentes (por ejemplo, la CPS y el informe de auditoría) a la CA raíz correspondiente para su aprobación (flujo 27/28). Si la comprobación de los documentos es positiva, la CA raíz envía un aprobación a las CA subordinadas correspondientes (flujo 29/30). La CA subordinada (EA o AA) transmitirá después por vía electrónica su solicitud firmada y entregará físicamente su formulario de solicitud (de conformidad con el epígrafe 3.2.2.1), la prueba de autorización y el documento de identificación a la CA raíz correspondiente. La CA raíz verifica la solicitud y los documentos recibidos (formulario de solicitud que contiene la huella, que es el valor hash SHA 256 de la solicitud de la CA subordinada, la prueba de autorización y el documento de identificación). Si todas las comprobaciones conducen a un resultado positivo, la CA raíz emite el correspondiente certificado de CA subordinada. La información detallada sobre cómo se realiza una solicitud inicial se describe en su CPS específica.
108)Además del formulario de solicitud de la CA subordinada, el representante autorizado de la CA subordinada adjuntará una copia de la CPS a la CA raíz.
109)La información se transmitirá a un auditor de la PKI acreditado para su auditoría de conformidad con el epígrafe 8.
110)Si la CA subordinada es propiedad de una entidad diferente de la entidad propietaria de la CA raíz, antes de emitir una solicitud de certificado de CA subordinada, la entidad de la CA subordinada firmará un contrato relativo al servicio de CA raíz.
4.1.2.4.Estación STI-C
111)El suscriptor responsable (fabricante/operador) realizará el registro inicial de los sujetos de entidad final (estaciones STI-C) ante la EA (flujos 33 y 35) tras la autenticación satisfactoria de la organización suscriptora y de uno de sus representantes, de conformidad con los epígrafes 3.2.2.4 y 3.2.5.2.
112)Las estaciones STI-C pueden generar un par de claves EC (véase el epígrafe 6.1) y crear una solicitud de EC firmada de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
113)Durante el registro de una estación STI-C normal (a diferencia de una estación STI-C móvil o fija especial), la EA debe verificar que los permisos de la solicitud inicial no están destinados a un uso estatal. Los permisos para uso estatal están definidos por los Estados miembros correspondientes. El procedimiento detallado para el registro y la respuesta de la EA al fabricante/operador (flujos 33 y 35) se establecerá en la correspondiente CPS de la EA.
114)Las estaciones STI-C podrán inscribirse en una EA (epígrafe 3.2.5.3) enviando su solicitud inicial de EC de conformidad con [1].
115)Tras el registro inicial por parte de un representante del suscriptor autenticado, la EA aprueba qué AT puede obtener el sujeto de entidad final (es decir, la estación STI-C). Además, a cada entidad final se le asigna un nivel de garantía de confianza, que está relacionado con la certificación de la entidad final de conformidad con uno de los perfiles de protección enumerados en el epígrafe 6.1.5.2.
116)Los vehículos ordinarios solo tendrán una estación STI-C, registrada en una sola EA. Los vehículos especiales (como los coches de policía y otros vehículos especiales con derechos específicos) pueden estar registrados en una EA adicional o contar con una estación STI-C adicional para las autorizaciones correspondientes al ámbito de su finalidad especial. Los responsables de los Estados miembros determinarán a qué vehículos se aplican las exenciones, y serán los únicos que concederán los permisos para estaciones STI-C móviles y fijas especiales. La CPS de las CA raíz o de las CA subordinadas que emitan certificados para este tipo de vehículos en esos Estados miembros determinará cómo se aplica el proceso de certificación a dichos vehículos.
117)Cuando el suscriptor esté en proceso de migrar una estación STI-C de una EA a otra, la estación podrá estar registrada en dos EA (similares).
118)Las estaciones STI-C generan un par de claves AT (véase el epígrafe 6.1) y crean una solicitud de AT de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
119)Las estaciones STI-C envían una solicitud de autorización a la URL de la AA (flujos 32 y 26) enviando al menos la información requerida mencionada en el epígrafe 3.2.3.3. La AA y la EA validan la autorización para cada solicitud, de conformidad con los epígrafes 3.2.6 y 4.2.2.5.
4.2.Tramitación de las solicitudes de certificado
4.2.1.Realización de las funciones de identificación y autenticación
4.2.1.1.Identificación y autenticación de las CA raíz
120)El representante autorizado de la CPA es el responsable de autenticar al representante autorizado de la CA raíz y aprobar su proceso de inscripción, de conformidad con el epígrafe 3.
4.2.1.2.Identificación y autenticación del TLM
121)El representante autorizado de la CPA es el responsable de autenticar al representante autorizado del TLM y aprobar su formulario de solicitud del proceso de inscripción, de conformidad con el epígrafe 3.
4.2.1.3.Identificación y autenticación de la EA y la AA
122)La CA raíz correspondiente es responsable de autenticar al representante autorizado de la EA/AA y aprobar su formulario de solicitud del proceso de inscripción, de conformidad con el epígrafe 3.
123)La CA raíz confirmará su validación positiva del formulario de solicitud a la EA/AA. La EA/AA puede entonces enviar una solicitud de certificado a la CA raíz (flujos 21 y 24), que emitirá los certificados a la EA/AA correspondiente (flujo 18/19).
4.2.1.4.Identificación y autenticación del suscriptor de EE
124)Antes de que una estación STI-C pueda solicitar un certificado de EC, el suscriptor de EE transmitirá de forma segura a la EA la información del identificador de la estación STI-C (flujo 33). La EA verificará la solicitud y, en caso de verificación positiva, registrará la información de la estación STI-C en su base de datos y la confirmará al suscriptor de EE (flujo 35). El fabricante u operador realiza esta operación solo una vez para cada estación STI-C. Una vez que la estación STI-C ha sido registrada por una EA, puede solicitar a la vez un único certificado de EC que necesite (flujo 31). La EA autentica y verifica que la información contenida en la solicitud de certificado de EC es válida para una estación STI-C.
4.2.1.5.Tiques de autorización
125)Durante las solicitudes de autorización (flujo 32), de conformidad con [1], la AA debe autenticar a la EA de la que la estación STI-C recibió su EC. Pueden utilizarse otros protocolos, siempre que se aplique [1]. Si la AA no es capaz de autenticar a la EA, la solicitud es rechazada (flujo 26). Como requisito, la AA poseerá el certificado de EA para autenticar a la EA y verificar su respuesta (flujos 25 y 23 y epígrafe 3.2.5.3).
126)La EA autentica la estación STI-C que solicita un AT verificando su EC (flujos 25 y 23).
4.2.2.Aprobación o denegación de las solicitudes de certificado
4.2.2.1.Aprobación o denegación de certificados de CA raíz
127)El TLM introduce y suprime los certificados de CA raíz en la ECTL de conformidad con la aprobación de la CPA (flujo 1/2).
128)El TLM debería verificar la firma, la información y la codificación de los certificados de CA raíz tras recibir una aprobación de la CPA (flujo 1). Tras la validación positiva y la aprobación de la CPA, el TLM pondrá el certificado raíz correspondiente en la ECTL y lo notificará a la CPA (flujo 5).
4.2.2.2.Aprobación o denegación del certificado de TLM
129)La CPA es responsable de aprobar o rechazar los certificados de TLM.
4.2.2.3.Aprobación o denegación de certificados de EA y AA
130)La CA raíz verifica las solicitudes de certificado de CA subordinada (flujo 21/ 24) y los informes pertinentes (emitidos por el auditor de la PKI acreditado) cuando los recibe (flujo 36, epígrafe 8) de la correspondiente CA subordinada de la CA raíz. Si la comprobación de la solicitud conduce a un resultado positivo, la CA raíz correspondiente emite un certificado a la EA/AA solicitante (flujo 18/19); en caso contrario, se rechaza la solicitud y no se emitirá ningún certificado a la AE/AA.
4.2.2.4.Aprobación o denegación de EC
131)La EA verificará y validará las solicitudes de EC de conformidad con los epígrafes 3.2.3.2 y 3.2.5.3.
132)Si la solicitud de certificado de conformidad con [1] es correcta y válida, la EA generará el certificado solicitado.
133)Cuando la solicitud de certificado no es válida, la EA lo rechaza y envía una respuesta que expone el motivo de la denegación, de conformidad con [1]. Si una estación STI-C desea aun así una EC, presentará una nueva solicitud de certificado. Pueden utilizarse otros protocolos, siempre que se aplique [1].
4.2.2.5.Aprobación o denegación de AT
134)La EA comprueba la solicitud de certificado. La AA establecerá una comunicación con la EA para validar la solicitud (flujo 25). La EA autenticará a la estación STI-C solicitante y validará si tiene derecho a recibir el AT solicitado según lo estipulado en la CP (por ejemplo, comprobando la situación de revocación, la validez temporal y regional, los permisos, el nivel de garantía, etc.). La EA devolverá una respuesta de validación (flujo 23) y, si la respuesta es positiva, la AA generará el certificado solicitado y lo transmitirá a la estación STI-C. Si la solicitud de AT no es correcta o la respuesta de validación de la EA es negativa, la AA rechaza la solicitud. Si una estación STI-C aun así requiere un AT, presentará una nueva solicitud de autorización.
4.2.3.Plazo para procesar la solicitud de certificado
4.2.3.1.Solicitud de certificado de CA raíz
135)La tramitación del proceso de identificación y autenticación de una solicitud de certificado se realiza durante los días laborables y estará sujeta a un plazo máximo establecido en la CPS de la CA raíz.
4.2.3.2.Solicitud de certificado de TLM
136)La tramitación de la solicitud de certificado de TLM estará sujeta a un plazo máximo establecido en la CPS del TLM.
4.2.3.3.Solicitud de certificado de EA y AA
137)La tramitación del proceso de identificación y autenticación de una solicitud de certificado se realiza durante los días laborables, de conformidad con el acuerdo y el contrato entre la CA raíz del Estado miembro u organización privada y la CA subordinada. El plazo para tramitar las solicitudes de certificado de CA subordinada estará sujeto a un límite máximo establecido en la CPS de la CA subordinada.
4.2.3.4.Solicitud de EC
138)La tramitación de las solicitudes de EC estará sujeta a un plazo máximo establecido en la CPS de la EA.
4.2.3.5.Solicitud de AT
139)La tramitación de las solicitudes de AT estará sujeta a un plazo máximo establecido en la CPS de la AA.
4.3.Emisión de certificados
4.3.1.Acciones de la CA durante la emisión de certificados
4.3.1.1.Emisión de certificados de CA raíz
140)Las CA raíz emiten sus propios certificados autofirmados de CA raíz, certificados de enlace, certificados de CA subordinada y CRL.
141)Tras la aprobación de la CPA (flujo 4), la CA raíz envía su certificado al TLM a través del CPOC para que se añada a la ECTL (flujos 11 y 8) (véase el epígrafe 4.1.2.1). El TLM comprueba si la CPA ha aprobado el certificado (flujo 1).
4.3.1.2.Emisión de certificados de TLM
142)El TLM emite su propio certificado de TLM y de enlace autofirmado y lo envía al CPOC (flujo 6).
4.3.1.3.Emisión de certificados de EA y AA
143)Las CA subordinadas generan una solicitud de certificado firmada y la transmiten a la CA raíz correspondiente (flujos 21 y 24). La CA raíz verifica la solicitud y emite un certificado a la CA subordinada solicitante de conformidad con [5] lo antes posible, como se estipula en la CPS para las prácticas operativas habituales, pero en un plazo máximo de cinco días laborables tras la recepción de la solicitud.
144)La CA raíz actualizará el repositorio que contenga los certificados de las CA subordinadas.
4.3.1.4.Emisión de EC
145)Las estaciones STI-C enviarán una solicitud de EC a la EA, de conformidad con [1]. La EA autenticará y verificará que la información contenida en la solicitud de certificado es válida para una estación STI-C. Pueden utilizarse otros protocolos, siempre que se aplique [1].
146)En caso de validación positiva, la EA emitirá un certificado, de conformidad con el registro de la estación STI-C (véase el epígrafe 4.2.1.4), y lo enviará a la estación STI-C usando un mensaje de respuesta de EC, de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
147)Si no hay registro, la EA generará un código de error y lo enviará a la estación STI-C utilizando un mensaje de respuesta de EC, de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
148)Las solicitudes y respuestas de EC se cifrarán para garantizar la confidencialidad y se firmarán para garantizar la autenticación y la integridad.
4.3.1.5.Emisión de AT
149)La estación STI-C enviará un mensaje de solicitud de AT a la AA, de conformidad con [1]. La AA enviará a la EA una solicitud de validación de AT, de conformidad con [1]. La EA enviará a la AA una respuesta de validación de AT. En caso de respuesta positiva, la AA generará un AT y lo enviará a la estación STI-C utilizando un mensaje de respuesta de AT, de conformidad con [1]. En caso de respuesta negativa, la AA generará un código de error y lo enviará a la estación STI-C utilizando un mensaje de respuesta de AT, de conformidad con [1]. Pueden utilizarse otros protocolos, siempre que se aplique [1].
150)Las solicitudes y respuestas de AT se cifrarán (solo es necesario en el caso de las estaciones STI-C móviles) para garantizar la confidencialidad y se firmarán para garantizar la autenticación y la integridad.
4.3.2.Notificación de la CA al suscriptor sobre la emisión de certificados
No aplicable.
4.4.Aceptación de certificados
4.4.1.Forma en la que se acepta el certificado
4.4.1.1.CA raíz
No aplicable.
4.4.1.2.TLM
No aplicable.
4.4.1.3.EA y AA
151)La EA/AA verificará el tipo de certificado, la firma y la información del certificado recibido. La EA/AA eliminará todos los certificados de EA/AA que no estén correctamente verificados y emitirá una nueva solicitud.
4.4.1.4.Estación STI-C
152)La estación STI-C contrastará la respuesta de EC/AT recibida de la EA/AA con su solicitud inicial, incluida la firma y la cadena de certificación. Eliminará todas las respuestas de EC/AT que no se hayan verificado correctamente. En tales casos, debería enviar una nueva solicitud de EC/AT.
4.4.2.Publicación del certificado
153)Los certificados de TLM y sus certificados de enlace se pondrán a disposición de todos los participantes a través del CPOC.
154)El CPOC publica los certificados de CA raíz mediante la ECTL, firmada por el TLM.
155)La CA raíz publica los certificados de las CA subordinadas (EA y AA).
156)Las EC y los AT no se publican.
4.4.3.Notificación de la emisión del certificado
No hay notificaciones de emisión.
4.5.Uso del par de claves y del certificado
4.5.1.Uso de las claves privadas y de los certificados
4.5.1.1.Uso de las claves privadas y de los certificados por el TLM
157)El TLM usará sus claves privadas para firmar sus propios certificados (TLM y enlace) y la ECTL.
158)Los participantes de la PKI usarán el certificado de TLM para verificar la ECTL y autenticar el TLM.
4.5.1.2.Uso de las claves privadas y de los certificados por las CA raíz
159)Las CA raíz usarán sus claves privadas para firmar sus propios certificados, la CRL, los certificados de enlace y los certificados de EA/AA.
160)Los participantes de la PKI usarán los certificados de CA raíz para verificar los certificados de AA y EA asociados, los certificados de enlace y las CRL.
4.5.1.3.Uso de las claves privadas y de los certificados por las EA y AA
161)Las EA usarán sus claves privadas para firmar EC y para el descifrado de la solicitud de inscripción.
162)Los certificados de EA se usarán para verificar la firma de las EC asociadas y para el cifrado de las solicitudes de EC y AT por las EE, tal como se define en [1].
163)Las AA usarán sus claves privadas para firmar AT y para descifrar las solicitudes de AT.
164)Las EE usarán los certificados de AA para verificar los AT asociados y para el cifrado de solicitudes de AT, tal y como se define en [1].
4.5.1.4.Uso de las claves privadas y de los certificados por la entidad final
165)Las EE usarán la clave privada correspondiente a una EC válida para firmar una nueva solicitud de inscripción, tal y como se define en [1]. La nueva clave privada se usará para construir la firma interna en la solicitud para demostrar la posesión de la clave privada correspondiente a la nueva clave pública de EC.
166)Las EE usarán la clave privada correspondiente a una EC válida para firmar una solicitud de autorización, tal y como se define en [1]. La clave privada correspondiente al nuevo AT se usará para construir la firma interna en la solicitud para demostrar la posesión de la clave privada correspondiente a la nueva clave pública de AT.
167)Las EE usarán la clave privada correspondiente a un AT adecuado para firmar los mensajes de STI-C, tal y como se define en [5].
4.5.2.Uso de las claves privadas y de los certificados por la parte confiante
168)Las partes confiantes usan la cadena de certificación de confianza y las claves públicas asociadas para los fines mencionados en los certificados y para autenticar la identidad común de confianza de las EC y los AT.
169)Las partes confiantes no usarán los certificados de CA raíz, EA y AA, las EC y los AT sin una comprobación preliminar.
4.6.Renovación de certificados
No autorizado.
4.7.Renovación de claves de los certificados
4.7.1.Circunstancias para la renovación de las claves de un certificado
170)La renovación de las claves de un certificado se tramitará cuando este llegue al final de su período de validez o una clave privada alcance el final de su uso operativo, pero la relación de confianza con la CA todavía exista. En todos los casos, se generará un nuevo par de claves y se emitirá el certificado correspondiente.
4.7.2.Quién puede solicitar una renovación de claves
4.7.2.1.CA raíz
171)La CA raíz no solicita renovaciones de claves. El proceso de renovación de claves es interno en el caso de la CA raíz, ya que su certificado es autofirmado. La CA raíz renovará las claves con certificados de enlace o con nuevas emisiones (véase el epígrafe 4.3.1.1).
4.7.2.2.TLM
172)El TLM no solicita renovaciones de claves. El proceso de renovación de claves es interno en el caso del TLM, ya que su certificado es autofirmado.
4.7.2.3.EA y AA
173)La solicitud de certificado de CA subordinada debe presentarse a su debido tiempo para asegurarse de que se dispone de un nuevo certificado de CA subordinada y un par de claves operativas de CA subordinada antes de la expiración de la clave privada vigente de CA subordinada. Con respecto a la fecha de presentación también debe tenerse en cuenta el tiempo necesario para la aprobación.
4.7.2.4.Estación STI-C
No aplicable.
4.7.3.Proceso de renovación de claves
4.7.3.1.Certificado de TLM
174)El TLM decide renovar las claves sobre la base de los requisitos de los epígrafes 6.1 y 7.2. El proceso detallado se establece en su CPS.
175)El TLM ejecutará el proceso de renovación de claves a su debido tiempo para permitir la distribución de los nuevos certificados de TLM y de enlace a todos los participantes antes de que expire el certificado de TLM en vigor.
176)El TLM usará los certificados de enlace para renovar las claves y para garantizar la relación de confianza del nuevo certificado autofirmado. El nuevo certificado de TLM y de enlace recién creado se transfiere al CPOC.
4.7.3.2.Certificado de CA raíz
177)La CA raíz decide renovar las claves sobre la base de los requisitos de los epígrafes 6.1.5 y 7.2. El proceso detallado debería establecerse en su CPS.
178)La CA raíz ejecutará el proceso de renovación de claves a su debido tiempo (antes de que expire el certificado de CA raíz) para permitir la inserción del nuevo certificado en la ECTL antes de que el certificado de CA raíz adquiera validez (véase el epígrafe 5.6.2). El proceso de cambio de claves se llevará a cabo mediante certificados de enlace o como una solicitud inicial.
4.7.3.3.Certificados de EA y AA
179)La EA o AA solicitará un nuevo certificado como sigue:
Etapa
|
Indicación
|
Solicitud de renovación de claves
|
1
|
Generación del par de claves
|
Las CA subordinadas (EA y AA) generarán nuevos pares de claves de conformidad con el epígrafe 6.1.
|
2
|
Generación de solicitudes de certificado y firmas internas
|
La CA subordinada genera una solicitud de certificado a partir de la clave pública recién generada, teniendo en cuenta el sistema de nomenclatura (subject_info) del epígrafe 3, el algoritmo de firma, los Service Specific Permissions (SSP) y el parámetro adicional optativo, y genera la firma interna con la correspondiente clave privada nueva. Si se requiere una clave de cifrado, la CA subordinada también debe demostrar que posee la clave privada de descifrado correspondiente.
|
3
|
Generar la firma externa
|
La solicitud completa deberá ser firmada con la clave privada válida vigente para garantizar la autenticidad de la solicitud firmada.
|
4
|
Enviar la solicitud a la CA raíz
|
La solicitud firmada se enviará a la CA raíz correspondiente.
|
5
|
Verificación de la solicitud
|
La CA raíz correspondiente verificará la integridad y autenticidad de la solicitud. En primer lugar, comprobará la firma externa. Si la verificación es positiva, comprobará la firma interna. Si existe prueba de la posesión de la clave privada de descifrado, también comprobará dicha prueba.
|
6
|
Aceptar o rechazar la solicitud
|
Si todas las comprobaciones conducen a un resultado positivo, la CA raíz acepta la solicitud; de lo contrario, la rechaza.
|
7
|
Generar y emitir el certificado
|
La CA raíz genera un nuevo certificado y lo distribuye a la CA subordinada solicitante.
|
8
|
Enviar respuesta
|
La CA subordinada enviará un mensaje de situación (sobre si se ha recibido o no el certificado) a la CA raíz.
|
Cuadro 3: Proceso de renovación de claves para las EA y AA
180)Durante la renovación automática de claves para las CA subordinadas, la CA raíz se asegurará de que el solicitante está efectivamente en posesión de su clave privada. Los protocolos adecuados para la prueba de la posesión de claves privadas de descifrado se aplicará, por ejemplo, como se define en los documentos RFC 4210 y 4211. Para las claves de firma privadas, debería usarse la firma interna.
4.7.3.4.Certificados de estación STI-C
No se aplica a los AT.
4.8.Modificación de certificados
No autorizado.
4.9.Revocación y suspensión de certificados
Véase el epígrafe 7.
4.10.Servicios de situación de certificados
4.10.1.Características operativas
No aplicable.
4.10.2.Disponibilidad del servicio
No aplicable.
4.10.3.Características opcionales
No aplicable.
4.11.Fin de la suscripción
No aplicable.
4.12.Custodia y recuperación de claves
4.12.1.Suscriptor
4.12.1.1.Qué par de claves puede custodiarse
No aplicable.
4.12.1.2.Quién puede presentar una solicitud de recuperación
No aplicable.
4.12.1.3.Proceso y responsabilidades de recuperación
No aplicable.
4.12.1.4.Identificación y autenticación
No aplicable.
4.12.1.5.Aprobación o denegación de las solicitudes de recuperación
No aplicable.
4.12.1.6.Acciones KEA y KRA durante la recuperación del par de claves
No aplicable.
4.12.1.7.Disponibilidad de KEA y KRA
No aplicable.
4.12.2.Política y prácticas de encapsulación y recuperación de claves de sesión
No aplicable.
5.Controles operativos, de instalaciones y de gestión
181)La PKI se compone de la CA raíz, la EA/AA, el CPOC y el TLM, incluidos su componentes TIC (por ejemplo, redes y servidores).
182)En el presente epígrafe, la entidad responsable de un elemento de la PKI se identifica por el propio elemento. En otras palabras, la frase «la CA es responsable de realizar la auditoría» es equivalente a «la entidad o personal que gestiona la CA es responsable de realizar...».
183)La expresión «elementos del modelo de confianza STI-C» incluye la CA raíz, el TLM, la EA/AA, el CPOC y la red de seguridad.
5.1.Controles físicos
184)Todas las operaciones del modelo de confianza STI-C se llevarán a cabo en un entorno protegido físicamente que evite y detecte el uso y divulgación no autorizados de información y sistemas sensibles, así como el acceso a ellos, y que disuada de tal uso y divulgación. Los elementos del modelo de confianza STI-C usarán controles físicos de seguridad en cumplimiento de las normas ISO 27001 e ISO 27005.
185)Las entidades que gestionen los elementos del modelo de confianza STI-C describirán los controles físicos, de procedimiento y de personal en sus CPS. En particular, las CPS contendrán información sobre la ubicación y construcción de los edificios y sus controles físicos de seguridad que garanticen un acceso controlado a todas las salas usadas en las instalaciones de las entidades del modelo de confianza STI-C.
5.1.1.Ubicación física y construcción
5.1.1.1.CA raíz, CPOC y TLM
186)La ubicación y la construcción de las instalaciones utilizadas para alojar el equipo y los datos (HSM, datos de activación, copia de seguridad del par de claves, ordenadores, registro, script de la ceremonia de claves, solicitud de certificados, etc.) de la CA raíz, el CPOC y el TLM serán acordes a las instalaciones utilizadas para alojar información sensible y de alto valor. Las operaciones de la CA raíz tendrán lugar en una zona física específica separada de las zonas físicas de otros componentes de la PKI.
187)La CA raíz, el CPOC y el TLM aplicarán políticas y procedimientos que garanticen el mantenimiento de un alto nivel de seguridad en el entorno físico en el que esté instalado el equipo de la CA raíz, a fin de garantizar que:
esté aislado de las redes ajenas al modelo de confianza;
esté dividido en una serie de (al menos dos) perímetros físicos con seguridad progresiva;
los datos sensibles (HSM, copia de seguridad de pares de claves, datos de activación, etc.) se almacenen en una caja fuerte específica ubicada en una zona física específica sujeta a un control de acceso múltiple.
188)Las técnicas de seguridad empleadas se diseñarán para resistir un gran número y una combinación de diferentes formas de ataques. Los mecanismos utilizados incluirán, como mínimo:
alarmas de perímetro, televisión en circuito cerrado, muros reforzados y detectores de movimiento;
autenticación de doble factor (por ejemplo, tarjeta inteligente y PIN) para cada persona, y acreditación para entrar y salir de las instalaciones de la CA raíz y de la zona física segura.
189)La CA raíz, el CPOC y el TLM utilizan personal autorizado para supervisar continuamente los equipos de alojamiento de las instalaciones las veinticuatro horas, todos los días del año. El entorno operativo (por ejemplo, las instalaciones físicas) nunca se dejará sin vigilancia. El personal del entorno operativo nunca tendrá acceso a las zonas seguras de las CA raíz y de las CA subordinadas a no ser que esté autorizado.
5.1.1.2.EA/AA
190)Se aplican las mismas disposiciones del epígrafe 5.1.1.1.
5.1.2.Acceso físico
5.1.2.1.CA raíz, CPOC y TLM
191)El equipo y los datos (HSM, datos de activación, copia de seguridad del par de claves, ordenadores, registro, script de la ceremonia de claves, solicitud de certificados, etc.) estarán siempre protegidos contra el acceso no autorizado. Los mecanismos físicos de seguridad para el equipo, como mínimo:
vigilarán, de forma manual o electrónica, la intrusión no autorizada en todo momento;
garantizarán que no se permita el acceso no autorizado al hardware y a los datos de activación;
garantizarán que todos los soportes extraíbles y papeles que contengan información sensible de texto sin cifrar se almacenen en un depósito seguro;
garantizarán que cualquier persona que entre en una zona segura que no esté autorizada de forma permanente no se quede sin supervisión de un empleado autorizado de las instalaciones de la CA raíz, el CPOC y el TLM;
garantizarán que se mantenga e inspeccione periódicamente un registro de acceso;
proporcionarán al menos dos capas progresivamente más seguras, por ejemplo, en el perímetro, el edificio y la sala operativa;
exigirán dos controles de acceso físico de rol de confianza para el HSM y los datos de activación criptográficos.
192)Se efectuará un control de seguridad de las instalaciones que alojen el equipo si este se deja sin vigilancia. Como mínimo, el control comprobará que:
el equipo se encuentra en un estado adecuado para el modo de funcionamiento actual;
se apaga todo el equipo de los componentes fuera de línea;
todos los contenedores de seguridad (sobres a prueba de manipulaciones, cajas fuertes, etc.) están correctamente protegidos;
los sistemas de seguridad físicos (por ejemplo, cerraduras de puertas, tapas de ventilación y electricidad) funcionan correctamente;
la zona está protegida contra el acceso no autorizado.
193)Los módulos criptográficos extraíbles se desactivarán antes de su almacenamiento. Cuando no se utilicen, estos módulos y los datos de activación utilizados para acceder a ellos o habilitarlos se pondrán en una caja fuerte. Los datos de activación se memorizarán o registrarán y se almacenarán de manera acorde con la seguridad garantizada al módulo criptográfico. No deberán almacenarse junto con el módulo criptográfico, a fin de evitar que solo una persona tenga acceso a la clave privada.
194)Una persona o un grupo de roles de confianza se hará explícitamente responsable de la realización de dichos controles. Cuando un grupo de personas sea responsable, se mantendrá un registro que identifique a la persona que lleve a cabo cada control. Si la instalación no tiene presencia humana continua, la última persona que salga deberá rubricar una hoja de salida que indique la fecha y hora, y que confirme que todos los mecanismos de protección física necesarios están instalados y activados.
5.1.2.2.EA/AA
195)Se aplican las mismas disposiciones del epígrafe 5.1.2.1.
5.1.3.Alimentación eléctrica y aire acondicionado
196)Las instalaciones seguras de los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) estarán dotadas de un acceso fiable a la alimentación eléctrica para garantizar el funcionamiento sin fallos o con fallos menores. Se necesitan instalaciones primarias y auxiliares en caso de fallo de la alimentación externa, y un cierre correcto de los equipos del modelo de confianza STI-C en caso de falta de alimentación. Las instalaciones del modelo de confianza STI-C estarán equipadas con sistemas de calefacción/ventilación/aire acondicionado para mantener la temperatura y la humedad relativa de los equipos del modelo de confianza STI-C dentro de los límites operativos. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.4.Exposición al agua
197)Las instalaciones seguras de los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) deberían protegerse de forma que se minimice el impacto de la exposición al agua. Por este motivo, se evitarán las cañerías y las tuberías de desagüe. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.5.Prevención y protección contra incendios
198)Para evitar daños producidos por las llamas o el humo, las instalaciones seguras de los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) se construirán y equiparán en consecuencia, y se aplicarán procedimientos para hacer frente a los riesgos relacionados con el fuego. Los soportes de memoria deberían estar protegidos contra el fuego en contenedores apropiados.
199)Los elementos del modelo de confianza STI-C protegerán los soportes físicos que contengan copias de seguridad de los datos críticos del sistema o cualquier otra información sensible contra los riesgos medioambientales y contra la utilización, el acceso o la divulgación no autorizados. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.6.Gestión de soportes
200)Los soportes utilizados en los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) son tratados de forma segura para protegerlos contra daños, contra el robo y contra el acceso no autorizado. Se aplican procedimientos de gestión de soportes para protegerlos contra la obsolescencia y el deterioro durante el período en el que deben conservarse los registros.
201)Los datos sensibles estarán protegidos contra el acceso derivado de la reutilización de los soportes de memoria (por ejemplo, ficheros suprimidos), que puede hacer que los datos sensibles sean accesibles a usuarios no autorizados.
202)Se mantendrá un inventario de todos los activos de información y se establecerán requisitos para la protección de dichos activos que sean coherentes con el análisis de riesgos. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.7.Eliminación de residuos
203)Los elementos del modelo de confianza STI-C (CA raíz, CPOC, TLM, EA y AA) aplicarán procedimientos para la eliminación segura e irreversible de residuos (como papeles o soportes) para evitar el uso o la divulgación no autorizados de residuos que contengan información confidencial o privada, o el acceso no autorizado a ellos. Todos los soportes utilizados para el almacenamiento de información sensible, como claves, datos de activación o ficheros, serán destruidos antes de ser eliminados como residuos. La CPS del elemento del modelo de confianza STI-C describirá detalladamente el plan y los procesos para aplicar dichos requisitos.
5.1.8.Copias de seguridad fuera de las instalaciones
5.1.8.1.CA raíz, CPOC y TLM
204)Después de la implantación de la CA raíz, el CPOC y el TLM, y después de cada nueva generación de par de claves, se realizan fuera de las instalaciones copias de seguridad completas de los componentes de la CA raíz, el CPOC y el TLM, que sean suficientes para una recuperación si se produce un fallo en el sistema. Periódicamente se realizan copias de seguridad de la información empresarial y el software esenciales (par de claves y CRL). Se proporcionan instalaciones adecuadas para copias de seguridad a fin de que se pueda recuperar toda la información empresarial y el software esenciales tras una catástrofe o un fallo de los soportes. Los mecanismos de copias de seguridad de los sistemas individuales se someten a pruebas periódicas para garantizar que cumplen los requisitos del plan de continuidad de las actividades. Al menos una copia de seguridad completa se almacena en un lugar fuera de las instalaciones (recuperación en caso de catástrofe). La copia de seguridad se almacena en un emplazamiento con controles físicos y de procedimiento acordes con el sistema operativo PKI.
205)Los datos de la copia de seguridad están sujetos a los mismos requisitos de acceso que los datos operativos, y se cifrarán y almacenarán fuera de las instalaciones. En caso de que se produzca una pérdida completa de datos, la información necesaria para poner de nuevo en funcionamiento la CA raíz, el CPOC y el TLM se recuperará completamente a partir de los datos de la copia de seguridad.
206)Las copias de seguridad del material de la clave privada de la CA raíz, el CPOC y el TLM no se realizarán utilizando mecanismos estándar de copias de seguridad, sino utilizando la función de copia de seguridad del módulo criptográfico.
5.1.8.2.EA/AA
207)Los procesos descritos en el epígrafe 5.1.8.1 se aplican a este epígrafe.
5.2.Controles de procedimiento
En este epígrafe se describen los requisitos relativos a los roles, las funciones y la identificación del personal.
5.2.1.Roles de confianza
208)Se considerará «personas de confianza» a los empleados, contratistas y consultores a los que se hayan asignado roles de confianza. Las personas que deseen convertirse en personas de confianza para obtener de una posición de confianza deberán cumplir los requisitos de control de la presente política de certificación.
209)Las personas de confianza controlan o tienen acceso a las operaciones de autenticación o cifrado que puedan afectar materialmente a:
la validación de la información en las solicitudes de certificados;
la aceptación, el rechazo u otra tramitación de solicitudes de certificados, de revocación o de renovación;
la emisión o revocación de certificados, incluido el personal que tenga acceso a las partes restringidas de su repositorio o al tratamiento de la información o solicitudes del suscriptor.
210)Entre los roles de confianza se encuentran:
servicio al cliente;
administración del sistema;
ingeniería designada;
directivos encargados de la gestión de la fiabilidad de las infraestructuras.
211)La CA proporcionará descripciones claras de todos los roles de confianza en su CPS.
5.2.2.Número de personas necesarias por tarea
212)Los elementos del modelo de confianza STI-C establecerán, mantendrán y harán cumplir procedimientos de control rigurosos para garantizar la separación de funciones según los roles de confianza y para garantizar que sean necesarias varias personas de confianza para llevar a cabo tareas sensibles. Los elementos del modelo de confianza STI-C (TLM, CPOC, CA raíz, EA y AA) deberían cumplir lo estipulado en [4], así como los requisitos de los apartados siguientes.
213)Existen procedimientos de política y de control para garantizar la separación de funciones según las responsabilidades en el puesto de trabajo. Las tareas más sensibles, como el acceso al hardware criptográfico de la CA (HSM) y a su material de claves asociado, así como su gestión, deben requerir la autorización de varias personas de confianza.
214)Estos procedimientos de control interno estarán diseñados de manera que se necesiten al menos dos personas de confianza para tener acceso físico o lógico al dispositivo. Las restricciones de acceso al hardware criptográfico de la CA deben ser aplicadas estrictamente por varias personas de confianza a lo largo de todo su ciclo de vida, desde la recepción y la inspección de entrada hasta la destrucción lógica o física final. Cuando se ha activado un módulo con claves operativas, se invocan más controles de acceso para mantener el control fraccionado sobre el acceso tanto físico como lógico al dispositivo.
5.2.3.Identificación y autenticación para cada rol
215)Todas las personas a las que se ha asignado un rol, tal como se describen en la presente CP, están identificadas y autenticadas a fin de garantizar que el rol les permita desempeñar sus funciones PKI.
216)Los elementos del modelo de confianza STI-C verificarán y confirmarán la identidad y la autorización de todo el personal que desee convertirse en persona de confianza, antes de que:
se expidan sus dispositivos de acceso y se les conceda acceso a las instalaciones necesarias;
hayan recibido las credenciales electrónicas para acceder a funciones específicas en los sistemas de la CA y ejercerlas.
217)La CPS describe los mecanismos utilizados para identificar y autenticar a las personas.
5.2.4.Roles que requieren separación de funciones
218)Entre los roles que requieren separación de funciones se encuentran:
la aceptación, el rechazo y la revocación de solicitudes, y otras tramitaciones de las solicitudes de certificados de CA;
la generación, emisión y destrucción de un certificado de CA.
219)La separación de funciones podrá ejecutarse utilizando equipos o procedimientos de PKI, o ambas cosas. No se asignará más de una identidad a ninguna persona, salvo que la CA raíz lo apruebe.
220)La parte de la CA raíz y de la CA relacionada con la gestión de la generación y la revocación de certificados será independiente de otras organizaciones para sus decisiones relativas al establecimiento, la dotación, el mantenimiento y la suspensión de los servicios, de conformidad con las políticas de certificación aplicables. En particular, sus altos cargos, el personal directivo y el personal que desempeñen roles de confianza estarán libres de toda presión comercial, financiera o de otro tipo que pueda influir negativamente en la confianza en los servicios que presta.
221)Las EA y las AA que presten servicio a las estaciones STI-C móviles serán entidades operativas aparte, con infraestructuras y equipos de gestión de TI independientes. De conformidad con el RGPG, la EA y la AA no intercambiarán datos personales, excepto en lo que se refiere a la autorización de las solicitudes de AT. Transferirán los datos relativos a la aprobación de las solicitudes de AT utilizando únicamente el protocolo de validación de la autorización que figura en [1] por medio de una interfaz segura específica. Pueden utilizarse otros protocolos, siempre que se aplique [1].
222)Los archivos de registro almacenados por la EA y la AA pueden utilizarse únicamente para la revocación de las EC indebidas basadas en AT de los CAM/DENM maliciosos interceptados. Tras la identificación de un CAM/DENM como malicioso, la AA examinará la clave de verificación del AT en sus registros de emisión y enviará una solicitud de revocación a la EA que contenga la firma cifrada bajo la clave privada de la EC que se utilizó durante la emisión del AT. Todos los archivos de registro deberán estar adecuadamente protegidos contra el acceso de partes no autorizadas y no podrán compartirse con otras entidades o autoridades.
Nota: En el momento de la redacción de la presente versión de la CP, no se ha definido el diseño de la función de comportamiento inadecuado. Se ha previsto la posibilidad de diseñar dicha función en futuras revisiones de la política.
5.3.Controles de personal
5.3.1.Requisitos relativos a las cualificaciones, la experiencia y la autorización
223)Los elementos del modelo de confianza STI-C emplean a un número suficiente de personal con los conocimientos especializados, la experiencia y las cualificaciones necesarias para desempeñar las funciones profesionales y los servicios que ofrecen. El personal de la PKI cumple estos requisitos mediante formación y titulaciones formales, experiencia real o una combinación de ambas. Los roles y las responsabilidades de confianza, como se describen en la CPS, están documentados en las descripciones de los puestos de trabajo y están claramente identificados. Los subcontratistas de personal PKI tienen descripciones de los puestos de trabajo definidas para garantizar la separación de funciones y privilegios, y la sensibilidad de la posición se determina sobre la base de las funciones y los niveles de acceso, el control de antecedentes personales y la formación y sensibilización de los empleados.
5.3.2.Procedimientos de comprobación de antecedentes
224)Los elementos del modelo de confianza STI-C llevarán a cabo comprobaciones de antecedentes de los miembros del personal que deseen convertirse en personas de confianza. Al menos cada cinco años, se repetirán las comprobaciones de antecedentes del personal que posea posiciones de confianza.
225)Los factores revelados en una comprobación de antecedentes que pueden considerarse motivos para rechazar a los candidatos a una posición de confianza o para tomar medidas contra una persona de confianza que ya ocupe el puesto son, entre otros, los siguientes:
declaraciones incorrectas realizadas por el candidato o la persona de confianza;
referencias profesionales muy desfavorables o poco fiables;
determinadas condenas penales;
indicios de falta de responsabilidad económica.
226)Los informes que contengan dicha información serán evaluados por el personal de recursos humanos, que tomará medidas razonables a la luz del tipo, la magnitud y la frecuencia de la conducta descubierta por la comprobación de antecedentes. Esta acción puede incluir medidas que pueden llegar a la supresión de las ofertas de empleo presentadas a los candidatos para puestos de confianza o a la rescisión del contrato de las personas de confianza que ya ocupen el puesto. El uso de la información revelada en una comprobación de antecedentes como base para tal acción estará sujeto a la legislación aplicable.
227)La investigación de antecedentes de las personas que desean convertirse en personas de confianza incluye, entre otras cosas:
confirmación de empleos anteriores;
una comprobación de las referencias profesionales relativas a su empleo durante un período mínimo de cinco años;
confirmación del título educativo más elevado o más pertinente obtenido;
una comprobación de antecedentes penales.
5.3.3.Requerimientos de formación
228)Los elementos del modelo de confianza STI-C proporcionarán a su personal la formación necesaria para cumplir sus responsabilidades en relación con las operaciones de la CA de manera competente y satisfactoria.
229)Los programas de formación se revisarán periódicamente y su formación abordará cuestiones que sean pertinentes para las funciones desempeñadas por su personal.
230)Los programas de formación abordarán cuestiones que sean pertinentes para el entorno particular de la persona en formación, en particular:
los principios y mecanismos de seguridad de los elementos del modelo de confianza STI-C;
las versiones de hardware y software en uso;
todas las funciones que se espera que realice la persona, así como los procesos y secuencias internos y externos de presentación de informes;
los procesos operativos y flujos de trabajo de la PKI;
la notificación y gestión de incidentes y comprometimientos;
los procedimientos de recuperación y de continuidad de las actividades en caso de catástrofe;
conocimientos suficientes en materia de TI.
5.3.4.Requerimientos y frecuencia de actualización de la formación
231)Las personas asignadas a roles de confianza tienen la obligación de actualizar de forma continua los conocimientos adquiridos en la formación utilizando un entorno de formación. La formación deberá repetirse siempre que se considere necesario y, como mínimo, cada dos años.
232)Los elementos del modelo de confianza STI-C proporcionarán a su personal formaciones complementarias y actualizaciones en la medida y con la frecuencia necesarias para garantizar que mantengan el nivel requerido de competencia para cumplir sus responsabilidades laborales de forma competente y satisfactoria.
233)Las personas que ocupen roles de confianza serán conscientes de los cambios en las operaciones PKI, según proceda. Todo cambio significativo de las operaciones deberá ir acompañado de un plan de formación (de sensibilización), cuya ejecución se documentará.
5.3.5.Frecuencia y secuencia de rotación de tareas
234)No estipulado, siempre que se garanticen las capacidades técnicas, la experiencia y los derechos de acceso. Los administradores de los elementos del modelo de confianza STI-C garantizarán que los cambios de personal no afecten a la seguridad del sistema.
5.3.6.Sanciones por actuaciones no autorizadas
235)Cada elemento del modelo de confianza STI-C debe elaborar un proceso disciplinario formal para garantizar que las acciones no autorizadas sean debidamente sancionadas. En los casos graves, deben retirarse las asignaciones del rol y los privilegios correspondientes.
5.3.7.Requisitos para los contratistas independientes
236)Los elementos del modelo de confianza STI-C pueden permitir que contratistas o consultores independientes se conviertan en personas de confianza solo en la medida necesaria para establecer relaciones de externalización claramente definidas, y a condición de que la entidad confíe en los contratistas o consultores en la misma medida que si fueran empleados y de que estos cumplan los requisitos aplicables a los empleados.
237)De no ser así, los contratistas y consultores independientes tendrán acceso a las instalaciones seguras de la PKI del C-ITS solo si están acompañados y directamente supervisados por personas de confianza.
5.3.8.Documentación proporcionada al personal
238)Los elementos del modelo de confianza STI-C proporcionarán a su personal la formación y el acceso a la documentación que necesitan para cumplir sus responsabilidades laborales de forma competente y satisfactoria.
5.4.Procedimientos de registro de auditoría
239)En el presente epígrafe se establecen los requisitos en relación con los tipos de eventos que deben registrarse y la gestión de los registros de auditoría.
5.4.1.Tipos de eventos que cada CA debe registrar y notificar
240)Un representante de la CA revisará periódicamente los registros, eventos y procedimientos de dicha CA.
241)Los elementos del modelo de confianza STI-C registrarán los siguientes tipos de eventos de auditoría (si procede):
acceso a las instalaciones físicas: se registrará el acceso de las personas físicas a las instalaciones mediante el almacenamiento de las solicitudes de acceso a través de tarjetas inteligentes; se creará un evento cada vez que se genere un registro;
gestión de los roles de confianza: se registrará cualquier cambio en la definición y el nivel de acceso de los diferentes roles, incluida la modificación de los atributos de los roles. se creará un evento cada vez que se genere un registro;
acceso lógico: se generará un evento cuando una entidad (por ejemplo, un programa) tenga acceso a zonas sensibles (es decir, redes y servidores);
gestión de las copias de seguridad: se crea un evento cada vez que se completa una copia de seguridad, tanto de forma satisfactoria como fallida;
gestión de los registros: se almacenarán los registros; se crea un evento cuando el tamaño del registro supera un tamaño determinado;
datos del proceso de autenticación para suscriptores y elementos del modelo de confianza STI-C: se generarán eventos para cada solicitud de autenticación por parte de los suscriptores y de los elementos del modelo de confianza STI-C;
aceptación y denegación de las solicitudes de certificado, incluida la creación y renovación de certificados: se generará periódicamente un evento con una lista de solicitudes de certificado aceptadas y denegadas en los últimos siete días;
registro de fabricantes: se creará un evento cuando se registre un fabricante;
registro de estaciones STI-C: se creará un evento cuando se registre una estación STI-C;
gestión de HSM: se creará un evento cuando se registre una violación de seguridad HSM;
gestión de la informática y de la red, en la medida en que estén relacionada con los sistemas PKI: se creará un evento cuando un servidor PKI se apague o se reinicie;
gestión de la seguridad (intentos de acceso al sistema PKI logrados y fallidos, acciones ejecutadas de PKI y del sistema de seguridad, cambios en los perfiles de seguridad, caídas del sistema, fallos y otras anomalías de hardware, actividades de cortafuegos y encaminador; y entradas y salidas de las instalaciones PKI);
los datos relacionados con los eventos se conservarán durante al menos cinco años, a menos que sean de aplicación normas nacionales adicionales.
242)De conformidad con el RGDP, los registros de auditoría no permitirán el acceso a los datos relacionados con la privacidad relativos a los vehículos privados de la estación STI-C.
243)En la medida de lo posible, los registros de auditoría de seguridad se compilarán de manera automática. Cuando esto no sea posible, se utilizará un cuaderno de registro, un formulario en papel u otro mecanismo físico. Se conservarán todos los registros de auditoría de seguridad, tanto electrónicos como no electrónicos, y se pondrán a disposición durante las auditorías de conformidad.
244)Cada evento relacionado con el ciclo de vida del certificado se registra de manera que pueda atribuirse a la persona que lo ha realizado. Todos los datos relativos a las identidades personales se cifran y protegen contra el acceso no autorizado.
245)Como mínimo, cada historial de auditoría incluye la siguiente información (registrada automática o manualmente para cada evento objeto de auditoría):
tipo de evento (según la lista anterior);
fecha y hora de confianza en que se produjo el evento;
resultado del evento: logrado o fallido, según corresponda;
identidad de la entidad u operador que causó el evento, si procede;
identidad de la entidad a la que se dirige el evento.
5.4.2.Frecuencia de tratamiento de los registros
246)Los registros de auditoría se analizarán en respuesta a las alertas basadas en irregularidades e incidentes dentro de los sistemas de la CA y, además, periódicamente cada año.
247)El tratamiento de los registros de auditoría consistirá en analizarlos y en documentar el motivo de todos los eventos significativos en un resumen del registro de auditoría. Los análisis del registro de auditoría incluirán una verificación de que el registro no ha sido manipulado, una inspección de todas las entradas del registro y una investigación de cualquier alerta o irregularidad en los registros. Se documentarán las medidas adoptadas sobre la base de los análisis de los registros de auditoría.
248)El registro de auditoría se archiva al menos una vez por semana. Un administrador lo almacenará manualmente si el espacio de disco libre para el registro de auditoría está por debajo de la cantidad prevista de datos del registro de auditoría producidos esa semana.
5.4.3.Período de conservación de los registros de auditoría
249)Los registros relativos a los ciclos de vida de los certificados se conservan durante al menos cinco años a partir de la fecha de expiración del certificado correspondiente.
5.4.4.Protección de los registros de auditoría
250)La integridad y la confidencialidad del registro de auditoría están garantizadas por un mecanismo de control del acceso basado en roles. Los registros internos de auditoría solo pueden ser consultados por los administradores; los usuarios que cuenten con la autorización adecuada también pueden acceder a los registros de auditoría relacionados con el ciclo de vida de los certificados, a través de una página web y con el identificador de usuario. El acceso debe concederse con autenticación multiusuario (al menos dos usuarios) y de al menos dos niveles. Debe garantizarse técnicamente que los usuarios no puedan acceder a sus propios ficheros de registro.
251)Cada anotación en el registro se firmará utilizando el material de claves procedente del HSM.
252)Los registros de eventos que contienen información que puede conducir a la identificación personal, como un vehículo privado, están cifrados de forma que solo las personas autorizadas pueden leerlos.
253)Los eventos están registrados de tal manera que no se pueden borrar o destruir fácilmente (salvo en caso de transferencia a soportes a largo plazo) dentro del período durante el cual los registros deben conservarse.
254)Los registros de eventos están protegidos de tal manera que siguen siendo legibles mientras dura su período de almacenamiento.
5.4.5.Procedimientos de respaldo de los registros de auditoría
255)Las copias de seguridad de los registros y de los resúmenes de auditoría se efectúan a través de mecanismos de copia de seguridad de empresa, bajo el control de roles de confianza autorizados, por separado del componente que los haya generado. Las copias de seguridad de los registros de auditoría están protegidas con el mismo nivel de confianza que se aplica a los registros originales.
5.4.6.Sistema de recogida de información de auditoría (interno o externo)
256)El equipo de los elementos del modelo de confianza STI-C activará los procesos de auditoría cuando se inicie el sistema y los desactivará únicamente cuando se apague el sistema. Si los procesos de auditoría no están disponibles, el elemento del modelo de confianza STI-C suspenderá su funcionamiento.
257)Al final de cada período de operación y en la renovación de claves de los certificados, la situación colectiva de los equipos debería comunicarse al gestor de operaciones y al órgano de gobierno de las operaciones del elemento respectivo de la PKI.
5.4.7.Notificación al sujeto causa del evento
258)Cuando el sistema de recogida de información de auditoría registra un evento, garantiza que este esté vinculado a un rol de confianza.
5.4.8.Análisis de vulnerabilidades
259)El rol encargado de realizar la auditoría y los roles encargados de la operación del sistema PKI en los elementos del modelo de confianza STI-C explican todos los eventos significativos en un resumen del registro de auditoría. En estos análisis se verifica que el registro no haya sido manipulado y que no exista discontinuidad u otra pérdida de datos de auditoría y, a continuación, se inspeccionan brevemente todas las entradas de los registros, con una investigación más exhaustiva de las eventuales alertas o irregularidades en los registros. Las medidas adoptadas como resultado de estos análisis se documentan.
260)Los elementos del modelo de confianza STI-C:
aplicarán controles organizativos o técnicos de detección y prevención bajo el control de los elementos del modelo de confianza STI-C, a fin de proteger los sistemas PKI contra virus y softwares maliciosos;
documentarán y seguirán un proceso de corrección de las vulnerabilidades que aborde la identificación, el análisis, la respuesta y la resolución de las vulnerabilidades;
llevarán a cabo un escaneo de vulnerabilidades o se someterán a él:
después de cualquier cambio en el sistema o en la red que los elementos del modelo de confianza STI-C consideren significativo para los componentes PKI; y
al menos una vez al mes, en las direcciones IP públicas y privadas identificadas por la CA y el CPOC como sistemas de la PKI;
se someterán a una prueba de penetración en los sistemas de la PKI, como mínimo una vez al año y después de las mejoras o modificaciones de la infraestructura o de la aplicación que los elementos del modelo de confianza STI-C consideren significativas para el componente de la PKI de la CA;
en el caso de los sistemas en línea, registrarán evidencias de que cada escaneo de vulnerabilidades y cada prueba de penetración han sido realizados por una persona o entidad (o un grupo colectivo de ellas) con las capacidades, las herramientas, la competencia, el código ético y la independencia necesarios para realizar escaneos de vulnerabilidades o pruebas de penetración fiables;
buscarán y solucionarán las vulnerabilidades, en consonancia con las políticas de ciberseguridad y la metodología de reducción del riesgo de la empresa.
5.5.Archivo de registros
5.5.1.Tipos de registros archivados
261)Los elementos del modelo de confianza STI-C conservarán registros lo suficientemente detallados como para establecer la validez de una firma y el funcionamiento adecuado de la PKI. Como mínimo, se archivarán los siguientes registros de eventos PKI (si procede):
registro de acceso a las instalaciones físicas de los elementos del modelo de confianza STI-C (un año como mínimo);
registro de la gestión de los roles de confianza de los elementos del modelo de confianza STI-C (diez años como mínimo);
registro de acceso TI de los elementos del modelo de confianza STI-C (cinco años como mínimo);
registro de creación, uso y destrucción de claves de CA (cinco años como mínimo) (no aplicable al TLM y el CPOC);
registro de creación, uso y destrucción de certificados (dos años como mínimo);
registro de solicitudes de CPA (dos años como mínimo);
registro de la gestión de los datos de activación de los elementos del modelo de confianza STI-C (cinco años como mínimo);
registro de TI y de red de los elementos del modelo de confianza STI-C (cinco años como mínimo);
documentación PKI de los elementos del modelo de confianza STI-C (cinco años como mínimo);
informe de los incidentes de seguridad e informe de auditoría de los elementos del modelo de confianza STI-C (diez años como mínimo);
equipo, software y configuración del sistema (cinco años como mínimo).
262)Los elementos del modelo de confianza STI-C conservarán la siguiente documentación relativa a las solicitudes de certificado y su verificación, y todos los certificados de TLM, CA raíz y CA, junto con su CRL, durante al menos siete años después de que todo certificado basado en dicha documentación deje de ser válido:
documentación de la auditoría de la PKI conservada por los elementos del modelo de confianza STI-C;
documentación de la CPS conservada por los elementos del modelo de confianza STI-C;
contrato entre la CPA y otras entidades conservado por los elementos del modelo de confianza STI-C;
certificados (u otra información sobre revocaciones) conservados por la CA y el TLM;
registros de solicitudes de certificados en el sistema de la CA raíz (no aplicable al TLM);
otros datos o aplicaciones que permitan verificar el contenido de los archivos;
todo el trabajo relacionado con los elementos del modelo de confianza STI-C y los auditores de conformidad, o procedente de ellos.
263)La entidad CA conservará toda la documentación relativa a las solicitudes de certificado y su verificación, y todos sus certificados y su revocación, durante al menos siete años después de que todo certificado basado en dicha documentación deje de ser válido.
5.5.2.Período de conservación del archivo
264)Sin perjuicio de los reglamentos que requieran un período de archivo más largo, los elementos del modelo de confianza STI-C conservarán todos los registros durante al menos cinco años tras la expiración del certificado correspondiente.
5.5.3.Protección del archivo
265)Los elementos del modelo de confianza STI-C almacenarán el archivo de los registros en una instalación de almacenamiento segura, protegida y separada de los equipos de la CA, con controles de seguridad físicos y de procedimiento equivalentes a los de la PKI o mejores.
266)El archivo se protegerá contra la consulta, modificación, supresión u otra manipulación no autorizada mediante el almacenamiento en un sistema fiable.
267)Los soportes que contengan los datos del archivo y las aplicaciones necesarias para su tratamiento se mantendrán de manera que pueda accederse a ellos durante el período establecido en la presente CP.
5.5.4.Archivo y almacenamiento del sistema
268)Los elementos del modelo de confianza STI-C realizarán copias de seguridad acumulativas de los archivos del sistema de esta información diariamente, y copias de seguridad completas semanalmente. Las copias de los registros en papel se conservarán en un lugar seguro fuera de las instalaciones.
5.5.5.Requisitos relativos al sellado de tiempo de los registros
269)Los elementos del modelo de confianza STI-C que gestionen una base de datos de revocaciones garantizarán que los registros contengan información sobre la fecha y la hora en que se crean los registros de revocación. La integridad de dicha información se conseguirá con soluciones criptográficas.
5.5.6.Sistema de compilación de archivos (interno o externo)
270)El sistema de compilación de archivos es interno.
5.5.7.Procedimientos para obtener y verificar la información de los archivos
271)Todos los elementos del modelo de confianza STI-C permitirán solamente a las personas de confianza autorizadas acceder al archivo. Las CA y las CA raíz describirán en la CPS los procedimientos para crear, verificar, empaquetar, transmitir y almacenar la información de los archivos.
272)Los equipos de la CA raíz y la CA verificarán la integridad de la información antes de que se restituya.
5.6.Cambio de claves de los elementos del modelo de confianza STI-C
273)Los siguientes elementos del modelo de confianza STI-C tienen requisitos específicos para su cambio de claves: certificados de TLM, CA raíz y EA/AA
5.6.1.TLM
274)El TLM suprimirá su clave privada al expirar el correspondiente certificado. Generará un nuevo par de claves y el correspondiente certificado de TLM antes de la desactivación de la clave privada válida vigente. Velará por que el nuevo certificado (de enlace) se incluya en la ECTL a tiempo para ser distribuido a todas las estaciones STI-C antes de que adquiera validez. El certificado de enlace y el nuevo certificado autofirmado se transfieren al CPOC.
5.6.2.CA raíz
275)La CA raíz desactivará y suprimirá la clave privada vigente (incluidas las claves de copia de seguridad), de modo que no emitirá certificados de EA/AA con una validez que se extienda más allá de la validez del certificado de CA raíz.
276)La CA raíz generará un nuevo par de claves y un certificado correspondiente de CA raíz y de enlace antes de la desactivación de la clave privada vigente (incluidas las claves de copia de seguridad) y los remitirá al TLM para su introducción en la ECTL. El período de validez del nuevo certificado de CA raíz comenzará a partir de la desactivación prevista de la clave privada vigente. La CA raíz velará por que el nuevo certificado se incluya en la ECTL a tiempo para ser distribuido a todas las estaciones STI-C antes de que adquiera validez.
277)La CA raíz activará la nueva clave privada cuando el correspondiente certificado de CA raíz adquiera validez.
5.6.3.Certificado de EA/AA
278)La EA/AA desactivará la clave privada vigente, de modo que no emita EC/AT con una validez que se extienda más allá de la validez del certificado de EA/AA.
279)La EA/AA generará un nuevo par de claves y solicitará el correspondiente certificado EA/AA antes de la desactivación de la clave privada vigente. El período de validez del nuevo certificado EA/AA comenzará a partir de la desactivación prevista de la clave privada vigente. La EA/AA velará por que el nuevo certificado pueda publicarse a tiempo para ser distribuido a todas las estaciones STI-C antes de que adquiera validez.
280)La EA/AA activará la nueva clave privada cuando el correspondiente certificado de EA/AA adquiera validez.
5.6.4.Auditor
Ninguna disposición.
5.7.Recuperación en caso de comprometimiento y catástrofe
5.7.1.Tratamiento de incidentes y comprometimientos
281)Los elementos del modelo de confianza STI-C supervisarán sus equipos de manera continua, a fin de detectar posibles intentos de piratería u otras formas de comprometimiento. Si estos se producen, investigarán para determinar la naturaleza y el grado del daño.
282)Si el personal responsable de la gestión de la CA raíz o el TLM detecta un posible intento de piratería u otra forma de comprometimiento, investigará para determinar la naturaleza y el grado del daño. Si se produce un comprometimiento de la clave privada, se revocará el certificado de CA raíz. Los expertos en seguridad de las TI de la CPA evaluarán el alcance de los posibles daños para determinar si la PKI debe ser reconstruida, si solo deben revocarse algunos certificados o si la PKI se ha visto comprometida. Además, la CPA determina qué servicios deben mantenerse (información de revocación y de situación de certificados) y cómo, de conformidad con el plan de continuidad de las actividades de la CPA.
283)Los incidentes, los comprometimientos y la continuidad de las actividades están recogidos en la CPS, que también pueden basarse en otros recursos y planes empresariales para su implementación.
284)Si el personal responsable de la gestión de la EA / la AA / el CPOC detecta un posible intento de piratería u otra forma de comprometimiento, investigará para determinar la naturaleza y el grado del daño. El personal responsable de la gestión de la entidad CA o CPOC evaluará el alcance de los posibles daños para determinar si el componente de la PKI debe ser reconstruido, si solo deben revocarse algunos certificados o si el componente de la PKI se ha visto comprometido. Además, la entidad CA subordinada determina qué servicios deben mantenerse y cómo, de acuerdo con el plan de continuidad de las actividades de la entidad CA subordinada. En caso de que se comprometa un componente de la PKI, la entidad CA alertará a su propia CA raíz y al TLM a través del CPOC.
285)Los incidentes, comprometimientos y continuidad de las actividades están recogidos en la CPS de la CA raíz o del TLM, o en otros documentos pertinentes en el caso de la CPOC, que también puede basarse en otros recursos y planes empresariales para su implementación.
286)La CA raíz y la CA alertarán, con información precisa sobre las consecuencias del incidente, a cada representante de los Estados miembros y cada CA raíz con los que tengan un acuerdo en el contexto de los STI-C, a fin de que puedan activar su propio plan de gestión de incidentes.
5.7.2.Corrupción de recursos informáticos, software o datos
287)Si se descubre una catástrofe que impida el correcto funcionamiento de un elemento del modelo de confianza STI-C, dicho elemento suspenderá su funcionamiento e investigará si la clave privada se ha visto comprometida (excepto el CPOC). El hardware defectuoso se sustituirá lo antes posible y se aplicarán los procedimientos descritos en los epígrafes 5.7.3 y 5.7.4.
288)La corrupción de recursos informáticos, software o datos se comunicará a la CA raíz en un plazo de veinticuatro horas cuando se trate de los niveles más elevados de riesgo. Todos los demás eventos deben incluirse en el informe periódico de la CA raíz, las EA y las AA.
5.7.3.Procedimientos en caso de comprometimiento de claves privadas de entidades
289)Si la clave privada de una CA raíz se ve comprometida, se pierde, se destruye o se sospecha que está comprometida, la CA raíz:
suspenderá su funcionamiento;
iniciará el plan de recuperación y de migración en caso de catástrofe;
revocará su certificado de CA raíz;
investigará el «problema clave» que generó el comprometimiento y lo notificará a la CPA, que revocará el certificado de CA raíz a través del TLM (véase el epígrafe7);
alertará a todos los suscriptores con los que tenga un acuerdo.
290)Si la clave de una EA/AA se ve comprometida, se pierde, se destruye o se sospecha que está comprometida, la EA/AA:
suspenderá su funcionamiento;
revocará su propio certificado;
investigará el «problema clave» e informará a la CA raíz;
alertará a los suscriptores con los que exista un acuerdo.
291)Si la clave EC o AT de una estación STI-C se ve comprometida, se pierde, se destruye o se sospecha que está comprometida, la EA/AA a la que está suscrita dicha estación:
revocará la EC del STI afectado;
investigará el «problema clave» e informará a la CA raíz;
alertará a los suscriptores con los que tenga un acuerdo.
292)En caso de que alguno de los algoritmos o parámetros asociados utilizados por la CA raíz o la CA o las estaciones STI-C resulte insuficiente para su uso restante previsto, la CPA (con una recomendación de expertos en criptografía) informará a la entidad CA raíz con la que tenga un acuerdo y modificará los algoritmos utilizados. (Para más detalles, véanse el epígrafe 6 y las CPS de la CA raíz y la CA subordinada).
5.7.4.Capacidad de continuidad de las actividades después de una catástrofe
293)Los elementos del modelo de confianza STI-C que utilicen instalaciones seguras para las operaciones de la CA deberán desarrollar, probar, mantener y aplicar un plan de recuperación en caso de catástrofe diseñado para mitigar los efectos de cualquier catástrofe natural o antropogénica. Dichos planes abordarán el restablecimiento de los servicios de los sistemas de información y las principales funciones empresariales.
294)Tras un incidente de cierto nivel de riesgo, la CA comprometida debe volver a ser auditada por un auditor de la PKI acreditado (véase el epígrafe 8).
295)Cuando la CA comprometida no pueda seguir funcionando (por ejemplo, a raíz de un incidente grave), debe elaborarse un plan de migración para la transferencia de sus funciones a otra CA raíz. Como mínimo la CA raíz de la UE estará disponible para apoyar el plan de migración. La CA comprometida cesará sus funciones.
296)Las CA raíz incluirán en la CPS el plan de recuperación en caso de catástrofe y el plan de migración.
5.8.Cese y transferencia
5.8.1.TLM
297)El TLM no cesará su actividad, pero una entidad que gestione el TLM podrá hacerse cargo de otra entidad.
298)En caso de cambio de la entidad gestora:
esta solicitará a la CPA la aprobación de un cambio en la gestión del TLM de la antigua entidad a la nueva entidad;
la CPA aprobará el cambio de gestión del TLM;
todos los registros de auditoría y registros archivados se transferirán de la antigua entidad de gestión a la nueva entidad.
5.8.2.CA raíz
299)La CA raíz no cesará ni comenzará su funcionamiento sin establecer un plan de migración (expuesto en la CPS correspondiente) que garantice el funcionamiento ininterrumpido para todos los suscriptores.
300)En caso de cese del servicio de la CA raíz, esta:
informará a la CPA;
informará al TLM para que pueda suprimir de la ECTL el certificado de CA raíz;
revocará la CA raíz correspondiente emitiendo una CRL en la que se incluya a sí misma;
avisará a las CA raíz con las que tenga un acuerdo para la renovación de los certificados de EA/AA;
destruirá la clave privada de CA raíz;
comunicará la última información sobre la situación de revocación (CRL firmada por la CA raíz) a la parte confiante, indicando claramente que es la última información sobre revocación;
archivará todos los registros de auditoría y otros registros antes del cese de la PKI;
transferirá los registros archivados a una autoridad apropiada.
301)El TLM suprimirá de la ECTL el certificado correspondiente de la CA raíz.
5.8.3.EA/AA
302)En caso de cese del servicio de EA/AA, la entidad EA/AA lo notifica antes del cese. Las EA y AA no cesarán ni comenzarán su funcionamiento sin establecer un plan de migración (expuesto en la CPS correspondiente) que garantice el funcionamiento ininterrumpido para todos los suscriptores. La EA/AA:
informará a la CA raíz mediante carta certificada;
destruirá la clave privada de CA;
transferirá su base de datos a la entidad designada por la CA raíz;
dejará de emitir certificados;
durante la transferencia de su base de datos y hasta que esta sea plenamente operativa en una nueva entidad, mantendrá la capacidad de autorizar solicitudes de la autoridad responsable de la privacidad;
en caso de que se haya comprometido una CA subordinada, la CA raíz revocará la CA subordinada y emitirá una nueva CRL con una lista de las CA subordinadas revocadas;
archivará los registros de auditoría y otros registros antes del cese de la PKI;
transferirá sus registros archivados a una entidad designada por la CA raíz.
303)En caso de cese de los servicios de la CA, esta será responsable de mantener todos los registros pertinentes relativos a las necesidades de los componentes de la CA y la PKI.
6.Controles técnicos de seguridad
6.1.Generación e instalación de pares de claves
6.1.1.TLM, CA raíz, EA y AA
304)El proceso de generación de pares de claves cumplirá los siguientes requisitos:
cada participante podrá generar sus propios pares de claves con arreglo a lo dispuesto en los epígrafes 6.1.4 y 6.1.5;
el proceso de derivar claves simétricas de cifrado y una clave MAC para las solicitudes de certificados (ECIES) se llevará a cabo según lo dispuesto en [1] y [5];
el proceso de generación de claves utilizará los algoritmos y longitudes de clave que se describen en los epígrafes 6.1.4.1 y 6.1.4.2;
el proceso de generación de claves estará sujeto a los requisitos de un «almacenamiento seguro de claves privadas» (véase el epígrafe 6.1.5);
las CA raíz y sus suscriptores (CA subordinadas) velarán por que la integridad y la autenticidad de sus claves públicas y los parámetros conexos se mantengan durante la distribución a las entidades CA subordinadas registradas.
6.1.2.EE: estación STI-C móvil
305)Cada estación STI-C móvil generará sus propios pares de claves con arreglo a lo dispuesto en los epígrafes 6.1.4 y 6.1.5.
306)El proceso de derivar claves simétricas de cifrado y una clave MAC para las solicitudes de certificados (ECIES) se llevará a cabo de conformidad con [1] y [5].
307)El proceso de generación de claves utilizará los algoritmos y longitudes de clave que se describen en los epígrafes 6.1.4.1 y 6.1.4.2.
308)El proceso de generación de claves estará sujeto a los requisitos de un «almacenamiento seguro de claves privadas» (véase el epígrafe 6.1.5);
6.1.3.EE: estación STI-C fija
309)Cada estación STI-C fija generará su propio par de claves con arreglo a lo dispuesto en los epígrafes 6.1.4 y 6.1.5.
310)El proceso de generación de claves utilizará los algoritmos y longitudes de clave que se describen en los epígrafes 6.1.4.1 y 6.1.4.2.
311)El proceso de generación de claves estará sujeto a los requisitos de un «almacenamiento seguro de claves privadas» (véase el epígrafe 6.1.5);
6.1.4.Requisitos criptográficos
312)Todos los participantes de la PKI deberán cumplir los requisitos criptográficos establecidos en los epígrafes siguientes por lo que se refiere al algoritmo de firma, la longitud de la clave, el generador de números aleatorios y los certificados de enlace.
6.1.4.1.Longitud de los algoritmos y de las claves: algoritmos de firma
313)Todos los participantes de la PKI (TLM, CA raíz, EA, AA y estaciones STI-C) serán capaces de generar pares de claves y utilizar la clave privada para firmar las operaciones con algoritmos seleccionados a más tardar dos años después de la entrada en vigor del presente Reglamento, de conformidad con el cuadro 4.
314)Todos los participantes de la PKI que deban comprobar la integridad de la ECTL, los certificados o los mensajes firmados de conformidad con su rol, como se define en el epígrafe 1.3.6, reconocerán los algoritmos correspondientes enumerados en el cuadro 5 para verificación. En particular, las estaciones STI-C podrán comprobar la integridad de la ECTL.
|
TLM
|
CA raíz
|
EA
|
AA
|
Estación STI-C
|
ECDSA_nistP256_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
ECDSA_brainpoolP256r1_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
-
|
-
|
X indica reconocimiento obligatorio
|
Cuadro 4: Generación de pares de claves y uso de la clave privada para operaciones de firma
|
TLM
|
CA raíz
|
EA
|
AA
|
Estación STI-C
|
ECDSA_nistP256_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
ECDSA_brainpoolP256r1_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
X
|
X
|
X indica reconocimiento obligatorio
|
Cuadro 5: Resumen de la verificación
315)Si la CPA así lo decide debido a la detección de nuevas deficiencias criptográficas, todas las estaciones STI-C podrán cambiar a uno de los dos algoritmos (ECDSA_nistP256_with_SCS 256 o ECDSA_brainpoolP256_wit_SHA 256) lo antes posible. Los algoritmos que se utilicen se especificarán en la CPS de la CA que emita el certificado de la clave pública correspondiente, de conformidad con la presente CP.
6.1.4.2.Longitud de los algoritmos y de las claves: algoritmos de cifrado para la inscripción y la autorización
316)Todos los participantes de la PKI (EA, AA y estaciones STI-C) podrán usar claves públicas para cifrar solicitudes y respuestas de inscripción y autorización con algoritmos seleccionados a más tardar dos años después de la entrada en vigor del presente Reglamento, de conformidad con el cuadro 6. Los algoritmos que se utilicen se especificarán en la CPS de la CA que emita el certificado de la clave pública correspondiente, de conformidad con la presente CP.
317)Los algoritmos mencionados en el cuadro 6 indican la longitud de la clave y del algoritmo hash, y se aplicarán de conformidad con [5].
|
TLM
|
CA raíz
|
EA
|
AA
|
Estación STI-C
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X indica reconocimiento obligatorio
|
Cuadro 6: Uso de claves públicas para el cifrado de solicitudes y respuestas de inscripción y autorización
318)Todos los participantes de la PKI (EA, AA y estaciones STI-C) podrán generar claves públicas y usar la clave privada para descifrar solicitudes y respuestas de inscripción y autorización con algoritmos seleccionados a más tardar dos años después de la entrada en vigor del presente Reglamento, de conformidad con el cuadro 7:
|
TLM
|
CA raíz
|
EA
|
AA
|
Estación STI-C
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X indica reconocimiento obligatorio
|
Cuadro 7: Generación de pares de claves y uso de la clave privada para descifrar solicitudes y respuestas de inscripción y autorización
6.1.4.3.Criptoagilidad
319)Los requisitos sobre longitudes de claves y algoritmos deben modificarse a lo largo del tiempo para mantener un nivel adecuado de seguridad. La CPA supervisará la necesidad de tales cambios a la luz de las vulnerabilidades reales y de la criptografía más avanzada. Elaborará, aprobará y publicará una actualización de la presente política de certificación si decide que los algoritmos criptográficos deberían actualizarse. En caso de que una nueva versión de la presente CP señale un cambio de la longitud del algoritmo o de la clave, la CPA adoptará una estrategia de migración que incluya períodos de transición durante los que deberán aceptarse las longitudes anteriores de los logaritmos y claves.
320)A fin de permitir y facilitar la transferencia a nuevas longitudes de algoritmos o de claves, se recomienda que todos los participantes de la PKI instalen hardware o software capaces de cambiar longitudes de claves y algoritmos.
321)Las modificaciones de los certificados raíz y de TLM se aceptarán y ejecutarán con la ayuda de los certificados de enlace (véase el epígrafe 4.6) que se utilizan para cubrir el período de transición entre los antiguos certificados raíz y los nuevos («migración del modelo de confianza»).
6.1.5.Almacenamiento seguro de claves privadas
En este epígrafe se describen los requisitos para el almacenamiento seguro y la generación de pares de claves y números aleatorios para las CA y las entidades finales. Estos requisitos se definen y describen para los módulos criptográficos en los subepígrafes siguientes.
6.1.5.1.Nivel de CA raíz, CA subordinada y TLM
322)Se utilizará un módulo criptográfico para:
generar, utilizar, administrar y almacenar claves privadas;
generar y usar números aleatorios (la evaluación de la función de generación de números aleatorios formará parte de la evaluación y certificación de la seguridad);
crear copias de seguridad de las claves privadas según lo dispuesto en el epígrafe 6.1.6;
suprimir claves privadas.
El módulo criptográfico se certificará con uno de los siguientes perfiles de protección (PP), con nivel de garantía EAL-4 o superior:
PP para HSM:
CEN EN 419 221-2: Protection profiles for TSP cryptographic modules – Part 2:Cryptographic module for CSP signing operations with backup («Perfiles de protección para módulos criptográficos TSP. Parte 2: Módulo criptográfico para las operaciones de firma del CSP con copia de seguridad»);
CEN EN 419 221-4: Protection profiles for TSP cryptographic modules – Part 4: Cryptographic module for CSP signing operations without backup («Perfiles de protección para módulos criptográficos TSP. Parte 4: Módulo criptográfico para las operaciones de firma del CSP sin copia de seguridad»);
CEN EN 419 221-5: Protection profiles for TSP cryptographic modules – Part 5: Cryptographic module for trust services («Perfiles de protección para módulos criptográficos TSP. Parte 5: Módulo criptográfico para servicios de confianza»);
PP para tarjetas inteligentes:
CEN EN 419 211-2: Protection profiles for secure signature creation device – Part 2: Device with key generation («Perfiles de protección para dispositivos seguros de creación de firma. Parte 2: Dispositivo con generación de claves»);
CEN EN 419 211-3: Protection profiles for secure signature creation device — Part 3: Device with key import («Perfiles de protección para dispositivos seguros de creación de firma. Parte 3: Dispositivo con importación de claves»);
El acceso manual al módulo criptográfico requerirá la autenticación de doble factor por parte del administrador. Además, esto requerirá la participación de dos personas autorizadas.
La aplicación de un módulo criptográfico garantizará que las claves no sean accesibles fuera de dicho módulo. El módulo criptográfico incluirá un mecanismo de control del acceso para evitar el uso no autorizado de claves privadas.
6.1.5.2.Entidad final
323)Se utilizará un módulo criptográfico para las EE a fin de:
generar, utilizar, administrar y almacenar claves privadas;
generar y usar números aleatorios (la evaluación de la función de generación de números aleatorios formará parte de la evaluación y certificación de la seguridad);
suprimir claves privadas de forma segura.
324)El módulo criptográfico se protegerá contra la retirada, sustitución y modificación no autorizadas. Todos los PP y documentos conexos aplicables a la certificación de seguridad del módulo criptográfico serán evaluados, validados y certificados conforme a la norma ISO 15408, aplicando el Acuerdo sobre el reconocimiento mutuo de certificados de evaluación de la seguridad de las tecnologías de la información del Grupo de Altos Funcionarios sobre Seguridad de los Sistemas de Información (SOG-IS), o un régimen europeo equivalente de certificación de la ciberseguridad en el marco europeo de ciberseguridad pertinente.
325)Dada la importancia de mantener el nivel de seguridad más elevado posible, los certificados de seguridad para el módulo criptográfico serán emitidos conforme al sistema de certificación de criterios comunes (ISO 15408) por un organismo de evaluación de la conformidad reconocido por el comité de gestión en el marco del Acuerdo SOG-IS, o bien serán emitidos por un organismo de evaluación de la conformidad acreditado por una autoridad nacional de certificación de la ciberseguridad de un Estado miembro. Dicho organismo de evaluación de la conformidad proporcionará, como mínimo, condiciones de evaluación de la seguridad equivalentes a las previstas en el Acuerdo sobre el reconocimiento mutuo SOG-IS.
Nota: se protegerá el vínculo entre el módulo criptográfico y la estación STI-C.
6.1.6.Copia de seguridad de claves privadas
326)La generación, el almacenamiento y la utilización de copias de seguridad de las claves privadas cumplirán, como mínimo, los requisitos del nivel de seguridad requerido para las claves originales.
327)Las copias de seguridad de las claves privadas serán realizadas por las CA raíz, las EA y las AA.
328)No se realizarán copias de seguridad de las claves privadas en el caso de las EC y los AT.
6.1.7.Destrucción de claves privadas
329)Las CA raíz, AE, AA, así como las estaciones STI-C móviles y fijas, destruirán su clave privada y las copias de seguridad correspondientes si se han generado e instalado correctamente un nuevo par de claves y el certificado correspondiente, y si el período de solapamiento (si existe, solo en el caso de la CA) ha pasado. La clave privada será destruida utilizando el mecanismo ofrecido por el módulo criptográfico utilizado para el almacenamiento de claves, o según lo descrito en el PP correspondiente, como se indica en el epígrafe 6.1.5.2.
6.2.Datos de activación
330)Los datos de activación se refieren a los factores de autenticación necesarios para utilizar módulos criptográficos a fin de evitar accesos no autorizados. El uso de los datos de activación de un dispositivo criptográfico de la CA requerirá la intervención de dos personas autorizadas.
6.3.Controles de seguridad informática
331)Los controles de seguridad informática de la CA se diseñarán de conformidad con el nivel de seguridad elevado cumpliendo los requisitos de la norma ISO/IEC 27002.
6.4.Controles técnicos del ciclo de vida
332)Los controles técnicos de la CA abarcarán todo su ciclo de vida, lo que incluye, en particular, los requisitos del epígrafe 6.1.4.3 («Criptoagilidad»).
6.5.Controles de seguridad de las redes
333)Las redes de las CA (CA raíz, EA y AA) se reforzarán contra los ataques en consonancia con los requisitos y las directrices de aplicación de las normas ISO/IEC 27001 e ISO/IEC 27002.
334)La disponibilidad de las redes de CA se diseñará teniendo en cuenta el tráfico previsto.
7.Perfiles de los certificados, CRL y CTL
7.1.Perfil de certificado
335)Los perfiles de certificación definidos en [5] se usarán para el TLM, los certificados raíz, los certificados EA, los certificados AA, los AT y las EC. Las EA estatales nacionales pueden utilizar otros perfiles de certificados para las EC.
336)Los certificados de CA raíz, EA y AA indicarán los permisos para los que estas CA (raíz, EA y AA) están autorizadas a emitir certificados.
337)Sobre la base de [5]:
cada CA raíz hará uso de su propia clave privada de firma para emitir las CRL;
el TLM hará uso de su propia clave privada de firma para emitir la ECTL.
7.2.Validez del certificado
338)Todos los perfiles de los certificados de los STI-C incluirán una fecha de emisión y expiración, que representa el período de validez del certificado. En cada nivel PKI, los certificados se generarán con antelación suficiente antes de la expiración.
339)El período de validez de los certificados de CA y EC incluirá un período de solapamiento. Los certificados del TLM y la CA raíz se emitirán e incluirán en la ECTL un máximo de tres meses y un mínimo de un mes antes de que empiece su validez, basándose en la fecha de inicio que figura en el certificado. Se requiere esta fase de precarga para distribuir los certificados de forma segura a todas las partes confiantes correspondientes, de conformidad con el epígrafe 2.2. Esto garantiza que, desde el inicio del período de solapamiento, todas las partes confiantes puedan ya verificar los mensajes emitidos con un nuevo certificado.
340)Al inicio del período de solapamiento, los sucesivos certificados de CA, EC y AT serán emitidos (si procede), distribuidos a las partes confiantes correspondientes e instalados por dichas partes. Durante el período de solapamiento, el certificado vigente se utilizará únicamente para verificación.
341)Dado que los períodos de validez enumerados en el cuadro 8 no deben superar el período de validez del certificado superior, se aplican las siguientes restricciones:
maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA);
maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);
maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
342)La validez de los certificados de enlace (raíz y de TLM) comienza con el uso de la clave privada correspondiente y termina al acabar el período máximo de validez de la CA raíz o el TLM.
343)El cuadro 8 muestra el período máximo de validez de los certificados STI-C (para los períodos de validez de los AT, véase el epígrafe 7.2.1).
Entidad
|
Período máximo de utilización de la clave privada
|
Período máximo de validez
|
CA raíz
|
3 años
|
8 años
|
EA
|
2 años
|
5 años
|
AA
|
4 años
|
5 años
|
EC
|
3 años
|
3 años
|
TLM
|
3 años
|
4 años
|
Cuadro 8: Períodos de validez de los certificados en el modelo de confianza STI-C
7.2.1.Certificados de pseudónimos
344)En este contexto, los pseudónimos son aplicados por los AT. Por consiguiente, este epígrafe se refiere a los AT en lugar de a los pseudónimos.
345)Los requisitos establecidos en el presente epígrafe solo se aplican a los AT de las estaciones STI-C móviles que envíen CAM y DENM, cuando sea aplicable el riesgo de privacidad de la ubicación. No se aplican requisitos específicos sobre certificados de AT a los AT para estaciones STI-C fijas y móviles utilizadas para funciones especiales, en las que la privacidad de la ubicación no es aplicable (por ejemplo, vehículos marcados de servicios de emergencia y policiales).
346)Se entenderá por:
«período de validez de los AT»: período durante el cual un AT es válido, es decir, el período comprendido entre la fecha de inicio y la fecha de expiración;
«período de precarga de los AT»: la precarga es la posibilidad de que las estaciones STI-C obtengan AT antes del comienzo del período de validez. El período de precarga es el período máximo de tiempo permitido desde la solicitud de los AT hasta la última fecha de final de validez de los AT solicitados;
«período de uso de los AT»: período durante el cual un AT se utiliza efectivamente para firmar CAM/DENM;
«número máximo de AT paralelos»: el número de AT de entre los que una estación STI-C puede elegir en un momento dado al firmar un CAM/DENM, es decir, el número de distintos AT emitidos a una estación STI-C que son válidos al mismo tiempo.
347)Deberán cumplirse los siguientes requisitos:
el período de precarga de los AT no será superior a tres meses;
el período de validez de los AT no será superior a una semana;
el número máximo de AT paralelos no será superior a 100 por estación STI-C;
el período de uso de un AT depende de la estrategia de cambio de AT y del tiempo que un vehículo esté en funcionamiento, pero se ve limitado por el número máximo de AT paralelos y el período de validez. Más concretamente, el período medio de uso para una estación STI-C es, al menos, el tiempo de funcionamiento del vehículo durante un período de validez dividido por el número máximo de AT paralelos.
7.2.2.Tiques de autorización para estaciones STI-C fijas
348)Se aplican las definiciones del epígrafe 7.2.1 y los requisitos siguientes:
el período de precarga de los AT no será superior a tres meses;
el número máximo de AT paralelos no será superior a dos por estación STI-C.
7.3.Revocación de certificados
7.3.1.Revocación de certificados de CA, EA y AA
Los certificados de CA raíz, EA y AA serán revocables. Los certificados revocados de las CA raíz, EA y AA se publicarán en una CRL tan pronto como sea posible y sin demoras indebidas. Esta CRL será firmada por su CA raíz correspondiente y utilizará el perfil descrito en el epígrafe 7.4. Para la revocación de los certificados de CA raíz, la CA raíz correspondiente emite una CRL en la que se incluye a sí misma. Además, en caso de un comprometimiento de la seguridad, se aplica el epígrafe 5.7.3. Asimismo, el TLM suprimirá de la lista de confianza las CA raíz revocadas y emitirá una nueva lista de confianza. Los certificados caducados se retirarán de la CRL y de la lista de confianza correspondientes.
349)Los certificados se revocan cuando:
las CA raíz tienen motivos para creer o sospechar firmemente que la clave privada correspondiente se ha visto comprometida;
se notifica a las CA raíz que se ha puesto fin al contrato con el suscriptor;
la información (como el nombre y las asociaciones entre la CA y el sujeto) contenida en el certificado es incorrecta o ha cambiado;
se produce un incidente de seguridad que afecta al propietario del certificado;
una auditoría (véase el epígrafe 8) conduce a un resultado negativo.
350)El suscriptor deberá informar inmediatamente a la CA cuando se produzca o se sospeche que se ha producido un comprometimiento de su clave privada. Debe garantizarse que solo las solicitudes autenticadas den lugar a la revocación de los certificados.
7.3.2.Revocación de las credenciales de inscripción
351)La revocación de las credenciales de inscripción puede ser iniciada por el suscriptor de la estación STI-C (flujo 34) y se ejecutará mediante una lista negra interna en una base de datos de revocación con un sello de tiempo, que cada EA genera y mantiene. La lista negra nunca se publica y será confidencial y utilizada únicamente por la EA correspondiente para verificar la validez de las EC correspondientes en el contexto de las solicitudes de AT y de nuevas EC.
7.3.3.Revocación de los tiques de autorización
352)Dado que los AT no son revocados por las CA correspondientes, deberán tener una vida breve, y no pueden emitirse con demasiada antelación respecto del inicio de su validez. Los valores admisibles de los parámetros del ciclo de vida de los certificados se establecen en el epígrafe 7.2.
7.4.Lista de revocación de certificados
353)El formato y el contenido de la CRL emitida por la CA raíz serán los establecidos en [1].
7.5.Lista de confianza de certificación europea
354)El formato y el contenido de la ECTL emitida por el TLM serán los establecidos en [1].
8.Auditoría de conformidad y otras evaluaciones
8.1.Temas cubiertos por la auditoría y base de auditoría
355)La finalidad de una auditoría de conformidad es verificar que el TLM, las CA raíz, las EA y las AA operan de conformidad con la presente CP. El TLM, las CA raíz, las EA y las AA seleccionarán para auditar su CPS un auditor de la PKI acreditado que actúe de manera independiente. La auditoría se combinará con una evaluación ISO/IEC 27001 e ISO/IEC 27002.
356)Las auditorías de conformidad de las CA raíz son encargadas por la propia CA raíz (flujo 13), y las de las CA subordinadas son encargadas por su EA/AA subordinada.
357)Las auditorías de conformidad del TLM son encargadas por la CPA (flujo 38).
358)Cuando se solicite, un auditor de PKI acreditado realizará una auditoría de conformidad en uno de los siguientes niveles:
1)conformidad de la CPS del TLM, la CA raíz, la EA o la AA con la presente CP;
2)conformidad de las prácticas previstas del TLM, la CA raíz, la EA o la AA con su CPS antes de su funcionamiento;
3)conformidad de las prácticas y actividades operativas del TLM, la CA raíz, la EA o la AA con su CPS durante su funcionamiento.
359)La auditoría cubrirá todos los requisitos de la presente CP que deben cumplir el TLM, las CA raíz, las EA y las AA que deben auditarse. También cubrirá el funcionamiento de la CA en la PKI de los STI-C, incluidos todos los procesos mencionados en su CPS, los locales y las personas responsables.
360)El auditor acreditado de la PKI proporcionará un informe detallado de la auditoría a la CA raíz (flujo 36), EA, AA o CPA (flujos 16 y 40), según proceda.
8.2.Frecuencia de las auditorías
361)Las CA raíz, los TLM, las EA o las AA encargarán una auditoría de su conformidad realizada por un auditor de la PKI acreditado e independiente en los siguientes casos:
en su primera fase de establecimiento (conformidad de niveles 1 y 2);
en cada modificación de la CP. La CPA definirá el contenido y el calendario de implantación de la modificación de la CP y determinará en consecuencia las necesidades de auditoría (incluido el nivel de conformidad necesario);
en cada modificación de su CPS (conformidad de niveles 1, 2 y 3). Dado que las entidades gestoras de las CA raíz, el TLM y las EA/AA deciden qué cambios de implementación conlleva la actualización de sus CPS, encargarán una auditoría de conformidad antes de llevar a cabo las modificaciones. En caso de que solo se introduzcan ligeras modificaciones en las CPS (por ejemplo, de redacción), la entidad gestora puede enviar a la CPA una solicitud debidamente justificada de su aprobación para omitir las auditorías de conformidad de nivel 1, 2 o 3;
periódicamente, y como mínimo cada tres años durante su funcionamiento (conformidad de nivel 3).
8.3.Identidad y cualificaciones del auditor
362)La CA que se va a auditar seleccionará una empresa u organización acreditada («organismo auditor») o auditores acreditados de PKI que actúen de manera independiente para que la auditen de conformidad con la presente CP. El organismo auditor estará acreditado y certificado por un miembro de la Entidad Europea de Acreditación.
8.4.Relación del auditor con la entidad auditada
363)El auditor de la PKI acreditado será independiente de la entidad auditada.
8.5.Medidas adoptadas como resultado de una deficiencia
364)En caso de que un informe de auditoría considere que el TLM no es conforme, la CPA ordenará al TLM que adopte medidas preventivas o correctoras inmediatas.
365)Cuando una CA raíz con un informe de auditoría no conforme presente una nueva solicitud, la CPA rechazará la solicitud y enviará la denegación correspondiente a la CA raíz (flujo 4). En tal caso, se suspenderá la CA raíz. Debe adoptar medidas correctoras, volver a encargar la auditoría y hacer una nueva solicitud de aprobación de la CPA. Durante la suspensión, no se permitirá a la CA raíz emitir certificados.
366)En caso de auditoría periódica de la CA raíz o un cambio en la CPS de una CA raíz, y dependiendo de la naturaleza del incumplimiento descrito en el informe de auditoría, la CPA puede decidir revocar la CA raíz y comunicar esta decisión al TLM (flujo 2), provocando la supresión del certificado de CA raíz de la ECTL y la inclusión de la CA raíz en la CRL. La CPA enviará la denegación correspondiente a la CA raíz (flujo 4). La CA raíz debe adoptar medidas correctoras, volver a encargar una auditoría completa (niveles 1 a 3) y presentar una nueva solicitud de aprobación de la CPA. Otra posibilidad es que la CPA puede decidir no revocar la CA raíz, sino darle un período de gracia en el que la CA raíz tome medidas correctoras, encargue una nueva auditoría y vuelva a presentar el informe de auditoría a la CPA. En este caso, el funcionamiento de la CA raíz debe suspenderse y no se le permite emitir certificados ni CRL.
367)En caso de auditoría de una EA/AA, la CA raíz decidirá si acepta o no el informe. En función del resultado de la auditoría, la CA raíz decidirá si va a revocar el certificado EA/AA de conformidad con las normas que figuran en la CPS de la CA raíz. La CA raíz garantizará en todo momento el cumplimiento de la presente CP por parte de la EA/EA.
8.6.Comunicación de los resultados
368)La CA raíz y el TLM enviarán el informe de auditoría a la CPA (flujo 16). La CA raíz y el TLM almacenarán todos los informes de auditoría que hayan encargado. La CPA enviará la aprobación o denegación correspondiente (flujo 4) a la CA raíz y la TLM.
369)La CA raíz enviará un certificado de conformidad a la correspondiente EA/AA.
9.Otras disposiciones
9.1.Tasas
370)Uno de los principios del modelo de confianza STI-C de la Unión es que las CA raíz financian juntas en su totalidad los costes recurrentes periódicos del funcionamiento de la CPA y los elementos centrales (TLM y CPOC) relacionados con las actividades expuestas en la presente CP.
371)Las CA raíz (incluida la CA raíz de la Unión) están autorizadas a cobrar tasas a sus CA subordinadas.
372)Durante su período de funcionamiento, todos los participantes del modelo de confianza STI-C tendrán acceso al menos a una CA raíz, EA y AA, de manera no discriminatoria.
373)Cada CA raíz está autorizada a repercutir las tasas que paga por la CPA y los elementos centrales (TLM y CPOC) a los participantes registrados del modelo de confianza STI-C, incluidas las estaciones STI-C inscritas y autorizadas.
9.2.Responsabilidad financiera
374)El establecimiento inicial de una CA raíz abarcará un período de al menos tres años de funcionamiento, antes de convertirse en miembro del modelo de confianza STI-C de la Unión. La CPS de un operador de CA raíz también contendrá disposiciones detalladas sobre la revocación o el cierre de la CA raíz.
375)Cada CA raíz debe demostrar la viabilidad financiera de la entidad jurídica que la ejecuta durante al menos tres años. Este plan de viabilidad financiera forma parte del conjunto inicial de documentos de inscripción y debe actualizarse cada tres años y notificarse a la CPA.
376)Cada CA raíz debe comunicar cada año la estructura de las tarifas aplicadas a las AE/AA y las estaciones STI-C inscritas y autorizadas al gestor de operaciones y a la CPA para demostrar su sostenibilidad financiera.
377)Todas las entidades financieras y jurídicas responsables de las CA raíz, las EA, las AA y los elementos centrales del modelo de confianza STI-C (CPOC y TLM) deben cubrir sus funciones operativas con seguros adecuados para compensar los errores operativos y la recuperación financiera respecto de sus funciones si uno de los elementos técnicos falla.
9.3.Confidencialidad de la información empresarial
378)Se mantendrán confidenciales y privados:
los registros de solicitudes de las CA raíz, las EA y las AA, tanto si son aprobadas como denegadas;
los informes de auditoría de las CA raíz, las EA, las AA y el TLM;
los planes de recuperación en caso de catástrofe de las CA raíz, las EA, las AA, el CPOC y el TLM;
las claves privadas de los elementos del modelo de confianza STI-C (estaciones STI-C, TLM, EA, AA y CA raíz);
cualquier otra información considerada confidencial por la CPA, las CA raíz, las EA, las AA, el TLM y el CPOC.
9.4.Plan de privacidad
379)Las CPS de la CA raíz y las AE/AA establecerán el plan y los requisitos para el tratamiento de la información personal y la privacidad sobre la base del RGPD y de otros marcos legislativos (por ejemplo, nacionales) aplicables.
10.Referencias
En el presente anexo se utilizan las siguientes referencias:
[1]
|
ETSI TS 102 941 V1.2.1, Intelligent transport systems (ITS) – security, trust and privacy management («Sistemas de transporte inteligentes [STI]. Gestión de la seguridad, la confianza y la privacidad»).
|
[2]
|
ETSI TS 102 940 V1.3.1, Intelligent transport systems (ITS) – security, ITS communications security architecture and security management («Sistemas de transporte inteligentes [STI]. Seguridad, arquitectura de seguridad de las comunicaciones STI y gestión de la seguridad».
|
[3]
|
Certificate policy and certification practices framework («Política de certificados y marco de las prácticas de certificación») (RFC 3647, 1999).
|
[4]
|
ETSI TS 102 042 V2.4.1 Policy requirements for certification authorities issuing public key certificates («Requisitos de actuación aplicables a las autoridades de certificación que emiten certificados de clave pública»).
|
[5]
|
ETSI TS 103 097 V1.3.1, Intelligent transport systems (ITS) – security, security header and certificate formats («Sistemas de transporte inteligentes [STI]. Seguridad, cabecera de seguridad y formatos de certificado»).
|
[6]
|
Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. Van Haren Publishing.
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – information technology, security techniques, information security risk management («Tecnología de la información, técnicas de seguridad y gestión del riesgo de seguridad de la información»). ISO.
|
|
|