WO2007042664A1 - Vérification d'un message reçu en mode de multidiffusion dans un réseau de communications - Google Patents

Vérification d'un message reçu en mode de multidiffusion dans un réseau de communications Download PDF

Info

Publication number
WO2007042664A1
WO2007042664A1 PCT/FR2006/002275 FR2006002275W WO2007042664A1 WO 2007042664 A1 WO2007042664 A1 WO 2007042664A1 FR 2006002275 W FR2006002275 W FR 2006002275W WO 2007042664 A1 WO2007042664 A1 WO 2007042664A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
client
access point
common multiple
client entities
Prior art date
Application number
PCT/FR2006/002275
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 WO2007042664A1 publication Critical patent/WO2007042664A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/14—Arrangements for conditional access to broadcast information or to broadcast-related services
    • H04H60/23—Arrangements for conditional access to broadcast information or to broadcast-related services using cryptography, e.g. encryption, authentication, key distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • 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
    • 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
    • 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 communications networks.
  • client entity a communicating entity (hereinafter referred to as “client entity”), via a network, and
  • the following are elements of the IEEE 802.11i standard, which concerns the security aspects of the IEEE 802.11 general standard.
  • 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 an individual PTK (for "pairwise transient key") and is known only to the access point and the station, which is used for encrypting data frames, in particular in the mode of individual diffusion (of the word Anglo-Saxon “unicasf).
  • 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 (from the English word "broadcasf").
  • 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 "sign” here refers to the fact of 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 multicast mode ("broadcasf") 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 "b” for "broadcasf") in multicast to a plurality of N client entities ECi, ..., EQ, ..., ECN (with i ranging from 1 to N).
  • the access point AP calculates (E11) a digest H (MESS), by a hash function, of the message MESS to send and stores (E12) this digest in a TAB table ( Figure 1).
  • the access point sends (E13) the MESS message in multicast mode in the aforementioned TR b frame by signing it with a GTK group key.
  • each client entity EQ receiving the frame TRb calculates (E14) a digest H (MESSR), by the aforementioned hash function, of the message MESS R contained in the received frame TR b .
  • the client entity EQ signs this new digest H (MESSR) using the key individual PTK and transmits (E15) in unicast mode ⁇ 'unicasf) a frame TR U ⁇ (with the indices "u" for "unicasf and" i "for the entity EQ) containing this new digest to the point d AP access (as illustrated in Figure 1.)
  • each client entity EQ triggers a clock counter (E16).
  • the access point AP checks whether the digests H (MESSR) contained in the frames TR u ⁇ that it receives are found in the table TAB, by comparing (test E17) the 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 ECj finally validates the initial message contained in the frame TR b (E18).
  • the opposite case (KO arrow 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".
  • an EQ client entity receiving this "countermand" denial frame consults (E20) the clock counter and if the counter value is less than a predetermined THR threshold (OK arrow at the output of the E20 test), the entity EQ ignores the frame TR b initially received (E21). On the other hand, if the EQ entity does not receive a deny frame before the clock counter reaches the threshold value THR (KO arrow at the output of the test E20), this entity EQ considers that the frame TR b received previously is valid and the interpreter (E18). 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 i 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 for all types of broadcast frames, including data frames, management frames, and control frames.
  • a communication method in a network intended for a communicating group comprising an access point of the network and client entities.
  • the access point (noted AP) sends a multicast message to the client entities
  • the client entities (noted ECi) receiving a message in multicast mode check whether the message received has been sent by the access point.
  • each client entity initially stores a number (denoted ⁇ j) associated with this client entity and known to the access point.
  • step a) of sending a message the access point calculates a common multiple (denoted PPCM (Xi)) between integer expressions (denoted XO respectively specific to the client entities and obtained by a known function of the client entities and applied to the numbers ( ⁇ ,) associated with the respective client entities and to information contained in a message to be sent in multicast mode, and
  • the access point then sends the aforementioned message and this common multiple (PPCM (Xi)) in multicast mode.
  • PPCM (Xi) common multiple
  • step b) of verifying the message each client entity:
  • the present invention also aims, as such, an access point of a network for a communicating group comprising this access point and client entities.
  • the access point in the sense of the invention then comprises means for:
  • These means may advantageously comprise a processor capable of executing a computer program then comprising instructions for the implementation of the method above, by the access point.
  • the present invention is directed to such a computer program.
  • the present invention also aims, as such, a client entity of a network for a communicating group having an access point and client entities.
  • the client entity within the meaning of the invention then comprises means for, on receiving a message and a common multiple number (PPCM (Xi)):
  • X 1 an integer expression specific to this client entity, based on an associated number ( ⁇ ,) to the client entity and the content of the received message, and - checking, from the received message and the multiple common (PPCM (Xi)) received, if the result of the division (PPCM (Xj) / Xj) of the common multiple by the expression (Xj) specific to the client entity is a non-zero integer.
  • These means may advantageously comprise a processor capable of executing a computer program then comprising instructions for the implementation of the method above, by the client entity. As such, the present invention also aims at such a computer program.
  • the present invention is advantageously an application of the above method to a wireless communication context, in particular according to the IEEE 802.11 standard.
  • the invention thus presents an attractive alternative to protection by simple encryption using a group key, since in the sense of the invention, each entity client can check, with the help of an individual expression (X 1 ), the validity of the message sent.
  • CRTDH An Efficient Key Agreement Scheme for Secure Group Communications in Wireless Ad Hoc Networks
  • RK Balachandran et al, COMMUNICATIONS, 2005, ICC2005, IEEE International Conference on Seoul, Korea (2005-05-16), pages 1123-1127, describes a key exchange for secure group communication in a wireless, ad hoc network (that is to say without access point).
  • step 4 paragraph A. Key Agreement
  • step 4 paragraph A. Key Agreement
  • step 6 of this document is to develop a system of equations to calculate the value crt ,, where the least common multiple is divisor, so that the document Balachandran et al does not disclose the step verification of the remainder of the division of the smallest common multiple within the meaning of the invention.
  • This difference is not, in fact, a simple difference in mathematical calculation, but rather that the architecture of an ad hoc network, where there is no real access point, is different from the architecture of a wireless network involving at least one access point.
  • FIG. 3 illustrates the sending of a message by an access point with, within the meaning of the invention, a common multiple between known expressions of client entities, to check the validity of the message.
  • the following devices are connected together by a wireless communication protocol (for example Wl-Fl), preferably according to the IEEE 802.11 i standard.
  • a wireless communication protocol for example Wl-Fl
  • these devices are part of a group of communicating entities comprising:
  • EQ a number of client entities (referenced EQ for an ith 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 PTKj with each of the EQ entities.
  • a frame typically comprises a frame body (hereinafter referred to as "payload") and ancillary fields including in particular a frame counter.
  • expression X denotes a sequence of bits obtained by applying a global function, called “one-way function” and denoted F, to a frame TR b to protect and an unpredictable variable, denoted ⁇ s and known only to the access point and a client entity ECi to which this variable ⁇ , is associated.
  • This "one-way" function F can, for example, be a hash function such as the function SHA-1 (for "Secure Hash Algorithm 1").
  • SHA-1 for "Secure Hash Algorithm 1”
  • f also denotes a function that applies to the frame itself, alone.
  • this function f can also be applied to other data from other fields of the frame, for example to the frame counter.
  • the method according to the invention makes it possible to send a TR b frame in multicast mode (or "Broadcasf") from the access point AP and to the client entities ECi, and this in a secure way since the process continues with a verification of the frame received from the client entities.
  • a TR b frame in multicast mode or "Broadcasf”
  • a first global step (E32-1, E32-2), the access point AP calculates, for each client entity ECi, the sequence of bits Xj ⁇ F (TR b , ⁇ ) (E32-1). The access point AP then calculates a common multiple PPCM (Xi) between all these expressions Xj (E32-2).
  • each expression Xj resulting from the application of the global function F to the variable a ,, on the one hand, and the result of the application of the particular function f to the frame TR b to send.
  • the access point AP and the client entity ECi, to which the variable d ⁇ is associated know this variable a ,.
  • each client entity ECi knows the global function F, as well as the particular function f. In other words, each client entity ECi knows, in principle, to calculate its own expression Xj from its associated variable a, and the frame TR b that it receives, by the relation given above:
  • the access point AP sends a frame TR b and the common multiple PPCM (Xi) above, in multicast mode and destined for all client entities ECi from which he has calculated the expression Xj.
  • the access point AP sends the message (E33-1) of the frame TR b and the common multiple PPCM (Xj) (E33-2) in the same frame.
  • the common multiple PPCM (Xi) is too large, the latter PPCM (Xi) can be sent in several frames. For example, a first part of the common multiple PPCM (Xj) may be included in the frame TR b and the remainder of the common multiple PPCM (Xj) may be sent in one or more subsequent frames, in multicast mode.
  • the common multiple PPCM (Xj) may also be sent separately in one or more separate frames of the frame TR b , in multicast mode.
  • a clock counter HOR test T-34 shown in dashed lines
  • the client entity ECi then verifies (test T36) that the result of the division of the common multiple received PPCM (Xi) by its own expression Xj is a non-zero integer, to avoid a piracy of simply replacing the value of PPCM ( Xj) by zero in a pirate frame).
  • the client entity validates the TRb frame and processes it (E38) because the degree of certainty for the frame to come from the access point AP is high.
  • a random message, or from a hacker client entity has a very low probability (close to zero) of giving an entire result in the aforementioned division.
  • a probability close to zero is usually a criterion of security in cryptography.
  • the client entity ECi ignores the received message (E37) if the division result is zero or is a non-integer rational (KO arrow at the output of the test T36).
  • the above-mentioned common multiple PPCM (Xi) is advantageously the smallest common multiple between the expressions Xj.
  • a number ⁇ chosen by the access point for example to minimize or, at least, reduce to an acceptable size, a value the smallest common multiple PPCM (Xj). It is thus possible advantageously to limit the number of bits necessary to form the variable PPCM (Xj).
  • the interest of this characteristic can be illustrated by the following very simple example.
  • the access point AP preferably selects the number ⁇ dynamically, depending on the content of the frame and the variables a ,, for example after a limited number of tests, then transmits to the client entities the number ⁇ chosen in the frame TR b (E33-1) or in a next frame (E33-3).
  • this number ⁇ makes it possible to manage the probabilities for which the calculated expressions Xj have too few common factors, which increases the value of the least common multiple.
  • the access point AP after the calculation of the expressions Xj, can then check the number of common prime factors between these different expressions Xj (or perform any other test equivalent). If the result of the test is not satisfactory, the access point AP chooses another number ⁇ to ensure that the expressions Xj can satisfy the above test.
  • the expressions Xi are functions of the body of the frame to be sent, but also the frame counter (or "frame count value sent" according to a more generic formulation).
  • the frame counter or "frame count value sent” according to a more generic formulation.
  • the frame counter value should vary with each message multicast sent predictably by the access point and / or the client entities.
  • the field indicating this frame counter value is suitable for example in communication context according to the 802.11i standard.
  • Each client entity checks, in addition to the checks described above, that the counter value is strictly increasing compared to a previous value. If this is not the case, the client entity rejects the frame because it is probably a replay.
  • Step E31 of FIG. 3 is now described, in which the access point AP communicates the variables ⁇ respectively associated with the client entities ECi, for example during a phase of initialization of the so-called "4-way handshake" communication.
  • these variables ⁇ , - are calculated by the respective client entities ECi and by the access point AP, independently (each on their own), from the respective individual keys PTKi associated with the client entities.
  • Each variable t can simply match the key of the entity PTKj ECi client.
  • the access point AP designs a C1 Payload bit string
  • the access point AP sends the entities ECi the bit string C1 (in one or more frames), in multicast mode;
  • the global encryption of the transmitted messages is not used in the example described above, but in a sophisticated variant, this measure may be advantageous if it is not desired that intruders easily access the contents of the frames. .
  • Such encryption does not constitute authentication per se, because it can only be encryption by means of a group key shared by all the multicast providers (for example the GTK key in the context of the standard 802.11 i).
  • a client entity receiving a message in multicast mode can not know if this message comes from the access point, or another client entity hacker impersonating the access point. This encryption would only serve the confidentiality of the exchange.
  • each expression has been described above the application of a hash function to a concatenation of the information derived from the frame and a variable ctj to obtain each expression Xj.
  • each expression has been described above the application of a hash function to a concatenation of the information derived from the frame and a variable ctj to obtain each expression Xj.
  • each expression has been described above the application of a hash function to a concatenation of the information derived from the frame and a variable ctj to obtain each expression Xj.
  • each expression has been described above the application of a hash function to a concatenation of the information derived from the frame and a variable ctj to obtain each expression Xj.
  • Xi can be obtained by applying a concatenation of a variable ai and the result of a hash function that is still known to the corresponding client entity EQ and applied to information contained in a message to be sent.
  • This variant combined with prior communication of the variables ⁇ to the client entities (for example in the context of a "4-way handshake"), will typically be used in the case where the only frames TR b that it is necessary to secure are those of disassociation sent by the access point in communication context according to 802.11 i.

Abstract

L'invention concerne le domaine des communications, en particulier entre un point d'accès (AP) d'un réseau et des entités clientes (EQ). Chaque entité cliente (ECi) stocke un nombre (αj) associé à cette entité cliente et connu du point d'accès (AP). Avant d'envoyer un message en mode de multidiffusion, le point d'accès calcule un multiple commun (PPCM(Xi)) entre des expressions entières (Xj) propres aux entités clientes et qui sont obtenues par une fonction connue des entités clientes et appliquée aux nombres associés respectifs (αι) et à des informations contenues dans le message à envoyer. Ensuite, chaque entité cliente recevant un message : - calcule l'expression (Xi) propre à cette entité cliente, en fonction de son nombre associé (αι) et du contenu du message reçu, et - vérifie, à partir du message reçu et du multiple commun reçu, si le résultat de la division (PPCM(Xj)/Xj) du multiple commun par l'expression propre est un nombre entier non nul. Application aux réseaux selon la norme IEEE 802.11.

Description

Vérification d'un message reçu en mode de multidiffusion dans un réseau de communications
La présente invention concerne le domaine des réseaux de communications.
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.11i, 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 "c/é 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 "unicasf). 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 "broadcasf).
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 "frame 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 "signer" 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 i 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 ("broadcasf) 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 "b" pour "broadcasf) en mode de multidiffusion à destination d'une pluralité de N entités clientes ECi, ..., EQ, ..., ECN (avec i compris entre 1 et N).
En référence à la figure 2, dans une première étape générale, 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 (E13) 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, chaque entité cliente EQ 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 EQ signe ce nouveau condensé H(MESSR) en utilisant la clé individuelle PTK et transmet (E15) en mode de diffusion individuelle Ç'unicasf) une trame TRUι (avec les indices "u" pour "unicasf et "i" pour l'entité EQ) contenant ce nouveau condensé à destination du point d'accès AP (comme illustré sur la figure 1). Par ailleurs, chaque entité cliente EQ déclenche un compteur d'horloge (E16).
Dans une troisième étape générale, 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 ECj 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 multidiffusion 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, une entité cliente EQ 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é EQ ignore la trame TRb reçue initialement (E21 ). En revanche, si l'entité EQ 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é EQ considère que la trame TRb reçue précédemment est valide et l'interprète (E18). 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 TRUi 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 pour tous les types de trames de diffusion, notamment les trames de données, les trames de gestion et les trames de contrôle.
Elle propose à cet effet un procédé de communication, dans un réseau destiné à un groupe communicant comprenant un point d'accès du réseau et des entités clientes. Dans ce procédé : a) le point d'accès (noté AP) envoie un message en mode de multidiffusion à destination des entités clientes, et b) les entités clientes (notées ECi) recevant un message en mode de multidiffusion vérifient si le message reçu a bien été envoyé par le point d'accès.
Au sens de l'invention, chaque entité cliente stocke au départ un nombre (noté αj) associé à cette entité cliente et connu du point d'accès.
Ensuite, à l'étape a) d'émission d'un message : - le point d'accès calcule un multiple commun (noté PPCM(Xi)) entre des expressions entières (notées XO respectivement propres aux entités clientes et qui sont obtenues par une fonction connue des entités clientes et appliquée aux nombres (α,) associés aux entités clientes respectives et à des informations contenues dans un message à envoyer en mode de multidiffusion, et
- le point d'accès envoie alors le message précité et ce multiple commun (PPCM(Xi)) en mode de multidiffusion.
A l'étape b) de vérification du message, chaque entité cliente :
- calcule l'expression entière (X1) propre à cette entité cliente, en fonction de son nombre associé (αι) et du contenu du message reçu, et
- vérifie, à partir du message reçu et du multiple commun reçu, si le résultat de la division (PPCM(Xj)/Xj) du multiple commun par l'expression (Xj) propre à l'entité cliente est un nombre entier non nul.
La présente invention vise aussi, en tant que tel, un point d'accès d'un réseau destiné à un groupe communicant comportant ce point d'accès et des entités clientes. Le point d'accès au sens de l'invention comporte alors des moyens pour :
- calculer un multiple commun (PPCM(Xi)) entre des expressions entières (Xi) respectivement propres aux entités clientes et qui sont obtenues par une fonction connue des entités clientes et appliquée : * à des nombres (α,) respectivement associés aux entités clientes et connus respectivement des entités clientes, et
* à des informations contenues dans un message à envoyer en mode de multidiffusion,
- et envoyer le message, ainsi que ce multiple commun, en mode de multidiffusion.
Ces moyens peuvent avantageusement comporter un processeur capable d'exécuter un programme d'ordinateur comportant alors des instructions pour la mise en œuvre du procédé ci-avant, par le point d'accès. A ce titre, la présente invention vise un tel programme d'ordinateur.
La présente invention vise aussi, en tant que telle, une entité cliente d'un réseau destiné à un groupe communicant comportant un point d'accès et des entités clientes. L'entité cliente au sens de l'invention comporte alors des moyens pour, sur réception d'un message et d'un nombre multiple commun (PPCM(Xi)) :
- calculer une expression entière (X1) propre à cette entité cliente, en fonction d'un nombre associé (α,) à l'entité cliente et du contenu du message reçu, et - vérifier, à partir du message reçu et du multiple commun (PPCM(Xi)) reçu, si le résultat de la division (PPCM(Xj)/Xj) du multiple commun par l'expression (Xj) propre à l'entité cliente est un nombre entier non nul. Ces moyens peuvent avantageusement comporter un processeur capable d'exécuter un programme d'ordinateur comportant alors des instructions pour la mise en œuvre du procédé ci-avant, par l'entité cliente. A ce titre, la présente invention vise aussi un tel programme d'ordinateur.
La présente invention vise avantageusement une application du procédé ci- avant à un contexte de communication sans fil, notamment selon la norme IEEE 802.11.
En contexte d'envoi de messages en mode de multidiffusion, l'invention présente alors une alternative séduisante à la protection par simple cryptage à l'aide d'une clé de groupe, dès lors qu'au sens de l'invention, chaque entité cliente peut vérifier, à l'aide d'une expression individuelle propre (X1), la validité du message envoyé.
Le document de l'art antérieur :
"CRTDH: An Efficient Key Agreement Scheme for Secure Group Communications in Wireless Ad Hoc Networks", RK. Balachandran et al, COMMUNICATIONS, 2005, ICC2005, IEEE International Conférence on Séoul, Korea (2005-05-16), pages 1123-1127, décrit un échange de clé pour une communication de groupe sécurisée dans un réseau sans fil, ad hoc (c'est-à-dire sans point d'accès).
Bien que ce document divulgue à l'étape 4 (paragraphe A. Key Agreement) le calcul du plus petit commun multiple parmi les valeurs DH tirées des clés secrètes chacune associée à une entité, le calcul d'une clé publique pour l'envoi d'un message par une entité et la vérification de cette clé publique par les autres entités ayant reçu le message s'effectue à partir d'une solution CRT (pour "Chinese Remainder Theorem") qui n'a rien a voir avec la vérification que le reste de la division du plus petit commun multiple par la valeur secrète de chaque entité est nul, comme au sens de la présente invention. En effet, l'étape 6 de ce document revient à élaborer un système d'équations en vue de calculer la valeur crt,, où le plus petit commun multiple est diviseur, de sorte que le document Balachandran et al ne divulgue aucunement l'étape de vérification du reste de la division du plus petit commun multiple au sens de l'invention.
Cette différence ne se limite pas, en réalité, à une simple différence de calcul mathématique, mais vient plutôt de ce que l'architecture d'un réseau ad hoc, où il n'existe pas réellement de point d'accès, est différente de l'architecture d'un réseau sans fil faisant intervenir au moins un point d'accès.
En effet, dans le procédé au sens de l'invention, seul le point d'accès peut envoyer le plus petit commun multiple et les entités clientes ne peuvent mener que l'étape de vérification. Dans le document Balachandran et al, toutes les entités peuvent envoyer une expression crtj, ce qui ne résout pas les problèmes de sécurité introduits ci-avant et qui se posent dans le contexte de la présente invention.
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 par un point d'accès avec, au sens de l'invention, un multiple commun entre des expressions connues des entités clientes, pour vérifier la validité du message.
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.11 i. 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
- un nombre N d'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 PTKj avec chacune des entités EQ.
Par ailleurs, les messages du point d'accès AP et à destination des entités clientes ECi sont envoyés par trames. Une trame comporte typiquement un corps de trame (noté ci-après "Payload") et des champs annexes comportant notamment un compteur de trames.
On désigne ci-après par les termes "expression X" une suite de bits obtenue par application d'une fonction globale, dite "à sens unique" (ou "one-way fonction") et notée F, à une trame TRb à protéger et à une variable non prédictible, notée αs et connue uniquement du point d'accès et d'une entité cliente ECi à laquelle cette variable α, est associée.
Cette fonction F "à sens unique" peut, par exemple, être une fonction de hachage telle que la fonction SHA-1 (pour "Secure Hash Algorithm 1"). On retiendra donc que chaque expression Xj est donnée globalement par une relation du type Xj = F(TRb, cti)-
On désigne aussi par les termes "fonction particulière", notée f, une fonction s'appliquant à la trame elle-même, seule. Par exemple, le résultat de cette fonction f appliquée à la trame peut être directement le corps de trame (soit "f(trame) = Payload"). Néanmoins, cette fonction f pourra s'appliquer en outre à d'autres données issues d'autres champs de la trame, par exemple au compteur de trame. La relation précitée donnant chaque expression Xi s'écrit alors plus exhaustivement : Xj = F[f(TRb), αj. On retiendra toutefois la notation précédente Xj = F(TRb, ai), plus succincte, dans ce qui suit. A titre d'exemple, la fonction globale F peut être un hachage appliqué à une simple concaténation du corps de trame (en tant que résultat de la fonction particulière f appliquée à la trame) et de la variable αu ce qui s'écrit X) = hash( Payload || cij).
On indique ici que les calculs pour obtenir une telle expression Xi opèrent sur des bits. Pour obtenir le résultat du hachage, on identifie ensuite une suite de bits avec la représentation d'un nombre entier en base 2. Par conséquent, le résultat du hachage Xi = /7as/?(Payload || ai) est bien une valeur entière.
En référence maintenant à la figure 3, le procédé au sens de l'invention permet d'envoyer une trame TRb en mode de multidiffusion (ou "Broadcasf) à partir du point d'accès AP et à destination des entités clientes ECi, et ce de manière sécurisée puisque le procédé se poursuit par une vérification de la trame reçue auprès des entités clientes.
Ce procédé peut être décrit globalement comme suit, des compléments et variantes du procédé étant décrits plus loin.
Dans une première étape globale (E32-1 , E32-2), le point d'accès AP calcule, pour chaque entité cliente ECi, la suite de bits Xj ≈ F(TRb, αι) (E32-1 ). Le point d'accès AP calcule ensuite un multiple commun PPCM(Xi) entre toutes ces expressions Xj (E32-2). Ainsi, chaque expression Xj résuite de l'application de la fonction globale F à la variable a,, d'une part, et au résultat de l'application de la fonction particulière f à la trame TRb à envoyer. Comme indiqué ci-avant, seuls le point d'accès AP et l'entité cliente ECi, à laquelle la variable d\ est associée, connaissent cette variable a,. En outre, l'entité cliente ECi connaît la fonction globale F, ainsi que la fonction particulière f. En d'autres termes, chaque entité cliente ECi sait, en principe, calculer son expression propre Xj à partir de sa variable associée a, et de la trame TRb qu'elle reçoit, par la relation donnée ci-avant :
Xi = F(TRb, ai)
Dans une seconde étape globale (E33-1 , E33-2, E33-3), le point d'accès AP envoie une trame TRb et le multiple commun PPCM(Xi) précité, en mode de multidiffusion et à destination de toutes les entités clientes ECi desquelles il a calculé l'expression Xj. Préférentiellement, le point d'accès AP envoie le message (E33-1) de la trame TRb et le multiple commun PPCM(Xj) (E33-2) dans une même trame. Néanmoins, si le multiple commun PPCM(Xi) est de trop grande taille, ce dernier PPCM(Xi) pourra être envoyé en plusieurs trames. Par exemple, une première partie du multiple commun PPCM(Xj) peut être incluse dans la trame TRb et le reste du multiple commun PPCM(Xj) peut être envoyé dans une ou plusieurs trames suivantes, en mode de multidiffusion.
Dans une variante, le multiple commun PPCM(Xj) pourra aussi être envoyé séparément dans une ou plusieurs trames distinctes de la trame TRb, en mode de multidiffusion. Dans ce cas, il est avantageusement prévu un compteur d'horloge HOR (test T-34 représenté en traits pointillés) pour ignorer une trame reçue TRb si, après une durée prédéterminée THR, l'entité cliente n'a pas reçu aussi la ou les trame(s) comportant le multiple commun PPCM(Xj) (E37). Dans une troisième étape globale (E35, T36), chaque entité cliente ECi recevant une trame TRb calcule son expression propre Xj = F(TRb, Qi), à partir du contenu de cette trame (le corps de trame et éventuellement le compteur de trame comme décrit plus loin) et de sa variable associée αj (E35). L'entité cliente ECi vérifie ensuite (test T36) que le résultat de la division du multiple commun reçu PPCM(Xi) par son expression propre Xj est un entier différent de zéro, pour éviter un piratage consistant à remplacer simplement la valeur de PPCM(Xj) par zéro dans une trame pirate).
Si cette condition est vérifiée (flèche OK en sortie du test T36), l'entité cliente valide la trame TRb et la traite (E38) car le degré de certitude pour que la trame provienne bien du point d'accès AP est élevé.
En effet, un message aléatoire, ou issu d'une entité cliente pirate (connectée au point d'accès) a une très faible probabilité (proche de zéro) de donner un résultat entier dans la division précitée. Une probabilité proche de zéro est usuellement un critère de sécurité en cryptographie.
Au contraire, l'entité cliente ECi ignore le message reçu (E37) si le résultat de la division est nul ou vaut un rationnel non entier (flèche KO en sortie du test T36).
On décrit ci-après quelques autres caractéristiques optionnelles avantageuses de l'invention.
Le multiple commun précité PPCM(Xi) est avantageusement le plus petit commun multiple entre les expressions Xj.
Le fait de calculer le plus petit commun multiple permet avantageusement de limiter le nombre de bits nécessaires pour former la variable PPCM(Xj) et d'éviter alors de surcharger inutilement le réseau. Par ailleurs, le calcul du plus petit commun multiple est très rapide, bien plus rapide par exemple que l'exponentiation modulaire qui sert en cryptographie asymétrique.
II peut être avantageux de faire intervenir en outre, dans la fonction globale précitée F (E32-1), un nombre β choisi par le point d'accès, par exemple pour minimiser ou, du moins, réduire à une taille acceptable, une valeur du plus petit commun multiple PPCM(Xj). On peut ainsi limiter avantageusement le nombre de bits nécessaires pour former la variable PPCM(Xj). L'intérêt de cette caractéristique peut être illustrée par l'exemple très simple suivant. Les expressions Xj qui ont été calculées sont par exemple 3, 5 et 7. Comme ces nombres sont tous premiers, leur plus petit commun multiple vaut leur produit, soit 105 = 3x5x7. En revanche, en ajoutant une unité à chacun des trois nombres précités, soit 4=3+1 , 6=5+1 , 8=7+1 , le plus petit commun multiple vaut seulement 24. Dans cet exemple simple, la fonction globale F peut alors être de la forme Xj = /7as/i[(Payload||αj)]+β, avec β=1, si le calcul des Xj = /7as/7[(Payload||c(j)] a donné 3, 5 et 7 pour différents αj.
Néanmoins, comme on le voit déjà dans cet exemple, le choix le plus judicieux de la valeur du nombre β dépend du contenu de la trame (Payload). Par conséquent, le point d'accès AP choisit préférentiellement le nombre β de façon dynamique, en fonction du contenu de la trame et des variables a,, par exemple après un nombre limité de tests, puis transmet aux entités clientes le nombre β choisi dans la trame TRb (E33-1) ou dans une trame suivante (E33-3).
Ainsi, ce nombre β permet de gérer les probabilités pour lesquelles les expressions Xj calculées auraient trop peu de facteurs communs, ce qui augmente la valeur du plus petit commun multiple. Le point d'accès AP, après le calcul des expressions Xj, peut alors vérifier le nombre de facteurs premiers communs entre ces différentes expressions Xj (ou effectuer tout autre test équivalent). Si le résultat du test n'est pas satisfaisant, le point d'accès AP choisit un autre nombre β afin de s'assurer que les expressions Xj puissent satisfaire le test précité.
Selon une autre caractéristique optionnelle avantageuse de l'invention, les expressions Xi sont des fonctions du corps de la trame à envoyer, mais aussi du compteur de trame (ou "valeur de comptage de trames envoyées" selon une formulation plus générique). On rappelle que cette information est indiquée par un champ de la trame.
Cette option permet de se prémunir contre le rejeu. En effet, la valeur de compteur de trame doit varier à chaque multidiffusion de message envoyé de manière prédictible par le point d'accès et/ou les entités clientes. Le champ indiquant cette valeur de compteur de trame convient par exemple en contexte de communication selon la norme 802.11i.
Néanmoins, une fonction strictement croissante dont la valeur est donnée par le point d'accès en clair (dans l'une des trames en multidiffusion par exemple) convient également de façon équivalente. Chaque entité cliente vérifie alors, outre les vérifications décrites ci-avant, que la valeur de compteur est bien strictement croissante par rapport à une valeur précédente. Si tel n'est pas le cas, l'entité cliente rejette la trame car il s'agit vraisemblablement d'un rejeu.
On décrit maintenant l'étape E31 de la figure 3, dans laquelle le point d'accès AP communique les variables αι respectivement associées aux entités clientes ECi, par exemple pendant une phase d'initialisation de la communication dite "4-way handshake".
Selon une autre variante, non représentée, ces variables α,- sont calculées par les entités clientes respectives ECi et par le point d'accès AP, indépendamment (chacun de leur côté), à partir des clés individuelles respectives PTKi associées aux entités clientes. Chaque variable at peut simplement correspondre à la clé PTKj de l'entité cliente ECi.
Un exemple concret de réalisation est le suivant, en reprenant les notations ci- avant :
- le point d'accès AP conçoit une chaîne de bits C1 Payload|| PPCM(Xj) où X1=SHA-I(PTKi II Payload), pour i=1 ,..., N, pour un groupe communicant comportant N entités clientes ;
- le point d'accès AP envoie aux entités ECi la chaîne de bits C1 (en une ou plusieurs trames), en mode de multidiffusion ;
- chaque entité cliente ECi récupère la chaîne de bits C1 , calcule l'expression Xj =SHA-1 (PTKi || Payload) avec le message reçu et sa clé individuelle PTK1, puis vérifie le résultat de la division PPCM(Xi)/Xi :
o Si le résultat est un entier non nul, l'entité valide la trame ;
o Sinon, il l'ignore.
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. Un tel chiffrement ne constitue pas une authentification en soi, car il ne peut alors s'agir que d'un chiffrement grâce à une clé de groupe partagée par tous les intervenants de la multidiffusion (par exemple la clé GTK dans le contexte de la norme 802.11 i). Ainsi, une entité cliente recevant un message en mode de multidiffusion ne peut savoir si ce message provient bien du point d'accès, ou d'une autre entité cliente pirate se faisant passer pour le point d'accès. Ce chiffrement ne servirait donc qu'à la confidentialité de l'échange.
Par ailleurs, on a décrit ci-avant l'application d'une fonction de hachage à une concaténation des informations tirées de la trame et d'une variable ctj pour obtenir chaque expression Xj. Toutefois, dans une variante, chaque expression
Xi peut être obtenue par application d'une concaténation d'une variable ai et du résultat d'une fonction de hachage connue encore de l'entité cliente EQ correspondante et appliquée à des informations contenues dans un message à envoyer.
En d'autres termes, dans cette variante, la fonction globale F ne porte pas sur les variables Qj. Ainsi, chaque expression X, s'estime comme suit : Xj = F(trame) || a-, . Cette variante, combinée à une communication préalable des variables αι aux entités clientes (par exemple dans le cadre d'un "4-way handshake"), sera typiquement utilisée dans le cas où les seules trames TRb qu'il est nécessaire de sécuriser sont celles de désassociation envoyées par le point d'accès en contexte de communication selon la norme 802.11 i.
Bien que l'application de l'invention est avantageuse dans le cadre de trames de données communiquées en mode de multidiffusion, la présente invention s'applique plus généralement à tout type de trame (trames de gestion, trames de contrôle, ou encore trames de données).

Claims

Revendications
1. Procédé de communication, dans un réseau destiné à un groupe communicant comprenant un point d'accès du réseau et des entités clientes, dans lequel : a) le point d'accès envoie un message en mode de multidiffusion à destination desdites entités clientes, et b) les entités clientes recevant un message en mode de multidiffusion vérifient si le message reçu a été envoyé par ledit point d'accès, caractérisé en ce que chaque entité cliente (ECi) stocke un nombre (αj) associé à cette entité cliente et connu du point d'accès (AP), en ce que, à l'étape a) :
- le point d'accès calcule un multiple commun (PPCM(Xi)) entre des expressions entières (Xj) respectivement propres aux entités clientes et qui sont obtenues par une fonction connue des entités clientes et appliquée auxdits nombres associés respectifs (ai) et à des informations contenues dans un message à envoyer en mode de multidiffusion, et
- le point d'accès envoie ledit message et ledit multiple commun (PPCM(Xi)) en mode de multidiffusion, et en ce que, à l'étape b), chaque entité cliente :
- calcule l'expression (X,) propre à cette entité cliente, en fonction de son nombre associé (a{) et du contenu du message reçu, et
- vérifie, à partir du message reçu et du multiple commun reçu, si le résultat de la division (PPCM(Xj)/Xj) du multiple commun par ladite expression propre à l'entité cliente est un nombre entier non nul.
2. Procédé selon la revendication 1 , caractérisé en ce que ledit multiple commun est le plus petit commun multiple entre lesdites expressions respectives.
3. Procédé selon la revendication 2, caractérisé en ce que ladite fonction connue des entités clientes fait intervenir en outre un nombre (β) choisi pour diminuer une valeur dudit plus petit commun multiple (PPCM(Xi)).
4. Procédé selon l'une des revendications précédentes, caractérisé en ce que chaque entité cliente ignore le message reçu si le résultat de la division est nul ou est un rationnel non entier.
5. Procédé selon l'une des revendications précédentes, dans lequel chaque message est envoyé dans une trame comportant au moins un corps de trame, caractérisé en ce que lesdites expressions propres (Xj) sont des fonctions au moins du corps de la trame à envoyer et respectivement des nombres (a{) associés.
6. Procédé selon la revendication 5, dans lequel chaque message est envoyé dans une trame comportant au moins un corps de trame et un champ indiquant une valeur de comptage de trames envoyées, caractérisé en ce que lesdites expressions propres (X1) sont des fonctions du corps de la trame à envoyer, de ladite valeur de comptage et des nombres associés (ai) respectifs.
7. Procédé selon l'une des revendications précédentes, dans lequel le point d'accès (AP) est agencé pour communiquer les nombres associés respectifs (ctj) aux entités clientes (ECi) préalablement à l'étape a).
8. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que lesdits nombres (a{) associés aux entités clientes sont calculés indépendamment par les entités clientes respectives (ECi) et par le point d'accès (AP) à partir des clés individuelles respectives (PTKj) associées aux entités clientes.
9. Procédé selon l'une des revendications précédentes, caractérisé en ce que lesdites expressions propres (Xi) sont obtenues par application d'une concaténation desdits nombres associés respectifs (a\) et d'un résultat d'une fonction connue des entités clientes (EQ) et appliquée auxdites informations contenues dans un message à envoyer.
10. Procédé selon l'une des revendications 1 à 8, caractérisé en ce que lesdites expressions propres (Xj) sont obtenues par application d'une fonction connue des entités clientes (EQ) et appliquée à une concaténation desdits nombres associés respectifs (α,) et desdites informations contenues dans un message à envoyer.
11. Procédé selon l'une des revendications précédentes, caractérisé en ce que ladite fonction connue des entités clientes est une fonction dite "à sens unique", telle qu'une fonction de hachage.
12. Procédé selon l'une des revendications précédentes, dans lequel chaque message est envoyé dans une trame, caractérisé en ce que le point d'accès envoie ledit message et ledit multiple commun (PPCM(Xi)) séparément dans des trames distinctes, en mode de multidiffusion.
13. Application du procédé selon l'une des revendications précédentes, à un contexte de communication sans fil, notamment selon la norme IEEE 802.11.
14. Programme d'ordinateur, destiné à être exécuté par un processeur d'un point d'accès d'un réseau destiné à un groupe communicant comprenant ce point d'accès et des entités clientes, caractérisé en ce qu'il comporte des instructions pour :
- calculer un multiple commun (PPCM(Xi)) entre des expressions entières (Xj) respectivement propres aux entités clientes et qui sont obtenues par une fonction connue des entités clientes et appliquée :
* à des nombres (a,) respectivement associés aux entités clientes et connus respectivement des entités clientes, et
* à des informations contenues dans un message à envoyer en mode de multidiffusion, - et envoyer le message, ainsi que ledit multiple commun, en mode de multidiffusion.
15. Programme d'ordinateur selon la revendication 14, 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 à 12.
16. Programme d'ordinateur, destiné à être exécuté par un processeur d'une entité cliente d'un réseau destiné à un groupe communicant comprenant un point d'accès et des entités clientes, caractérisé en ce qu'il comporte des instructions pour, sur réception d'un message et d'un nombre multiple commun : - calculer une expression entière (Xi) propre à cette entité cliente, en fonction d'un nombre associé (Q1) à l'entité cliente et du contenu du message reçu, et
- vérifier, à partir du message reçu et du multiple commun reçu, si le résultat de la division (PPCM(Xi)/Xj) du multiple commun par ladite expression propre à l'entité cliente est un nombre entier non nul.
17. Programme d'ordinateur selon la revendication 16, 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 à 12.
18. Point d'accès d'un réseau destiné à un groupe communicant comportant le point d'accès et des entités clientes, caractérisé en ce qu'il comporte des moyens pour : - calculer un multiple commun (PPCM(Xj)) entre des expressions entières (Xi) respectivement propres aux entités clientes et qui sont obtenues par une fonction connue des entités clientes et appliquée :
* à des nombres (ctj) respectivement associés aux entités clientes et connus respectivement des entités clientes, et * à des informations contenues dans un message à envoyer en mode de multidiffusion,
- et envoyer le message, ainsi que ledit multiple commun, en mode de multidiffusion.
19. Point d'accès selon revendication 18, 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 à 12.
20. Entité cliente d'un réseau destiné à un groupe communicant comprenant un point d'accès et des entités clientes, caractérisée en ce qu'elle comporte des moyens pour, sur réception d'un message et d'un nombre multiple commun (PPCM(Xi)) :
- calculer une expression entière (Xj) propre à cette entité cliente, en fonction d'un nombre associé (cij) à l'entité cliente et du contenu du message reçu, et
- vérifier, à partir du message reçu et du multiple commun (PPCM(Xi)) reçu, si le résultat de la division (PPCM(Xj)/Xj) du multiple commun par ladite expression propre à l'entité cliente est un nombre entier non nul.
21. Entité cliente selon revendication 20, 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 à 12.
PCT/FR2006/002275 2005-10-14 2006-10-10 Vérification d'un message reçu en mode de multidiffusion dans un réseau de communications WO2007042664A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0510516 2005-10-14
FR05/10516 2005-10-14

Publications (1)

Publication Number Publication Date
WO2007042664A1 true WO2007042664A1 (fr) 2007-04-19

Family

ID=36648383

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/002275 WO2007042664A1 (fr) 2005-10-14 2006-10-10 Vérification d'un message reçu en mode de multidiffusion dans un réseau de communications

Country Status (1)

Country Link
WO (1) WO2007042664A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008074534A1 (fr) * 2006-12-21 2008-06-26 International Business Machines Corporation Distribution de clé pour sécuriser une transmission de diffusion vers des groupes d'utilisateurs dans des réseaux sans fil

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040006705A1 (en) * 2002-07-05 2004-01-08 Walker Jesse R. Secure two-message synchronization in wireless networks
WO2004093381A1 (fr) * 2003-04-16 2004-10-28 Telefonaktiebolaget Lm Ericsson (Publ) Procede d'authentification
US20050123141A1 (en) * 2003-02-03 2005-06-09 Hideyuki Suzuki Broadcast encryption key distribution system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040006705A1 (en) * 2002-07-05 2004-01-08 Walker Jesse R. Secure two-message synchronization in wireless networks
US20050123141A1 (en) * 2003-02-03 2005-06-09 Hideyuki Suzuki Broadcast encryption key distribution system
WO2004093381A1 (fr) * 2003-04-16 2004-10-28 Telefonaktiebolaget Lm Ericsson (Publ) Procede d'authentification

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BALACHANDRAN R K ET AL: "CRDTH: an efficient key agreement scheme for secure group communications in wireless ad hoc networks", COMMUNICATIONS, 2005. ICC 2005. 2005 IEEE INTERNATIONAL CONFERENCE ON SEOUL, KOREA 16-20 MAY 2005, PISCATAWAY, NJ, USA,IEEE, 16 May 2005 (2005-05-16), pages 1123 - 1127, XP010825462, ISBN: 0-7803-8938-7 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008074534A1 (fr) * 2006-12-21 2008-06-26 International Business Machines Corporation Distribution de clé pour sécuriser une transmission de diffusion vers des groupes d'utilisateurs dans des réseaux sans fil
US7933414B2 (en) 2006-12-21 2011-04-26 International Business Machines Corporation Secure data distribution

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
CA2423024C (fr) Systeme de telecommunication, notamment de type ip, et equipements pour un tel systeme
US6449473B1 (en) Security method for transmissions in telecommunication networks
EP2721857B1 (fr) Procédé de traitement d'un paquet de données a l'émission, procédé de traitement d'un paquet de données à la réception, dispositifs et équipements de noeuds associés
EP2887574A1 (fr) Procédé de conversion d'un contenu à acces conditionnel
EP1151576B1 (fr) Procede cryptographique a cles publique et privee
WO2009115755A2 (fr) Procédé d'authentification, système d'authentification, terminal serveur, terminal client et programmes d'ordinateur correspondants
EP2186252B1 (fr) Procede de distribution de cles cryptographiques dans un reseau de communication
EP3439226B1 (fr) Dispositif d'émission/ réception a radio de réveil résistant aux attaques par déni de sommeil
EP2156600B1 (fr) Procédé de distribution de clé d'authentification, terminal, serveur de mobilité et programmes d'ordinateurs correspondants
US20070055870A1 (en) Process for secure communication over a wireless network, related network and computer program product
EP1145483A1 (fr) Procede d'authentification ou de signature a nombre de calculs reduit
WO2007042664A1 (fr) Vérification d'un message reçu en mode de multidiffusion dans un réseau de communications
EP3035583A1 (fr) Dispositif et système de communication, méthode de traitement de données et méthode d'échange sécurisé de données
EP2665224B1 (fr) Procédé de distribution d'une clef numérique de chiffrement vers des terminaux de télécommunication
FR2899750A1 (fr) Procede et terminal pour securiser la generation d'une cle de chiffrement
EP3340508B1 (fr) Procédé de réception, récepteur, émetteur et système de communication associés
WO2007034045A1 (fr) Controle d'un message reçu en mode de multidiffusion dans un reseau sans fil
EP2002585A1 (fr) Transmission de donnees confidentielle par changement de frequence dans un reseau de telecommunications
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
EP4338375A1 (fr) Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe
FR2900776A1 (fr) Procede de securisation de donnees
Rhee et al. Key recovery in IPSec for improving robustness
FR2899047A1 (fr) Autorisation de deconnexion entre un terminal d'usager et un point d'acces dans un reseau local sans fil
EP1992104A1 (fr) Authentification d'un dispositif informatique au niveau utilisateur

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: 06820181

Country of ref document: EP

Kind code of ref document: A1