Identificación segura RSA

Identificación segura RSA

Sitio web	https://www.rsa.com/en-us/products/rsa-securid-suite

RSA SecurID , anteriormente conocido como SecurID , es un mecanismo desarrollado por RSA para realizar la autenticación de dos factores de un usuario en 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 de software ), 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 incorporado y la clave casi aleatoria codificada de fábrica de la tarjeta (conocida como la "semilla"). La semilla es diferente para cada token y se carga en el servidor RSA SecurID correspondiente (RSA Authentication Manager, anteriormente ACE/Server ^[1] ) a medida que se compran los tokens. ^[2] También hay tokens a pedido disponibles, que proporcionan un código de token a través de correo electrónico o entrega de SMS, eliminando la necesidad de proporcionar un token al usuario.

El hardware del token está diseñado para ser resistente a la manipulación para disuadir la ingeniería inversa . Cuando aparecieron en el mercado las implementaciones de software del mismo algoritmo ("tokens de software"), la comunidad de seguridad había desarrollado un 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 de semilla RSA SecurID original de 64 bits introducido en el servidor. ^[3] Más tarde, 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 de semilla es la clave secreta utilizada para generar contraseñas de un solo uso . Las versiones más nuevas también cuentan con 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) debe introducir un número de identificación personal y 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 ignoran por completo la implementación del PIN y se basan en combinaciones de contraseñas y códigos RSA SecurID. El servidor, que también tiene un reloj en tiempo real y una base de datos de tarjetas válidas con los registros de semillas asociados, autentica a un usuario calculando qué número se supone que debe mostrar el token en ese momento y comparándolo con lo que el usuario ingresó.

En versiones anteriores de SecurID, se puede utilizar un "PIN de coacción", un código alternativo que crea un registro de eventos de seguridad que muestra que un usuario fue obligado a ingresar su PIN, al mismo tiempo que proporciona una autenticación transparente. ^[6] El uso del PIN de coacción permitiría una autenticación exitosa, después de la cual el token se deshabilitaría automáticamente. La función "PIN de coacción" ha quedado obsoleta y no está disponible en las versiones compatibles actualmente.

Aunque el sistema RSA SecurID añade una capa de seguridad a una 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 tiene en cuenta automáticamente la desviación normal del reloj del token ajustando un valor de "desviación" almacenado a lo largo del tiempo. Si la condición de desincronización no es resultado de una desviación normal del reloj del token de hardware, se puede corregir la sincronización del reloj del servidor de Authentication Manager con el token (o tokens) desincronizado de varias maneras diferentes. Si el reloj del servidor se desfasó y el administrador realizó un cambio en el reloj del sistema, los tokens se pueden volver a sincronizar uno por uno o se pueden ajustar manualmente los valores de desviación almacenados. La desviación se puede realizar en tokens individuales o en masa 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 de uso diario como unidades flash USB y teléfonos celulares, para reducir los costos y la cantidad de objetos que el usuario debe llevar consigo. ^[7]

Los códigos de token se roban con facilidad, porque no existe autenticación mutua (todo lo que puede robar una contraseña también puede robar un código de token). Esto es importante, ya que es la principal amenaza que la mayoría de los usuarios creen que están resolviendo con esta tecnología.

La vulnerabilidad práctica más sencilla de cualquier contenedor de contraseñas es la pérdida del dispositivo de clave especial o del teléfono inteligente activado con la función de clave integrada. Esta vulnerabilidad no se puede solucionar con ningún dispositivo contenedor de tokens individual dentro del período de tiempo preestablecido de activación. Todas las consideraciones posteriores presuponen 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 un nivel de protección contra ataques de repetición de contraseñas , no están diseñados para ofrecer protección contra ataques de tipo 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 próximo código de token sea válido, podrá iniciar sesión en el servidor. El análisis basado en riesgos (RBA), una nueva característica en 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 habilitado para RBA. RSA SecurID no evita los ataques basados ​​en man in the browser (MitB).

El servidor de autenticación SecurID intenta evitar el rastreo de contraseñas y el inicio de sesión simultáneo rechazando ambas solicitudes de autenticación si se presentan dos credenciales válidas en un período de tiempo determinado. Esto ha sido documentado en una publicación no verificada de John G. Brainard. ^[8] Sin embargo, si el atacante elimina la capacidad de autenticarse del usuario, el servidor SecurID asumirá que es el usuario quien realmente 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 resistente a la manipulación de los tokens duros no tiene igual en las implementaciones de tokens blandos, ^[9] lo que podría permitir que las claves secretas del registro semilla se dupliquen y que se produzca la suplantación de identidad del usuario.

Por otro lado, los tokens duros pueden ser robados físicamente (o adquiridos a través de ingeniería social ) de los usuarios finales. El pequeño tamaño de los tokens hace que el robo de tokens duros sea mucho más viable que el escaneo de computadoras portátiles o de escritorio. Un usuario normalmente esperará más de un día antes de informar que el dispositivo se perdió, lo que le da al atacante mucho tiempo para vulnerar el sistema desprotegido. Sin embargo, esto solo podría ocurrir si también 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 complicados de reemplazo y reinscripción.

En 2003, RSA SecurID dominaba más del 70% del mercado de autenticación de dos factores ^[10] y hasta la fecha se han producido 25 millones de dispositivos. ^{[ cita requerida ]} Varios competidores, como VASCO , fabrican tokens de seguridad similares, en su mayoría basados ​​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 más conocidos como OTP , ya que S/Key es una marca registrada de Telcordia Technologies , anteriormente Bellcore ) intentan proporcionar el nivel de autenticación "algo que tienes" sin requerir un token de hardware. ^{[ cita requerida ]}

El 17 de marzo de 2011, RSA anunció que había sido víctima de "un ciberataque extremadamente sofisticado". ^[12] Se expresaron preocupaciones específicamente en referencia al sistema SecurID, diciendo que "esta información podría potencialmente usarse para reducir la efectividad de una implementación actual de autenticación de dos factores". Sin embargo, su presentación formal del Formulario 8-K ^[13] indicó que no creían que la violación tuviera un "impacto material en sus resultados financieros". La violación le costó a EMC, la empresa matriz de RSA, 66,3 millones de dólares, que se descontaron de las ganancias del segundo trimestre. Cubrió los costos de investigar el ataque, fortalecer sus sistemas de TI y monitorear las transacciones de los clientes corporativos, según el vicepresidente ejecutivo y director financiero de EMC, David Goulden, en una conferencia telefónica con analistas. ^[14]

La vulneración de 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] Junto al correo electrónico había un archivo de Microsoft Excel que contenía malware . Cuando un empleado de RSA abrió el archivo de Excel, el malware explotó una vulnerabilidad en Adobe Flash . La explotación permitió a los piratas informáticos utilizar el RAT Poison Ivy para obtener el control de las máquinas y acceder a los servidores de la red de RSA. ^[16]

Hay algunos indicios de que la violación implicó el robo de la base de datos de RSA que asigna los números de serie de los tokens a las "semillas" de tokens secretos que se inyectaron para que cada uno fuera único. ^[17] Los informes de ejecutivos de RSA que les dicen a los clientes que "se aseguren de proteger los números de serie de sus tokens" ^[18] dan credibilidad a esta hipótesis.

Salvo una debilidad fatal en la implementación criptográfica del algoritmo de generación de código de token (lo cual es poco probable, ya que implica la aplicación simple y directa del cifrado de bloque AES-128 ampliamente examinado ), la única circunstancia bajo la cual un atacante podría montar un ataque exitoso sin posesión física del token es si los registros de semillas del token se hubieran filtrado. ^{[ cita requerida ]} RSA declaró que no publicó detalles sobre el alcance del ataque para no dar a los atacantes potenciales información que pudieran usar para descubrir 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, luego de un intento de violación cibernética en un 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 a uno de sus clientes de defensa, el presidente de la compañía, Art Coviello, dijo que "creemos y seguimos creyendo que los clientes están protegidos". ^[21]

En abril de 2011, surgieron rumores no confirmados que indicaban que L-3 Communications había sido atacada como resultado del ataque a RSA. ^[22]

En mayo de 2011, esta información se utilizó para atacar los sistemas de Lockheed Martin . ^{[23] [24]} Sin embargo, Lockheed Martin afirma que debido a las "acciones agresivas" del equipo de seguridad de la información de la empresa , "ningún dato personal de clientes, programas o empleados" se vio comprometido por este "ataque significativo y tenaz". ^[25] El Departamento de Seguridad Nacional y el Departamento de Defensa de los EE. UU. ofrecieron ayuda para determinar el alcance del ataque. ^[26]

Wikimedia Commons tiene medios relacionados con RSA SecurID .

• Sitio web oficial de RSA SecurID

Detalles técnicos

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

Ataques publicados contra la función hash 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 .