cryptography - simulacion - numeros pseudoaleatorios
¿Cuál es el impacto de la virtualización en generadores de números aleatorios criptográficamente fuertes? (3)
/ dev / random y / dev / urandom usan ruido ambiental para generar aleatoriedad.
Con un servidor virtualizado puede haber varias instancias de un sistema operativo en una configuración de hardware. Todos estos sistemas operativos obtendrán su aleatoriedad del mismo ruido ambiental.
¿Significa esto como un grupo la fuerza de los generadores de números aleatorios se reduce ya que todas las instancias del sistema operativo basan sus cálculos en la misma entrada? O bien, ¿está el ruido ambiental dividido para que no se comparta?
Si esto último es cierto, puedo ver que esto reduce la efectividad de / dev / urandom porque reutiliza su grupo interno y con menos información ambiental, reduce la entropía.
/ dev / random debería estar bien porque bloquea hasta que se adquiera suficiente ruido ... a menos que, por supuesto, todas las instancias del SO compartan la entrada.
Entonces, la pregunta: ¿Cuál es el impacto de la virtualización en generadores de números aleatorios criptográficamente fuertes, específicamente aquellos que usan ruido ambiental?
No pude encontrar ninguna referencia rápidamente, pero me parece que la entropía se deriva de las estructuras de datos del kernel para los dispositivos, no de los dispositivos mismos. Dado que estos serían independientes independientemente de la virtualización, sospecho que la respuesta no es mucho.
[EDITAR] Después de leer el origen del kernel (en realidad el historial del parche), parece que Linux, al menos, reúne entropía de las pulsaciones del teclado, la actividad del mouse, el tiempo de interrupción (pero no todas las interrupciones) y bloquea los tiempos de finalización de solicitud del dispositivo. En un sistema virtualizado, sospecho que los eventos de mouse / teclado serían bastante bajos y, por lo tanto, no contribuirían a la entropía reunida. Presumiblemente, esto se vería compensado por una actividad de interrupción de E / S de red adicional, pero no está claro. En este sentido, no creo que difiera mucho del servidor que no es VM.
Gracias.
Por lo que entiendo, un sistema que depende de la E / S de red para la entropía es susceptible al hombre en los ataques intermedios. Encontré el siguiente artículo que analiza las fuentes apropiadas de entropía. Su sugerencia es eliminar la E / S de red del kernel de Linux debido a su susceptibilidad.
Creo que eso significa que existe la posibilidad de explotar el hardware común en un entorno virtualizado. La posibilidad aumenta si se usa la E / S de red. De lo contrario, es lo suficientemente bajo como para no ser una preocupación para todas las aplicaciones salvo las más seguras. En tales casos, probablemente sea más seguro alojar su propia aplicación de todos modos.
Por definición, la aleatoriedad de un PRNG criptográficamente fuerte no debería verse afectada por la virtualización. Como mencionas, la diferencia entre / dev / random y / dev / urandom [ref: http://en.wikipedia.org/wiki/Urandom/] es que una operación de lectura en / dev / random bloqueará si el sistema tiene reunió una entropía insuficiente para producir la cantidad deseada de datos aleatorios. También puede escribir en / dev / random para mezclar sus propios datos en el grupo de entropía.