¿Cuántos certificados puede emitir una CA antes de renovar su clave secreta?

Esta es una gran oportunidad para desarrollar los conceptos básicos de cómo funcionan las AC. Asumiré que estamos hablando de CA raíz, ya que renovar una CA subordinada no es realmente un gran problema.

  

¿Con qué frecuencia las CA renuevan las claves y en qué circunstancias (número de certificados emitidos, tiempo, etc.)?

Volveré a formular esta pregunta:

  

¿Qué factores aumentan la probabilidad de un atacante de descifrar la clave privada de la AC?

Suponiendo que no estamos hablando de hacks, puertas traseras, amenazas internas, etc., y solo hablamos de craqueo basado en información pública, entonces la respuesta es: la elección del algoritmo, el tamaño de la clave y la cantidad de tiempo.

El cálculo es algo así: digamos que elegimos RSA-4096, luego buscaremos el tiempo de ejecución de los ataques más conocidos contra RSA, buscaremos costos para alquilar esa cantidad de potencia de cómputo en Amazon, haremos algo de la Ley de Moore cálculos y adivinar cuánto tiempo le tomaría a un atacante romperlo. Resulta que para RSA y ECC que los ataques más conocidos solo necesitan la clave pública; una firma pierde información cero sobre la clave privada, por lo que ver muchas firmas no ayuda.

Tenga en cuenta que esto no será cierto para algunos de los algoritmos de firma post-cuántica. En particular, con firmas basadas en hash [ article1 ], [ article2 ], las claves privadas son esencialmente grandes colecciones de claves de un solo uso donde cada firma revela una clave privada. Una vez que el mundo cambie a criptografía post-cuántica, su pregunta será mucho más relevante.

  

En el caso de que una CA necesite renovar su par de claves, ¿qué sucede con los certificados anteriores que aún son válidos? ¿Se vuelven a firmar con la nueva clave?

Este es, de hecho, un problema fundamental con la forma en que se diseñan las CA. He visto que se maneja de dos maneras diferentes:

1. La CA simplemente no emitirá certificados que sobrevivan a sí mismos. Digamos que tienes una CA que emite certificados de 1 año. Cuando la propia CA tenga menos de un año, se enfrentará a una nueva CA emisora. La antigua CA todavía está disponible para las revisiones de revocación y demás, pero ya no emite nuevos certificados.

2. Certifique de forma cruzada la CA antigua con la nueva, de modo que al validar un certificado emitido por la CA antigua, se encadenará a la CA actual. Esto es un poco hacky porque técnicamente hay un CA caducado en la cadena. La mayoría de los motores TLS no admiten este tipo de cosas, por lo que solo lo he visto en entornos cerrados como el correo electrónico corporativo o los sistemas de identificación con credenciales de identificación, en los que tiene más control sobre los clientes.

Debido a la interrupción de traspasar una CA raíz, desea que sea válida durante mucho tiempo. Un vistazo rápido a través de los certificados de raíz de mi navegador muestra certificados de 15 años, certificados de 20 años e incluso unos 30 años.

No creo que haya ningún límite técnico, en términos del estándar x509 publicado por ISO / IEC / ITU-T (no tengo una copia de ISO 9594-8 para confirmar esto, si alguien la tiene, puede por favor verifica esto?). Sin embargo, de acuerdo con RFC 5280 : "el número de serie DEBE ser un número entero positivo" y "las CA correspondientes no DEBEN utilizar valores de número de serie más de 20 octetos ", por lo que un solo certificado de CA puede emitir 2 ¹⁵⁹ -1 certificados de descendientes directos con números de serie únicos que cumplen con RFC 5280.

En la práctica, cada CA a menudo tiene límites de implementación en su infraestructura que limita aún más lo que realmente podrán generar. Sin embargo, las implementaciones que no son de CA pueden tratar el campo del número de serie como un BLOB, por lo que serían capaces de manejar números de serie incluso de gran tamaño o codificados incorrectamente.

En términos de gestión de riesgos empresariales, es realmente prudente que una CA limite la cantidad de certificados que puede emitir una única raíz o certificados intermedios. Esto es así, si, por cualquier motivo, tienen que revocar la raíz o el certificado intermedio, solo tendrían que volver a emitir un número menor de certificados en lugar de lo que sucedió a Symantec , en el que un problema con una de sus subsidiarias causa el Los certificados para toda su base de usuarios se revocarán, ya que no hay manera de que los navegadores distingan entre los problemas de certificados de las subsidiarias problemáticas en comparación con los certificados emitidos por las subsidiarias que cumplen con los requisitos.

Esencialmente, se pregunta cuánto texto simple se necesita para obtener la clave privada al realizar una firma RSA o ECDSA, porque tiene el certificado y el hash (algoritmo de firma de entrada) y la firma (salida). Actualmente no hay un ataque prácticamente viable contra estas firmas cuando se usan tamaños de clave comunes. Esto significa que intentar obtener la clave privada de la CA de los certificados que emitió no es un problema en la práctica, independientemente de la cantidad de certificados emitidos.

Sin embargo, los certificados (sub) de CA también se renovarán de vez en cuando porque caducaron o porque el algoritmo de firma utilizado para firmar la CA se considera inseguro.

  

¿Con qué frecuencia las CA renuevan las claves y en qué circunstancias (número de certificados emitidos, tiempo, etc.)?

la pregunta no tiene sentido. El período de renovación de la clave de CA depende de diferentes factores. Por ejemplo, tamaño de clave, seguridad de clave, tamaño de CRL. No existe una correlación directa entre la renovación de la clave de CA y varios certificados firmados.

  

¿Qué sucede con los certificados anteriores que siguen siendo válidos? ¿Se vuelven a firmar con la nueva clave?

no, los certificados emitidos anteriormente no se vuelven a firmar con las nuevas claves de CA. Técnicamente, la renovación de la clave de CA implica una nueva CA con un nombre coincidente "accidentalmente".