¿Por qué no usar la misma CA emisora subordinada para generar certificados que se usarán para diferentes cosas?

2

Microsoft ha recomendado a mi organización que use diferentes CA de emisor subordinado para emitir certificados que se usarán para diferentes cosas. Por ejemplo, recomiendan utilizar una CA para emitir certificados que se usarán para conectarse a wifi y otra CA para emitir certificados que se usarán para que las aplicaciones se autentiquen en los servicios web.

Dicen que la razón es reducir el riesgo de que una CA funcione mal para afectar a todos los servicios.

¿Cuáles son los riesgos de usar la misma CA emisora subordinada para generar certificados que se usarán para diferentes cosas (por ejemplo, autenticación wifi vs autenticación de servicios web)?

¿Hay solo razones de disponibilidad o también razones de confidencialidad?

    
pregunta Eloy Roldán Paredes 28.12.2015 - 13:25
fuente

2 respuestas

2

Hay un principio general de que las claves se deben usar para un solo propósito. De acuerdo con las Pautas de uso clave de NIST (consulte la sección 5.2 en la página 42) / p>

  

En general, una sola clave debe usarse para un solo propósito (por ejemplo,   cifrado, autenticación, ajuste de clave, generación de números aleatorios, o   firmas digitales). Hay varias razones para esto:

     
  1. El uso de la misma clave para dos procesos criptográficos diferentes puede debilitar la seguridad proporcionada por uno o ambos procesos.
  2.   
  3. Al limitar el uso de una clave, se limita el daño que se podría hacer si la clave está comprometida.
  4.   
  5. Algunos usos de las teclas interfieren entre sí. Por ejemplo, considere un par de claves utilizadas tanto para el transporte de claves como para las firmas digitales. En esto   En este caso, la clave privada se utiliza como clave de transporte privada de clave para   descifrar las claves de cifrado de datos y una clave de firma privada para aplicar   firmas digitales. Puede ser necesario conservar la clave privada-clave de transporte   Más allá del criptoperiodo del público correspondiente.   clave de transporte clave para descifrar las claves de cifrado de datos necesarias   Para acceder a los datos encriptados. Por otro lado, la clave de firma privada.   será destruida a la expiración de su criptoperiodo para prevenir   su compromiso (ver Sección 5.3.6). En este ejemplo, la longevidad.   Requisitos para la clave privada de transporte clave y el privado   la clave de firma digital se contradice entre sí.
  6.   

Las mismas razones por las que las claves comunes deben tener un solo propósito también se aplican a una clave de firma de CA o una clave de firma de CA subordinada (SCA).

No puedo pensar en una vulnerabilidad específica en los certificados que la razón # 1 pueda crear, pero hemos visto suficientes vulnerabilidades criptográficas que se producen cada vez que se violan los principios, por lo que no lo descartaría por completo.

Con respecto al # 2, obviamente desea limitar el daño que podría hacerse si un servidor de firmas está comprometido. Cuando comienza a ejecutar su propia PKI, se da cuenta de lo frágiles que pueden ser los sistemas y lo fácil que puede ser cometer errores sutiles.

La razón # 3 entra en la flexibilidad del sistema. Por ejemplo, alguien en administración de propiedades puede comprar una solución de seguridad preempaquetada para construir el control de acceso, y puede tener sus propios requisitos para emitir certificados de SCA que no coincidan con su jerarquía actual de certificados de SCA. En lugar de interrumpir sus otros procesos de emisión de certificados, puede aislar el cambio solo al dominio afectado.

Por supuesto, no puede simplemente apilar certificados de CA subordinados como bloques de construcción. Cada enlace de SCA en la cadena de confianza significa otro certificado que debe validarse, y hay límites prácticos a la cantidad de certificados que pueden validarse antes de que el proceso sea demasiado oneroso para los clientes. Por esa razón, verá que las CA raíz de confianza no delegan a los certificados SCA en sus servidores de trabajo, incluso si esto segrega mejor su infraestructura. Pero las CA raíz de confianza tienen mucha experiencia en el campo y han diseñado sus sistemas enfocados en la seguridad de su arquitectura; Todos confiamos en ellos para hacer bien su trabajo. (La realidad cínica es que cada vez que una entidad emisora raíz ha cometido un error y se ha comprometido en el pasado, la pérdida de confianza significa que la empresa tiende a salir del negocio rápidamente).

    
respondido por el John Deters 28.12.2015 - 23:24
fuente
2

El uso de diferentes CA intermedias le permitirá diferenciar los certificados de entidad final por su emisor. Esto hace posible crear reglas de confianza que limitarán el uso de certificados en función de su emisor.

La emisión de todos sus certificados desde el mismo iCA hará que sea fácil permitir que un certificado sea utilizado para algo no deseado.

Eso, por ejemplo, le permitirá generar un certificado de autenticación wifi desde iCA1 y un certificado de conexión de cliente TLS (servicios web) desde iCA2 y luego configurar su punto de acceso wifi para confiar en cualquier certificado emitido por iCA1. Esto evitará que el certificado que emita para sus servicios web sea reutilizado para acceder a su red wifi (y viceversa) sin tener que meterse con el OID en certificados (que tal vez ni siquiera sean compatibles con el software que utiliza estos certificados).

Puede hacer exactamente lo mismo con CA independientes, excepto que esto requiere un mayor esfuerzo de administración.

    
respondido por el Stephane 28.12.2015 - 13:51
fuente

Lea otras preguntas en las etiquetas