Jutilise les clés RSA SecureID ® depuis un certain temps maintenant (peut-être 10 ans), pour des choses telles que la sécurité de mon compte bancaire à domicile en ligne ou laccès à mon réseau dordinateurs de lentreprise depuis la maison. Ces clés génèrent un jeton numérique à 6 chiffres qui expire. Cependant, je me suis toujours demandé comment cela fonctionne.
Sur le côté droit, il y a un point (non montré sur limage) qui clignote une fois par seconde, et sur la gauche il y a une pile de six verticalement empilés horizontalement barres, dont chacune disparaît une fois toutes les dix secondes. Chaque fois que soixante secondes se sont écoulées, le jeton se réinitialise et le jeton précédent devient invalide.
AFAIK ces appareils nutilisent pas le réseau, et les nombres quils génèrent doivent être vérifiés par le serveur (si le serveur soit une banque ou le serveur dune entreprise). Par conséquent, à lintérieur de cet appareil, il doit être stocké un algorithme qui génère des nombres aléatoires avec un mécanisme qui comprend une minuterie très précise alimentée par une petite batterie. Le minuteur doit être très précis, car le serveur doit vérifier la validité des chiffres générés dans le même intervalle de temps. Pour chaque utilisateur / employé, le serveur doit, pour autant que je sache, stocker le même algorithme de génération de nombres aléatoires, avec un tel algorithme par client / employé. La puce doit bien sûr être construite de telle manière quen cas de vol, lattaquant ne puisse pas accéder à lalgorithme de génération de nombres aléatoires qui y est stocké, même si lappareil est cassé.
Est-ce ainsi que cela fonctionne?
Merci!
Commentaires
- De la même manière TOTP fonctionne, sauf pour ce dernier que vous ‘ devez acheter une solution hors de prix et pouvez utiliser des téléphones ordinaires ou tout appareil capable de calcul de base, même une smartwatch .
- Les OTP définis par logiciel sont extrêmement mauvais car vous nobtenez pas la résistance à laltération, qui est nécessaire pour gagner en résistance contre le clonage de la graine. Toute personne disposant dun câble micro-USB et des bons outils peut cloner votre téléphone en < 5 minutes. Si son mot de passe est protégé, le clone crypté peut être stocké jusquà ce que le code puisse être obtenu par un logiciel malveillant ou en surfant sur lépaule. Certains téléphones offrent aujourdhui un magasin de clés matérielles inviolables, alors cest une bonne idée de lutiliser, ou un Security Smart-MicroSD. Cela empêche lextraction de la graine, seul » utilisé « . Mais les jetons TOTP matériels non RSA sont vraiment bon marché.
- Connexes: Fonctionnement des jetons RSA
- @sebastiannielsen that repose toujours sur lingénierie sociale ou sur les utilisateurs qui ne surveillent pas correctement leurs contenus. Si je peux connecter le téléphone de lutilisateur ‘ à un ordinateur sans quil sen aperçoive, je peux aussi bien voler son token RSA et en mettre un autre à sa place (et il a gagné ‘ t avertir jusquà la prochaine fois quil essaiera de lutiliser, ce qui serait trop tard).
- Ça vaut le coup de lier: Le les nombres sur les jetons RSA SecurID doivent-ils être prédits?
Réponse
Oui, cela fonctionne comme vous le dites . La puce est « inviolable » et effacera la « graine » (clé secrète) si une tentative est faite pour lattaquer. Ceci est souvent accompli en ayant une batterie non remplaçable par lutilisateur et un «piège» qui coupe lalimentation du dispositif une fois que le dispositif est ouvert ou que la surface de la puce est retirée. La clé est ensuite stockée dans une SRAM, nécessitant une alimentation pour conserver la clé.
La clé est une graine, qui est combinée avec lheure actuelle en 60 secondes (effectivement, lhorodatage UNIX actuel / 60), actualise le code.
Non, lappareil na PAS besoin dêtre précis. Au lieu de cela, le serveur stockera lheure du dernier code accepté. Ensuite, le serveur acceptera un code une minute plus tôt, une minute à lavance et à lheure actuelle, donc si lheure actuelle sur le serveur est 23:20, alors il acceptera un code de 23:19, 23:20 et 23: 21.
Après cela, il stockera lheure du dernier code accepté, par exemple si un code 23:21 a été accepté, il stockera 23:21 dans une base de données, et refusera daccepter tout code qui a été généré à 23h21 ou plus tôt.
Passons maintenant à la partie intéressante: pour éviter quun jeton imprécis ne se désynchronise du serveur, le serveur stockera dans sa base de données, sil était nécessaire daccepter un 23: 19 ou un code 23:21 à 23:20 heure. Cela garantira quà la prochaine connexion, le serveur corrigera le code avec le nombre détapes.
Disons que vous vous connectez à lhorloge 23:20 avec un code 23:19. Le serveur stocke « -1 » dans sa base de données (et sil sagit dun code 23:21, il stocke « +1 » dans la base de données). La prochaine fois que vous vous connectez, il est 23h40. Ensuite, le serveur acceptera un code 23:38, 23:39 ou 23:40.Si un code 23:38 est accepté, il stockera « -2 » dans la base de données, à 23:39 il gardera « -1 » dans la base de données, et à 23:40 il stockera « 0 » dans la base de données.
Cela garantit efficacement la synchronisation du serveur avec votre token. En plus de cela, le système, si un jeton « sest trop éloigné » du serveur (en raison de son inutilisé pendant une longue période), autorise la resynchronisation. Ceci est accompli par un administrateur système ou un service de resynchronisation en libre-service est présenté où lutilisateur du jeton est invité à fournir 2 codes suivants du jeton, comme 23:20 et 23:21, ou 19:10 et 19:11. Notez que le serveur nacceptera JAMAIS un code de jeton généré à ou avant lheure à laquelle le «dernier code de jeton utilisé» était (car cela permettrait la réutilisation des codes OTP). Lorsquune resyncronisation est effectuée, le jeton stockera la différence par rapport aux 2 codes de jeton fournis, et lheure actuelle du serveur et dans une resynchronisation, la fenêtre de recherche pourrait être comme plus / moins 50 étapes (ce qui permettrait environ 0,75 heure de désynchronisation dans les deux sens).
Le serveur peut détecter un jeton désynchronisé en générant les 50 codes précédents et les 50 codes futurs, et si le code spécifié correspond à cela, il lancera automatiquement le processus de resynchronisation. Plusieurs fois, pour empêcher un attaquant dutiliser le processus de resynchronisation pour trouver des codes valides, une fois quun compte est en mode resynchronisation, la connexion ne sera pas acceptée sans resynchronisation, ce qui obligerait lattaquant à trouver le code exact après ou avant le code juste trouvé.
Commentaires
- Des trucs sympas, je ne ‘ pas savoir à ce sujet.
Réponse
Le jeton SecurID a une valeur « seed » qui lui est assignée, et est programmé avec un algorithme spécifique qui génère des nombres basé sur la graine et son horloge système. La valeur de départ est également stockée dans un fichier livré avec le jeton. À la réception du jeton, les administrateurs système importent le fichier dorigine sur le serveur dauthentification. Étant donné que le périphérique de jeton SecurID et le serveur ont tous deux la valeur de départ et quils utilisent tous deux lalgorithme, le serveur peut déterminer quel doit être le bon code de jeton à tout moment.
Parfois, le jeton « s lhorloge peut ne pas être synchronisée avec le serveur dauthentification. Dans ce cas, les administrateurs système ou tout autre personnel dassistance autorisé peuvent aider lutilisateur en effectuant un processus de resynchronisation sur le serveur. Cela configurera le serveur pour quil reconnaisse le décalage horaire pour ce jeton afin que les futures tentatives dauthentification soient traitées avec précision.
Remarque: Comme ces nombres doivent être prévisibles par le serveur, en se basant uniquement sur les données stockées dans le fichier de départ, lheure actuelle et un algorithme standard, ils peut également être prédit par un attaquant doté doutils spéciaux et dun accès au jeton. (Ou pire, laccès aux fichiers de départ eux-mêmes – comme soupçonné davoir eu lieu en 2011 .) Étant donné suffisamment de codes de jeton consécutifs, il y a à ols qui peuvent déterminer la valeur de départ et ensuite générer eux-mêmes les futurs codes.
Réponse
La réponse de Sebastian a été formidable. Je le répéterai en termes simples. Le jeton SecureID est simplement une horloge avec une valeur de départ. Au lieu dafficher lheure, il affiche un nombre. Le point que nous pouvons voir sur limage est en secondes (je pense), la barre indique quand le nombre va changer pour que vous puissiez le chronométrer. Sil atteint le bas, il est sur le point de changer et si vous le saisissez, vous voudrez attendre.
Le » seed « se trouve également sur le serveur qui authentifie le périphérique. Lorsque les responsables de la sécurité installent le serveur RSA, ils doivent charger les mêmes graines sur le serveur qui recevra votre code PIN.
Donc … En gros, il est un cryptoclock. Tout comme les vieilles montres LCD que mes enfants ont avec Dora, ou des princesses dessus. La différence est la graine qui fournit le calcul du nombre.