Des utilisateurs d'une liaison chiffré ont une calculette RSA SecureID
qui leur fournir un code servant à établir la liaison.
Je me pose une question : comment le token est-il généré ou récupéré par
la calculette ? Ils changent toutes les minutes.
Je suppose que le token a une pile et une horloge précise qui lui permet
de générer les tokens corrects pendant 1 an, et que le protocole
d'authentification sait gérer les éventuelles désynchronisations.
Une confirmation ?
Dans l'article <43dfd832$0$27143$, Mister Jack écrit:
Mister Jack wrote on 30/01/2006 12:40:
Donc il y a génération du code d'authentification à partir d'une horloge et d'un identifiant unique.
non, à partir d'une clé et d'un compteur enfouis dans le token et d'un aléa transmis par le serveur. (il n'y a pas d'horloge atomique dans un token à 5 euros).
La clé, ok. Le compteur, ok. (même si je ne saisis pas la différence entre mon horloge et ce compteur, passons)
Dans SecureID, le token a effectivement une horloge temps réel (certes approximative) qui s'incrémente en permanence, et non pas un compteur d'utilisation (qui s'incrémenterais de 1 à chaque fois), ce qui serait (si'il n'y a pas d'aléa du serveur) une grosse faille en cas d'emprunt du token puisque l'on pourrait obtenir par avance des codes utilisables.
L'aléa, je coince. Comment le serveur transmet l'aléa au token ???
Au moins dans la version de base du token SecureID, il n'y a pas d'aléa. J'ai aussi vu des systèmes où il y a un clavier pour saisir un aléa fourni par le serveur, et d'autres encore où le serveur transmet de l'information au token par 2 cellules photoélectriques dans le token, que l'on colle à l'écran.
Je pensais avoir pigé le fonctionnement, mais là ça me démonte tout...
Ce que je pensais avoir pigé : - l'horloge (ou le compteur) du token est synchronisé sur le serveur à la fabrication
Dans SecureID, synchronisée sur le temps universel, sur lequel s'aligne le serveur.
- le token reçoit une clé unique,
Oui
correspondant à son utilisateur.
En pratique, à son numéro; et c'est le numéro qui est associé à l'utilisateur après fabrication, par le serveur.
- chaque minute, le token calcule un code sur la base du compteur et de la clé. - si l'horloge du token décale, le serveur essaie dans une certaine mesure de détecter le décalage et d'en tenir compte.
Oui; la tolérance peut être proportionelle au temps écoulé depuis la dernière fois où le serveur a vu le token, et mémorisé son décallage. Il a été dit que dans certaines anciennes versions d'un certain token, il arrivait que l'horloge du token revienne intempestivement à zéro, et que le serveur avait une rustine pour le tolérer, si le token est utilisé par trop longtemps après sa remise à zéro.
Je ne vois pas comment le serveur peut donner de l'aléa au token à 5 euros...
Dans la version la plus simple (aussi la plus répandue je crois) du token SecureID, pas d'aléa.
François Grieu
Dans l'article <43dfd832$0$27143$626a54ce@news.free.fr>,
Mister Jack <news@mjcie.net> écrit:
Mister Jack wrote on 30/01/2006 12:40:
Donc il y a génération du code d'authentification à partir d'une
horloge et d'un identifiant unique.
non, à partir d'une clé et d'un compteur enfouis dans le token et d'un
aléa transmis par le serveur. (il n'y a pas d'horloge atomique dans un
token à 5 euros).
La clé, ok.
Le compteur, ok. (même si je ne saisis pas la différence entre mon
horloge et ce compteur, passons)
Dans SecureID, le token a effectivement une horloge temps réel (certes
approximative) qui s'incrémente en permanence, et non pas un compteur
d'utilisation (qui s'incrémenterais de 1 à chaque fois), ce qui serait
(si'il n'y a pas d'aléa du serveur) une grosse faille en cas d'emprunt
du token puisque l'on pourrait obtenir par avance des codes utilisables.
L'aléa, je coince. Comment le serveur transmet l'aléa au token ???
Au moins dans la version de base du token SecureID, il n'y a pas d'aléa.
J'ai aussi vu des systèmes où il y a un clavier pour saisir un aléa
fourni par le serveur, et d'autres encore où le serveur transmet
de l'information au token par 2 cellules photoélectriques dans le
token, que l'on colle à l'écran.
Je pensais avoir pigé le fonctionnement, mais là ça me démonte tout...
Ce que je pensais avoir pigé :
- l'horloge (ou le compteur) du token est synchronisé sur le serveur
à la fabrication
Dans SecureID, synchronisée sur le temps universel, sur lequel
s'aligne le serveur.
- le token reçoit une clé unique,
Oui
correspondant à son utilisateur.
En pratique, à son numéro; et c'est le numéro qui est associé à
l'utilisateur après fabrication, par le serveur.
- chaque minute, le token calcule un code sur la base du compteur
et de la clé.
- si l'horloge du token décale, le serveur essaie dans une
certaine mesure de détecter le décalage et d'en tenir compte.
Oui; la tolérance peut être proportionelle au temps écoulé depuis la
dernière fois où le serveur a vu le token, et mémorisé son décallage.
Il a été dit que dans certaines anciennes versions d'un certain token,
il arrivait que l'horloge du token revienne intempestivement à zéro,
et que le serveur avait une rustine pour le tolérer, si le token
est utilisé par trop longtemps après sa remise à zéro.
Je ne vois pas comment le serveur peut donner de l'aléa au token
à 5 euros...
Dans la version la plus simple (aussi la plus répandue je crois)
du token SecureID, pas d'aléa.
Dans l'article <43dfd832$0$27143$, Mister Jack écrit:
Mister Jack wrote on 30/01/2006 12:40:
Donc il y a génération du code d'authentification à partir d'une horloge et d'un identifiant unique.
non, à partir d'une clé et d'un compteur enfouis dans le token et d'un aléa transmis par le serveur. (il n'y a pas d'horloge atomique dans un token à 5 euros).
La clé, ok. Le compteur, ok. (même si je ne saisis pas la différence entre mon horloge et ce compteur, passons)
Dans SecureID, le token a effectivement une horloge temps réel (certes approximative) qui s'incrémente en permanence, et non pas un compteur d'utilisation (qui s'incrémenterais de 1 à chaque fois), ce qui serait (si'il n'y a pas d'aléa du serveur) une grosse faille en cas d'emprunt du token puisque l'on pourrait obtenir par avance des codes utilisables.
L'aléa, je coince. Comment le serveur transmet l'aléa au token ???
Au moins dans la version de base du token SecureID, il n'y a pas d'aléa. J'ai aussi vu des systèmes où il y a un clavier pour saisir un aléa fourni par le serveur, et d'autres encore où le serveur transmet de l'information au token par 2 cellules photoélectriques dans le token, que l'on colle à l'écran.
Je pensais avoir pigé le fonctionnement, mais là ça me démonte tout...
Ce que je pensais avoir pigé : - l'horloge (ou le compteur) du token est synchronisé sur le serveur à la fabrication
Dans SecureID, synchronisée sur le temps universel, sur lequel s'aligne le serveur.
- le token reçoit une clé unique,
Oui
correspondant à son utilisateur.
En pratique, à son numéro; et c'est le numéro qui est associé à l'utilisateur après fabrication, par le serveur.
- chaque minute, le token calcule un code sur la base du compteur et de la clé. - si l'horloge du token décale, le serveur essaie dans une certaine mesure de détecter le décalage et d'en tenir compte.
Oui; la tolérance peut être proportionelle au temps écoulé depuis la dernière fois où le serveur a vu le token, et mémorisé son décallage. Il a été dit que dans certaines anciennes versions d'un certain token, il arrivait que l'horloge du token revienne intempestivement à zéro, et que le serveur avait une rustine pour le tolérer, si le token est utilisé par trop longtemps après sa remise à zéro.
Je ne vois pas comment le serveur peut donner de l'aléa au token à 5 euros...
Dans la version la plus simple (aussi la plus répandue je crois) du token SecureID, pas d'aléa.
François Grieu
Mister Jack
Mister Jack écrit:
Je ne vois pas comment le serveur peut donner de l'aléa au token à 5 euros...
Dans la version la plus simple (aussi la plus répandue je crois) du token SecureID, pas d'aléa.
OK, merci beaucoup.
-- Mister Jack (MJ) "Dans quel état j'erre ?"
Mister Jack <news@mjcie.net> écrit:
Je ne vois pas comment le serveur peut donner de l'aléa au token
à 5 euros...
Dans la version la plus simple (aussi la plus répandue je crois)
du token SecureID, pas d'aléa.
