Mostrar Mensajes
De primeras creo que todos sabemos que se considera inseguro el uso de criptografía asímetrica basada en curvas elípticas segun en que plataforma suceda el intercambio de claves. Cuando el NIST introdujo los estándares para módulos criptográficos entre todas las funcionalidades aprobadas definieron cuatro algorítmos criptográficos de generación de números aleatorios (CRNGs).
Unos ingenieros de Microsoft se percataron de que el algoritmo Dual_EC_DRBG (generador de números aleatorio determinista para curvas elípticas) era totalmente reversible ya que el estándar proporcionaba ciertas constantes ("hardcodeadas") que permiten al propietario obtener el estado del mismo, de esta forma es muy fácil determinar el valor de salida final. De aquí se armaron muchas polemicas entre ellas que la NSA pagó a RSA para que conviertiera en predeterminado dicho algoritmo. Todo esto es debido a que la NSA revisa los estándares antes de ser aprobados por el NIST.
Se recomienda migrar a cualquiera de los tres algoritmos CRNG restantes, si es que la plataforma lo soporta.
Os dejo una lista de todas las plataformas que incluyen los algoritmos de generación de números aleatorios deterministas aprobados por el NIST.
Lista: http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html
Info de algoritmos soportados en Windows + docu de uso y parametrización de la API -> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1891.pdf
Info de modulos de criptográficos de Windows aprobados por el FIPS -> https://technet.microsoft.com/en-us/library/security/cc750357.aspx#_CNG_Validated_Cryptographic
Sí, entre ellos destacan Cisco, BSAFE, OpenSSL y Windows, como no. Lo mejor de esta lista es que la documentación es descargable y puedes examinar que modulos de user-mode y kernel-mode hacen uso de dichos algoritmos. El predeterminado en Windows en la funcion BCryptGenRandom() es CRT_DBG (AES-256 counter mode).
Cito de la MSDN concretamente la funcion BCryptGenRandom()
Citar
The default random number provider implements an algorithm for generating random numbers that complies with the NIST SP800-90 standard, specifically the CTR_DRBG portion of that standard.
He de decir que la entropía proporcionada por la función del kernel SystemPrng() para la generación de la seed es bastante buena, podeis revisarlo en uno de los pdfs de la lista del NIST, el relacionado al driver CNG.sys. Mas info en -> Pág. 19 de http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1891.pdf
A partir de aqui entra la paranoia y el riesgo del espionaje por parte de ya sabemos quien. Hay muchas funciones en la documentación de Windows que no están explicadas al 100%, mucha nube negra. Mi humilde opinión al respecto es utilizar librerías que no implementen Dual_EC_DRBG, curiosamente OpenSSL falló al implementarlo así que permaneció inmune. Eso o hookear el sistema para verificar el paso de parámetros y las llamadas a la Crypto API.
Otra historia es como la gente utilice la criptografía para proteger las comunicaciones en sus plataformas, sólo el 18% de las páginas de internet se consideran seguras o no son vulnerables a ataques conocidos. Sólo decir que uno recoge lo que siembra... Mas info en: https://www.trustworthyinternet.org/ssl-pulse/
Cambiando de tema, con esto no quiero decir que las curvas elípticas sean vulnerables ni mucho menos, son superiores a los métodos de intercambio de claves actuales ya que proveen de perfect forward secrecy, constan de un tamaño de clave inferior a Diffie-Hellman, DSA o RSA pero la complejidad computacional que requieren es similar a la de los algoritmos ya citados. Simplemente deben de utilizarse correctamente.
Sobre DSA parece limpio pero no lo he estudiado a fondo, prefiero RSA para la autenticación ya que lo tengo estudiado. Analicé la entropia en Windows sobre la generación del par de números primos (p,q) para RSA y está perfecta, guardan una distancia suficiente grande que no facilita para la posibilidad de hacer criba para rebajar el problema de factorización.
Sobre PKI que decir, mil cosas, los certificados han tenido problemas desde su inicio y el estándar apenas ha mejorado en consideración con sus orígenes. Si os interesa el tema buscad sobre los ataques a: Basic Constraints, Null-Prefix attacks, MD5 Collision & rogue root CA y mi favorito -> http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf. Este último pdf simplemente habla de desastres en librerías criptográficas muy extendidas en pasarelas de pago como PayPal, apps de Android, iOS etc Como dije antes uno recoge lo que siembra. Quien rompe PKI rompe TLS, ya que el cliente aceptaría el certificado presentado por el atacante y se establecería la conexión con el mismo (MITM).
Para terminar, sólo decir que de aquí puede salir un buen debate jeje.
Saludos!
jejej
