¿Qué exige este criterio?
La calidad de la aleatoriedad es fundamental para la seguridad de todo el sistema. Los requisitos son: (1) para claves y tokens: usar el TRNG del HSM; (2) para nonces y IVs en código de aplicación: usar /dev/urandom, CryptGenRandom o equivalente del SO; (3) nunca usar rand() de C, Math.random() de JavaScript u otras fuentes no criptográficas; (4) el CSPRNG debe estar debidamente inicializado con entropía del sistema.

¿Qué hay que revisar al cliente?

• Generación de claves: ¿usa el TRNG del HSM?
• Generación de serialNumbers de tokens: ¿usa CSPRNG?
• Generación de IVs/nonces en la aplicación: ¿usa /dev/urandom o equivalente?
• Ausencia de uso de rand() u otras fuentes no criptográficas.
• Inicialización del CSPRNG con entropía suficiente del SO.

Preguntas clave para las entrevistas

• ¿Las claves del servicio se generan con el TRNG del HSM?
• ¿Los serialNumbers de los tokens se generan con un CSPRNG validado?
• ¿Se ha revisado el código para detectar usos de rand() o Math.random() en contextos criptográficos?

¿Por qué es esencial para QERDS y TSA?
Una fuente de aleatoriedad débil puede comprometer todas las claves generadas y por tanto todo el sistema criptográfico. Es el tipo de vulnerabilidad más difícil de detectar en auditoría (requiere revisión de código o pruebas estadísticas) pero uno de los más catastróficos si se explota.

Evidencia que demostraría conformidad

• Especificación del TRNG del HSM y su uso en la generación de claves.
• Revisión de código para uso correcto de CSPRNG.
• Documentación de fuentes de aleatoriedad por componente.