WO2007034045A1 - Controle d'un message reçu en mode de multidiffusion dans un reseau sans fil - Google Patents

Controle d'un message reçu en mode de multidiffusion dans un reseau sans fil Download PDF

Info

Publication number
WO2007034045A1
WO2007034045A1 PCT/FR2006/001974 FR2006001974W WO2007034045A1 WO 2007034045 A1 WO2007034045 A1 WO 2007034045A1 FR 2006001974 W FR2006001974 W FR 2006001974W WO 2007034045 A1 WO2007034045 A1 WO 2007034045A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
access point
signature
client entity
received
Prior art date
Application number
PCT/FR2006/001974
Other languages
English (en)
Inventor
Stanislas Francfort
Fabrice Stevens
Jérôme RAZNIEWSKI
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2007034045A1 publication Critical patent/WO2007034045A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/102—Route integrity, e.g. using trusted paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

  • the present invention relates to the field of wireless communications.
  • client entity a communicating entity (hereinafter referred to as “client entity”), via a network, and
  • a client entity When a client entity (or station hereafter) authenticates with an access point, encryption keys are obtained (either directly communicated or derived). The keys are subsequently used for the encryption and signature of sent frames.
  • a first key is called “individual key PTK” (for "pairwise transient key”). It is known only from the access point and the station. This key is used for the encryption of the data frames, in particular in unicast mode (the English word “unicast”).
  • a second key is called a “group transient key” (GTK) and is known to all stations associated with the same access point.This key is used for encrypting and signing frames. in multicast mode (the English word "broadcast”).
  • the message communications are carried out by "frames", this term designating, in IEEE 802.11 standardized context, all the data transmitted on a channel. radiofrequency by a client entity or an access point in a continuous transmission.
  • a frame typically contains a header (or “header”), a content (called “payload”) or frame body (for "frame body”), and a check field (called FCS for "frame check sequence” and typically based on a “checksum” type calculation).
  • the term "bookmark” is understood here to mean composing a "cryptographic signature” by constructing a number dependent on a secret key known to the signer and the content of the message to be signed. The verification of the signature is performed by means of a key associated with said secret key. It can thus be verified that the message has not been altered and that it comes from an entity that knows this secret key.
  • Frame protection in multicast mode is not complete because, even if confidentiality is provided, the authenticity of the frames is not verifiable. For example, any station associated with an access point is capable of sending a frame in multicast mode claiming to be the access point. Thus, the security of multicast communications is not yet optimized.
  • the invention is part of a technique in which one or more additional confirmation messages are sent for each message broadcast in "broadcast" mode in order to provide guarantees of the authenticity of this message.
  • An AP access point ( Figure 1), or where appropriate a "false” access point (typically an intruder attacker), transmits a frame TR b (with the index "£>" for "broadcast") in multicast mode to a plurality of client entities EC-j, ..., ECj,..., ECN (where i is between 1 and N).
  • the access point AP calculates (E11) a digest H (MESS), by a hash function, of the message MESS to send and stores (E12). condensed in a TAB table ( Figure 1).
  • the access point sends (E 13) the MESS message in multicast mode to the above-mentioned TRb frame by signing it using a GTK group key.
  • each client entity ECj receiving the frame TR b calculates (E14) a digest H (MESSR), by the aforementioned hash function, of the message MESSR contained in the received frame TRb.
  • the client entity ECj signs this new digest H (MESSR) using the key individual PTK and transmits (E15) in unicast mode a frame TR ui (with the indices "u" for "unicast” and "i" for the entity EC 1 ) containing this new digest destined for the AP access point (as shown in Figure 1).
  • each client entity ECi triggers a clock counter (E16).
  • the access point AP checks whether the digests H (MESSR) contained in the frames TR U ⁇ which it receives are found in the table TAB, by comparing (test E17) said received digests H (MESSR) to the condensed H (MESS) of the initial message MESS.
  • MESSR digests H
  • the access point AP does not perform any additional operation and the client entity concerned EQ finally validates the initial message contained in the frame TR b (E18).
  • the opposite case (arrow KB at the output of the test E17) is indicative that a "false" access point has broadcast a multicast frame by usurping the name of the real access point AP.
  • the real AP access point reacts accordingly by sending (step E19) a frame, in IEEE 802.11 IEEE, to all the client entities that sent a frame containing the H digest (MESSR) no. identified in the TAB table.
  • the access point AP thus prevents the client entities concerned that it has not sent the frame TR b - Such denial is called "countermand".
  • a client entity ECi receiving this denial frame "countermand” consults (E20) the clock counter and if the counter value is less than a predetermined threshold THR (ok arrow at the output of the test E20), the entity ECi ignores the frame TR b initially received (E21). On the other hand, if the entity ECi does not receive a deny frame before the clock counter reaches the threshold value THR (arrow ko at the output of the test E20), this entity ECj considers that the frame TR b received previously is valid and the interpreter (E 18). This implementation thus makes it possible to detect the presence of an intruder having usurped the name of the access point AP and to ignore then the messages that this intruder sent.
  • each of the client entities attempts to occupy a radio frequency channel allocated for the communication to transmit (E15) the frame TR U j containing the signature of the received message H (MESSR). Therefore, it is very likely that collisions occur, resulting in the retransmission of these frames. As a result, there is a loss of bandwidth on the transmission channel.
  • MESSR signature of the received message H
  • this technique remains open to pirate communications that have not been refuted at the end of the process of Figure 2.
  • this technique is vulnerable to an easily achievable attack and consists of the following.
  • a false access point transmitting a frame in multicast mode and then scrambling the radio frequency channel (for example by continuously sending frames) to prevent client entities from receiving the denial frame, can thus accept a multicast frame TR b any to the client entities.
  • the present invention improves the situation.
  • a method of communication in a wireless network, between entities of a group comprising an access point of the network and at least one client entity.
  • the access point is arranged to compute a cryptographic signature of a message using an individual key (PTKi) associated with the client entity, and the client entity is arranged to verify this cryptographic signature with the using said message and its individual key (PTK).
  • PTKi individual key associated with the client entity
  • the client entity is arranged to verify this cryptographic signature with the using said message and its individual key (PTK).
  • the access point transmits a first message in multicast mode (TRb), and the client entity, for its part, receives, apparently from the access point, this first message in multicast mode.
  • the method in the sense of the invention, it seeks to check, preferably with the aforementioned client entity, especially if the first message received in multicast mode has been issued by the apparent access point.
  • the access point further sends, at least to said client entity, a second message comprising a signature of an expression of the first transmitted message, calculated using the individual key associated with the aforementioned client entity,
  • the client entity for its part, verifies the received signature, using its individual key and the first message received in multicast mode, and decides a invalidity of the first message received in case of failure in the verification of this signature.
  • the present invention is advantageously an application of the above method to a communication context according to the IEEE 802.11 standard.
  • the present invention also aims at an access point, as well as a client entity, comprising respective means for the implementation of the method above. Concerning the access point, these means may comprise a processor capable of executing a computer program product comprising instructions for, from:
  • the invention also aims at such a computer program.
  • these means may comprise a processor capable of executing another computer program product comprising instructions for, from:
  • the invention is also aimed at this other computer program.
  • FIG. 3 illustrates the sending of a confirmation message in unicast mode, in an exemplary embodiment
  • FIG. 4 illustrates the sending of a confirmation message in multicast mode, in a variant of the embodiment illustrated in FIG. 3;
  • FIG. 5 illustrates the sending of a signature with a GTK group key; prior to sending the confirmation message, and
  • FIG. 6 illustrates the taking into account of a value counting the replay of a frame in a frame body identifier ID_Playload.
  • the following devices are connected together by a wireless communication protocol (for example Wl-Fl), preferably according to the IEEE 802.11i standard.
  • a wireless communication protocol for example Wl-Fl
  • these devices form part of a group of communicating entities comprising: an access point (referenced AP as in FIG. 1 previously described), and
  • client entities referenced as EQ for an i th entity, with i ranging from 1 to N.
  • the access point and all EQ entities share the same GTK group secret key.
  • the access point shares an individual secret key PTKi with each of the EQ entities.
  • the term "identifier" of a message denotes any numerical value that makes it possible, unambiguously, to identify this message (or this client entity, respectively) during a session.
  • identifier a strictly increasing sequence initialized to "0" in The beginning of the session of a client entity could be used to uniquely identify any message intended for it.
  • the MAC address typically the address of its interface Wl-Fl or "IEEE 802.11 card"
  • this entity ECj preferably uses the same identifier (denoted ID_ECj) for all its communication sessions.
  • X denotes information relating to a frame body and which is easily identifiable especially for a client entity that has already received this frame body. It is hereinafter referred to as "expression X”.
  • the expression X may also relate to an expression specific to the client entity ECi which has previously received the frame body. It is noted Xj in this case (with i between 1 and N).
  • the value Xi may correspond to a combination of the frame body and the identifier IDJEQ specific to the entity ECj, this combination can very simply consist of a concatenation.
  • the AP AP has sent (step E31) a message in a TR b frame in broadcast (broadcast) mode to the client entities ECi (where i is between 1 and N).
  • the access point will confirm this sending by calculating (E32) a signature of an expression X of this message (denoted signp ⁇ i (X)) by using the individual key PTKi associated with each entity EQ.
  • the method according to the invention in its simplest form access point side, can simply stop then the transmission, in unicast mode, to each EQ entity, a TR frame U ⁇ (recalling here that the index "u" refers to the individual distribution mode and the index i is the i th client entity ECi) incorporating the corresponding signature signp ⁇ i (X) (with i between 1 and N).
  • each client entity EQ receiving this frame TR U j verifies (E33) if its signp ⁇ (X) content results from a signature, using the individual key PTKi which is associated with this same entity ECj, the expression X of the message contained in the frame TR b received in multicast mode in the previous step E31.
  • the entity EQ validates the frame TR b received in multicast mode (E34), which means that it is the access point and not a pirate who sent this frame TR b . Otherwise (ko arrow at the output of the test E33), the entity EQ ignores this frame TRb (E35). In one possible embodiment, the entity EQ can simply destroy such a frame TR b and / or send an alert message to a supervisor of the network.
  • a clock counter can be provided to each EQ client entity, which can be accessed (E37) to wait, until a time limit THR, the receipt of the sign signature PT ⁇ i (X) - Beyond this time limit (arrow KB at the output of the test E36), the client entity EQ which has not received the confirmation message including the signature signp ⁇ i (X) ignores the frame TR b received in multicast mode ( E35).
  • the identity of the access point AP has been verified and, on the other hand, the client entities EQ have thus proved their identity, simply by the transmission of confirmation frames to these entities ECi, according to a first advantage that presents the invention.
  • FIG. 3 In more general terms, the embodiment illustrated in FIG. 3 can be described as follows:
  • the access point communicates with a plurality of client entities
  • the access point is arranged to calculate a plurality of cryptographic signatures of a message using a plurality of respective individual keys each associated with a client entity, and each client entity is arranged to check a cryptographic signature with the aid of said message and its individual key.
  • the access point then transmits a first message in multicast mode TR b to said plurality of client entities, and each client entity receives a first message, apparently from the access point, in multicast mode.
  • the access point also sends (E32), in unicast mode (TR U i) within the meaning of this embodiment, a second message to each client entity, the second message comprising a signature of an expression of the first message issued, calculated using the individual key associated with the recipient client entity.
  • each client entity verifies the signature received, using its individual key and the first message received in multicast mode, and decides a disability of the first message received in case of failure in the verification of this signature.
  • a single confirmation frame including all signatures signp ⁇ i (X) (with i between 1 and N) is sent to the client entities ECi in broadcast mode.
  • the identifier ID_ECj of each client entity EQ is advantageously used here, as follows.
  • the access point AP calculates, as previously the signature of X (denoted signp ⁇ (X)) using the individual key PTKi associated with each entity ECi and, in a succession of bits Yi specific to each client entity EQ, adds thereto ( E41) the identifier ID_ECj of this client entity EQ.
  • the access point AP performs (E42) a concatenation C 1 of the sequences of bits Y 1 that it transmits (E43) in one or more frames TR b (Ci) in multicast mode ("broadcast"), to destination of all client entities ECj.
  • each entity EQ can verify the signature signp ⁇ i (X) with its associated individual key PTK], as described above. with reference to FIG. 3 (steps E33, E34 / E35).
  • FIG. 4 In more general terms, the embodiment illustrated in FIG. 4 can be described as follows:
  • the access point sends (E43), in multicast mode (TR b (CI)), a second message destined for the client entities, this second message comprising:
  • step E31 of FIG. 3 is replaced by: a step E51 in which the access point AP constructs a bit string C 0 comprising the message to be transmitted in multicast mode and its expression X signed by the group key GTK (denoted signG ⁇ (X)), and
  • a step E52 in which at least one frame TR b (C 0 ) comprising this bit string C 0 is sent to all the entities EC 1 in multicast mode.
  • each client entity ECj verifies the validity of the message received in multicast mode as follows.
  • Each client entity EQ retrieves the bit string C 0 and satisfies (E53) the signature sign GT ⁇ (X), using its key GTK group and information (expression X) it deducts from the rest of the message received, to ensure that this message comes from a member of the group. If the signature is not valid (arrow KB at the output of the test E53), the entity ECi ignores this message (E54). On the other hand, if the signature is valid (arrow ok at the exit of the test E53), the entity EQ can then treat the frame containing the signature (s) with the individual key (s) (s) ) leading (respectively step E44 of FIG. 4 and) steps E33, E34 or E35 of FIG.
  • FIG. 5 In more general terms, the embodiment illustrated in FIG. 5 can be described as follows:
  • the access point is arranged to calculate a cryptographic signature of a message by means of a group key (GTK) associated with a group comprising the access point and at least one client entity, and each The client entity of this group is arranged to check a cryptographic signature using the message and the group key.
  • GTK group key
  • the AP access point transmits (E52), in multicast mode, the first aforementioned message with a signature sign G ⁇ (X), calculated (E51) using the group key, of an expression X of the first message, destined for at least one client entity of the group, and
  • the access point may be provided to group all the aforementioned bit sequences C 0 and Ci in at least one same frame TR b to be transmitted from the access point to the client entities ECj in multicast mode.
  • this frame TR b it suffices to include in this frame TR b the frame body and the signatures of the same expression X relative to this frame body, using the individual keys PTKi, on the one hand, and using the GTK group key, on the other hand.
  • the advantage of this embodiment is to transmit at least one TR b frame in multicast mode.
  • the access point sends the first (Co) and second (Ci) messages mentioned above in at least one frame in multicast mode.
  • ID_Payload a frame body identifier
  • the ID_Payload identifier is preferably an element of a series of numbers which must be unambiguous and must not be repeated during a session.
  • session is meant here a period of time during which a single GTK group key is shared.
  • This sequence may be a sequence of numbers, encoded on a certain number of bytes and preferably strictly increasing. It may also be a sequence generated by the access point AP and concatenated and / or inserted in the sequence of bits Co described above with reference to FIG.
  • the expression X which is used in particular for the calculation of the signG ⁇ (X) group signature preferably depends on this ID_Payload identifier. It can for example be a combination (such as a concatenation) of the ID_Payload frame body identifier and the frame body itself.
  • the expression X is constructed for example as a function of the frame body, of its identifier and possibly of an expression specific to each client entity (construction of an expression Xj described herein -before).
  • the access point AP sends, in multicast mode, a frame TR b containing a signature of the expression X thus constructed and conducted using the group key GTK.
  • an EQ client entity When an EQ client entity receives frames containing the bit strings Co and Ci, this entity verifies (in addition to the checks described above) that the identifier ID_Payload is strictly greater than its last valid value received (test E63). If the identifier ID_Payload is valid (ok arrow at the exit of the test E63), the entity EQ updates the identifier ID_Payload stored in a memory which it comprises and pursues the verifications of the signatures described above (E44; E33, E34 / E35). Otherwise (kow arrow at the output of the test E63), the entity ECj ignores the message contained in the frame TR b (E64).
  • the embodiment illustrated in Figure 6 can be described as well.
  • the expression X of the first message further comprises an expression of this identifier and on receipt of the first message, the client entity decides (E64) that this first message is invalid if the identifier value of the first received message is less than or equal to an identifier value of a previously received message (test E63 ).
  • This embodiment using a frame body identifier is particularly advantageous in a context of secure multicasting against replay attacks in which an intruder could return exactly one and the same frame containing in particular the sequence of bits C 0 .
  • This verification of the ID_Payload identifier should preferably take into account the initialization of other equipment providing an ID_Payload identifier during a new connection to the wireless network.
  • the access point can provide an initial value of this identifier to a client entity EC) which connects (for example at the same time as the communication of the GTK group key).
  • the global encryption of the transmitted messages is not used in the example described above, but in a sophisticated variant, this measure can be advantageous if it is not desired that intruders easily access the contents of the frames.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne le domaine des communications sans fil, en particulier entre un point d'accès (AP) d'un réseau sans fil et des entités clientes (ECi). Après un premier message envoyé en mode de multidiffusion (E31), le point d'accès envoie un second message (E32), de confirmation, comprenant une signature (signPTKi(X)) d'une expression du premier message et calculée à l'aide d'une clé individuelle de chaque entité cliente. Chaque entité cliente (ECi) vérifie alors la signature reçue (E33), à l'aide de sa clé individuelle et du premier message reçu en mode de multidiffusion.

Description

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 TRb (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 TRb 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 TRui (avec les indices "u" pour "unicast" et "i" pour l'entité EC1) 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 TRUι 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 TRb (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 TRb- 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 TRb 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 TRb 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 TRb 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 TRUj 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 TRb 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 ieme 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 TRb 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 TRUι (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 TRUj 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 TRb 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 TRb 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 TRb. 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 TRb 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 signPTκ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 TRb 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 TRb à 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 (TRUi) 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 C1 des suites de bits Y1 qu'il transmet (E43) en une ou plusieurs trames TRb(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 (TRb(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 TRb 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 C0 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 TRb(C0) comportant cette chaîne de bits C0 est envoyée à toutes les entités EC1 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 C0 et vérifie (E53) la signature signGTκ(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 signGτκ(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 signPTκ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 C0 et Ci précitées dans au moins une même trame TRb à 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 TRb 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 TRb 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 TRb 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 TRb (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 C0.
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.

Claims

Revendications
1. 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 (AP) étant agencé pour calculer une signature cryptographique d'un message à l'aide d'une clé individuelle (PTKi) associée à l'entité cliente (EC1), et l'entité cliente (ECi) étant agencée pour vérifier ladite signature cryptographique à l'aide dudit message et de sa clé individuelle (PTKi), procédé dans lequel le point d'accès (AP) émet un premier message en mode de multidiffusion (TRb), et l'entité cliente (ECi) reçoit un premier message en mode de multidiffusion (TRb), caractérisé en ce que :
- le point d'accès envoie en outre, au moins à ladite entité cliente, un second message comprenant une signature (signPTκi(X)) d'une expression du premier message émis, calculée à l'aide de la clé individuelle associée à ladite entité cliente,
- l'entité cliente vérifie (E33) la signature reçue, à 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.
2. Procédé selon la revendication 1 , dans lequel : - 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, et dans lequel le point d'accès émet un premier message en mode de multidiffusion à destination de ladite pluralité d'entités clientes, et chaque entité cliente reçoit un premier message en mode de multidiffusion, caractérisé en ce que :
- le point d'accès envoie en outre (E32), en mode de diffusion individuelle (TRui), 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,
- 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 ladite signature.
3. Procédé selon la revendication 1 , dans lequel :
- 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, et dans lequel le point d'accès émet un premier message en mode de multidiffusion à destination de ladite pluralité d'entités clientes, et chaque entité cliente reçoit un premier message en mode de multidiffusion, caractérisé en ce que :
- le point d'accès envoie en outre (E43), en mode de multidiffusion (TRb(CI )), un second message à destination des entités clientes, le 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 (ID_EQ) 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.
4. Procédé selon la revendication 3, dans lequel les messages sont communiqués par trames, caractérisé en ce que le point d'accès envoie les premier (Co) et second (C-i) messages dans au moins une même trame en mode de multidiffusion (TRb).
5. Procédé selon l'une des revendications précédentes, dans lequel : - 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, caractérisé en ce que :
- le point d'accès (AP) émet (E52), en mode de multidiffusion, ledit premier message avec une signature (signGτκ(X)), calculée (E51 ) à l'aide de la clé de groupe, d'une expression dudit premier message, à destination d'au moins une entité cliente du groupe, et
- ladite entité cliente (ECj) :
* 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) ladite signature (signGTK (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 (signpτκ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.
6. Procédé selon l'une des revendications précédentes, dans lequel les messages sont communiqués par trames comportant notamment un corps de trame, caractérisé en ce que ladite expression (X) du premier message comporte une expression d'au moins un corps d'une trame incluant tout ou partie du premier message.
7. Procédé selon la revendication 6, dans lequel un identifiant de corps de trame ("ID_payload") comporte une valeur comptant un nombre de sessions de communication d'une entité cliente, caractérisé en ce que ladite expression du premier message comporte en outre une expression dudit identifiant, et en ce que, sur réception du premier message, l'entité cliente décide (E64) une invalidité du 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 (E63).
8. Application du procédé selon l'une des revendications précédentes, à un contexte de communication selon la norme IEEE 802.11.
9. Produit programme d'ordinateur, destiné à être exécuté par un processeur d'un point d'accès d'un réseau sans fil, caractérisé en ce qu'il comporte 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 (signpτκi(X)) d'une expression (X) dudit premier message, à l'aide d'une clé individuelle associée à l'entité cliente destinataire.
10. Produit programme d'ordinateur selon la revendication 9, caractérisé en ce qu'il comporte en outre des instructions pour la mise en œuvre du procédé selon l'une des revendications 2 à 7.
11. Produit programme d'ordinateur, destiné à être exécuté par un processeur d'une entité cliente d'un réseau sans fil, caractérisé en ce qu'il comporte 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 (E33) si le contenu du second message comporte une signature d'une expression (X) du premier message reçu, calculée à l'aide d'une clé individuelle (PTKi) associée à l'entité cliente (ECj), et - déclarer (E35) une invalidité du premier message reçu en cas d'échec de la vérification.
12. Produit programme d'ordinateur selon la revendication 11 , caractérisé en ce qu'il comporte en outre des instructions pour la mise en œuvre du procédé selon l'une des revendications 2 à 7.
13. Point d'accès d'un réseau sans fil, caractérisé en ce qu'il comporte des moyens pour :
- émettre un premier message en mode de multidiffusion et à destination d'une ou plusieurs entités clientes,
- calculer, pour chaque entité cliente destinataire, une signature (signPTκi(X)) d'une expression (X) dudit premier message, à l'aide d'une clé individuelle associée à l'entité cliente destinataire, et
- émettre la ou lesdites signatures dans au moins un second message à destination de la ou des entités clientes.
14. Point d'accès selon revendication 13, caractérisé en ce qu'il comporte en outre des moyens pour la mise en œuvre du procédé selon l'une des revendications 2 à 7.
15. Entité cliente d'un réseau sans fil, caractérisée en ce qu'elle comporte : - des moyens de réception :
* d'un premier message 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, - et des moyens pour :
* vérifier (E33) si le contenu du second message comporte une signature d'une expression (X) du premier message reçu, calculée à l'aide d'une clé individuelle (PTKj) associée à l'entité cliente (EQ), et
* et décider (E35) une invalidité du premier message reçu en cas d'échec de la vérification.
16. Entité cliente selon revendication 15, caractérisée en ce qu'elle comporte en outre des moyens pour la mise en œuvre du procédé selon l'une des revendications 2 à 7.
PCT/FR2006/001974 2005-09-19 2006-08-23 Controle d'un message reçu en mode de multidiffusion dans un reseau sans fil WO2007034045A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0509547 2005-09-19
FR0509547 2005-09-19

Publications (1)

Publication Number Publication Date
WO2007034045A1 true WO2007034045A1 (fr) 2007-03-29

Family

ID=36574050

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/001974 WO2007034045A1 (fr) 2005-09-19 2006-08-23 Controle d'un message reçu en mode de multidiffusion dans un reseau sans fil

Country Status (1)

Country Link
WO (1) WO2007034045A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086465A1 (en) * 2003-10-16 2005-04-21 Cisco Technology, Inc. System and method for protecting network management frames

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050086465A1 (en) * 2003-10-16 2005-04-21 Cisco Technology, Inc. System and method for protecting network management frames

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HECKER A ET AL: "Pre-authenticated signaling in wireless LANs using 802.1X access control", GLOBAL TELECOMMUNICATIONS CONFERENCE, 2004. GLOBECOM '04. IEEE DALLAS, TX, USA 29 NOV.-3 DEC., 2004, PISCATAWAY, NJ, USA,IEEE, vol. 4, 29 November 2004 (2004-11-29), pages 2180 - 2184, XP010757917, ISBN: 0-7803-8794-5 *
ZHIGUO WAN ET AL: "DoS-resistant access control protocol with identity confidentiality for wireless networks", WIRELESS COMMUNICATIONS AND NETWORKING CONFERENCE, 2005 IEEE NEW ORLEANS, LA, USA 13-17 MARCH 2005, PISCATAWAY, NJ, USA,IEEE, 13 March 2005 (2005-03-13), pages 1521 - 1526, XP010791402, ISBN: 0-7803-8966-2 *

Similar Documents

Publication Publication Date Title
EP1022922B1 (fr) Procédé d'authentification, avec établissement d'un canal sécurise, entre un abonné et un fournisseur de services accessible via un opérateur de télécommunications
US8144874B2 (en) Method for obtaining key for use in secure communications over a network and apparatus for providing same
EP1949651B1 (fr) Procede et appareil permettant d'etablir une association de securite
USRE39589E1 (en) Security method for transmissions in telecommunication networks
CA2423024C (fr) Systeme de telecommunication, notamment de type ip, et equipements pour un tel systeme
US20030182553A1 (en) End-to end protection of media stream encryption keys for voice-over-IP systems
EP3386162A1 (fr) Communication sécurisée de bout en bout pour capteur mobile dans un réseau iot
EP3613186B1 (fr) Système et procédé de communications
EP1753173A1 (fr) Contrôle d'accès d'un équipement mobile à un réseau de communication IP par modification dynamique des politiques d'accès
EP1913728A1 (fr) Securite totale de session d'echange
WO2009115755A2 (fr) Procédé d'authentification, système d'authentification, terminal serveur, terminal client et programmes d'ordinateur correspondants
EP2577901A1 (fr) Procede et dispositifs de communications securisees dans un reseau de telecommunications
WO2022161369A1 (fr) Procédé et appareil de traitement d'informations de gestion de sécurité pour réseau de transport optique
WO2009027447A2 (fr) Procede de distribution de cles cryptographiques dans un reseau de communication
EP1348279B1 (fr) Certification des transactions
WO2007034045A1 (fr) Controle d'un message reçu en mode de multidiffusion dans un reseau sans fil
WO2014154634A1 (fr) Procede d'authentification mutuelle entre un element de securite d'un terminal de telecommunications et un element d'un reseau de telecommunications de type gsm
CN113950802B (zh) 用于执行站点到站点通信的网关设备和方法
WO2007042664A1 (fr) Vérification d'un message reçu en mode de multidiffusion dans un réseau de communications
EP4298759A1 (fr) Procédé d'échanges sécurisés entre un lecteur de contrôle d'accès, concentrateur iot et une unité de traitement de données
EP4344131A1 (fr) Procédé d'établissement de session mcdata ipcon
Rhee et al. Key recovery in IPSec for improving robustness
WO2007125263A2 (fr) Procede de securisation de donnees

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06794348

Country of ref document: EP

Kind code of ref document: A1