RSA SecurID

RSA SecurID es un mecanismo desarrollado por RSA para realizar la autenticación de dos factores de un usuario para acceder a un recurso de red.

El mecanismo de autenticación RSA SecurID consiste en un " token " —ya sea de hardware (por ejemplo, un llavero ) o de software (un token virtual )— que se asigna a un usuario de computadora y que crea un código de autenticación a intervalos fijos (generalmente 60 segundos) utilizando un reloj integrado y la clave casi aleatoria codificada de fábrica de la tarjeta (conocida como "semilla"). La semilla es diferente para cada token y se carga en el servidor RSA SecurID correspondiente (RSA Authentication Manager, anteriormente ACE/Server ^{[ 1 ]} ) cuando se compran los tokens. ^{[ 2 ]} También están disponibles tokens bajo demanda, que proporcionan un código de token por correo electrónico o SMS, eliminando la necesidad de proporcionar un token al usuario.

El hardware del token está diseñado para ser resistente a manipulaciones y así evitar la ingeniería inversa . Cuando aparecieron en el mercado implementaciones de software del mismo algoritmo ("tokens de software"), la comunidad de seguridad había desarrollado código público que permitía a un usuario emular RSA SecurID en software, pero solo si tenía acceso a un código RSA SecurID actual y al archivo semilla RSA SecurID original de 64 bits introducido en el servidor. ^{[ 3 ]} Posteriormente, el algoritmo RSA SecurID de 128 bits se publicó como parte de una biblioteca de código abierto. ^{[ 4 ]} En el esquema de autenticación RSA SecurID, el registro semilla es la clave secreta utilizada para generar contraseñas de un solo uso . Las versiones más recientes también incluyen un conector USB, que permite utilizar el token como un dispositivo similar a una tarjeta inteligente para almacenar certificados de forma segura . ^{[ 5 ]}

Un usuario que se autentica en un recurso de red —por ejemplo, un servidor de acceso telefónico o un cortafuegos— necesita introducir tanto su número de identificación personal como el número que se muestra en ese momento en su token RSA SecurID. Aunque cada vez es menos frecuente, algunos sistemas que utilizan RSA SecurID prescinden por completo de la implementación del PIN y se basan en combinaciones de contraseña y código RSA SecurID. El servidor, que también dispone de un reloj en tiempo real y una base de datos de tarjetas válidas con sus registros de clave asociados, autentica al usuario calculando el número que el token debería mostrar en ese momento y comparándolo con el que introdujo el usuario.

En versiones anteriores de SecurID, se podía usar un "PIN de coacción", un código alternativo que generaba un registro de eventos de seguridad que indicaba que un usuario se había visto obligado a introducir su PIN, a la vez que proporcionaba una autenticación transparente. ^{[ 6 ]} El uso del PIN de coacción permitía una autenticación exitosa, tras la cual el token se desactivaba automáticamente. La función de "PIN de coacción" está obsoleta y no está disponible en las versiones compatibles actualmente.

Si bien el sistema RSA SecurID añade una capa de seguridad a la red, pueden surgir problemas si el reloj del servidor de autenticación se desincroniza con el reloj integrado en los tokens de autenticación. El servidor compensa automáticamente la desviación normal del reloj de los tokens ajustando un valor de "deriva" almacenado a lo largo del tiempo. Si la desincronización no se debe a la desviación normal del reloj del hardware del token, la corrección de la sincronización entre el reloj del servidor de Authentication Manager y el token (o tokens) desincronizado puede realizarse de varias maneras. Si el reloj del servidor se ha desincronizado y el administrador ha modificado el reloj del sistema, los tokens pueden resincronizarse uno a uno o bien se pueden ajustar manualmente los valores de deriva almacenados. La corrección de la desviación puede realizarse en tokens individuales o en bloque mediante una utilidad de línea de comandos.

RSA Security ha impulsado una iniciativa llamada "Autenticación Ubicua", asociándose con fabricantes de dispositivos como IronKey , SanDisk , Motorola , Freescale Semiconductor , Redcannon, Broadcom y BlackBerry para integrar el software SecurID en dispositivos cotidianos como unidades flash USB y teléfonos celulares, para reducir el costo y la cantidad de objetos que el usuario debe llevar consigo. ^{[ 7 ]}

Los códigos de token son fáciles de robar, ya que no existe autenticación mutua (cualquier cosa que pueda robar una contraseña también puede robar un código de token). Esto es importante, puesto que es la principal amenaza que la mayoría de los usuarios creen estar solucionando con esta tecnología.

La vulnerabilidad práctica más simple de cualquier contenedor de contraseñas es la pérdida del dispositivo de llave especial o del teléfono inteligente activado con la función de llave integrada. Esta vulnerabilidad no se puede solucionar con un solo dispositivo contenedor de tokens dentro del plazo de activación preestablecido. Cualquier otra consideración implica la prevención de pérdidas, por ejemplo, mediante una correa electrónica adicional o un sensor corporal y una alarma.

Si bien los tokens RSA SecurID ofrecen cierto nivel de protección contra ataques de repetición de contraseñas , no están diseñados para proteger contra ataques de intermediario ( man-in-the-middle) cuando se usan solos. Si el atacante logra impedir que el usuario autorizado se autentique en el servidor hasta que el siguiente código de token sea válido, podrá iniciar sesión. El análisis basado en riesgos (RBA), una nueva función de la última versión (8.0), proporciona una protección significativa contra este tipo de ataque si el usuario está habilitado y se autentica en un agente compatible con RBA. RSA SecurID no previene los ataques de intermediario en el navegador (MitB).

El servidor de autenticación SecurID intenta evitar la interceptación de contraseñas y el inicio de sesión simultáneo rechazando ambas solicitudes de autenticación si se presentan dos credenciales válidas dentro de un período de tiempo determinado. Esto se ha documentado en una publicación no verificada de John G. Brainard. ^{[ 8 ]} Sin embargo, si el atacante elimina la capacidad de autenticación del usuario, el servidor SecurID asumirá que es el usuario quien se está autenticando y, por lo tanto, permitirá la autenticación del atacante. Bajo este modelo de ataque, la seguridad del sistema se puede mejorar utilizando mecanismos de cifrado/autenticación como SSL .

Aunque los tokens blandos pueden ser más convenientes, los críticos indican que la propiedad de resistencia a la manipulación de los tokens duros no tiene parangón en las implementaciones de tokens blandos, ^{[ 9 ]} lo que podría permitir que se dupliquen las claves secretas del registro semilla y que se produzca la suplantación de identidad del usuario.

Por otro lado, los tokens físicos pueden ser robados (o adquiridos mediante ingeniería social ) a los usuarios finales. Su pequeño tamaño hace que el robo de tokens físicos sea mucho más factible que el escaneo de computadoras portátiles o de escritorio. Un usuario generalmente esperará más de un día antes de reportar la pérdida del dispositivo, lo que le da al atacante tiempo suficiente para vulnerar el sistema desprotegido. Sin embargo, esto solo podría ocurrir si se conocen el ID de usuario y el PIN del usuario. El análisis basado en riesgos puede brindar protección adicional contra el uso de tokens perdidos o robados, incluso si los atacantes conocen el ID de usuario y el PIN del usuario.

Las baterías se agotan periódicamente, lo que requiere procedimientos complejos de reemplazo y reinscripción.

En 2003, RSA SecurID controlaba más del 70 % del mercado de autenticación de dos factores ^{[ 10 ]} y se habían producido 25 millones de dispositivos hasta la fecha. Varios competidores, como VASCO , fabrican tokens de seguridad similares , basados ​​principalmente en el estándar abierto OATH HOTP . Un estudio sobre OTP publicado por Gartner en 2010 menciona a OATH y SecurID como los únicos competidores. ^{[ 11 ]}

Otros sistemas de autenticación de red, como OPIE y S/Key (a veces conocido de forma más general como OTP , ya que S/Key es una marca registrada de Telcordia Technologies , anteriormente Bellcore ), intentan proporcionar el nivel de autenticación de "algo que tienes" sin requerir un token de hardware.

El 17 de marzo de 2011, RSA anunció que había sido víctima de un ciberataque extremadamente sofisticado. ^{[ 12 ]} Se expresaron preocupaciones específicas en relación con el sistema SecurID, indicando que "esta información podría utilizarse para reducir la eficacia de la implementación actual de autenticación de dos factores". Sin embargo, su presentación formal del Formulario 8-K ^{[ 13 ]} indicaba que no creían que la brecha de seguridad tuviera un impacto significativo en sus resultados financieros. La brecha le costó a EMC, la empresa matriz de RSA, 66,3 millones de dólares, que se contabilizaron como un cargo contra las ganancias del segundo trimestre. Este monto cubrió los costos de investigación del ataque, el fortalecimiento de sus sistemas de TI y el monitoreo de las transacciones de los clientes corporativos, según declaró David Goulden, vicepresidente ejecutivo y director financiero de EMC, en una conferencia telefónica con analistas. ^{[ 14 ]}

La intrusión en la red de RSA fue llevada a cabo por piratas informáticos que enviaron correos electrónicos de phishing a dos pequeños grupos de empleados de RSA. ^{[ 15 ]} El correo electrónico contenía un archivo adjunto de Microsoft Excel con malware . Cuando un empleado de RSA abrió el archivo de Excel, el malware explotó una vulnerabilidad en Adobe Flash . Esta vulnerabilidad permitió a los piratas informáticos usar el troyano de acceso remoto Poison Ivy para tomar el control de las máquinas y acceder a los servidores de la red de RSA. ^{[ 16 ]}

Hay indicios de que la brecha implicó el robo de la base de datos de RSA que relaciona los números de serie de los tokens con las "semillas" secretas que se inyectaron para que cada uno fuera único. ^{[ 17 ]} Los informes de ejecutivos de RSA que les dijeron a los clientes que "se aseguraran de proteger los números de serie de sus tokens" ^{[ 18 ]} dan credibilidad a esta hipótesis.

RSA declaró que no reveló detalles sobre el alcance del ataque para no dar a los posibles atacantes información que pudieran usar para averiguar cómo atacar el sistema. ^{[ 19 ]}

El 6 de junio de 2011, RSA ofreció reemplazos de tokens o servicios gratuitos de monitoreo de seguridad a cualquiera de sus más de 30 000 clientes de SecurID, tras un intento de intrusión cibernética en su cliente de defensa Lockheed Martin , que parecía estar relacionado con la información de SecurID robada a RSA. ^{[ 20 ]} A pesar del ataque resultante contra uno de sus clientes de defensa, el presidente de la compañía, Art Coviello, afirmó que «Creemos y seguimos creyendo que los clientes están protegidos». ^{[ 21 ]}

• Sitio web oficial

Detalles técnicos

• Ejemplo de emulador de token SecurID con importación de secreto de token ICWiener, publicación en Bugtraq.
• Debilidades aparentes en el protocolo cliente/servidor de Security Dynamics. Adam Shostack, 1996.
• Hilo de Usenet que analiza los nuevos detalles de SecurID Vin McLellan, et al., comp.security.misc .
• Información no oficial sobre SecurID y algunos intentos de ingeniería inversa en Yahoo Groups securid-users .
• Análisis de los posibles riesgos derivados del acuerdo de 2011.

Ataques publicados contra la función hash de SecurID

• Criptoanálisis de la supuesta función hash de SecurID (PDF) Alex Biryukov , Joseph Lano y Bart Preneel .
• Criptoanálisis mejorado de SecurID (PDF) Scott Contini y Yiqun Lisa Yin .
• Ataques rápidos basados ​​en software contra SecurID (PDF) Scott Contini y Yiqun Lisa Yin .