Sí, existe un riesgo aquí, aunque su alcance está casi totalmente limitado a la red / usuarios de dichos dispositivos proxy / firewall. La baja entropía también podría tener un efecto menor en el cliente nonce en el protocolo de enlace TLS que afecta a las conexiones salientes desde el dispositivo proxy / firewall.
La baja entropía puede significar números primos adivinables, lo que significa claves privadas adivinables, que pueden conducir a ataques MITM viables. Si hay un problema de baja entropía en un sistema de este tipo y la clave de CA es lo primero que se genera, entonces usted puede tener un problema real .
(Hay un beartrap obvio con dichos sistemas si se utiliza una clave / CA proporcionada por el proveedor o compartida, pero eso es bastante problema diferente.)
Generalmente, se asigna un mayor riesgo a los problemas de verificación de la cadena y la revocación, y una configuración deficiente que lleva al uso de sistemas de cifrado o cifrado SSL no seguros, consulte el CERT de EE. UU. TA17-075A La intercepción de HTTPS debilita la seguridad de TLS (a esto agregaría una protección insuficiente de las claves privadas, aunque al menos un producto comercial admite HSM, aunque Sospecho que solo funciona para la CA interna en lugar de los certificados a pedido).
El problema potencial aquí es que si la entropía es baja, los números primos pueden ser predecibles, pero esto solo no hace que el módulo sea más fácil de factorizar (para determinar la clave privada). Hace hace hacer viable un ataque de fuerza bruta, en este caso la entrada de PRNG de fuerza bruta (el el atacante sabe el PRNG) para intentar descubrir un primo (y, por lo tanto, una clave) que está en uso.
Si resulta que usted es un administrador malvado con acceso a un proxy de tal forma que puede recopilar claves y certificados, entonces tiene el paquete de apilado su favor si ataca el proxy de otra persona.
Como usuario malvado, puede generar suficiente tráfico para encontrar colisiones, pero esto es menos interesante.
En la práctica (ciertamente en el caso de OpenSSL) se usa un PRNG para generar el material fuente clave (para buscar números primos ), por lo que se requiere muy poca entropía" real ". Por lo general, un proxy es un buen candidato para capturar la entropía de los eventos de sincronización y hardware (red y disco potencialmente ocupados, con muchas conexiones aleatorias).
Estimo que aproximadamente 90-100 kB de salida de PRNG generalmente se requeriría para una generación de clave de 2048 bits (2x primos de 1024 bits, con un algoritmo de generación / prueba / descarte ingenuo), que requiere solo un puñado de bytes no PRNG de la entropía "real" a la semilla (32 bytes por observación). El retraso en la generación de claves es en realidad la prueba de primalidad .
Para las implicaciones de las claves de baja entropía, puede leer el documento (titulado ingeniosamente) Extracción de sus Ps y Qs: Detección de claves débiles generalizadas en dispositivos de red (PDF).
Hay dos documentos útiles que tratan los problemas de seguridad relacionados con el uso de dichos servidores proxy:
Esto plantea muchos otros problemas de seguridad, pero la aleatoriedad / entropía solo se menciona brevemente en el segundo:
Entropía durante la generación.
Es posible que la entropía.
utilizado durante la generación de un nuevo par de claves pública / privada
En el momento de la instalación, los certificados generados son inadecuados. En la práctica,
Ya que la mayoría de los productos que analizamos generan un certificado raíz.
con claves RSA usando OpenSSL, el proceso de generación es
Se espera que llame a ciertas funciones conocidas, por ejemplo, RAND_seed (),
RAND_event (), RSA_generate_key_ex (); encontramos
Llamadas a la última función en muchos casos. Sin embargo, no lo hicimos
Investigue más a fondo el algoritmo de generación de claves en los ACC.
Ver también: