Contrôle d'un message reçu en mode de multidiffusion dans un réseau sans fil

La présente invention concerne le domaine des communications sans fil.

Elle vise, de manière générale, la sécurité d'une communication entre :

- une entité communicante (dite ci-après "entité cliente"), via un réseau, et

- un point d'accès de ce réseau (du vocable anglo-saxon "Access Point").

Elle s'applique avantageusement au contexte des communications via des réseaux sans fil tels que spécifiés notamment dans la norme IEEE 802.11 (réseaux Hot Spots, Entreprises et Résidentiels, ou autres).

On rappelle ci-après des éléments de la norme IEEE 802.11 i, qui concerne les aspects sécuritaires de la norme générale IEEE 802.11.

Lorsqu'une entité cliente (ou station ci-après) s'authentifie auprès d'un point d'accès, des clés de cryptage sont obtenues (soit directement communiquées, soit dérivées). Les clés sont utilisées par la suite pour le chiffrement et la signature des trames envoyées. Une première clé est dite "clé individuelle PTK" (pour "pairwise transient key"). Elle n'est connue que du point d'accès et de la station. Cette clé est utilisée pour le chiffrement des trames de données, en particulier en mode de diffusion individuelle (du vocable anglo-saxon "unicast"). Une seconde clé est dite "clé de groupe GTK' (pour "group transient key"). Elle est connue de toutes les stations qui se sont associées à un même point d'accès. Cette clé sert pour le chiffrement et la signature des trames de données en mode de multidiffusion (du vocable anglo-saxon "broadcast").

Les communications de messages notamment entre le point d'accès et les entités clientes s'effectuent par "trames", ce terme désignant, en contexte normalisé IEEE 802.11 , l'ensemble des données transmises sur un canal

radiofréquence par une entité cliente ou un point d'accès en une transmission continue. Une trame contient typiquement un en-tête (ou "header"), un contenu (dit "payload") ou corps de trame (pour "trame body"), et un champ de vérification (dit FCS pour "frame check séquence" et basé typiquement sur un calcul de type "checksum").

Par ailleurs, on entend ici par le terme "signet" le fait de composer une "signature cryptographique" en construisant un nombre dépendant d'une clé secrète connue du signataire et du contenu du message à signer. La vérification de la signature est effectuée au moyen d'une clé associée à ladite clé secrète. On peut ainsi vérifier que le message n'a pas été altéré et qu'il provient d'une entité connaissant cette clé secrète.

Les avancées récentes (norme 802.11 adoptée en juin 2004) pour pallier les techniques de piratage des réseaux du type précité améliorent considérablement la sécurité des réseaux, fournissant en particulier des primitives pour dériver les clés de session pour les points d'accès et pour les entités clientes afin de pouvoir chiffrer les échanges de données. Cependant, cette norme ne répond pas à toutes les exigences de sécurité des communications sans fil.

En effet, parmi les trois types de trames échangées dans de telles communications (les trames de données, les trames de gestion et les trames de contrôle), les seuls efforts réalisés en terme de protection n'ont pu se concentrer, à l'heure actuelle, que sur les trames de données.

La protection des trames en mode de multidiffusion n'est pas complète, car, même si une confidentialité est prévue, l'authenticité des trames n'est pas vérifiable. Par exemple, une station quelconque associée à un point d'accès est capable d'envoyer une trame en mode de multidiffusion en prétendant être

le point d'accès. Ainsi, la sécurité des communications en mode de multidiffusion n'est pas encore optimisée.

Par ailleurs, il n'existe à l'heure actuelle aucune protection des trames de gestion.

L'invention s'inscrit dans une technique dans laquelle un ou plusieurs messages supplémentaires de confirmation sont envoyés pour chaque message émis en mode de multidiffusion {"broadcast") afin de fournir les garanties de l'authenticité de ce message.

Récemment, une mise en œuvre sécuritaire qui a été proposée pour la norme IEEE 802.11 i, permettant de fournir l'authenticité des trames en mode de diffusion, peut se décrire comme suit, en référence aux figures 1 et 2.

Un point d'accès AP (figure 1), ou le cas échéant un "faux" point d'accès (typiquement un attaquant intrus), émet une trame TR _b (avec l'indice "£>" pour "broadcast") en mode de multidiffusion à destination d'une pluralité d'entités clientes EC-j, ..., ECj, ..., ECN (avec i compris entre 1 et N).

En référence à la figure 2, dans une première étape générale (E1), le point d'accès AP calcule (E11 ) un condensé H(MESS), par une fonction de hachage, du message MESS à envoyer et stocke (E12) ce condensé dans une table TAB (figure 1 ). Le point d'accès envoie (E 13) le message MESS en mode de multidiffusion dans la trame TRb précitée en la signant à l'aide d'une clé de groupe GTK.

Dans une deuxième étape générale (E2), chaque entité cliente ECj recevant la trame TR _b calcule (E14) un condensé H(MESSR), par la fonction de hachage précitée, du message MESSR contenu dans la trame reçue TRb. L'entité cliente ECj signe ce nouveau condensé H(MESSR) en utilisant la clé

individuelle PTK et transmet (E15) en mode de diffusion individuelle {"unicast") une trame TR _ui (avec les indices "u" pour "unicast" et "i" pour l'entité EC ₁ ) contenant ce nouveau condensé à destination du point d'accès AP (comme illustré sur Ia figure 1). Par ailleurs, chaque entité cliente ECi déclenche un compteur d'horloge (E16).

Dans une troisième étape générale (E3), le point d'accès AP vérifie si les condensés H(MESSR) contenus dans les trames TR _U ι qu'il reçoit se retrouvent dans la table TAB, en comparant (test E17) lesdits condensés reçus H(MESSR) au condensé H(MESS) du message initial MESS.

Si tel est le cas (flèche ok en sortie du test E17), le point d'accès AP n'effectue aucune opération supplémentaire et l'entité cliente concernée EQ valide finalement le message initial contenu dans la trame TR _b (E18). En revanche, le cas contraire (flèche ko en sortie du test E17) est indicatif qu'un "faux" point d'accès a diffusé une trame en muitidiffusion en usurpant le nom du vrai point d'accès AP. Le vrai point d'accès AP réagit en conséquence en envoyant (étape E19) une trame, en mode de diffusion individuelle et signée selon la norme IEEE 802.11 , à toutes les entités clientes qui ont envoyé une trame contenant le condensé H(MESSR) non identifié dans la table TAB. Le point d'accès AP prévient ainsi les entités clientes concernées qu'il n'a pas émis la trame TR _b - Un tel démenti est appelé "countermand".

Dans une quatrième étape générale (E4), une entité cliente ECi recevant cette trame de démenti "countermand" consulte (E20) le compteur d'horloge et si la valeur de compteur est inférieure à un seuil THR prédéterminé (flèche ok en sortie du test E20), l'entité ECi ignore la trame TR _b reçue initialement (E21 ). En revanche, si l'entité ECi ne reçoit pas de trame de démenti avant que le compteur d'horloge n'atteigne la valeur seuil THR (flèche ko en sortie du test E20), cette entité ECj considère que la trame TR _b reçue précédemment est valide et l'interprète (E 18).

Cette mise en œuvre permet ainsi de détecter la présence d'un intrus ayant usurpé le nom du point d'accès AP et d'ignorer alors les messages que cet intrus a envoyé.

Toutefois, cette mise en œuvre présente plusieurs désavantages.

D'abord, il est nécessaire d'attendre que le compteur d'horloge dépasse la valeur seuil THR (E17) avant de pouvoir interpréter les trames TR _b initialement reçues en mode de multidiffusion.

Par ailleurs, chacune des entités clientes tente d'occuper un canal radiofréquence alloué pour la communication pour émettre (E15) la trame TR _U j contenant la signature du message reçu H(MESSR). Par conséquent, il est très probable que des collisions aient lieu, résultant en la réémission de ces trames. Il advient par conséquent une perte de bande passante sur le canal de transmission.

En outre, cette technique reste ouverte aux communications pirates qui n'ont pas été réfutées à l'issue du procédé de la figure 2. Ainsi, cette technique est vulnérable à une attaque facilement réalisable et qui consiste en ce qui suit. Un faux point d'accès, émettant une trame en mode de multidiffusion et brouillant ensuite la voie radiofréquence (par exemple en envoyant continuellement des trames) pour éviter que les entités clientes ne reçoivent la trame de démenti, peut ainsi faire accepter une trame de multidiffusion TR _b quelconque aux entités clientes.

La présente invention vient améliorer la situation.

Elle propose à cet effet un procédé de communication, dans un réseau sans fil, entre des entités d'un groupe comprenant un point d'accès du réseau et au moins une entité cliente.

Le point d'accès est agencé pour calculer une signature cryptographique d'un message à l'aide d'une clé individuelle (PTKi) associée à l'entité cliente, et l'entité cliente est agencée pour vérifier cette signature cryptographique à l'aide dudit message et de sa clé individuelle (PTK,). Dans ce procédé, le point d'accès émet un premier message en mode de multidiffusion (TRb), et l'entité cliente, de son côté, reçoit, apparemment du point d'accès, ce premier message en mode de multidiffusion.

Dans le procédé au sens de l'invention, on cherche à vérifier, préférentiellement auprès de l'entité cliente précitée, notamment si le premier message reçu en mode de multidiffusion a bien été émis par le point d'accès apparent.

Le procédé au sens de l'invention comporte alors les étapes suivantes :

- le point d'accès envoie en outre, au moins à ladite entité cliente, un second message comprenant une signature d'une expression du premier message émis, calculée à l'aide de la clé individuelle associée à l'entité cliente précitée,

- l'entité cliente, de son côté, vérifie la signature reçue, à l'aide de sa clé individuelle et du premier message reçu en mode de multidiffusion, et décide une invalidité du premier message reçu en cas d'échec dans la vérification de cette signature.

La présente invention vise avantageusement une application du procédé ci- avant à un contexte de communication selon la norme IEEE 802.11.

La présente invention vise aussi un point d'accès, ainsi qu'une entité cliente, comportant des moyens respectifs pour la mise en œuvre du procédé ci-avant.

Concernant le point d'accès, ces moyens peuvent comporter un processeur capable d'exécuter un produit programme d'ordinateur comportant des instructions pour, à partir :

* d'un premier message émis par le point d'accès en mode de multidiffusion et à destination d'une ou plusieurs entités clientes,

- calculer, pour chaque entité cliente destinataire, une signature d'une expression du premier message, à l'aide d'une clé individuelle associée à l'entité cliente destinataire.

A ce titre, l'invention vise aussi un tel programme d'ordinateur.

Concernant l'entité cliente, ces moyens peuvent comporter un processeur capable d'exécuter un autre produit programme d'ordinateur comportant des instructions pour, à partir :

* d'un premier message reçu d'un point d'accès apparent dudit réseau sans fil, en mode de multidiffusion, et

* d'un second message reçu du point d'accès,

- vérifier si le contenu du second message comporte une signature d'une expression du premier message reçu, calculée à l'aide d'une clé individuelle (PTKj) associée à l'entité cliente, et - déclarer une invalidité du premier message reçu en cas d'échec de la vérification.

A ce titre, l'invention vise aussi cet autre programme d'ordinateur.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels, outre les figures 1 et 2 décrites ci-avant :

- la figure 3 illustre l'envoi d'un message de confirmation en mode de diffusion individuelle, dans un exemple de réalisation,

- la figure 4 illustre l'envoi d'un message de confirmation en mode de multidiffusion, dans une variante de la réalisation illustrée sur la figure 3, - la figure 5 illustre l'envoi d'une signature avec une clé de groupe GTK, préalablement à l'envoi du message de confirmation, et

- la figure 6 illustre la prise en compte d'une valeur comptant le rejeu d'une trame dans un identifiant de corps de trame ID_Playload.

II est considéré dans la description détaillée ci-après que les équipements suivants sont connectés ensemble par un protocole de communication sans fil (par exemple Wl-Fl), préférentiellement selon la norme IEEE 802.11i. En reprenant l'exemple de la figure 1 , ces équipements font partie d'un groupe d'entités communicantes comportant : - un point d'accès (référencé AP comme sur la figure 1 décrite précédemment), et

- des entités clientes (référencées EQ pour une i ^eme entité, avec i compris entre 1 et N).

En conformité avec la norme actuelle IEEE 802.11 i telle que présentée en tant qu'état de la technique en référence aux figures 1 et 2 ci-avant, le point d'accès et toutes les entités EQ partagent une même clé secrète de groupe GTK. En outre, le point d'accès partage une clé secrète individuelle PTKi avec chacune des entités EQ.

Ci-après, le terme "identifiant" de message (respectivement d'entité cliente) désigne toute valeur numérique permettant, de manière non ambiguë, d'identifier ce message (respectivement cette entité cliente), lors d'une session. Par exemple, une suite strictement croissante initialisée à "0" en

début de session d'une entité cliente pourrait être utilisée pour identifier de manière unique tout message lui étant destiné. Par ailleurs, l'adresse MAC (typiquement l'adresse de son interface Wl-Fl ou "carte IEEE 802.11") peut avantageusement être utilisée pour identifier une entité cliente. Dans ce dernier cas, cette entité ECj utilise préférentiellement le même identifiant (noté ID_ECj) pour toutes ses sessions de communication.

Par ailleurs, on note "X" une information relative à un corps de trame et qui est facilement identifiable notamment pour une entité cliente qui a déjà reçu ce corps de trame. Elle est désignée ci-après par les termes "expression X".

Préférentiellement, il peut s'agir du corps de trame lui-même. Cette mesure est avantageuse pour éviter le rejeu de trames par un intrus. En complément, l'expression X peut porter en outre sur une expression propre à l'entité cliente ECi qui a précédemment reçu le corps de trame. Elle est notée Xj dans ce cas (avec i compris entre 1 et N). Par exemple, la valeur Xi peut correspondre à une combinaison du corps de trame et de l'identifiant IDJEQ propre à l'entité ECj, cette combinaison pouvant très simplement consister en une concaténation.

En référence maintenant à la figure 3, le point d'accès AP a envoyé (étape E31 ) un message dans une trame TR _b en mode de multidiffusion ("broadcast") aux entités clientes ECi (avec i compris entre 1 et N). Au sens de l'invention, le point d'accès va confirmer cet envoi en calculant (E32) une signature d'une expression X de ce message (notée signpτκi(X)) en utilisant la clé individuelle PTKi associée à chaque entité EQ. Le procédé selon l'invention, dans sa forme la plus simple côté point d'accès, peut s'arrêter simplement ensuite à la transmission, en mode de diffusion individuelle ("unicast"), à chaque entité EQ, d'une trame TR _U ι (en rappelant ici que l'indice "u" vise le mode de diffusion individuelle et l'indice i vise la i ^ème entité cliente ECi) incorporant la signature correspondante signpτκi(X) (avec i compris entre 1 et N).

De leur côté, chaque entité cliente EQ recevant cette trame TR _U j vérifie (E33) si son contenu signpτκι(X) résulte bien d'une signature, à l'aide de la clé individuelle PTKi qui est associée à cette même entité ECj, de l'expression X du message contenu dans la trame TR _b reçue en mode de multidiffusion à l'étape précédente E31. Si la correspondance est vérifiée (flèche ok en sortie du test E33), l'entité EQ valide la trame TR _b reçue en mode de multidiffusion (E34), ce qui signifie que c'est bien le point d'accès et non un pirate qui a envoyé cette trame TR _b . Sinon (flèche ko en sortie du test E33), l'entité EQ ignore cette trame TRb (E35). Dans une réalisation possible, l'entité EQ peut simplement détruire une telle trame TR _b et/ou envoyer un message d'alerte à destination d'un superviseur du réseau.

En pratique, il peut être prévu un compteur d'horloge, auprès de chaque entité cliente EQ, qui peut être consulté (E37) pour attendre, jusqu'à une durée limite THR, la réception de la signature sign _PT κi(X)- Au-delà de cette durée limite (flèche ko en sortie du test E36), l'entité cliente EQ qui n'a pas reçu le message de confirmation comportant la signature signpτκi(X) ignore la trame TR _b reçue en mode de multidiffusion (E35).

D'une part, on a donc vérifié l'identité du point d'accès AP et, d'autre part, les entités clientes EQ ont prouvé ainsi leur identité, simplement par la transmission de trames de confirmation vers ces entités ECi, selon un premier avantage que présente l'invention.

En termes plus généraux, la réalisation illustrée sur la figure 3 peut être décrite ainsi :

- le point d'accès communique avec une pluralité d'entités clientes,

- le point d'accès est agencé pour calculer une pluralité de signatures cryptographiques d'un message à l'aide d'une pluralité de clés individuelles respectives associées chacune à une entité cliente, et

- chaque entité cliente est agencée pour vérifier une signature cryptographique à l'aide dudit message et de sa clé individuelle.

Le point d'accès émet alors un premier message en mode de multidiffusion TR _b à destination de ladite pluralité d'entités clientes, et chaque entité cliente reçoit un premier message, apparemment du point d'accès, en mode de multidiffusion.

Le point d'accès envoie en outre (E32), en mode de diffusion individuelle (TR _U i) au sens de cette réalisation, un second message à destination de chaque entité cliente, le second message comprenant une signature d'une expression du premier message émis, calculée à l'aide de la clé individuelle associée à l'entité cliente destinataire.

De leur côté, chaque entité cliente vérifie la signature reçue, à l'aide de sa clé individuelle et du premier message reçu en mode de multidiffusion, et décide une invalidité du premier message reçu en cas d'échec dans la vérification de cette signature.

Dans la variante de la figure 4, une unique trame de confirmation incluant toutes les signatures signpτκi(X) (avec i compris entre 1 et N) est envoyée à aux entités clientes ECi en mode de multidiffusion ("broadcast"). On fait avantageusement intervenir ici l'identifiant ID_ECj de chaque entité cliente EQ, comme suit. Le point d'accès AP calcule, comme précédemment la signature de X (notée signpτκι(X)) en utilisant la clé individuelle PTKi associée à chaque entité ECi et, dans une succession de bits Yi propre à chaque entité cliente EQ, y ajoute (E41 ) l'identifiant ID_ECj de cette entité cliente EQ.

Ensuite, le point d'accès AP effectue (E42) une concaténation C ₁ des suites de bits Y ₁ qu'il transmet (E43) en une ou plusieurs trames TR _b (Ci) en mode de multidiffusion ("broadcast"), à destination de toutes les entités clientes ECj.

Avantageusement grâce à l'identifiant IDJξC-, que chaque entité ECj retrouve (E44) dans la concaténation C-i, chaque entité EQ peut vérifier la signature signpτκi(X) à l'aide de sa clé individuelle PTK] associée, comme décrit ci-avant en référence à la figure 3 (étapes E33, E34/E35).

En termes plus généraux, la réalisation illustrée sur la figure 4 peut être décrite ainsi :

- le point d'accès envoie (E43), en mode de multidiffusion (TR _b (CI )), un second message à destination des entités clientes, ce second message comprenant :

* une concaténation (E42) d'une pluralité de signatures de ladite expression du premier message émis, ces signatures étant calculées à l'aide des clés individuelles respectivement associées à chaque entité cliente destinataire, et * des identifiants (IDJξQ) respectifs des entités clientes destinataires,

- et chaque entité cliente :

* retrouve (E44), à partir de son identifiant dans le second message, la signature calculée à l'aide de sa clé individuelle,

* vérifie (E33) ladite signature à l'aide de sa clé individuelle et du premier message reçu en mode de multidiffusion, et

* décide (E35) une invalidité du premier message reçu en cas d'échec dans la vérification de ladite signature.

Dans une réalisation générale préconisée d'ailleurs par la norme IEEE 802.11 , on prévoit en outre une vérification supplémentaire portant sur la clé de groupe GTK, avantageusement dès l'envoi du message initial dans la trame TR _b en mode de multidiffusion. Ainsi, en référence à la figure 5, l'étape E31 de la figure 3 est remplacée par :

- une étape E51 dans laquelle le point d'accès AP construit une chaîne de bits C ₀ comportant le message à transmettre en mode de multidiffusion et son expression X signée par la clé de groupe GTK (notée signGτκ(X)), et

- une étape E52, dans laquelle au moins une trame TR _b (C ₀ ) comportant cette chaîne de bits C ₀ est envoyée à toutes les entités EC ₁ en mode de multidiffusion.

De leur côté, chaque entité cliente ECj vérifie la validité du message reçu en mode de multidiffusion comme suit. Chaque entité cliente EQ récupère la chaîne de bits C ₀ et vérifie (E53) la signature sign _GT κ(X), à l'aide de sa clé de groupe GTK et de l'information (l'expression X) qu'elle déduit du reste du message reçu, afin de s'assurer que ce message provient bien d'un membre du groupe. Si la signature n'est pas valide (flèche ko en sortie du test E53), l'entité ECi ignore ce message (E54). En revanche, si la signature est valide (flèche ok en sortie du test E53), l'entité EQ peut traiter ensuite la trame contenant la (ou les) signature(s) avec la (ou les) clé(s) individuelle(s) en menant (respectivement l'étape E44 de la figure 4 et) les étapes E33, E34 ou E35 de la figure 3.

En termes plus généraux, la réalisation illustrée sur la figure 5 peut être décrite ainsi :

- le point d'accès est agencé pour calculer une signature cryptographique d'un message à l'aide d'une clé de groupe (GTK) associée à un groupe comportant le point d'accès et au moins une entité cliente, et - chaque entité cliente de ce groupe est agencée pour vérifier une signature cryptographique à l'aide dudit message et de la clé de groupe.

En particulier, dans cette réalisation :

- le point d'accès AP émet (E52), en mode de multidiffusion, le premier message précité avec une signature sign _G τκ(X), calculée (E51) à l'aide de

la clé de groupe, d'une expression X du premier message, à destination d'au moins une entité cliente du groupe, et

- l'entité cliente EQ :

* reçoit un premier message en mode de multidiffusion, avec une signature calculée à l'aide de la clé de groupe d'une expression dudit premier message reçu,

* vérifie (E53) cette signature signGτκ(X) avec la clé de groupe et le premier message reçu, et

- décide (E54) une invalidité du premier message reçu en cas d'échec dans la vérification de ladite signature avec la clé de groupe,

- ou décide la vérification (E33) de la signature sign _PT κi(X) dans le second message avec la clé individuelle, en cas de réussite dans la vérification de la signature dans le premier message avec la clé de groupe.

Dans une réalisation avantageuse, il peut être prévu de regrouper toutes les suites de bits C ₀ et Ci précitées dans au moins une même trame TR _b à transmettre du point d'accès vers les entités clientes ECj en mode de multidiffusion. Dans ce cas, il suffit d'inclure dans cette trame TR _b le corps de trame et les signatures d'une même expression X relative à ce corps de trame, à l'aide des clés individuelles PTKi, d'une part, et à l'aide de la clé de groupe GTK, d'autre part. L'intérêt de cette réalisation est de ne transmettre qu'au moins une trame TR _b en mode de multidiffusion. Ainsi, en termes plus généraux, dans le cas de messages communiqués par trames (notamment comme au sens de la norme IEEE 802.11), le point d'accès envoie les premier (Co) et second (Ci) messages précités dans au moins une même trame en mode de multidiffusion.

On décrit maintenant en référence à la figure 6 un mode de réalisation dans lequel on fait intervenir en outre un identifiant de corps de trame (noté ci-après ID_Payload) dans l'expression X.

L'identifiant ID_Payload est préférentiellement un élément d'une suite de nombres qui doit être non ambiguë et ne doit pas se répéter au cours d'une session. On entend ici par le terme "session" une période de temps pendant laquelle une unique clé de groupe GTK est partagée. Cette suite peut-être une suite de nombres, codée sur un certains nombre d'octets et de préférence strictement croissante. Elle peut également être une suite générée par le point d'accès AP et concaténée et/ou insérée dans la suite de bits Co décrite ci- avant en référence à la figure 5.

L'expression X qui sert notamment dans le calcul de la signature de groupe signGτκ(X) dépend préférentiellement de cet identifiant ID_Payload. Il peut par exemple s'agir d'une combinaison (telle qu'une concaténation) de l'identifiant de corps de trame ID_Payload et du corps de trame lui-même.

Ainsi, à l'étape E61 de la figure 6, l'expression X est construite par exemple en fonction du corps de trame, de son identifiant et éventuellement d'une expression propre à chaque entité cliente (construction d'une expression Xj décrite ci-avant). A l'étape E62, le point d'accès AP envoie, en mode de multidiffusion, une trame TR _b contenant une signature de l'expression X ainsi construite et menée à l'aide de la clé de groupe GTK.

A la réception par une entité cliente EQ des trames contenant les chaînes de bits Co et Ci, cette entité vérifie (outre les vérifications décrites ci-avant) que l'identifiant ID_Payload est strictement supérieur à sa dernière valeur valide reçue (test E63). Si l'identifiant ID_Payload est valide (flèche ok en sortie du test E63), l'entité EQ met à jour l'identifiant ID_Payload stocké dans une mémoire qu'elle comporte et poursuit les vérifications des signatures décrites

ci-avant (E44;E33,E34/E35). Sinon (flèche ko en sortie du test E63), l'entité ECj ignore le message contenu dans la trame TR _b (E64).

En termes plus généraux, la réalisation illustrée sur la figure 6 peut se décrire ainsi. Dans un contexte de communication dans lequel on prévoit un identifiant de corps de trame "ID_payload" comportant une valeur comptant un nombre de sessions de communication d'une entité cliente, l'expression X du premier message comporte en outre une expression de cet identifiant et, sur réception du premier message, l'entité cliente décide (E64) une invalidité de ce premier message si la valeur d'identifiant du premier message reçu est inférieure ou égale à une valeur d'identifiant d'un message reçu préalablement (test E63).

Cette réalisation utilisant un identifiant de corps de trame est particulièrement avantageuse en contexte de multidiffusion sécurisée contre les attaques par rejeu dans lesquelles un intrus pourrait renvoyer exactement une même trame contenant notamment la suite de bits C ₀ .

Cette vérification de l'identifiant ID_Payload doit préférentiellement tenir compte de l'initialisation d'autres équipements fournissant un identifiant ID_Payload lors d'une nouvelle connexion au réseau sans fil. A cet effet, le point d'accès peut fournir une valeur initiale de cet identifiant à une entité cliente EC) qui se connecte (par exemple en même temps que la communication de la clé de groupe GTK).

Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple ; elle s'étend à d'autres variantes.

Ainsi, le chiffrement global des messages transmis n'est pas utilisé dans l'exemple décrit ci-avant, mais dans une variante sophistiquée, cette mesure

peut être avantageuse s'il n'est pas souhaité que des intrus accèdent facilement au contenu des trames.