CryptGenRandom es una función de generación de números pseudoaleatorios criptográficamente segura . Se incluye en la interfaz de programación de aplicaciones criptográficas de Microsoft . Microsoft recomienda usarlo en todos los programas Win32 que requieren generación de números aleatorios. En 2007, un documento de la Universidad Hebrea señaló problemas en la implementación de CryptGenRandom en Windows 2000 (suponiendo que el criptoanalista tuviera acceso a la máquina). Posteriormente, Microsoft determinó que estos problemas también estaban presentes en Windows XP , y en Windows Vista ya no se observaron. Estos errores se solucionaron con el lanzamiento de Windows XP Service Pack 3 a mediados de 2008. [una]
La API de Win32 es totalmente compatible con los métodos de protección contra ataques criptográficos, incluidos TLS y firma digital . Este soporte se basa en bibliotecas nativas de Windows para tareas criptográficas como la generación de claves para algoritmos RSA o AES . Estas bibliotecas utilizan un generador de números pseudoaleatorios criptográficamente fuerte. CryptGenRandom es el generador estándar de este tipo para el entorno de desarrollo Win32.
Microsoft usa una implementación de CryptGenRandom basada en alguna función "RtlGenRandom" incorporada. [2] En 2007, solo se publicó un esquema general del funcionamiento de este algoritmo:
[ RtlGenRandom ] funciona como se especifica en FIPS 186-2 Apéndice 3.1 usando SHA-1 como la función G. Las fuentes de entropía son:
[omitido: larga lista de contadores y elementos de información de bajo nivel] Fuente: Writing Secure Code, segunda edición. isbn=0-7356-1722-8 (inglés) .
La estabilidad criptográfica de los generadores de números aleatorios es muy importante, ya que dichos generadores están directamente involucrados en la creación de claves dinámicas. Las claves que se necesitan sobre la marcha (por ejemplo, claves de sesión AES TLS para asegurar sesiones HTTPS en sitios bancarios) también se calculan utilizando estos generadores. Así, la previsibilidad del comportamiento de los generadores permite directamente predecir los valores de las claves generadas. Dado que CryptGenRandom es, de hecho, el generador estándar en el entorno Win32, su seguridad es fundamental para los usuarios de Windows.
Las características del algoritmo CryptGenRandom no se han publicado oficialmente. Como cualquier algoritmo de generación de números aleatorios no publicado, CryptGenRandom puede ser teóricamente vulnerable debido al uso de algoritmos obsoletos o, por ejemplo, al uso de varios contadores de entropía monotónicos que pueden ser utilizados por un criptoanalista con acceso al sistema.
En 2007, Leo Dorrendorf, junto con un grupo de científicos de la Universidad Hebrea y la Universidad de Haifa, publicaron los resultados del criptoanálisis CryptGenRandom , revelando importantes vulnerabilidades en la implementación del algoritmo bajo Windows 2000. [3]
Para explotar estas vulnerabilidades, un atacante necesitaría comprometer un programa en ejecución que usa este generador de números aleatorios. Todas las deficiencias de CryptGenRandom dependen del sifón de los bits de estado del generador. Si un atacante puede realizar este ataque, entonces, con un alto grado de probabilidad, puede romper cualquier generador de números aleatorios (por ejemplo, puede simplemente repetir los valores de salida del generador o corregirlos directamente en la memoria con valores ya conocidos). Sin embargo, los científicos de la Universidad Hebrea descubrieron que un criptoanalista solo necesita conocer los bits de estado una vez para asestar un duro golpe a la seguridad de CryptGenRandom. Luego, un atacante puede usar la información del bit de estado para recuperar los números generados por el algoritmo durante ejecuciones anteriores y, por lo tanto, obtener acceso a información potencialmente confidencial, como números de tarjetas de crédito ya enviados. Esto es posible porque CryptGenRandom usa el cifrado de flujo RC4 , que es reversible si hay al menos un estado conocido. Se ha observado que CryptGenRandom se ejecuta en modo de usuario , lo que permite que cualquier persona con acceso de nivel de usuario al sistema operativo obtenga información sobre el estado de CryptGenRandom para ese proceso, por ejemplo, mediante un desbordamiento de búfer . Finalmente, CryptGenRandom rara vez actualiza las fuentes para calcular la entropía. El problema se ve agravado por el hecho de que cada proceso Win32 tiene su propia instancia de estados CryptGenRandom. Tal independencia de procesos solo aumenta el tiempo de uso no autorizado del sistema después de un hackeo exitoso. El análisis realizado por un grupo de científicos liderado por Dorrendorf es, de hecho, el primer trabajo publicado sobre el funcionamiento de un generador de números aleatorios criptográficamente fuerte bajo Windows.
Windows 2000, XP y Windows 2003 , incluidas las implementaciones de CryptGenRandom() y FIPSGenRandom(), pasaron satisfactoriamente las pruebas EAL4+. La verificación de seguridad de los algoritmos reveló el pleno cumplimiento de los estándares EAL4 requeridos, la documentación está disponible en el portal Common Criteria . De esto podemos concluir que el probado sistema de verificación EAL4 funciona bien en la mayoría de los casos, pero no incluye un criptoanálisis más profundo.
Las siguientes implementaciones de los generadores de números aleatorios de Microsoft se han probado con éxito: Windows Vista (Certificado 321) Windows 2003 Enhanced Cryptographic Provider (rsaenh.dll) (Certificado 316) Windows 2003 Enhanced DSS y Diffie-Hellman Cryptographic Provider (dssenh.dll) (Certificado 314) Módulo criptográfico en modo kernel de Windows 2003 (fips.sys) (Certificado 313) Proveedor criptográfico mejorado de Windows CE y Windows Mobile (rsaenh.dll) (Certificado 292) Proveedor criptográfico mejorado de Windows CE y Windows Mobile (rsaenh.dll) (Certificado 286) ) Proveedor criptográfico mejorado de Windows CE (rsaenh.dll) (Certificado 66)
Estas pruebas están “destinadas a verificar el cumplimiento de varias especificaciones aprobadas de generadores de números aleatorios, y no a evaluar el nivel de seguridad del producto. […] Por lo tanto, la verificación no debe interpretarse como una evaluación o aprobación de la seguridad general del producto.” De esto podemos concluir que dichas comprobaciones pueden pasar por alto algunas características de los generadores de números aleatorios (por ejemplo, utilizados por un grupo de científicos de la Universidad Hebrea). [cuatro]
Hay una serie de utilidades para acceder al código fuente de los programas de Microsoft (generalmente protegidos por EULA), pero no es posible compartir este mismo código con el público.
Las bibliotecas para plataformas Windows se pueden desarmar usando herramientas como IDA Pro y objdump . Además, a diferencia de la mayoría de los proveedores de software de código cerrado, Microsoft proporciona símbolos de depuración para sus archivos binarios. Como resultado, estos archivos a menudo son evaluados por prácticas de terceros. El ataque de Dorrendorf mencionado anteriormente se basó precisamente en tales enfrentamientos.
Los desarrolladores de Windows tienen varios medios alternativos para acceder a las funciones de CryptGenRandom. Estas opciones invocan el mismo algoritmo, tienen el mismo nivel de seguridad, pero también pueden tener otros beneficios.
Usando RtlGenRandom“Históricamente, siempre les hemos dicho a los desarrolladores que no usen funciones como rand() para generar claves y contraseñas. Es mucho mejor usar funciones como CryptGenRandom, que son generadores de números aleatorios criptográficamente fuertes. El problema de usar CryptGenRandom está relacionado con la necesidad de conectar CryptoAPI (CryptAcquireContext y similares), que, sin embargo, es aceptable si ya usa otras funciones de CryptoAPI. De forma predeterminada en Windows XP, CryptGenRandom llama a la función ADVAPI32!RtlGenRandom, que no requiere que se incluya todo el conjunto de CryptAPI. De hecho, la nueva función Whidbey CRT rand_s() llama a RtlGenRandom. [5]
Usando RNGCryptoServiceProviderLos programadores de .Net deben usar la clase RNGCryptoServiceProvider. [6]