¿Debería la CA o la cadena influir en la selección de intensidad de bits de un certificado secundario?

Parece que estás haciendo 2 preguntas:

¿Hay algún beneficio en tener el certificado de entidad final con un espacio de claves mayor que el de las CA en la cadena de firmas?

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 entidad final para la confidencialidad (cifrado de clave durante la configuración de SSL, cifrado de datos para almacenamiento o transmisión) - entonces está obteniendo el beneficio de la clave más grande, independientemente de lo que esté haciendo el firmante de CA . Romper su cifrado está totalmente relacionado con encontrar su clave privada (o encontrar una debilidad en el algoritmo)
• Integridad: si está utilizando el par de claves de la entidad final para firmar datos, entonces la clave firma está vinculada a la fortaleza de su clave. Sin embargo, las comprobaciones de integridad a menudo se combinan con las 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 pretender ser su CA y puedo hacer un certificado y un par de claves de cualquier tamaño que se parezca a usted y tenga una clave par que yo controlo. Que prácticamente dispara la autentificación en el pie. No será capturado por una lista de certificados de CA de confianza porque el atacante emulará uno de esos certificados de confianza configurados. Y será difícil de detectar hasta que se encuentre la ruptura. Además, revocar un CA es doloroso. Debe tener una verificación de estado de 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 estamos hablando de un pequeño espacio clave 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 dependiente 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 el control de autenticación / acceso para que los servicios estén disponibles solo para los usuarios privilegiados. En ese sentido, la disponibilidad se captura tanto como la autenticación.

Entonces, el resumen: ¿para qué está utilizando el certificado? Si solo lo usa para mantener la confidencialidad y la integridad pura, no está tan mal. Pero tenga en cuenta que con frecuencia, los mecanismos de protección PKI combinan 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 una forma de falsificar la transmisión (integridad) y una prueba de que la transmisión provino del remitente (autenticación). Se vuelve peludo terriblemente rápido.

Siguiente pregunta ...

¿Es beneficioso o incluso posible que mi entidad final tenga una validez mayor que la CA que la emitió?

En los sistemas PKI en los que he trabajado, no absolutamente no, los certificados de entidades no se pueden emitir como un período de validez más largo que la vida del certificado de CA.

Dejando atrás la experiencia real, sin embargo, estoy viendo el RFC para Certificados X509: enlace

Section 6.1.3  Basic Certificate Processing

incluye la verificación de las fechas de validez de cada certificado en 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 comprobaciones de validez no son una extensión OPCIONAL, son parte necesaria del certificado.

Si el sistema está haciendo la validación de la ruta correctamente, tener una validez más larga en el certificado de la entidad final no debería servirle. No miré más lejos para ver si está permitido. Creo que los sistemas de CA que he probado han tenido una configuración que lo ha rechazado, pero también creo que con cierto grado de creatividad he podido generar un certificado que rompió este molde. Sin embargo, tenga en cuenta que lo estaba haciendo con privilegios de administrador del sistema y posiblemente incluso con 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 son el mercado hoy en día, el kilometraje puede variar.

Respuesta corta: sí, hay un 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 utiliza una clave RSA de 1024 bits (es decir, el certificado de la entidad final está firmado con una clave RSA de 1024 bits) y el final -la entidad utiliza una clave RSA de 2048 bits (es decir, la clave pública certificada y utilizada por 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:

• Usted está a salvo contra un atacante que puede romper el RSA de 1024 bits, pero no puede romper el 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, dicho atacante podría recuperar su clave privada RSA, escuchar las conexiones y descifrar el tráfico cifrado.

• Usted está a salvo contra un atacante que, dentro de cinco años, rompe el RSA de 1024 bits pero no puede romper el RSA de 2048 bits, suponiendo que la CA pase a la RSA de 2048 bits dentro de los próximos años (como muchos CAs están haciendo y muchos navegadores requieren). Esto se debe a que un atacante que puede recuperar la clave de firma de 1024 bits de la AC 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 ningún tráfico cifrado con SSL al que pueda tener acceso (ni siquiera el tráfico antiguo que registró hace mucho tiempo). Lo único que un atacante puede hacer 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 y la clave pública de 1024 bits de la CA ya no están 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 clave 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 llaves 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 qué tan molesto le resulte cambiar las claves en algún momento en el futuro.]

Línea inferior: podría haber algún beneficio al elegir una clave de entidad final que sea más grande que la clave de la AC. Sin embargo, no quiero reclamar que el beneficio es abrumador, o que lo único que importa es el tamaño de la clave pública de la entidad final. Contra un poderoso atacante que puede y está dispuesto a montar ataques activos, y que puede romper el RSA de 1024 bits dentro de la vigencia de la validez del certificado raíz de la AC, es probable que no tenga una llave pública del tamaño que elija.

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). 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. Posteriormente, el atacante intenta romper cualquier clave utilizada para el cifrado, para desentrañar los datos de texto sin formato. En el caso de SSL / TLS con una de las suites de cifrado "RSA" ( no la "DHE_RSA" suites), romper la clave pública RSA del servidor es suficiente para descifrar toda la sesión.

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

(Las suites de cifrado "DHE" usan la clave del servidor solo para una firma, que transfiere el problema a la clave Diffie-Hellman efímera que el servidor decide usar para el intercambio de clave real. De nuevo, el servidor tiene el derecho lógico para usar una clave DH que sea más fuerte que su propia clave RSA o las claves de CA.)

Si un atacante desea suplantar su sitio, puede hacerlo intentando romper su clave de entidad final, o puede romper una de las claves CA de firma, 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 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 un cierto costo en el 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 allí. Primero, una CA ni siquiera puede acordar emitir un certificado de este tipo; puede truncar el período de validez al de su certificado raíz. En segundo lugar, incluso si obtuviera un certificado de este tipo, la cadena no se verificará tan pronto como caduque 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.

Si la longitud de la clave del sitio web es la misma que la clave de CA, 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 encriptados de datos anteriores (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, entonces es más probable que el atacante solo 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 siguen siendo seguros. Todos los datos futuros pueden ser vulnerables a los ataques MITM.

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á su certificado lo antes posible.