Nous allons maintenant décrire comment s’est passée la phase de modélisa- tion : quels ont été les problèmes rencontrés, quelles solutions ont été trouvées et quels ont été les choix de modélisation. Les résultats fournis par AVISPA seront présentés et commentés dans la section 5.4.
5.3.1
Protocole ISO 9798-3
Étant donné que le protocole étudié étend le protocole d’authentification décrit dans le standard ISO 9798-3 [80], une première étude, conduite par des étudiants placés sous notre responsabilité [94], a commencé par la modélisation de ce dernier afin de préciser les échanges employés par le protocole étudié. Nous nous référons pour la suite à cette étude, en particulier en ce qui concerne les figures et les notations. Ce plan de travail a permis une prise en main du langage HLPSL sur un exemple simple à spécifier. En effet, la modélisation proposée par l’ISO 9798-3 reste assez élémentaire : une grande partie du travail est déjà accomplie et se trouve disponible sur le site du projet AVISPA [90].
Figure 5.1 – Animation SPAN
De plus, ce schéma de protocole ne fait intervenir que deux participants et utilise la cryptographie classique. Il a seulement fallu apporter à ces documents quelques modifications pour que la spécification corresponde à la version de la norme ISO adéquate. Le protocole a ensuite été animé avec SPAN pour voir si la modélisation était correcte (cf. Figure 5.1).
5.3.2
Notre protocole d’authentification
5.3.2.1 Problèmes rencontrés
On a vu que le protocole étudié reprend en grande partie les mécanismes du protocole ISO 9798-3 (cf. section 4.4.3). Pourtant, sa modélisation a été beau- coup plus complexe que celle de celui-ci. En effet, il a fallu surmonter différents problèmes, majoritairement dus aux limitations de l’outil AVISPA.
Tout d’abord, AVISPA considère la cryptographie comme une boite noire pré-codée dans le langage de description. En conséquence, il est impossible d’ef- fectuer d’autres opérations cryptographiques que celles prévues par le langage. Pour cette raison, les seules opérations prévues sont le chiffrement/déchiffrement par une clé symétrique ou asymétrique ainsi que le hachage (cf. section 2.4 du chapitre 2). De plus, AVISPA ne prend pas en compte les opérations arithmé- tiques les plus élémentaires comme l’addition. Cette limitation est clairement énoncée dans le manuel et le tutoriel d’AVISPA : « Do not use arithmetic ope- rators/relations (e.g.’+’, ’=<’). They are not supported by the translator. »,
5.3 Spécification du protocole d’authentification 109 « HLPSL does not support arbitrary arithmetic operators ; however, we can mo- del an approximation of addition which will reflect the properties that, from a security perspective, are most important ». Il apparaît donc que les éléments cryptographiques fondamentaux du protocole que sont la combinaison des parts de signature dans le schéma de Shoup [81] ou la vérification d’une adresse CGA, non contents de n’être pas présents dans le langage HLPSL, ne sont même pas programmables dans ce langage. Au mieux, il faut se contenter d’une modélisa- tion approchée de ces processus.
Un autre problème rencontré a été l’impossibilité pour un agent, d’envoyer plusieurs messages en même temps, voire même successivement. Un agent ne peut envoyer qu’un seul message, ce message est reçu par un autre agent et la réception provoque un changement d’état de ce dernier. Cet agent doit attendre la réponse d’un autre agent avant de pouvoir envoyer un nouveau message. On peut faire l’analogie avec des échanges de ping-pong.
Il n’a donc pas été possible de coder directement le fait qu’un JN envoie son identifiant à tous les pairs AAA et attende les th premières réponses. Dans la modélisation AVISPA, JN ne peut pas envoyer son identifiant à plusieurs pairs en même temps.
5.3.2.2 Solutions apportées
Afin de résoudre le problème de l’envoi simultané de l’identifiant de JN aux pairs, le problème a été modélisé de la façon suivante : JN envoie son identifiant une première fois. Le premier pair, AAA1 reçoit cet identifiant et lui envoie le
Figure 5.2 – Modélisation de l’envoi de IDJN(jn) et de RAAA (nonce) nonce1R
AAA. Lorsque JN reçoit RAAA, il envoie son identifiant au pair AAA2 et ainsi de suite (cf. Figure 5.2). Bien que dans la réalité le protocole ne soit pas implémenté de cette façon, nous considérons que cette modélisation conserve
1. Nonce dans l’acception ecclésiastique se traduit en français par nonce qui est la forme que nous avons retenue. Il s’agit d’un faux-ami. Dans le contexte informatique, ce mot-valise construit sur number once pourrait se construire sur nombre unique mais nous n’avons pas pu nous résoudre à le faire et avons gardé une traduction à l’évidence inexacte.
les propriétés de sécurité de ce protocole et reste raisonnablement fidèle à son fonctionnement.
Comme il n’était pas possible de coder la transformation des parts de signa- ture en une signature globale du groupe des pairs AAA, il était nécessaire d’en chercher une modélisation. Il a été choisi d’introduire un agent supplémentaire qui représenterait l’autorité AAA globale. Cet agent est un agent fictif : dans la réalité il n’existe pas.
L’idée est que le JN récupère le jeton signé avec les parts de clés privées des thpairs AAAi. Il les relaie ensuite au pair AAA global virtuel qui déchiffre les données avec la clé publique du système des pairs AAAi, puis les chiffre avec sa clé privée. Finalement, le JN reçoit le jeton signé par le pair AAA global.
Cette modélisation peut sembler étrange, mais au final, on a fait simplement appel à l’autorité AAA virtuelle pour effectuer une transformation qui a nor- malement lieu directement dans le JN. On fait donc passer par le réseau une information complémentaire qui, selon la spécification du protocole, devrait res- ter dans le JN. Comme l’attaquant a un contrôle total du réseau, on lui donne ainsi des possibilités supplémentaires d’action. Cette modélisation n’écarte donc pas d’attaque sur le protocole.
L’autre problème lié à la cryptographie est la difficulté de modéliser la vé- rification d’une adresse CGA. Comme les messages échangés à cet effet entre le JN et le destinataire résultent d’échanges SEND, Diffie-Hellman et de don- nées d’authentification (cf. section 4.5), nous avons simplement considéré que l’équivalent d’un échange SEND entre JN et le destinataire avait déjà eu lieu et qu’ainsi le destinataire possédait dans son cache des voisins (cf. section C.3.1 de l’annexe C) la CGA du JN ainsi que la clé publique associée.
Alors que la première modélisation aboutit à renforcer les possibilités d’at- taques, la seconde modélisation les diminue. Il n’est donc pas théoriquement sûr que la modélisation globale du protocole ne soit pas plus solide que le protocole initial lui même. Pour autant, ce que l’on sait du protocole SEND [70], sans constituer une véritable preuve est de nature à nous rassurer sur ce point. 5.3.2.3 Modélisation pour th = n
Il s’agit de comprendre le protocole d’authentification, c’est à dire d’étudier les échanges entre le JN et les pairs AAA (cf. sectionsect :ptmzt du chapitre 4). Cette étude s’arrête à l’obtention du jeton et ne prend pas en compte la phase d’autorisation où le JN communique avec un destinataire dans le réseau MANET.
Elle teste :
– l’authentification mutuelle entre un JN et les différents pairs sollicités, – l’authentification du pair AAA virtuel vis-à-vis du JN.
Pour th = n = 3, l’animation SPAN de cette modélisation est présentée dans la figure 5.3. Lors des steps 1 à 6, JN envoie son identifiant aux pairs AAA1, AAA2 et AAA3. Ces derniers lui répondent tous le même RAAA qui a la valeur nonce sur le schéma. Lors des steps 7 à 12, JN envoie son certificat assorti de différentes données aux AAAi afin de se faire authentifier. Une fois cette authentification acquise auprès des pairs AAAi, ceux-ci lui envoient leurs données d’authentification ainsi que les différentes parts du jeton signés avec leurs parts de clé privée respectives.
5.3 Spécification du protocole d’authentification 111
Figure 5.3 – Modélisation du protocole pour th = n = 3
Comme il a été expliqué plus haut, JN relaie ces messages vers le pair AAA global virtuel pour qu’il combine ces éléments de signatures. Au cours de cette phase, JN ne prend pas connaissance du contenu de ces messages provenant des AAAi car il ne dispose pas de leurs clés publiques.
Le pair AAA global reçoit les différents messages, combine les signatures et envoie le résultat au JN. JN peut en vérifier la signature grâce à la clé publique du service AAA. Le pair AAA virtuel est donc authentifié auprès du JN. 5.3.2.4 Modélisation pour th < n
Par rapport à l’étude pour th = n présentée ci-dessus, l’intérêt de cette modélisation serait la vérification du bon fonctionnement de l’authentification alors même que th−1 pairs sont corrompus. Cela pose déjà la question de savoir ce que signifie pour un pair d’être corrompu : s’agit-il d’une simple absence de réponses aux sollicitation ? s’agit-il d’une attitude plus activement néfaste ? Si oui, laquelle ? Quoiqu’il en soit, le langage HLPSL ne semble pas fournir de primitives de description de ces comportements, pas plus qu’il ne fournit les
éléments permettant d’en faire le codage soi-même.
D’autre part, il s’agit d’une certaine façon de tester si le protocole est résis- tant aux pannes, plus précisément si les pannes de certains éléments du réseau ne sont pas de nature à permettre des attaques contre le protocole. Il semble que le logiciel AVISPA n’est pas été prévu pour traiter de tels problèmes.