Hay varios factores en juego aquí:
- El mecanismo físico de HRNG utilizado dentro del microprocesador ARM.
- La lógica de soporte en el silicio dentro del microprocesador.
- El microcódigo implementado en el microprocesador.
- La implementación del RNG dentro de Linux.
Según el fabricante, ese chip en particular utiliza el ruido de un transistor de polarización inversa, en un diseño HRNG de colector abierto. Este es precisamente el hardware que estoy usando en mi proyecto HRNG actual, pero mucho más pequeño. Es una de las formas más baratas de implementar un HRNG directamente en silicio; mientras que estoy usando transistores discretos, el procesador ARM simplemente reduce esto a unas pocas señales de silicio en el chip chip.
Sabemos que este mecanismo es una fuente importante de aleatoriedad, porque se basa en un fenómeno llamado túnel cuántico , que se sabe que es probabilístico y aleatorio. La idea básica es que los electrones "saltan" al azar sobre el intervalo de banda dentro del transistor, lo que lleva a una señal fluctuante al azar. Luego podemos amplificar esto (el amplificador de transistor PNP simple funcionará) e interpretar la salida como un 1 o un 0 muestreando el resultado a una frecuencia fija: si supera un cierto umbral, es un 1, de lo contrario es un 0.
Una ligera deficiencia de este mecanismo es que cualquier fuga de CC provocará un sesgo hacia 1s que aparece más a menudo que 0s. Para solucionar esto, podemos usar un simple truco llamado descorrelación de von Neumann, que esencialmente implica codificar los pares de bits 01 y 10 a 0 y 1 respectivamente, e ignorar todos los 00 y 11 pares. Esto produce un flujo estadísticamente imparcial.
Es casi seguro que puedo garantizar que este es el mecanismo por el cual produce números aleatorios. Hay una alternativa importante (dos puertas NOT con polarización inversa en paralelo) pero está cubierta por una patente de Intel, así que dudo que ARM esté usando eso. Desafortunadamente, la única forma de saberlo con certeza es tomar un poco de ácido y destapar un chip, luego tomar un microscopio y comenzar a aplicar ingeniería inversa al silicio. No tengo el equipo de repuesto disponible para esto.
La vulnerabilidad potencial que puede encontrar en dicha exploración es que las señales del reloj de alta frecuencia u otras líneas de datos de HF se enrutan muy cerca del HRNG o su lógica de soporte, lo que lleva a un potencial de interferencia. Esto suele ser poco probable en los circuitos integrados, pero estamos hablando de aplicaciones de alta sensibilidad aquí, por lo que vale la pena buscarlo. Sin embargo, incluso si fuera el caso, no veo que ofrezca un sesgo útil desde una perspectiva criptoanalítica.
El siguiente potencial de explotación es microcódigo. Recientemente, un investigador demostró que era posible parchear el microcódigo para que los procesadores Intel buscaran patrones únicos en el búfer de instrucciones y detectar cuándo se estaba utilizando la instrucción RDRAND para completar el conjunto /dev/random . Luego identificaría la posición de ese búfer de agrupación en el caché del procesador y efectivamente la pondría a cero, haciendo que la agrupación de cero se vuelva a copiar en la memoria del sistema. Esto significaba que /dev/random emitiría constantemente el mismo valor controlado por el atacante, con resultados obviamente devastadores. Si se empleara un truco similar pero más sutil en el microcódigo ARM, podría ser posible reducir masivamente la entropía del HRNG de una manera que solo sea conocida por el creador del parche. Detectar tales trucos sería difícil, pero podría hacerse extrayendo el microcódigo y analizándolo.
Finalmente, el último problema es el diseño RNG dentro del kernel de Linux. La agrupación /dev/random generalmente se alimenta de un grupo de fuentes basadas en estado, utilizando un algoritmo de mezcla que se basa en una función criptográfica. Sin embargo, cuando RDRAND o instrucciones similares están disponibles, el motor simplemente almacena los datos en la agrupación. Esto no es exactamente una buena idea, ya que facilita la conexión de los datos de la agrupación de manera significativa mediante la producción de ciertos valores. Si se usara la función de mezcla más fuerte, el atacante tendría que romper eso (o hacer algo más visible) para obtener un control significativo sobre la piscina.
No hay una respuesta obvia a tu pregunta. Los generadores de números aleatorios de hardware pueden ser de muy alta calidad, pero es difícil analizar su implementación dado solo un dispositivo de consumidor. Dicho esto, si vas a desconfiar de tu hardware, no puedes hacer ninguna garantía en primer lugar. Si desea limitar el alcance de la desconfianza por completo a la calidad de los números aleatorios producidos, entonces diseñe su sistema de soporte alrededor de ese hecho.