Uso de CMP con 3GPP
EMPRESA Esta es una característica de EJBCA Enterprise.
Para obtener más información sobre cómo configurar CMP para 3GPP y operaciones y pruebas comunes, consulte Operaciones CMP de 3GPP .
Este documento describe el estándar 3GPP CMP y la integración de EJBCA con él. Contiene extractos de la especificación 3GPP TS 33.310 . En los estándares 3GPP se describe un ejemplo completo de una configuración CMP; consulte las Especificaciones 3GPP .
Terminología
Los siguientes términos son importantes para comprender el proceso subyacente de 3GPP (33.310).
Término | Significado |
Operador de red móvil | Operador de red móvil. El operador de red móvil (ORM) es el cliente de esta solución PKI, es decir, será la autoridad de certificación (CA). El ORM compra eNodeB a un proveedor. |
eNodoB | Una estación base en redes 4G y 5G, es decir, un dispositivo. |
Proveedor | Un proveedor de eNodeB, es decir, un fabricante de equipos de telecomunicaciones como Ericsson. |
Proveedor CA | Una CA operada por el proveedor. En este contexto, solo vemos los certificados de la CA del proveedor y no la configuramos. |
Operador CA | Una CA operada por el operador de red móvil (MNO) emite certificados a los eNodos B para que se comuniquen en la red del MNO. En este contexto, configuramos la CA del operador. |
Descripción general
El objetivo principal de utilizar 3GPP CMP es permitir que un eNodeB (estación base en redes 4G y 5G) se aprovisione automáticamente con un certificado de operador del operador de red móvil (MNO) sin que el fabricante del eNodeB y el MNO compartan PKI.
Esto se logra mediante un certificado emitido por el proveedor de la PKI del fabricante para autenticarse ante el operador móvil tras la instalación, lo que autoriza la emisión de un certificado de operador de la PKI del operador móvil. Este certificado se utiliza posteriormente para conectar el eNodoB a la red del operador móvil.
Flujo de trabajo generalizado
Esta sección describe el flujo de trabajo general de CMP 3GPP, a modo de resumen. El flujo de trabajo específico de EJBCA se ha modificado ligeramente; consulte Flujo de trabajo específico de EJBCA .
La siguiente figura muestra la arquitectura de implementación general para la inscripción de certificados de un dispositivo en una PKI de operador.
El dispositivo está provisto previamente con un par de claves pública-privada por el proveedor, y tiene preinstalado el certificado firmado por el proveedor de su clave pública.
Al contactar inicialmente con la red del operador, el dispositivo establece un canal de comunicación con la RA/CA del proveedor. Mediante un protocolo CMPv2, se envía una solicitud de certificado a la RA/CA. La red autentica los mensajes del dispositivo basándose en el certificado firmado por el proveedor y el certificado raíz del proveedor preinstalado en la red. El dispositivo comprueba la protección de la integridad de los mensajes de la RA/CA basándose en el certificado raíz del operador proporcionado. En un mensaje de respuesta, el dispositivo recibe el certificado firmado por el operador. Durante la ejecución del protocolo CMPv2, el dispositivo debe proporcionar una prueba de posesión de la clave privada asociada a la clave pública para obtener la certificación.
El certificado raíz del operador puede aprovisionarse en el dispositivo antes o durante la ejecución del protocolo CMPv2. La protección del certificado raíz del operador durante el aprovisionamiento puede determinarse mediante la política de seguridad del operador. Si hay un certificado raíz del operador aprovisionado antes de la ejecución del protocolo CMPv2, el dispositivo lo utilizará. De lo contrario, utilizará el certificado raíz del operador aprovisionado durante la ejecución de CMPv2. Si no se aprovisiona ningún certificado raíz del operador, el dispositivo cancelará el procedimiento.
Si el operador desea renovar el certificado del dispositivo, se ejecutará el mismo procedimiento con el antiguo certificado del dispositivo firmado por el operador en lugar del certificado firmado por el proveedor de la inscripción inicial.
La siguiente figura describe el flujo general de mensajes en ambos casos:
El dispositivo descubre la dirección RA/CA.
El dispositivo genera el par de claves privada/pública que se inscribirá en la CA del operador, si esta no está aprovisionada previamente.
El dispositivo genera la Solicitud de Inicialización (IR). El mensaje CertReqMsg dentro de la solicitud especifica el certificado solicitado. Si el dispositivo conoce la identidad sugerida, la incluye en el campo "asunto". Para demostrar la posesión, el dispositivo genera la firma para el campo "POPOSigningKey" del mensaje CertReqMsg utilizando la clave privada relacionada con la clave pública que la RA/CA certificará. El dispositivo firma la solicitud utilizando la clave pública proporcionada por el proveedor e incluye la firma digital en el mensaje PKIMessage. Su propio certificado firmado por el proveedor y cualquier certificado intermedio se incluyen en el campo "extraCerts" del mensaje PKIMessage que contiene la solicitud de inicialización.
El dispositivo envía el mensaje de solicitud de inicialización firmado a la RA/CA.
La RA/CA verifica la firma digital del mensaje de solicitud de inicialización con el certificado raíz del proveedor utilizando los certificados enviados por el dispositivo. La RA/CA también verifica la posesión de la clave privada del certificado solicitado.
La RA/CA genera el certificado para el dispositivo. Si la identidad sugerida del dispositivo no está incluida en el mensaje de solicitud de inicialización, la RA/CA la determina basándose en la identidad proporcionada por el proveedor que figura en el certificado del dispositivo. La RA/CA también puede reemplazar una identidad sugerida enviada por el dispositivo por otra basada en información local.
La RA/CA genera una Respuesta de Inicialización (IP) que incluye el certificado emitido. La RA/CA firma la respuesta con su clave privada (o la clave privada para firmar mensajes CMP, si es independiente) e incluye la firma, los certificados de la RA/CA y el certificado raíz del operador en el PKIMessage. Las cadenas de certificados adecuadas para autenticar los certificados de la RA/CA se incluyen en el PKIMessage.
La RA/CA envía la respuesta de inicialización firmada al dispositivo.
Si el certificado raíz del operador no está preaprovisionado en el dispositivo, este lo extrae del mensaje PKI. El dispositivo autentica el mensaje PKI mediante el certificado de RA/CA e instala el certificado del dispositivo si la operación se realiza correctamente.
El dispositivo crea y firma el mensaje CertificateConfirm (certconf).
El dispositivo envía el PKIMessage que incluye el CertificateConfirm firmado a la RA/CA.
La RA/CA autentica el mensaje PKI que incluye el CertificateConfirm.
La RA/CA crea y firma un mensaje de confirmación (pkiconf).
La RA/CA envía el PKIMessage firmado, incluido el mensaje pkiconf, al dispositivo.
El dispositivo autentica el mensaje pkiconf.
Flujo de trabajo específico de EJBCA
Para utilizar EJBCA con el perfil CMP 3GPP, se ajusta ligeramente la configuración generalizada descrita anteriormente.
El perfil CMP 3GPP es compatible con EJBCA Enterprise en modo cliente. En este caso, los dispositivos están en contacto directo con EJBCA y cada uno tiene una entidad final correspondiente en EJBCA.
Además, existe la opción de usar EJBCA en modo RA para la comunicación indirecta entre EJBCA y el dispositivo a través de una tercera entidad que actúa como RA. En este caso, la RA tiene una entidad final correspondiente en EJBCA y recibe los privilegios necesarios para procesar solicitudes CMP en nombre del dispositivo.
CA directa - Comunicación del dispositivo
En caso de contacto directo entre EJBCA y el dispositivo, EJBCA opera en modo cliente. Cada dispositivo tiene una entidad final correspondiente en EJBCA. El dispositivo envía la solicitud inicial de registro/certificación a EJBCA como una solicitud CMP firmada con la clave proporcionada por el proveedor. El certificado emitido por el proveedor se adjunta a la solicitud en el campo extraCerts. EJBCA autenticará la solicitud comprobando que el certificado en extraCerts fue emitido por la CA del proveedor (una CA externa en EJBCA). Si la autenticación es correcta, EJBCA emitirá un certificado para el dispositivo y lo incluirá en el mensaje de respuesta CMP.
En caso de contacto directo entre EJBCA y el dispositivo, EJBCA opera en modo cliente. Cada dispositivo tiene una entidad final correspondiente en EJBCA. El dispositivo envía la solicitud inicial de registro/certificación a EJBCA como una solicitud CMP firmada con la clave proporcionada por el proveedor. El certificado emitido por el proveedor se adjunta a la solicitud en el campo extraCerts. EJBCA autenticará la solicitud comprobando que el certificado en extraCerts fue emitido por la CA del proveedor (una CA externa en EJBCA). Si la autenticación es correcta, EJBCA emitirá un certificado para el dispositivo y lo incluirá en el mensaje de respuesta CMP.
Para futuras comunicaciones, cuando el dispositivo necesite actualizar su certificado, se utiliza el antiguo certificado EJBCA obtenido para autenticar la solicitud de actualización o renovación de clave. Esto se realiza normalmente cuando el dispositivo firma la solicitud de actualización con su clave privada y adjunta su certificado (el que se va a renovar) en el campo extraCerts del mensaje CMP.
Para conocer la configuración requerida, consulte Operaciones CMP 3GPP .
CA - Comunicación del dispositivo a través de una RA personalizada
El estándar 3GPP CMP especifica un perfil utilizable para la comunicación directa entre CA y dispositivo. Si bien este es el caso de uso principal de la especificación 3GPP, a menudo se encuentran soluciones cuando un punto central de confianza, una autoridad de registro o una pasarela de seguridad necesita emitir certificados a entidades finales bajo su control. Para estos casos, se puede utilizar CMP en modo RA, un perfil de CMP no descrito en el estándar 3GPP.
En caso de comunicación indirecta entre EJBCA y el dispositivo, EJBCA opera en modo RA. El dispositivo se comunica con la CA a través de un tercer dispositivo/organización que actúa como RA. La RA tiene una entidad final correspondiente en EJBCA con un certificado emitido. Este certificado se transfiere manualmente a la RA. La RA también está registrada en EJBCA como administrador y cuenta con los privilegios necesarios para procesar solicitudes CMP en nombre del dispositivo.
Se espera que tanto las solicitudes de inicialización/certificación como las de actualización de certificados de los dispositivos estén firmadas por la RA. Cualquier cambio o actualización del certificado de la RA se realizará directamente en EJBCA y se transferirá manualmente a la RA. Para la configuración requerida, consulte Operaciones CMP 3GPP .