¿Una autoridad de certificación usa claves privadas diferentes?

  

Me preguntaba si una CA tiene claves privadas diferentes para firmar   certificados con?

Por lo general, una CA tendrá una cantidad de claves intermedias para firmar certificados de clientes. Estas claves intermedias están a su vez firmadas por la Root Key de la entidad emisora de certificados, que se deben almacenar "fuera de línea" y solo se usan rara vez para firmar esas claves intermedias. El Certificado de raíz correspondiente es lo que se distribuye ampliamente y se encuentra en sus navegadores Autoridades de raíz de confianza .

  

¿Existe un riesgo de análisis criptográfico (o algo similar) cuando una CA   ¿Firmas miles de certificados con la misma clave privada? Haz esto   existe riesgo?

No, para citar Wikipedia , "Cada cifrado moderno intenta brindar protección contra ataques de solo texto cifrado". Por lo tanto, no hay una preocupación real de que la cantidad de firmas / encriptaciones realizadas con una clave genere un riesgo de análisis que aumente según la cantidad de firmas / encriptaciones que haya realizado.

(Por supuesto, para ser utilizada en tantas tareas, una clave debe ser de alguna manera accesible; por eso las claves Intermedias utilizadas para la firma diaria se mantienen "en línea" y la clave de Raíz generalmente tiene espacios de aire o se mantiene fuera de línea. Pero esta es una consideración práctica, operacional, no una consideración criptográfica.)

  

Me preguntaba si una CA tiene claves privadas diferentes para firmar certificados.

En general, no. Hay un par de claves, y por lo tanto una clave privada, por certificado. Los certificados se pueden transferir para utilizar un nuevo par de claves, por supuesto. Además, en general, una CA administra múltiples certificados para diferentes propósitos. La CA también puede tener diferentes certificados para diferentes algoritmos de firma, posiblemente para cubrir el mismo propósito (por ejemplo, RSA y ECDSA).

  

¿Existe un riesgo de análisis criptográfico (o algo similar) cuando una CA firma miles de certificados con la misma clave privada? ¿Existe este riesgo?

No desde un punto de vista de algoritmo. RSA y ECDSA están seguros de firmar muchos documentos o certificados para esa materia. ECDSA es vulnerable si el generador de números aleatorios está comprometido. Más razones para utilizar una implementación bien examinada con un buen DRBG, preferiblemente en hardware certificado por FIPS o CC.

Como han mencionado otros, la mayoría de los certificados se realizan mediante certificados intermedios de CA. Eso significa que la clave privada del certificado raíz no es directamente accesible para los atacantes. Si se encuentra que un intermediario está comprometido (la detección del compromiso es un tema en sí mismo), la raíz se puede usar para revocar el certificado intermedio y emitir uno nuevo, con una clave privada diferente.

Por supuesto, cuando se firman grandes cantidades de certificados, puede haber riesgos en el procedimiento. La CA aún debe validar que firma certificados para las entidades correctas. Además, por ejemplo, debe resistir la presión para generar el par de claves para los clientes en la ubicación de la CA.

Ninguno de los anteriores se manejó bien en DigiNotar para nombrar solo un ejemplo. Pero eso tiene poco que ver con los algoritmos de firma por sí mismos.

Lo que consideramos una Autoridad de Certificación está representado por un "Certificado de Raíz Confiable" que es un certificado autofirmado que se entrega por medios seguros (la mayoría de las veces durante el proceso de instalación del SO o el navegador). Por lo general, una única Autoridad de Certificación emite solo un certificado Trusted Root, pero no siempre. Una empresa que opera como CA es libre de tener múltiples certificados raíz; Thawte tiene una raíz de confianza para sus clientes de alta integridad (bancos, casas de desarrollo de software) y una raíz de confianza diferente para pequeñas empresas y usuarios domésticos.

También hay un modelo jerárquico de confianza, en el que una CA firma algunas Autoridades de certificación subordinadas, cada una de las cuales es responsable de firmar muchos certificados en funcionamiento. Esto es útil principalmente en organizaciones privadas para administrar su infraestructura de clave interna. (Imagine que el ejército tiene un solo certificado de CA y se usa para firmar un SCA para el Ejército, uno para la Armada; el Ejército usa su SCA para firmar los certificados emitidos a cada soldado, la Armada usa los suyos para firmar los certificados emitidos a cada marinero, etc. Y cada certificado se puede validar simplemente caminando por la cadena hasta la CA única, por lo que un hombre de la Armada puede confiar en el certificado de un hombre del Ejército.)

¿Existe un riesgo de seguridad al reutilizar una clave para firmar muchos certificados? No podemos decir "no" con certeza, porque en realidad fue un problema hace unos 10 años. Los investigadores explotaron una debilidad en la resistencia a la colisión del MD5, lo que permite la falsificación de nuevos certificados, suponiendo que el atacante podría obtener una CA para firmar una nueva solicitud de certificado en el momento exacto. A medida que se acercaba el tiempo señalado, los atacantes inundaron la CA con solicitudes de firma, esperando que uno de ellos devolviera exactamente la marca de tiempo que habían predicho. Este ataque demostró instantáneamente que la resistencia a la colisión era un atributo vital en el mundo real y causó que MD5 perdiera su estatus como un algoritmo criptográfico confiable; Millones de sitios web estuvieron en riesgo hasta que finalmente todos los certificados raíz MD5 se revocaron o caducaron. Project HashClash ahora ofrece una demostración de esta vulnerabilidad de colisión, aunque ya no hay CAs que utilicen MD5.

Tenga en cuenta que eso no significa que uno siga al otro: diferentes claves privadas no habrían evitado ese problema; simplemente habrían limitado el alcance del problema a un número menor de clientes expuestos a un certificado hash MD5. Pero si se comprometiera incluso uno de sus certificados raíz, el proveedor no sería confiable y quedaría rápidamente fuera del negocio (vea DigiNotar como un ejemplo de la rapidez con la que una empresa de CA puede colapsar si no protege sus claves privadas). )

Esto llega al problema central de la confianza. O tienes que verificar a todos independientemente; o los proveedores de sistemas operativos y navegadores deben verificar todas las organizaciones que deseen utilizar comunicaciones cifradas; o tienes que aceptar que la confianza puede ser entregada por alguien capaz de examinar a otros. ¿Es práctico requerir que conduzca a su banco para obtener su certificado e instalarlo en su computadora? Tal vez. ¿Es práctico requerir que conduzca a Seattle para obtener el certificado de Amazon e instalarlo en su navegador? Tal vez no. ¿Es práctico para Microsoft incluir 20 millones de certificados en su navegador? Tal vez no. ¿Es práctico que confíes en que tus amigos que fueron a Seattle te traen una copia del certificado de Amazon? Tal vez, pero es un poco torpe. Tener un número finito de certificados de nivel superior es un enfoque práctico que funciona principalmente.

Es mucho más fácil aceptar que Symantec verificó amazon.com y les emitió un certificado; es mucho más fácil mantener la confianza cuando su navegador incluye solo unas pocas docenas de certificados de CA. Como beneficio adicional, si algunas personas realmente inteligentes se dan cuenta de que el certificado de Symantec no es confiable, se lo dirán al mundo y se eliminarán rápidamente en un parche de software, lo que lo protege mucho más rápido que si hubiera establecido la confianza por su cuenta (cómo a menudo regresaría a su banco para verificar su certificado?)