9 Mark.Lomas.Gong.Saltzer

9.1 implémentation.

Mis au point à l'université de Cambridge (GB) [23], ce protocole mériterait à notre avis d'être largement utilisé.

9.2 objectifs.

Colmater les brèches ouvertes dans la sécurité par la faiblesse quasi-inévitable des mots_de_passe choisis par les utilisateurs. Le principe est qu'une clef choisie parmi un espace limité ne doit pas servir à chiffrer un message contenant du texte vérifiable. Un intrus qui voudrait essayer les uns à la suite des autres les quelques dix mille mots_de_passe les plus fréquents ne pourra donc pas le faire "chez lui" et sera vraisemblablement repéré s'il les essaye directement auprès de la centrale d'identification.

9.3 chiffrement.

A clef publique (RSA) vis à vis de la centrale d'identification et à clef secrète (DES) dans les autres cas.

9.4 hypothèses.

N'impose qu'un seul calcul RSA par connexion, ce qui n'alourdit pas trop la tâche d'un terminal limité. Suppose une horloge répartie pas trop fantaisiste. Ne suppose pas un circuit-DES, mais celui-ci sera bienvenu pour la suite du protocole.

9.5 déroulement.

La Table 10 donne la liste des messages de ce protocole. Supposant au départ $\mathrm{pub}\left( Ks , S \right)$, et une forme affaiblie de $\mathrm{sec}\left( Wp , P , S \right)$ et $\mathrm{sec}\left( Wq , Q , S \right)$, on arrive à une connexion entre P et Q, protégée par la clef forte k et par un numérotage en séquence des messages à partir du message (8). Voyons comment.

Table 10: Le protocole Mark, Lomas et al.

1	$P\hookrightarrow S$	$\left\{ P, Q, np1, np2, cp, \left\{ Tp\right\} _{Wp}\right\} _{Ks}$
2	$S\hookrightarrow Q$	P, Q
3	$Q\hookrightarrow S$	$\left\{ Q, P, nq1, nq2, cq, \left\{ Tq\right\} _{Wq}\right\} _{Ks}$
4	$S\hookrightarrow P$	$\left\{ np1, k xor np2\right\} _{Wp}$
5	$S\hookrightarrow Q$	$\left\{ nq1, k' xor nq2\right\} _{Wq}$
6	$Q\hookrightarrow P$	$\left\{ rq\right\} _{k}$
7	$P\hookrightarrow Q$	$\left\{ rq+1, seq\right\} _{k}$
8	$Q\hookrightarrow P$	$\left\{ seq+1, hello\right\} _{k}$

Concernant le message (1), il n'est pas vraiment possible d'affirmer que ce message est récent et n'a pu être chiffré que par P. Et cela bien qu'il contienne $\left\{ Tp\right\} _{Wp}$ (l'heure de P chiffrée avec le mot de passe de P). Il faudrait pour cela que d'une part Wp soit une clef forte, et d'autre part faire une hypothèse abusive sur l'horloge répartie.

Or celle-ci est utilisée ici comme heuristique et non comme preuve de fraîcheur : l'utilisation d'un mauvais mot_de_passe produira un résultat totalement aberrant, et donc immédiatement détectable. D'autre part, il ne pose aucun problème qu'un intrus rejoue ce message.

Le point essentiel est que le cryptogramme (1) ne peut pas être utilisé par un intrus pour une attaque à texte vérifiable sur Wp, car d'un côté seul S possède la clef forte Ks-1 qui permet d'accéder directement à $\left\{ Tp\right\} _{Wp}$ et d'autre part la présence du brouilleur cp empêche de vérifier Wp par la simple refabrication du message (1).

Concernant le message (4), il y a par contre la certitude de ce qu'il émane récemment de S. En effet, np1 est récent et était protégé par la clef forte de S. La sémantique de ce message est : $\mathrm{admet}\left( S , \mathrm{sec}\left( k , P , Q \right) \right)$. Or S peut être construit pour que $\mathrm{jauge}\left( S , \mathrm{sec}\left( k , P , Q \right) \right)$. On a donc bien obtenu une distribution d'une clef forte entre P et Q.

Mais cette sémantique se réalise de façon à ce que (4) ne contienne aucun texte vérifiable (sauf par P et par S). Même Q est empêché de "tenter sa chance", car sa connaissance de k est contrebalancée par son ignorance de np2, qui était protégé par la clef forte Ks de S.

A ce stade du protocole, il est maintenant possible de procéder aux questions-réponses des couples de messages (6)/(7) et (7)/(8). Étant protégés par une clef forte, il n'est plus gênant désormais qu'ils contiennent du texte vérifiable.

9.6 critique.

Il est clair que ce protocole est coûteux en messages. Il l'est d'autant plus qu'il a été écrit pour être clair et servir de modèle de référence dans l'évaluation des compromis inévitables aux implémentations effectives.

Lors d'une implémentation, ce coût pourra être très largement diminué si l'une des deux entités P ou Q dispose d'une clef bien choisie. La Table 11 montre une solution possible si Q est par exemple un serveur de fichier physiquement protégé, avec un mot de passe résidant en ROM et réellement choisi aléatoirement parmi les 256 clefs DES. Non seulement le nombre global de message a diminué, mais de plus l'échange (1)-(2) avec S peut n'avoir lieu qu'une fois par login, même si le serveur Q n'a pas de mémoire d'état (réplication par fork) : le ticket peut être confié au client puisqu'il ne lui permet pas de se livrer à une attaque à texte vérifiable sur le mot de passe de Q, celui-ci étant supposé être une clef forte.

Table: Protocole M.L.G.S. : le cas dissymétrique.

1'	$P\hookrightarrow S$	$\left\{ P, Q, np1, np2, cp, \left\{ Tp\right\} _{Wp}\right\} _{Ks}$
	$S$	ticket = $\left\{ P, Ttl\_k, k\right\} _{Wq}$
2'	$S\hookrightarrow P$	$\left\{ np1, k xor np2\right\} _{Wp}$, ticket
3'	$P\hookrightarrow Q$	$\left\{ rq\right\} _{k}$
4'	$Q\hookrightarrow P$	$\left\{ rq+1, seq\right\} _{k}$
5'	$P\hookrightarrow Q$	$\left\{ seq+1, hello\right\} _{k}$

Lorsque S se rend compte de ce que l'un des messages (1) ou (3) est aberrant, le protocole M.L.G.S. prévoit que S le note, et s'arrête. A notre avis, il serait préférable que S fasse semblant de continuer de se comporter selon le protocole, et envoie les messages (4) et (5) ... avec seulement le petit détail que k et k' seront différents. L'intrus ne saura pas qu'il a été détecté, il aura tout au plus l'impression de ce que Q est en panne.

9.7 conclusion.

Le protocole M.L.G.S. est clair et solide. Il est une bonne illustration des problèmes de l'identification et est une référence pour évaluer les compromis effort-efficacité inévitables dans les implémentations effectives.