it-swarm-es.com

¿Debe la CA o la cadena influir en la selección de la fuerza de bits de un certificado hijo?

Todas las cosas por igual; supongamos que tengo una cadena CA que tiene 1024 bits de cifrado RSA. ¿Significa esto que mi selección de un certificado secundario de CA o servidor web no obtiene ningún beneficio de un nivel más alto de cifrado?

Mi teoría en esa pregunta es que si un atacante necesita N ciclos de cómputo para atacar un certificado con 1024 bits de encriptación, entonces también podría atacar al más alto de la cadena.

¿Qué pasaría si las fechas de vencimiento de los certificados principales (1024 bits) fueran de 1 año y el vencimiento de mi certificado más fuerte (4028 bits) expira en 2 años (o más)? ¿Es eso técnicamente posible? ¿Es beneficioso? Si es así, ¿de qué manera?

7
goodguys_activate

Parece que estás haciendo 2 preguntas:

¿Existe algún beneficio en que el certificado de entidad final tenga un espacio de claves más grande que las CA en la cadena de firma

Estoy de acuerdo con otros carteles en que el resultado es mixto, pero quiero dividirlo en las características de seguridad típicas:

  • Confidencialidad: si está utilizando el par de claves de la entidad final para la confidencialidad (cifrado de clave durante la configuración de SSL, cifrado de datos para almacenamiento o transmisión), obtendrá el beneficio de la clave más grande independientemente de lo que esté haciendo el firmante de CA. Romper su cifrado está completamente relacionado con encontrar su clave privada (o encontrar una debilidad en el algoritmo)
  • Integridad: si está utilizando el par de claves de entidad final para firmar datos, entonces descifrar su ¡firma está vinculado a la fuerza de su clave. Sin embargo, las comprobaciones de integridad a menudo se combinan con comprobaciones de autenticación; consulte a continuación.
  • Autenticación: aquí está el problema. Sus capacidades de autenticación/no repudio disminuyen si la clave privada de su CA es más fácil de adivinar. Si puedo encontrar la clave privada de su CA debido al espacio de claves más pequeño, entonces puedo fingir ser su CA y puedo hacer un certificado y un par de claves de cualquier tamaño que se parezca a ¡usted y tiene un par de claves que controlo. Eso dispara la autenticación en el pie. No será detectado por una lista de certificados CA confiables porque el atacante emulará uno de esos certificados confiables configurados. Y será difícil de detectar hasta que se encuentre el allanamiento. Además, revocar una CA es doloroso. O debe tener una verificación del estado del certificado en cada sistema consumidor que verifique el estado tanto de la entidad final como de la cadena de CA, o debe revocar todas las entidades finales válidas emitidas por la CA. Esto se vuelve aún más difícil si hablamos de un espacio de clave pequeño en un certificado raíz autofirmado. No hay forma de verificar el estado de la raíz. El sistema de CA tendría que emitir una gran advertencia pública y hacer que cualquier parte de confianza elimine la raíz y todas sus CA secundarias de sus tiendas de confianza.

  • Disponibilidad: cuando pienso en la disponibilidad en PKI, pienso en el uso de PKI para la autenticación/control de acceso para que los servicios estén disponibles solo para los usuarios privilegiados. En ese sentido, la disponibilidad se dispara tanto como la autenticación.

Entonces, el resumen: ¿para qué está usando el certificado? Si solo lo está utilizando para la confidencialidad y la integridad pura, no está tan mal. Pero tenga en cuenta que, con frecuencia, los mecanismos de protección de PKI mezclan estas categorías. La autenticación de cliente o servidor SSL es tanto una forma de configurar un canal seguro (confidencialidad) como una forma de verificar la identidad del servidor (autenticación). Las firmas de correo electrónico son tanto una forma de proteger la transmisión (integridad) como una prueba de que la transmisión proviene del remitente (autenticación). Se pone peludo muy rápido.

Próxima pregunta...

¿Es beneficioso o incluso posible que mi entidad final tenga una validez más larga que la CA que la emitió?

En los sistemas PKI en los que he trabajado, no en absoluto, los certificados de entidad final no se pueden emitir con un período de validez más largo que la vida útil del certificado de CA.

Sin embargo, retrocediendo desde la experiencia real, estoy mirando el RFC para certificados X509: http://www.ietf.org/rfc/rfc3280.txt

Section 6.1.3  Basic Certificate Processing

incluye la verificación de las fechas de validez de cada certificado de la cadena.

Esta sección es parte de:

6.1  Basic Path Validation

   This text describes an algorithm for X.509 path processing.  A
   conformant implementation MUST include an X.509 path processing
   procedure that is functionally equivalent to the external behavior of
   this algorithm.  However, support for some of the certificate
   extensions processed in this algorithm are OPTIONAL for compliant
   implementations.  Clients that do not support these extensions MAY
   omit the corresponding steps in the path validation algorithm.

Por lo tanto, debe hacerse para cada certificado en la ruta (es decir, la entidad final, cada CA firmante y la raíz)

Las verificaciones de validez no son una extensión OPCIONAL, son parte obligatoria del certificado.

SI el sistema está realizando la validación de ruta correctamente, tener una validez más larga en el certificado de entidad final no debería servirle de nada. No miré más lejos para ver si estaba permitido. Creo que los sistemas de CA que probé tenían una configuración que no permitía esto, pero también creo que con cierto grado de creatividad pude generar un certificado que rompió este molde. Tenga en cuenta, sin embargo, que estaba haciendo eso con privilegios de administrador del sistema y posiblemente incluso mecanismos de prueba de caja blanca que no deberían estar disponibles en una CA reforzada. También estaba haciendo eso hace más de 10 años con CA que ya no están en el mercado hoy en día; el kilometraje puede variar.

10
bethlakshmi

Respuesta corta: Sí, existe algún beneficio potencial para que las entidades finales elijan una clave pública que sea más grande que la clave pública de la CA.

La pregunta no está del todo clara, pero supongo que su situación es que la raíz o el padre usan una clave RSA de 1024 bits (es decir, el certificado de la entidad final está firmado con una clave RSA de 1024 bits), y la entidad final usa una clave RSA de 2048 bits (es decir, la clave pública que está certificando y utilizando el host final es una clave RSA de 2048 bits).

En esta situación, puedo ver dos posibles beneficios de seguridad al usar un certificado de entidad final de 2048 bits en lugar de un certificado de entidad final de 1024 bits:

  • Está a salvo de un atacante que puede romper RSA de 1024 bits, pero no puede romper RSA de 2048 bits, y solo puede escuchar a escondidas pero no puede (o no está dispuesto a) manipular activamente las conexiones. En comparación, si usó una clave RSA de 1024 bits, ese atacante podría recuperar su clave privada RSA, escuchar las conexiones y descifrar el tráfico cifrado.

  • Está a salvo de un atacante que, dentro de cinco años, rompa RSA de 1024 bits pero no puede romper RSA de 2048 bits, asumiendo que la transición de CA a RSA de 2048 bits en los próximos años (como lo están haciendo muchas CA y muchos navegadores están requiriendo). Esto se debe a que un atacante que sea capaz de recuperar la clave de firma de 1024 bits de la CA dentro de cinco años no gana nada al hacerlo, si esa clave ya no es válida. La clave de firma de la CA no ayuda al atacante a descifrar el tráfico cifrado con SSL al que pueda tener acceso (ni siquiera el tráfico antiguo que registró hace mucho tiempo). Lo único que puede hacer un atacante con la clave de firma de una CA es firmar un nuevo certificado falso y usarlo para montar un ataque de intermediario en los usuarios, pero si el certificado raíz de la CA y la clave pública de 1024 bits ya no están disponibles. aceptado por los navegadores dentro de cinco años, eso no ayuda en absoluto al atacante: es demasiado tarde.

[Además, puede haber algunos beneficios de administración de claves al elegir una clave de 2048 bits ahora y poder continuar usándola durante varios años, incluso si tiene que renovar su certificado para hacerlo, en lugar de tener que cambiar las claves en un año o dos. Para ser claros, esto no es un beneficio de seguridad; es simplemente un beneficio logístico potencial, dependiendo de lo molesto que le resulte tener que cambiar sus llaves en algún momento en el futuro.]

En pocas palabras: puede resultar beneficioso elegir una clave de entidad final que sea más grande que la clave de la CA. Sin embargo, no quiero afirmar que el beneficio es abrumador, o que el tamaño de la clave pública de la entidad final es lo único que importa. Contra un atacante poderoso que es capaz y está dispuesto a montar ataques activos, y que puede romper RSA de 1024 bits dentro de la vigencia de la validez del certificado raíz de la CA, es probable que no importa el tamaño de clave pública que elija.

11
D.W.

Hay dos tipos de ataques que un atacante puede intentar montar:

  • Ataque activo: el atacante se entromete con los paquetes de datos en el momento en que se conecta al servidor (posiblemente hasta ejecutar su propio servidor falso completo). Para hacer eso, el atacante debe poder romper una de las claves públicas ¡ahora mismo (la clave del servidor o la clave de una de las CA).

  • Ataque pasivo: el atacante registra los paquetes de datos, pero no los altera. Luego, el atacante intenta romper cualquier clave que se usó para el cifrado, para desentrañar los datos de texto sin formato. En el caso de SSL/TLS con uno de los conjuntos de cifrado "RSA" ( ¡no los conjuntos "DHE_RSA"), romper la clave pública RSA del servidor es suficiente para descifrar toda la sesión.

El punto importante es que romper la clave de un CA ¡después no le da ninguna ventaja al atacante (solo lo ayuda para las sesiones de ataque que ocurren ¡después la rotura ). Sin embargo, romper la clave del servidor en sí ¡puede le ayudará a descifrar las sesiones grabadas previamente. Por lo tanto, las restricciones de seguridad de la clave del servidor son más estrictas que las de la clave CA; por lo tanto, tiene sentido usar una clave más grande para el servidor en sí.

(Los conjuntos de cifrado "DHE" usan la clave del servidor solo para una firma, lo que transfiere el problema a la clave efímera Diffie-Hellman que el servidor decide usar para el intercambio de claves real. Una vez más, el servidor tiene lógicamente el derecho de usar una Clave DH que es más fuerte que su propia clave RSA o las claves CA).

4
Thomas Pornin

Si un atacante desea hacerse pasar por su sitio, puede hacerlo intentando romper su clave de entidad final o puede romper una de las claves de CA firmantes, lo que les permitiría emitir sus propios certificados de entidad final para cualquier dominio. incluido el tuyo. Contra este ataque, la cadena de certificados es tan fuerte como su eslabón más débil.

Si un atacante desea leer el tráfico cifrado con SSL de su sitio, el atacante debe comprometer la clave de la entidad final; comprometer una clave de CA no ayuda aquí. Si le preocupa este ataque, podría tener sentido tener una clave de entidad final más larga. También tenga en cuenta que este ataque en particular se puede prevenir mediante el uso de conjuntos de cifrado DH efímeros, con cierto costo de rendimiento.

En cuanto a tener un certificado de entidad final con un período de validez más largo que un certificado de firma, existen varios problemas posibles. Primero, es posible que una CA ni siquiera acceda a emitir dicho certificado; puede truncar el período de validez al de su certificado raíz. En segundo lugar, incluso si obtiene un certificado de este tipo, la cadena no se verificará tan pronto como expire el primer certificado de la cadena. Puede haber una excepción a esto en el caso de un certificado firmado directamente por una raíz confiable.

2
Tom Wu

Si la longitud de la clave del sitio web es la misma que la clave de la CA, entonces el atacante puede atacar la clave del sitio web, ya que se puede obtener más valor con el mismo esfuerzo. La razón es que todos los datos cifrados anteriormente (y futuros) pueden ser descifrados. Esto también permite ataques MITM.

Sin embargo, si la clave del sitio web es más grande que la clave de CA, es más probable que el atacante simplemente ataque la clave de CA, y en ese caso solo son posibles los ataques MITM. Todos los datos previamente encriptados con la clave del sitio web aún están seguros. Todos los datos futuros pueden ser vulnerables a ataques MITM.

1
goodguys_activate
  1. CA solo valida su certificado, no tiene nada que ver con su conexión segura con su cliente, por lo que su longitud de bits adicional beneficiaría su conexión. Si un atacante irrumpe en su CA, solo puede intentar MITM en sus clientes y no romper su cifrado.

  2. Sí, es posible. CA renovaría su certificado lo antes posible.

0
AbiusX