He estado usando claves RSA SecureID ® durante bastante tiempo (quizás 10 años), para cosas como de forma segura mi cuenta bancaria en línea o para acceder a mi red de computadoras de la empresa desde casa. Estas claves generan un token numérico de 6 dígitos que está programado para caducar. Sin embargo, siempre me he preguntado cómo funcionan.
En el lado derecho hay un punto (que no se muestra en la imagen) que parpadea una vez por segundo, y en el lado izquierdo hay una pila de seis horizontales apilados verticalmente barras, cada una de las cuales desaparece una vez cada diez segundos. Cada vez que han pasado sesenta segundos, el token se reinicia y el token anterior deja de ser válido.
AFAIK, estos dispositivos no hacen uso de la red, y los números que generan deben ser verificados por el servidor (si el servidor sea un banco o el servidor de una empresa). De ahí que en el interior de este dispositivo se deba almacenar un algoritmo que genere números aleatorios con un mecanismo que incluye un temporizador muy preciso alimentado por una pequeña batería. El temporizador debe ser muy preciso, ya que el servidor debe verificar la validez de los dígitos generados en el mismo intervalo de tiempo. Para cada usuario / empleado, el servidor debe, según tengo entendido, almacenar el mismo algoritmo de generación de números aleatorios, con uno de esos algoritmos por cliente / empleado. Por supuesto, el chip debe estar construido de tal manera que, si es robado, el atacante no pueda acceder al algoritmo de generación de números aleatorios almacenado en él, incluso si el dispositivo está roto.
¿Así es como funciona esto?
¡Gracias!
Comentarios
- De la misma manera TOTP funciona, excepto en este último, no ‘ no tiene que comprar una solución cara y puede usar teléfonos normales o cualquier dispositivo capaz de realizar cálculos básicos, incluso un reloj inteligente .
- Las OTP definidas por software son extremadamente malas ya que no obtiene la resistencia a la manipulación, que se requiere para ganar resistencia contra la clonación de la semilla. Cualquiera con un cable micro-USB y las herramientas adecuadas puede clonar su teléfono en < 5 minutos. Si su contraseña está protegida, el clon cifrado se puede almacenar hasta que se pueda obtener el código mediante software malintencionado o navegando por el hombro. En la actualidad, algunos teléfonos ofrecen un almacén de claves de hardware a prueba de manipulaciones, por lo que es una buena idea usarlo o una Security Smart-MicroSD. Para evitar que se extraiga la semilla, solo » usó «. Pero los tokens TOTP de hardware que no son RSA son realmente baratos.
- Relacionado: Cómo funcionan los tokens RSA
- @sebastiannielsen que todavía se basa en la ingeniería social o en los usuarios que no vigilan sus cosas correctamente. Si puedo conectar el teléfono del usuario ‘ a una computadora sin que él se dé cuenta, también puedo robar su token RSA y poner otro en su lugar (y él ganó ‘ No se dará cuenta hasta la próxima vez que intente usarlo, lo cual sería demasiado tarde).
- Vale la pena vincular: ¿Puede el ¿Se pueden predecir los números en los tokens RSA SecurID?
Responder
Sí, funciona como usted dice . El chip es «a prueba de manipulaciones» y borrará la «semilla» (clave secreta) si se intenta atacarlo. Esto a menudo se logra al tener una batería no reemplazable por el usuario y una «trampa» que interrumpe la alimentación del dispositivo una vez que se abre el dispositivo o se retira la superficie del chip. Luego, la clave se almacena en una SRAM, lo que requiere energía para mantener la clave.
La clave es una semilla, que se combina con la hora actual en un paso de 60 segundos (efectivamente, la marca de tiempo UNIX actual / 60), actualiza el código.
No, el dispositivo NO necesita ser preciso. En cambio, el servidor almacenará la hora del último código aceptado. Luego, el servidor aceptará un código un minuto antes, un minuto antes y a la hora actual, por lo que si la hora actual en el servidor es 23:20, aceptará un código de 23:19, 23:20 y 23: 21.
Después de esto, almacenará la hora del último código aceptado, por ejemplo, si se aceptó un código 23:21, almacenará 23:21 en una base de datos y se negará a aceptar cualquier código que se generó a las 23:21 o antes.
Ahora a la parte interesante: para evitar que un token impreciso se desincronice del servidor, el servidor almacenará en su base de datos, si fuera necesario aceptar un 23: 19 o un código 23:21 a las 23:20 hora. Esto asegurará que en el próximo inicio de sesión, el servidor corregirá el código con el número de pasos.
Digamos que a las 23:20 inicie sesión con un código 23:19. El servidor almacena «-1» en su base de datos (y si fuera un código 23:21, almacenaría «+1» en la base de datos). La próxima vez que inicie sesión, el reloj son las 23:40. Entonces el servidor aceptará un código 23:38, 23:39 o 23:40.Si se acepta un código 23:38, almacenará «-2» en la base de datos, a las 23:39 mantendrá «-1» en la base de datos y a las 23:40 almacenará «0» en la base de datos.
Esto efectivamente asegura que el servidor se mantenga sincronizado con su token. Además de esto, el sistema, si un token «se alejó demasiado» del servidor (debido a que no se usó durante mucho tiempo), permite la resincronización. Esto lo logra un administrador del sistema o se presenta un servicio de resincronización de autoservicio en el que se solicita al usuario del token que proporcione 2 códigos posteriores del token, como 23:20 y 23:21, o 19:10 y 19:11. Tenga en cuenta que el servidor NUNCA aceptará un código de token generado en o antes de la hora en que fue el «código de token usado por última vez» (ya que esto permitiría la reutilización de códigos OTP). Cuando se realiza una resincronización, el token almacenará la diferencia de los 2 códigos de token proporcionados, y la hora actual del servidor y en una resincronización, la ventana de búsqueda podría ser como más / menos 50 pasos (lo que permitiría aproximadamente 0,75 horas de desincronizar en ambas direcciones).
El servidor puede detectar un token desincronizado generando los 50 códigos anteriores y los 50 códigos futuros, y si el código especificado coincide con eso, iniciará el proceso de resincronización automáticamente. Muchas veces, para evitar que un atacante utilice el proceso de resincronización para encontrar códigos válidos, una vez que una cuenta está en modo de resincronización, no se aceptará el inicio de sesión sin resincronizar, lo que requeriría que el atacante encontrara el código exacto antes o después del código recién encontrado.
Comentarios
- Cosas interesantes, no ‘ sabía de esto.
Respuesta
El token SecurID tiene un valor de «semilla» asignado y está programado con un algoritmo específico que genera números basado en la semilla y su reloj del sistema. El valor semilla también se almacena en un archivo que se envía con el token. Al recibir el token, los administradores del sistema importan el archivo semilla al servidor de autenticación. Dado que el dispositivo de token de SecurID y el servidor tienen el valor de inicialización y ambos utilizan el algoritmo, el servidor puede determinar cuál debe ser el código de token correcto en un momento dado.
Ocasionalmente, el token «s Es posible que el reloj no esté sincronizado con el servidor de autenticación. Si esto sucede, los administradores del sistema u otro personal de soporte autorizado pueden ayudar al usuario realizando un proceso de resincronización en el servidor. Esto configurará el servidor para que reconozca la compensación de tiempo para ese token para que los intentos de autenticación futuros se manejen con precisión.
Nota: Debido a que estos números deben ser predecibles por el servidor, basándose solo en los datos almacenados en el archivo semilla, la hora actual y un algoritmo estándar, también puede ser predicho por un atacante con herramientas especiales y acceso al token. (O peor aún, el acceso a los archivos semilla en sí, como se sospecha que sucedió en 2011 .) Dados suficientes códigos de token consecutivos, hay que ols que pueden determinar el valor semilla y luego generar códigos futuros por sí mismos.
Respuesta
La respuesta de Sebastian fue excelente. Lo reafirmaré en términos sencillos. El token SecureID es simplemente un reloj con un valor inicial. En lugar de mostrar el tiempo, muestra un número. El punto que podemos ver en la imagen son segundos (creo), la barra es cuando el número va a cambiar para que puedas cronometrarlo. Si está llegando al final, está a punto de cambiar y si lo estás escribiendo, querrás esperar.
El » seed «también está en el servidor que autentica el dispositivo. Cuando los agentes de seguridad instalan el servidor RSA, tienen que cargar las mismas semillas en el servidor que recibirá su código PIN.
Entonces … Básicamente es un criptoclock. Al igual que los viejos relojes LCD que mis hijos tienen con Dora o princesas. La diferencia es la semilla que proporciona las matemáticas para el número.