¿Qué tan negativos son las máquinas virtuales (vms) a / dev / urandom?

Question

¿Qué tan negativos son las máquinas virtuales (vms) a / dev / urandom?

#1 de Tom Leek (6 votos)

2

Observé las preguntas aquí y aquí .

Esto despertó mi interés ya que recientemente he estado involucrado con el análisis de la conformidad con FIPS, y en mi entorno vm / dev / urandom, las pruebas generan datos como este:

[admin@xxx~]$ cat /dev/urandom | rngtest -c 5000
rngtest 2
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 100000032
rngtest: FIPS 140-2 successes: 4998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.210; avg=63.902; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=2.477; avg=123.448; max=157.632)Mibits/s
rngtest: Program run time: 2277143 microseconds

Lo que falta en estas preguntas es: ¿qué tan malo es malo ? ¿Tenemos números firmes que dictan el cumplimiento estadístico?

¿Qué tan mal se mueve a una máquina virtual dañando la entropía?

cryptography encryption linux entropy fips

pregunta avgvstvs 17.10.2014 - 21:22

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography encryption linux entropy fips

¿Se puede guardar el virus en la tarjeta SIM? ¿Cómo respondo a un servidor de correo no deseado que invalida mis tokens? [duplicar]

score 6 · Accepted Answer

Las pruebas estadísticas como la que utiliza no pueden detectar si /dev/urandom es bueno o malo en una máquina específica.

Específicamente, /dev/urandom ejecuta un PRNG criptográficamente seguro . A partir de un estado interno inicial dado (la "semilla"), produce un flujo arbitrariamente largo de bytes aparentemente aleatorios. El hecho de que el PRNG sea criptográficamente seguro significa que para que un atacante realmente prediga el siguiente bit con probabilidad mejor que 1/2, DEBE haber adivinado el estado interno exacto (hasta el último bit); de lo contrario, no tiene nada.

El riesgo de /dev/urandom en una VM se relaciona con la posibilidad teórica de que el atacante pueda adivinar ese estado, ya que el estado se alimenta de fuentes de hardware y una VM no tiene hardware verdadero, solo hardware emulado. Sin embargo, esto requiere un atacante inteligente que sepa perfectamente que el PRNG es el usd por /dev/urandom en esta máquina específica, y el atacante intenta intencionalmente estados internos potenciales basados en lo que sabe sobre el hardware emulado y lo que extrae el sistema operativo como " semilla aleatoria "de ese hardware. Su rngtest no hace nada por el estilo; ejecuta pruebas estadísticas básicas para ver si hay sesgos en un flujo de 100 Mbits.

Para resumir: rngtest no prueba lo importante, que es la cantidad de semilla que es difícil de adivinar por un atacante inteligente. En cambio, rngtest mide qué tan bien el algoritmo PRNG criptográficamente seguro es criptográficamente seguro; y solo lo hace básicamente (no puede ver nada excepto los sesgos más obvios). Por naturaleza, rngtest no puede detectar ningún problema relacionado con la máquina virtual con /dev/urandom (y, en consecuencia, es bastante inútil ejecutarlo).