4 L'identification.

4.1 La certification en général

Ces techniques peuvent alors être utilisées pour résoudre les problèmes suivants dans un échange entre deux entités A et B :

• [Problème 1] (non-intrusion) : protéger A et B contre tous les messages que pourrait émettre une tierce partie C (y compris en "rejouant" des cryptogrammes qu'il aurait pu capter, mais pas su traduire).
• [Problème 2] (signature) : protéger A contre tous les messages que B pourrait fabriquer dans le but de prétendre que A en est l'auteur.
• [Problème 3] (non-répudiation) : protéger B contre toute tentative ultérieure de A pour prétendre qu'il ne serait pas l'auteur de messages qu'il aurait pourtant envoyé.

On voit que le problème 1 est un problème privé entre A et B, tandis que les problèmes 2 et 3 consistent à accumuler des évidences qui permettront à une troisième partie d'arbitrer le conflit.

4.2 Une logique de l'identification

Nous intéressant plus particulièrement à l'identification, il s'agit donc pour nous de décrire des protocoles, c'est à dire des échanges de messages, à la fin desquels on puisse obtenir la certitude de ce que quelque chose (présumé désagréable) ne se produira pas, ou bien de ce que quelque chose (présumé désirable) se produira.

On est donc dans un cas où l'attitude "empiriste" est très certainement mauvaise, et doit être remplacée par une solide méthode de preuve (cf. la réponse [43] de D.A. Simovici à la critique de son livre "Mathematical Foundation of Computer Science" parue dans IEEE- Computer [16]). Et cela d'autant plus que les protocoles d'identification fonctionnent en détournant les algorithmes de chiffrement de leur objet initial : la confidentialité, pour en inférer un certain nombre de prédicats [32].

Une formalisation des problèmes d'identification a été proposée par Burrows-Abadi-Needham [8]. Les prédicats élémentaires du formalisme B.A.N. sont listés dans la Table 1. On peut constater que le prédicat : "l'entité E a dit cela, dans une session ou une autre, et y croyait à cette époque" est clairement distinct du prédicat : "l'entité E vient de dire cela, immédiatement, et tient cela pour vrai, dans la session actuelle".

Table: Les prédicats de Burrows-Abadi-Needham.

énoncé	signification
$\mathrm{admet}\left( P , X \right)$	P est fondé à agir en tenant X pour vrai.
$\mathrm{connait}\left( P , X \right)$	P a reçu un message contenant X (et il est sûr de ne pas en être l'émetteur... )
$\mathrm{dixit}\left( P , X \right)$	P a envoyé (maintenant ou dans le passé) un message contenant X
	et $\mathrm{admet}\left( P , X \right)$ était vrai à ce moment là
$\mathrm{jauge}\left( S , X \right)$	S a juridiction sur X (son jugement sur la validité de X doit être tenu pour correct)
$\mathrm{recent}\left( X \right)$	la formule X n'a jamais été utilisée dans le passé
$\mathrm{sec}\left( k , P , Q \right)$	k est une clef secrète entre P et Q.
$\mathrm{pub}\left( k , Q \right)$	k est la clef publique de Q, sa clef privée étant notée $k^{-1}$

On fait alors les hypothèses suivantes sur la technique de codage : un message ne peut être déchiffré sans la clef, une clef ne peut être inférée des messages, les cryptogrammes (=message chiffré) sont vérifiables, et un cryptogramme vérifiable ne peut être fabriqué sans qu'on en connaisse la clef. Il devient alors raisonnable d'adopter un certain nombre de règles d'inférence, qui sont résumées dans la Table 2. Il convient alors qu'un protocole d'identification entre les entités P et Q aboutisse à :

$$\mathrm{admet}\left( P , \mathrm{admet}\left( Q , \mathrm{sec... ...rm{admet}\left( P , \mathrm{sec}\left( k , P , Q \right) \right) \right)$$

c'est à dire soit logiquement correct, avant que l'on se pose quelqu'autre question à son sujet.

Table: Règles d'inférence en logique B.A.N.

hypothèse	conclusion
$\mathrm{admet}\left( P , \mathrm{sec}\left( k , Q , P \right) \right)$ et $\mathrm{connait}\left( P , X_{k} \right)$	$\mathrm{admet}\left( P , \mathrm{dixit}\left( Q , X \right) \right)$
$\mathrm{admet}\left( P , \mathrm{pub}\left( k , Q \right) \right)$ et $\mathrm{connait}\left( P , X_{k^{-1}} \right)$	$\mathrm{admet}\left( P , \mathrm{dixit}\left( Q , X \right) \right)$
$\mathrm{admet}\left( P , \mathrm{recent}\left( X \right) \mathrm{et} \mathrm{dixit}\left( Q , X \right) \right)$	$\mathrm{admet}\left( P , \mathrm{admet}\left( Q , X \right) \right)$
$\mathrm{admet}\left( P , \mathrm{jauge}\left( Q , X \right) \mathrm{et} \mathrm{admet}\left( Q , X \right) \right)$	$\mathrm{admet}\left( P , \mathrm{admet}\left( Q , X \right) \right)$
$\mathrm{connait}\left( P , \left\{ X, Y\right\} \right)$	$\mathrm{connait}\left( P , X \right)$
$\mathrm{admet}\left( P , \mathrm{sec}\left( k , Q , P \right) \right)$ et $\mathrm{connait}\left( P , X_{k} \right)$	$\mathrm{connait}\left( P , X \right)$
$\mathrm{connait}\left( P , \left\{ X, Y\right\} \right)$ et $\mathrm{admet}\left( P , \mathrm{recent}\left( X \right) \right)$	$\mathrm{admet}\left( P , \mathrm{recent}\left( Y \right) \right)$

4.3 La grille de comparaison

Dans les paragraphes suivants, nous allons décrire plusieurs protocoles en nous efforçant de leur appliquer la même grille de lecture, afin de permettre des comparaisons. Nos rubriques sont :

• [1. implémentation]Il est clair qu'un protocole largement implanté, sur un ou des sites prestigieux, bénéficie d'une plus large critique, à la fois de la communauté scientifique et des intrus. On peut d'autant mieux apprécier sa "tenue de route".
• [2. objectifs.]Cette section souligne les objectifs particuliers qui ressortent des articles écrits par les initiateurs de ces protocoles. Se pose alors la question de la réalisation de ces objectifs particuliers, mais aussi la question d'évaluer le poids des inévitables compromis sécurité/rapidité sur les autres objectifs.
• [3. chiffrement.]La distinction principale est entre chiffrement à clef secrète (style DES) ou bien à clef publique (style RSA), le second permettant plus de possibilités, en particulier de signer un message. Mais il est aussi beaucoup plus lent et plus gourmand en puissance de calcul : coder un bloc (= 64 octets) nécessite environ 800 multiplications sur 64 octets, tandis que le DES, même implémenté par programme, fonctionne à quelques kilo-octets par seconde.
• [4. hypothèses.]Cette section met en évidence les présupposés matériels des protocoles examinés. Ainsi est-il naturel de vouloir que les "centrales d'authentification" s'exécutent sur quelques machines dédiées, confinées dans des locaux physiquement protégés. Il l'est moins de faire des hypothèses d'intégrité, même faibles, sur des stations en libre-service, accessibles de plus par rlogin. Dans le premier cas, le protocole reste un protocole "généraliste". Dans le second, il est captif d'une configuration matérielle inhabituelle.
• 
  

  Table 3: Conventions de notation.

  notation	désignation	commentaire
  $P,$ Q	entités communicantes	extrémités d'un lien de couche $\geq$ 4
  $W_{p}$	mot_de_passe de P	à exposer le moins possible
  $S$	centrale d'identification.	but : n'avoir que n clefs au lieu de n$²$
  $K_{s}$	clef publique de S	s'il y a lieu. supposée "incassable"
  k	clef temporaire	dédiée à une communication entre deux entités
  $X_{k}$	cryptogramme	obtenu par chiffrement du message X avec la clef k

  
  

• [5. déroulement.]Cette section décrit les messages échangés dans une double perspective : d'une part en termes de correction logique, et d'autre part en termes d'efficacité. Des heuristiques permettent en effet d'accélérer le déroulement de ces protocoles dans les cas les plus fréquents, diminuant le surcoût moyen dû à la sécurité. Les conventions utilisées sont décrites dans la Table 3.
  Les protocoles décrits ci-dessous comportent généralement un mécanisme de tickets à durée de vie limitée. Pour ce faire, l'utilisateur P et la centrale S s'identifient mutuellement par la possession du mot de passe de P. Comme décrit dans la Table 4, P reçoit en clair un ticket destiné à l'entité Q et en code une clef temporaire $k$ destinée à chiffrer le corps des messages destinés à Q et à déchiffrer les messages reçus de Q.
  Ce mécanisme permet une identification à chaque requête sans que le mot de passe de l'utilisateur soit stocké en clair dans la machine, ni retapé à chaque fois. D'autre part la compromission de la clef temporaire $k$ n'engendre que des problèmes ... temporaires, et est d'une gravité moindre que la compromission du mot de passe lui-même.
• 
  

  Table: Le mécanisme des tickets.

  obtention :

  1	$P\hookrightarrow S$	$P, Q, np$
  	$S$	ticket = $\left\{ P, Ttl_{k}, k\right\} _{Wq}$
  2	$S\hookrightarrow P$	Q ; ticket ; $\left\{ k, np\right\} _{Wp}$

  Wp mot de passe de P (connu de P et de S)

  k clef de session utilisable entre P et Q

  Ttl_k durée d'acceptabilité de k (time to live)

  utilisation :

  $P\hookrightarrow Q : ticket, M_{k}$ conduit à $\mathrm{admet}\left( Q , \mathrm{dixit}\left( P , M \right) \right)$

  
  

• [6. critique.]Il convient en premier lieu de rappeler que tout protocole, fût-il une passoire pour les initiés, constitue déjà un filtre qui élimine la plupart des intrus. Tandis que se protéger contre tout et tous, y compris contre les ingénieurs-système qui gèrent l'ensemble d'un domaine est une vaste question, qui d'ailleurs relève plus de la gendarmerie que de l'informatique.
  Tout compromis est donc raisonnable, à condition qu'il soit clairement exprimé et documenté, et que l'implémentation soit suffisamment paramétrique pour que l'on puisse choisir d'autres compromis lors du portage dans un site différent. La seule chose à ne pas faire est de gêner abusivement les utilisateurs, car sinon des stratégies de contournement apparaîtront qui empêcheront le protocole de fonctionner.
  Et, bien entendu, nous signalerons les fautes de logique ou de cryptologie, qui ne sont pas si rares.
• [7. conclusion.]Nous essaierons alors de formuler une opinion, qui portera principalement sur la netteté de la formulation des hypothèses (matériels utilisés et types d'attaques envisagés) et sur la clarté (et la validité) des garanties offertes.