¿Cómo puede generar claves de manera segura en AWS?

Este mantra de "baja entropía" es un fracaso. Consulte esta respuesta para obtener más información. El resumen ejecutivo es: algunos programas, en particular /dev/random , pueden reportar una "baja entropía" y bloquearse por razones que no tienen sentido práctico. La idea de "agotarse" la entropía proviene de un modelo matemático que solo tiene vínculos tenues con la realidad, y puede (teóricamente) proporcionar cualquier ganancia de seguridad solo cuando la aleatoriedad se usa para algoritmos de "información teóricamente segura". Los algoritmos habituales, como RSA o AES, no pertenecen a esta clase.

Entonces, lo que debes hacer es lo siguiente:

• OpenSSL normalmente debería usar /dev/urandom , evitando el problema. Si se produce el problema, se manifestará como un comportamiento de "bloqueo" (la generación de claves lleva una cantidad de tiempo anormal, sin utilizar la CPU).
• Si se produce el problema, "rellene" /dev/random con pseudoaleatoriedad reciente, que es lo suficientemente buena . Algo como: dd if=/dev/urandom of=/dev/random bs=1024 count=64

Sin embargo, hay otro problema que no es tan fácil de tratar. Los sistemas en la nube son máquinas virtuales, que pueden ejecutarse simultáneamente con otras máquinas virtuales en el mismo hardware. Cuando dos subprocesos de ejecución se ejecutan en dos núcleos de la misma CPU, incluso si se relacionan con distintas máquinas virtuales, comparten el caché de nivel 1 y pueden espiarse entre sí. La técnica consiste en hacer accesos a la memoria en una matriz que usa las mismas líneas de caché que el código de destino, y reconstruir los secretos de destino al notar cuando algunos elementos de la matriz han sido expulsados de la caché.

Se han demostrado prototipos de trabajo en condiciones de laboratorio. Si se pueden aplicar en una configuración práctica depende de muchos parámetros y actualmente se desconoce. Sin embargo, es plausible . La conclusión es que si hace algo serio con claves, debe esforzarse por ejecutar en su propio hardware, o al menos obtener alguna garantía del proveedor de la nube de que sus máquinas virtuales no compartirán el mismo hardware. Servidores como máquinas virtuales de otros clientes.

El hilo anterior, pero la buena pregunta y las pocas respuestas aquí no siempre son específicas de las máquinas de AWS o incluso de las máquinas virtuales de la nube, como se menciona en la pregunta, por lo que sugeriré echar un vistazo a una recomendación de Lemur equipo, que se aplica a escenarios más amplios: "La cantidad de esfuerzo que desea gastar para garantizar el hecho de que Lemur tiene una buena entropía depende de su tolerancia al riesgo específica y de cómo está configurado Lemur. Si desea generar más entropía para su sistema, le sugerimos que consulte los siguientes recursos: "y continúan recomendando < a href="https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged"> haveged .

Para aquellos interesados en leer más sobre los problemas con baja entropía, el siguiente documento, Un análisis del generador de números aleatorios de OpenSSL , y las referencias, merece una lectura.

  

La capacidad de generar números aleatorios de alta entropía es crucial para la   Generación de claves secretas, vectores de inicialización y otros valores.   de que depende la seguridad de las operaciones criptográficas.

Este artículo, Mejorando semillas aleatorias en Ubuntu 14.04 LTS Cloud Instances , sobre los esfuerzos de Ubuntu para mejorar la entropía en la nube, describe los problemas y las posibles soluciones ( polen ) con mucho más detalle:

  

P: ¿Entonces mi sistema operativo genera una inicialización inicial en el primer arranque?   A: si, pero   Las computadoras son predecibles, especialmente las máquinas virtuales. Las computadoras son inherentemente   determinista Y, por lo tanto, malo en la generación de aleatoriedad Real hardware puede   Proporcionar entropía de calidad. Pero las máquinas virtuales son básicamente clones de   unos a otros

Es posible que la solución Ubuntu aún no cumpla con los requisitos del OP, ya que es una solución de "entropía como servicio", sin embargo (según el desarrollador) es "rápida, eficiente y escalable".

Para pasar de la teoría a la práctica, consulta Prangster si estás interesado en evaluando qué tan bueno es tu PRNG:

  

Ahora nuestro objetivo es determinar la semilla que produjo una muestra dada de   salida pseudoaleatoria, y al hacerlo, concluyen con certeza el uso   de un PRNG inseguro y prepárate para atacar la aplicación que usa   eso. Esta es la función principal de la herramienta Prangster; todo lo que necesita   es la salida y el derecho PRNG y el alfabeto

.

Hay muchos conceptos erróneos y mitos sobre /dev/random o /dev/urandom . No es cierto en general que usar /dev/urandom siempre es lo suficientemente bueno y que /dev/random es solo para paranoicos.

La clave aquí es la cantidad total de entropía recopilada durante la vida útil de la instancia antes de que comiences a generar números. Eso es lo que más importa. Después de la aparición de la instancia (de AMI), el generador aleatorio necesita acumular suficiente entropía para comenzar a producir números indecibles.

Una vez que haya suficiente entropía, puede generar prácticamente "cualquier" cantidad de datos criptográficos a partir de /dev/urandom . Sin embargo, si la entropía recopilada no es suficiente, no hay otra solución que obtenerla primero.

Que /dev/random reduce el contador de entropía es un poco paranoico. Es obligatorio tener un buen generador de rnd que no pueda adivinar el próximo número generado, incluso si publica cualquier cantidad de números previamente generados . Para lograrlo, los generadores utilizan exactamente las mismas construcciones que se encuentran en los algoritmos de cifrado (AES, SHA, etc.). Por lo tanto, si no cree en su primer generador, no puede creer en su cifrado como tal.