BSAFE

Dell BSAFE , anteriormente conocida como RSA BSAFE , es una biblioteca de criptografía validada por FIPS 140-2 , disponible tanto en C como en Java. BSAFE fue creada inicialmente por RSA Security , que fue adquirida por EMC y luego, a su vez, por Dell. Cuando Dell vendió el negocio RSA a Symphony Technology Group en 2020, Dell decidió conservar la línea de productos BSAFE. ^{[1] [2]} BSAFE era uno de los kits de herramientas de cifrado más comunes antes de que expirara la patente de RSA en septiembre de 2000. También contenía implementaciones de los cifrados RC x , siendo el más común el RC4 . De 2004 a 2013, el generador de números aleatorios predeterminado en la biblioteca fue un estándar RNG aprobado por el NIST , ampliamente conocido por ser inseguro desde al menos 2006, que contenía una puerta trasera cleptográfica de la Agencia de Seguridad Nacional estadounidense (NSA), como parte de su programa secreto Bullrun . ^[3] En 2013, Reuters reveló que RSA había recibido un pago de 10 millones de dólares para establecer el algoritmo comprometido como la opción predeterminada. ^[3] El estándar RNG fue posteriormente retirado en 2014, y el RNG fue eliminado de BSAFE a principios de 2015.

Desde 2004 hasta 2013, el generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) predeterminado en BSAFE fue Dual_EC_DRBG , que contenía una supuesta puerta trasera de la NSA , además de ser un CSPRNG sesgado y lento. ^[4] La comunidad criptográfica había estado al tanto de que Dual_EC_DRBG era un CSPRNG muy pobre desde poco después de que se publicara la especificación en 2005, y en 2007 se había hecho evidente que el CSPRNG parecía estar diseñado para contener una puerta trasera oculta para la NSA, utilizable solo por la NSA a través de una clave secreta. ^[5] En 2007, Bruce Schneier describió la puerta trasera como "demasiado obvia para engañar a alguien para que la use". ^[5] La puerta trasera fue confirmada en las filtraciones de Snowden en 2013, y se insinuó que la NSA había pagado a RSA Security 10 millones de dólares para utilizar Dual_EC_DRBG por defecto en 2004, ^[3] aunque RSA Security negó que supiera de la puerta trasera en 2004. El artículo de Reuters que reveló el contrato secreto de 10 millones de dólares para utilizar Dual_EC_DRBG describió el acuerdo como "gestionado por líderes empresariales en lugar de tecnólogos puros". ^[3] RSA Security se ha negado en gran medida a explicar su decisión de seguir utilizando Dual_EC_DRBG incluso después de que se descubrieran los defectos y la puerta trasera potencial en 2006 y 2007, y ha negado haber insertado la puerta trasera a sabiendas. ^[6]

Entonces, ¿por qué RSA eligió Dual_EC como el valor predeterminado? Me has pillado. Dual_EC no sólo es ridículamente lento (lo que tiene consecuencias reales en el rendimiento), sino que se demostró que era un generador de números aleatorios simplemente malo en 2006. En 2007, cuando Shumow y Ferguson plantearon la posibilidad de una puerta trasera en la especificación, ningún criptógrafo sensato se atrevería a acercarse a ello. ¡Y lo peor es que RSA emplea a varios criptógrafos muy distinguidos! Es poco probable que todos se pierdan la noticia sobre Dual_EC.

—  Matthew Green, criptógrafo y profesor de investigación en la Universidad Johns Hopkins, Algunas reflexiones sobre ingeniería criptográfica ^[4] (de después de que se confirmara la puerta trasera, pero antes de que Reuters revelara el acuerdo secreto de 10 millones de dólares).

Como un generador de números aleatorios criptográficamente seguro es a menudo la base de la criptografía, muchos datos cifrados con BSAFE no eran seguros contra la NSA. En concreto, se ha demostrado que la puerta trasera hace que el SSL/ TLS sea completamente descifrable por la parte que tiene la clave privada de la puerta trasera (es decir, la NSA). ^[5] Dado que el gobierno de los EE. UU. y las empresas estadounidenses también han utilizado la vulnerable BSAFE, la NSA podría haber hecho que los datos estadounidenses fueran menos seguros, si se hubiera robado la clave secreta de la NSA para la puerta trasera. También es posible derivar la clave secreta resolviendo una única instancia del problema de la curva elíptica del algoritmo ^[5] (descifrar una instancia de criptografía de curva elíptica se considera poco probable con las computadoras y los algoritmos actuales, pero puede ocurrir un avance).

En junio de 2013, Edward Snowden comenzó a filtrar documentos de la NSA. En noviembre de 2013, RSA cambió el valor predeterminado a HMAC DRBG con SHA-256 como opción predeterminada. El mes siguiente, Reuters publicó el informe basado en las filtraciones de Snowden, en el que se afirmaba que RSA había recibido un pago de 10 millones de dólares para establecer Dual_EC_DRBG como opción predeterminada. ^[3]

Con los lanzamientos posteriores de Crypto-C Micro Edition 4.1.2 (abril de 2016), Micro Edition Suite 4.1.5 (abril de 2016) y Crypto-J 6.2 (marzo de 2015), Dual_EC_DRBG se eliminó por completo.

"Extended Random" fue una extensión propuesta para el protocolo Transport Layer Security (TLS), presentada para su estandarización al IETF por un empleado de la NSA, ^[7] aunque nunca se convirtió en un estándar. La extensión sería inofensiva de otra manera, pero junto con Dual_EC_DRBG, facilitaría el aprovechamiento de la puerta trasera. ^{[8] [9]}

Anteriormente no se sabía que la extensión estuviera habilitada en ninguna implementación, pero en diciembre de 2017, se encontró habilitada en algunos modelos de impresoras Canon , que usan la biblioteca RSA BSAFE, porque el número de extensión entraba en conflicto con una parte de la versión 1.3 de TLS. ^[9]

• Crypto-J es una biblioteca de cifrado de Java. En 1997, RSA Data Security obtuvo la licencia de la biblioteca J/CRYPTO de Baltimore Technologies, con planes de integrarla como parte de su nuevo kit de herramientas de cifrado JSAFE ^[10] y lanzó la primera versión de JSAFE ese mismo año. ^[11] JSAFE 1.0 apareció en la edición de enero de 1998 de la revista Byte . ^[12]
• Cert-J es una biblioteca de software API de infraestructura de clave pública , escrita en Java . Contiene el soporte criptográfico necesario para generar solicitudes de certificados, crear y firmar certificados digitales , y crear y distribuir listas de revocación de certificados . A partir de Cert-J 6.2.4, toda la API ha quedado obsoleta en favor de una funcionalidad similar proporcionada por la API BSAFE Crypto-J JCE .
• BSAFE Crypto-C Micro Edition (Crypto-C ME) se lanzó inicialmente en junio de 2001 con el nombre "RSA BSAFE Wireless Core 1.0". La versión inicial estaba destinada a Microsoft Windows , EPOC , Linux , Solaris y Palm OS .
• BSAFE Micro Edition Suite es un SDK de criptografía en C. BSAFE Micro Edition Suite se anunció inicialmente en febrero de 2002 ^[13] como una oferta combinada de BSAFE SSL-C Micro Edition, BSAFE Cert-C Micro Edition y BSAFE Crypto-C Micro Edition. Tanto SSL-C Micro Edition como Cert-C Micro Edition alcanzaron el fin de su vida útil en septiembre de 2014, mientras que Micro Edition Suite sigue siendo compatible con Crypto-C Micro Edition como su proveedor criptográfico validado por FIPS .
• SSL-C es un conjunto de herramientas SSL de la suite BSAFE. Fue escrito originalmente por Eric A. Young y Tim J. Hudson, como una bifurcación de la biblioteca abierta SSLeay , que desarrollaron antes de unirse a RSA. ^{[14] [15]} SSL-C llegó al final de su vida útil en diciembre de 2016.
• SSL-J es un kit de herramientas Java que implementa TLS . SSL-J se lanzó como parte de la oferta inicial de productos RSA JSAFE en 1997. ^[16] Crypto-J es el proveedor criptográfico predeterminado de SSL-J.

El 25 de noviembre de 2015, RSA anunció las fechas de fin de vida útil (EOL) para BSAFE. ^[17] El fin del soporte primario (EOPS) se alcanzaría el 31 de enero de 2017, y el fin del soporte extendido (EOXS) se fijó originalmente para el 31 de enero de 2019. Esa fecha fue extendida posteriormente por RSA para algunas versiones hasta el 31 de enero de 2022. ^[18] Durante el soporte extendido, a pesar de que la política de soporte establecía que solo se solucionarían los problemas más graves, se lanzaron nuevas versiones que contenían correcciones de errores, correcciones de seguridad y nuevos algoritmos. ^[19]

El 12 de diciembre de 2020, Dell anunció la revocación de la decisión anterior de RSA, lo que permite el soporte de productos BSAFE más allá de enero de 2022, así como la posibilidad de adquirir nuevas licencias en breve. Dell también anunció que estaba cambiando el nombre de los kits de herramientas a Dell BSAFE . ^[20]

• Página de soporte de BSAFE Cert-J
• Página de soporte de BSAFE Crypto-J
• Página de soporte de BSAFE SSL-J
• Página de soporte de BSAFE Crypto-C Micro Edition
• Página de soporte de BSAFE Micro Edition Suite