Token pour liaison chiffré

Mister Jack wrote:

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.

Oui (pour RSA), et le serveur peut calculer le décalage éventuel en
comparant les éléments précédents et suivants de la séquence.

Fred wrote on 29/01/2006 22:13:

Oui (pour RSA), et le serveur peut calculer le décalage éventuel en
comparant les éléments précédents et suivants de la séquence.

en parlant d'élements de la /séquence/ je pense que tu réponds à la
synchronisation d'un compteur (tel qu'utilisé par OTP/P.11); je ne
connais pas de token dont /l'horloge interne/ serait synchronisé avec un
serveur.

concernant les boitiers RSA (la marque, pas l'algo) SecureID, ils
réalisent AMHA une authentification (par mot de passe dynamique unique)
mais ne procurent pas (du tout / à eux seuls / directement) de liaison
chiffrée.

Sylvain.

Sylvain wrote:

Fred wrote on 29/01/2006 22:13:

Oui (pour RSA), et le serveur peut calculer le décalage éventuel en
comparant les éléments précédents et suivants de la séquence.

en parlant d'élements de la /séquence/ je pense que tu réponds à la
synchronisation d'un compteur (tel qu'utilisé par OTP/P.11); je ne
connais pas de token dont /l'horloge interne/ serait synchronisé avec un
serveur.

Non, c'est le contraire, c'est le serveur qui se cale sur le token.

Salut,

Sylvain wrote:

Fred wrote on 29/01/2006 22:13:

Oui (pour RSA), et le serveur peut calculer le décalage éventuel en
comparant les éléments précédents et suivants de la séquence.

en parlant d'élements de la /séquence/ je pense que tu réponds à la
synchronisation d'un compteur (tel qu'utilisé par OTP/P.11); je ne
connais pas de token dont /l'horloge interne/ serait synchronisé avec
un serveur.

Non, c'est le contraire, c'est le serveur qui se cale sur le token.

Ok, merci bien.
Donc il y a génération du code d'authentification à partir d'une horloge
et d'un identifiant unique.
Le serveur, lui, fait de son mieux pour être synchronisé avec le token
et valider correctement les authentifications.

C'est toujours un plaisir de passer par ici.

--
Mister Jack (MJ)
"Dans quel état j'erre ?"

Fred wrote on 30/01/2006 06:52:

Sylvain wrote:

en parlant d'élements de la /séquence/ je pense que tu réponds à la
synchronisation d'un compteur (tel qu'utilisé par OTP/P.11); je ne
connais pas de token dont /l'horloge interne/ serait synchronisé avec
un serveur.

Non, c'est le contraire

le contraire de quel affirmation ?

c'est le serveur qui se cale sur le token.

c'est évidemment et je n'ai rien dit de contraire ("être synchronisé
avec" n'est pas équivalent à "se synchroniser").

Sylvain.

Mister Jack wrote on 30/01/2006 12:40:

Ok, merci bien.
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).

Le serveur, lui, fait de son mieux pour être synchronisé avec le token
et valider correctement les authentifications.

(il fait surtout ce pour quoi il a été programmé, en l'occurrence) il
tentera plusieurs (un nombre fini et faible) incrémentations de son
compyeur (le compteur coté serveur sensé être la valeur courante du
token client) pour retomber sur le cryptogramme généré par le token.

Sylvain.

Sylvain wrote on 31/01/2006 02:48:

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).

j'aurais du dire "et *optionnellement* un compteur"; le mécanisme OTP

avec compteur est assez récent (récemment normalisé) et la plupart des
boitiers ne contiennent qu'une clé utilisée pour calculer un hash-mac
sur l'aléa - le pb de la synchro n'existe alors simplement pas.

Sylvain.

Salut,

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)
L'aléa, je coince. Comment le serveur transmet l'aléa au token ???

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
- le token reçoit une clé unique, correspondant à son utilisateur.
- 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.

Je ne vois pas comment le serveur peut donner de l'aléa au token à 5
euros...

Quelqu'un peut me dissiper les brumes ?

--
Mister Jack (MJ)
"Dans quel état j'erre ?"

Mister Jack wrote on 31/01/2006 22:35:

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)
L'aléa, je coince. Comment le serveur transmet l'aléa au token ???

pourquoi pas par l'utilisateur ? ni le token, ni le serveur n'ont
vocation à vivre tout seul ...

généralement un /utilisateur/ se connecte (par web par exemple) à un
serveur de quelque chose, disons contenu; ce serveur générè un aléa
(random) directement ou l'obtient d'un serveur d'authentification et
retourne une page à l'/utilisateur/ en lui indiquant de taper l'aléa sur
son token et de saisir la réponse du token dans la boite ci-dessous (sur
la page ouèbe pas dans ce post)

le serveur qui a fait un gros effort de mémoire se souvient de l'aléa
transmis et vérifie que le code saisi est le bon - bon de l'authen. pour
un niveau zéro; le client et anonymement authentifié comme ayant droit
d'accéder à la page suivante.

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

quand il existe un compteur,il est en effet initialisé de manière
synchrone avec le serveur, le token et son utilisateur ne sont aloers
plus anonyme; le serveur mémorise que tel client utilise tel compteur,
éventuellement telle clé (elle peut être unique par token ou commune),
et utilisera ces infos pour vérifier le login client; celle-ci fournira
généralement un alias ou un identifiant numérique (n° de compte, ...)
pour s'identifier en même temps qu'il s'authentifie (l'identification
servant au serveur à retrouver le bon compteur, even.t la clé).

- le token reçoit une clé unique, correspondant à son utilisateur.

oui s'il n'existe pas de compteur; pas nécessairement s'il y a un
compteur; dans ce second cas, le serveur peut utiliser la même clé pour
plusieurs tokens (et cela simplifie le déploiement dans l'opérateur du
service n'a aucune idée de la signification du sigle HSM ni n'a envie de
personnaliser de manière sécurisée ses boitiers avant remise au client
final); noter que, comme précedemment indiqué, en cas d'échec de
vérification, le serveur tentera de se synchroniser sur un écart faible
de valeur du compteur - il assumera que le compteur token a été
incrémenté par des calculs réalisés "pour jouer" par l'utilisateur, il
calculera alors qlq crytogrammes en incrémentant le compteur du client
coté serveur pour tenter de retrouver la même valeur que celle
transmisse, mais évidemment pour éviter les attaques par énumération,
comme les collisions avec d'autres tokens utilisant la même clé (mais
des valeurs initiales de compteurs très différentes - valeurs aléatoires
correctement distribuées sur leur espace de déf.) il opérera un nombre
faible (peut ête 5 ou 10) d'incréments.

- chaque minute, le token calcule un code sur la base du compteur et de
la clé.

pourquoi chaque minute ?? ou je n'ai pas compris de quel dispositif vous
parlez ou vous vous méprenez, les tokens RSA ID ne cherchent pas à
authentifier dans le temps un utilisateur; de tels systèmes sont assez
rares car le besoin même est assez rare; on priviligira généralement des
sessions courtes avec des "clés de sessions jetables" (diversification
symmétrique lié au mécanisme d'authentification, ou échange type DH)
plutot qu'une session longue (voire permanente) reposant sur le contrôle
périodique des protagonistes.

- 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.

le temps est rarement est un élément d'authentification; ce sont plutot
les droits acquis par une authentification qui peuvent dépendre du temps
(accès physique seulement de telle à telle heure par exemple).

s'il en était différemment comment géreriez-vous les décalages "dans une
certaine mesure" ?? faites-vous intervenir le temps à l'heure, la
seconde ou la femto-seconde ?
je disais qu'un token à 5 euros ne peut pas être basé sur un temps, non
pour médire des dits boitiers à 5 euros mais pour rappeller qu'une
horloge atomique coute un peu plus.

Sylvain.

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émoriser 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