EP4338375A1 - Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe - Google Patents

Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe

Info

Publication number
EP4338375A1
EP4338375A1 EP22726270.6A EP22726270A EP4338375A1 EP 4338375 A1 EP4338375 A1 EP 4338375A1 EP 22726270 A EP22726270 A EP 22726270A EP 4338375 A1 EP4338375 A1 EP 4338375A1
Authority
EP
European Patent Office
Prior art keywords
entities
access point
client device
requests
entity
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP22726270.6A
Other languages
German (de)
English (en)
Inventor
Fabrice Fontaine
David ARMAND
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4338375A1 publication Critical patent/EP4338375A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • 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 belongs to the general field of telecommunications. It relates, in particular, to a method of defending against a disconnection attempt between two entities corresponding to a network access point and a client device, as well as a system configured to implement said defense method.
  • the invention finds a particularly advantageous, although in no way limiting, application in the context of the "Internet of Things".
  • a client device when a client device wishes to connect to a communication network, such as for example a local network used at home or within a company, it first seeks to establish a connection with a point of contact. appropriate network access.
  • a communication network such as for example a local network used at home or within a company
  • network access point (or even more simply “access point” in the following description) conventionally refers to equipment configured to contribute to the deployment of said communication network, by offering communication services to one or more client devices equipped with network interfaces and located within the radio coverage area (home, business, etc.) of said access point.
  • an access point can take various forms, depending on the nature of the network deployed. By way of non-limiting example, it may be a router, a network switch, a server, a Wi-Fi internet box, etc.
  • connection between a client device and an access point is based on standardized messages exchanged between the latter.
  • Such messages consist of sending data packets, in the form of frames conforming to a determined communication protocol, and which correspond, as a general rule, to requests and responses to these requests.
  • FIG. 1 schematically represents messages exchanged within the framework of a connection between a client device 10 corresponding to a laptop-type user terminal and an access point 20 corresponding to an internet box Wi-Fi for home use.
  • the protocol used for the transmission of these messages is a Wi-Fi protocol complying with an IEEE 802.11 standard (ISO/CEI 8802-11).
  • the messages exchanged to establish the connection between the client device 10 and the access point 20 comprise successively in this order: 2
  • Said frames T1 and T2 define a discovery phase of the connection capacities of the client device 10 and of the access point 20;
  • T3 frame emitted by the client device 10 and corresponding to an authentication request ("AUTHENTICATION REQUEST" in English), as well as a T4 frame emitted by the access point 20, on reception of the T3 frame, and corresponding to a response to said authentication request
  • Said frames T3 and T4 define an authentication phase making it possible to validate that the client device 10 is able to connect to the access point 20;
  • connection process allowing the establishment of a connection (i.e. a point-to-point link) between the client device 10 and the access point 20.
  • connection process allowing the establishment of a connection (i.e. a point-to-point link) between the client device 10 and the access point 20.
  • additional standardized messages M1, M2, M3 and M4 are still transmitted between the client device 10 and the access point 20, so as to exchange keys of session allowing them to encrypt their subsequent exchanges.
  • This session key exchange corresponds to a so-called “4-way handshake” procedure.
  • connection can be broken. This can be done in a legitimate context where the client device 10 transmits to the access point 20 (respectively the access point 20 transmits to the client device 10) a frame corresponding to a disconnection request ("DEAUTH E NTICATION REQUEST" in English).
  • a third party entity distinct from the client device 10 and the access point 20, usurps for example the identity of the access point 20 to transmit to the client device 10 one or more disconnection (the opposite example, in which the impersonated identity is that of the client device 10, is of course also possible).
  • the client device 10 and/or the access point 20 can each be the subject, by said third party entity, of a malicious disconnection attempt.
  • the present invention aims to remedy all or part of the drawbacks of the prior art, in particular those set out above, by proposing a solution which makes it possible to provide 4 effective and easy-to-implement protection against malicious disconnection attempts likely to affect an access point and/or a client device.
  • the invention relates to a method of defending against a disconnection attempt between two entities corresponding to a network access point and a client device, said method comprising, after the establishment of a initial connection between said two entities to exchange data over a communication channel in accordance with a determined communication protocol, a set of steps implemented by one or each of said two entities, said set of steps comprising:
  • Said method further comprises, if at least one criterion is satisfied for at least one of said two entities, a step of execution, by at least one of said two entities, of a protection process against said malicious disconnection attempt, so maintaining a connection between said two entities.
  • the defense method comprises, initially, an analysis phase (evaluation of at least one criterion) executed by at least one of said two entities (client device, point of access) receiving one or more disconnection requests.
  • an analysis phase evaluation of at least one criterion
  • the analysis phase makes it possible to detect the illegitimate nature of said requests, and therefore ultimately the attack carried out by the attacker.
  • an analysis phase carried out by an entity does not conclude with the detection of a malicious disconnection attempt, then the connection between the two entities is legitimately broken.
  • the defense method according to the invention comprises another phase corresponding to the implementation of a protection process against said attack.
  • Said protection process aims to allow the maintenance of a connection between the client device and the access point, so 5 that the latter can continue to communicate with each other, even possibly in a degraded manner.
  • maintaining a connection between the client device and the access point refers either to maintaining the initial connection, or to maintaining a connection made after said initial connection, for example following voluntary disconnection of at least one of said two entities.
  • a voluntary disconnection is for example triggered following the activation, by at least one of said two entities, of a monitor mode, as described in more detail below with reference to particular modes of implementation of the 'invention.
  • Such an implementation is particularly advantageous in that it can be implemented in a simpler way than the solutions of the prior art.
  • the defense method according to the invention can be implemented at the application level (i.e. in a processor executing steps of the defense method and equipping an entity).
  • the solution proposed by the invention offers the possibility of easily deploying effective protection against malicious disconnection attempts.
  • the defense method may also include one or more of the following characteristics, taken in isolation or in all technically possible combinations.
  • a metric corresponds to the rate of reception of requests belonging to the set of requests received by an entity, the criterion associated with said metric being satisfied if said reception rate is greater than a given threshold.
  • a metric corresponds to the power level in reception of the requests belonging to the set of requests received by an entity, called "level 6 of disconnection", the criterion associated with said metric being satisfied if the difference between said disconnection level and the power level in reception of valid data frames received by said entity prior to the reception of said set of requests is, in value absolute and for a determined period, above a given threshold.
  • said method further comprises, when the rate of reception of requests belonging to the set of requests received by one of said two entities, called "first entity", has reached a first given threshold, steps implemented by said first entity and comprising:
  • a metric corresponds to the number or to the rate of falsified requests detected by said first entity, the criterion associated with said metric being satisfied if said number or said rate is greater than a second given threshold .
  • monitor mode by activating said monitor mode (“monitor” in English, other names may still be encountered, such as for example: Radio Frequency Monitoring, RF Monitor, rfmon, RFMON, Air Monitor, Network Monitor, NetMon, or even RF monitoring), an entity equipped with a suitable network card (for example a Wi-Fi network card) is able to listen (“to sniff”) the Wi-Fi traffic on the channel of its choice , including that of the communication network to which it was attached before the activation of said monitor mode.
  • a suitable network card for example a Wi-Fi network card
  • a metric corresponds to the number of falsified requests detected by said first entity, the criterion associated with said metric being satisfied if said number is greater than or equal to 1.
  • said method further comprises, when the rate of reception of requests belonging to the set of requests received by one of said two entities, called "first entity", has reached a first given threshold, steps implemented by said first entity and comprising:
  • a metric corresponds to the rate of valid data packets detected by said first entity, the criterion associated with said metric being satisfied if said rate is greater than a second given threshold.
  • a protection process executed by an entity comprises a modification of at least one communication parameter used by one of said two entities to transmit data after the establishment of said initial connection.
  • modifying at least one communication parameter corresponds to a defense strategy making it possible to circumvent the attack in progress, rather than seeking to lead a frontal opposition in the face of this attack.
  • a defense strategy is more a behavior of “flight” and/or “camouflaging” vis-à-vis the attack in progress, than a counter-attack behavior. Accordingly, the point here is not to try to identify the attacker, but rather to evade them, while trying to maintain a connection.
  • a protection process is executed by the client device, a modified parameter corresponding to a unique identifier of said client device.
  • a protection process is executed by the access point, at least one corresponding modified parameter:
  • a unique identifier such as for example a hardware address
  • the communication channel corresponds to a preferred implementation insofar as this makes it possible to increase security.
  • the existing connection or a future connection if applicable
  • each of said two entities executes a protection process comprising a role reversal, so that the access point is configured as a client device, and the client device is configured as access point.
  • a protection process is executed by said entity and consists in ignoring the disconnection request(s) received, or
  • a protection process is executed by each of said two entities and consists in ignoring the disconnection request(s) received.
  • Iterations can for example be carried out periodically within the same communication session.
  • the fact of iterating a protection process (for example by regularly modifying at least one communication parameter and/or by performing a role reversal on a regular basis) makes it possible to consolidate the defense that can be implemented, and ultimately improve the security of the connection between the client device and the access point.
  • said defense method comprises a step of transmitting a message from the other of said two entities, called "first entity”, to said second entity , said message comprising said protection process, said transmission being implemented following the establishment of the initial connection and in an encrypted manner.
  • the communication protocol is a Wi-Fi protocol.
  • the invention relates to a computer program comprising instructions for the implementation of reception, evaluation and execution steps of a defense method according to the invention when said program of computer is run by a computer.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention relates to a computer-readable information or recording medium on which a computer program according to the invention is recorded.
  • the information or recording medium can be any entity or device capable of storing the program.
  • the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording medium, for example a diskette (floppy disk) or a disk hard.
  • the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information or recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention relates to a network access point capable of being connected to a client device to exchange data over a communication channel in accordance with a determined communication protocol, said access point comprising:
  • reception module configured to receive, after a connection has been established between said access point and the client device, a set of disconnection requests
  • an evaluation module configured to evaluate at least one criterion defined from a metric based on said set of requests or else on at least one other disconnection request received after the reception of said set of requests, so as to allow the detection of a malicious logout attempt.
  • the invention relates to a client device capable of being connected to a network access point to exchange data over a communication channel in accordance with a determined communication protocol, said client device comprising:
  • reception module configured to receive, after a connection has been established between said access point and the client device, a set of disconnection requests
  • an evaluation module configured to evaluate at least one criterion defined from a metric based on said set of requests or else on at least one other disconnection request received after the reception of said set of requests, so as to allow the detection of a malicious logout attempt.
  • the invention relates to a system for defending against a disconnection attempt between two entities corresponding to a network access point and a client device, said entities being able to be connected to each other to exchange data on a communication channel in accordance with a determined communication protocol, and in which:
  • At least one of said two entities comprises an execution module configured to execute, if at least one criterion is satisfied for at least one of said two entities, a protection process against said malicious disconnection attempt, so as to maintain a connection between the access point and the client device.
  • FIG. 1 schematically represents a connection method, in accordance with the state of the art, between a client device and an access point, said connection method comprising exchanges of messages according to a Wi-Fi protocol;
  • FIG. 2 schematically shows, in its environment, a particular embodiment of a defense system according to the invention
  • FIG. 3 schematically shows an example of hardware architecture of a client device belonging to the defense system of Figure 2;
  • FIG. 4 schematically shows an example of hardware architecture of an access point belonging to the defense system of Figure 2;
  • FIG. 5 shows, in the form of a flowchart, the main steps of a defense method according to the invention as they are implemented by the defense system of Figure 2;
  • FIG. 6 schematically shows a first particular mode of implementation of the method of Figure 5;
  • FIG. 7 schematically shows a second particular mode of implementation of the method of Figure 5;
  • FIG. 8 schematically shows a third particular mode of implementation of the method of Figure 5;
  • FIG. 9 schematically shows a fourth particular embodiment of the method of Figure 5;
  • FIG. 10 schematically shows a fifth particular embodiment of the method of Figure 5;
  • FIG. 2 schematically represents, in its environment, a particular embodiment of a system 100 according to the invention.
  • the system 100 comprises two entities, namely a client device 110 and a network access point 120.
  • the client device 10 is a mobile terminal held by a user, such as for example a smart telephone or “smartphone”, a digital tablet, a laptop computer, etc.
  • the access point 120 is a network gateway making it possible to connect a local communication network for domestic private use 130 (“LAN” type network, acronym for the English expression “Local Area Network”) to the public network internet (“WAN” type network, acronym for the English expression “Wide Area Network”, not shown in FIG. 2). It is noted that said access point 120 is still known under the name “Internet box”. 11
  • the data (messages) exchanged between the client device 110 and the access point 120, via a CAN communication channel of the local network 130 deployed by the access point 120 are in the form of packets encapsulated in frames (for example requests and responses to these requests).
  • Said frames conform to a Wi-Fi protocol complying with an IEEE 802.11 standard (ISO/CEI 8802-11).
  • neither of said two entities 110, 120 is configured in software and hardware to implement PMF protection.
  • no limitation is attached to the respective natures of said client device 110 (fixed terminal for example, such as a fixed PC) and of said access point 120 (dedicated server for example).
  • an access point 120 offering connectivity to remote servers does not constitute an implementation variant of the invention.
  • the invention does not exclude considering other modes in which the client device 110 is intended solely to communicate with the access point 120 via the local network 130 deployed by the latter, i.e. without seeking to be connected with a another network likely to be placed behind the access point 120 (example: a drone acts as a Wi-Fi access point so that a mobile phone can connect to it to control it, all communications remaining between these only two entities, the drone offering no connectivity with remote servers).
  • Wi-Fi protocol such as for example a proprietary protocol.
  • the invention also does not exclude that the communication protocol is based on a wired technology (optical fiber, Ethernet cable, KNX bus, etc.).
  • FIG. 2 is given for purely illustrative purposes, and that the number of access points as well as the number of client devices that may belong to the system 100 are not limiting factors of the invention.
  • the client device 110 and the access point 120 are configured so as to be able to carry out processing allowing them to establish a connection between them, by implementing a connection method such as that described with reference to FIG. 1 (transmission of frames T1 to T6).
  • the client device 110 comprises for example one or more processors and storage means (magnetic hard disk, electronic memory, optical disk, etc.) in which are stored data and a computer program, in the form of a set of program code instructions to be executed to implement a first 12 set of steps (transmission of frames T1, T3, T5, and reception of frames T2, T4, T6) of said connection method.
  • processors and storage means magnetic hard disk, electronic memory, optical disk, etc.
  • a computer program in the form of a set of program code instructions to be executed to implement a first 12 set of steps (transmission of frames T1, T3, T5, and reception of frames T2, T4, T6) of said connection method.
  • the client device 110 also comprises one or more programmable logic circuits, of the FPGA, PLD, etc. type, and/or specialized integrated circuits (ASIC), and/or a set of discrete electronic components, etc. adapted to implement said first set of steps of the connection method.
  • programmable logic circuits of the FPGA, PLD, etc. type, and/or specialized integrated circuits (ASIC), and/or a set of discrete electronic components, etc. adapted to implement said first set of steps of the connection method.
  • the client device 110 includes a set of means configured in software (specific computer program) and/or hardware (FPGA, PLD, ASIC, etc.) to implement said first set of steps of the connection process.
  • the access point 120 comprises for example one or more processors and storage means (magnetic hard disk, electronic memory, optical disk, etc.) in which are stored data and a computer program, under the form of a set of program code instructions to be executed to implement a second set of steps (transmission of frames T2, T4, T6, and reception of frames T1, T3, T5) of said connection method.
  • processors and storage means magnetic hard disk, electronic memory, optical disk, etc.
  • the access point 120 also comprises one or more programmable logic circuits, of the FPGA, PLD, etc. type, and/or specialized integrated circuits (ASIC), and/or a set of discrete electronic components, etc. . adapted to implement said second set of steps of the connection method.
  • programmable logic circuits of the FPGA, PLD, etc. type, and/or specialized integrated circuits (ASIC), and/or a set of discrete electronic components, etc. . adapted to implement said second set of steps of the connection method.
  • the access point 120 comprises a set of means configured in software (specific computer program) and/or hardware (FPGA, PLD, ASIC, etc.) to implement said second set of steps of the connection process.
  • the system 100 is further configured to perform processing making it possible to provide, once the client device 110 and the access point 120 are connected to each other, a defense against an attack consisting of a malicious disconnection attempt. , by implementing a defense method according to the invention.
  • a defense aims in particular to maintain a connection between the client device 110 and the access point 120 so that they can continue to communicate with each other.
  • malware disconnection attempt reference is generally made to an attack targeting the client device 110 and/or the access point 120.
  • the client device 110 and the access point 120 can each receive one or more illegitimate disconnection requests (i.e. issued by an unauthenticated third-party entity at the origin of the attack in question).
  • the client device 110 and the access point 120 both contribute to the method of defense, and are 13 respectively configured appropriately to implement steps of said defense method.
  • the client device 110 (respectively the access point 120) can carry out processing operations making it possible to maintain a connection with the access point 120 (respectively with the client device 110).
  • FIG. 3 schematically represents an example of hardware architecture of the client device 110 belonging to the system 100 of FIG. 2.
  • the client device 110 has the hardware architecture of a computer.
  • the client device 110 comprises, in particular, a processor 1_1, a random access memory 2_1, a ROM 3_1 and a non-volatile memory 4_1. It further comprises a communication module 5_1.
  • the read only memory 3_1 of the client device 110 constitutes a recording medium in accordance with the invention, readable by the processor 1_1 and on which is recorded a computer program PROG_1 in accordance with the invention, comprising instructions for the execution of steps of the defense method according to the invention.
  • the PROG_1 program defines functional modules of the client device 110, which are based on or control the hardware elements 1_1 to 5_1 of the client device 110 mentioned above, and which include in particular:
  • reception module MOD_RX_l configured to receive, after a connection has been established between the access point 120 and the client device 110 (in accordance with the connection method mentioned above), a set of disconnection requests,
  • an evaluation module MOD_EVAL_l configured to evaluate at least one criterion defined from a metric based on said set of requests or on at least one other disconnection request received after the reception of said set of requests, so as to allow detection of a malicious disconnection attempt
  • an execution module MOD_EXEC_l configured to execute, if at least one criterion is satisfied for said client device 110, a protection process against said malicious disconnection attempt, so as to maintain a connection between the access point 120 and the client device 110.
  • a “set of disconnection requests” can comprise one or more disconnection requests.
  • the communication module 5_1 allows in particular the client device 110 to communicate with the access point 120, and therefore integrates the means configured in a material way and/or 14 software described above to implement said first set of steps (transmission of frames Tl, T3, T5, and reception of frames T2, T4, T6) of the connection process.
  • the communication module 5_1 also allows the client device 110 to communicate with entities of the local network other than the access point 120, and integrates in particular for this purpose said reception module MOD_RX_l (the disconnection request(s) received being likely to be illegitimate, and therefore transmitted by a third party).
  • the access point 120 has a hardware architecture similar to that of the client device 110.
  • FIG. 4 schematically represents an example of the hardware architecture of the access point 120 belonging to the system 100 of FIG. 2.
  • the access point 120 has the hardware architecture of a computer.
  • the access point 120 comprises, in particular, a processor 1_2, a random access memory 2_2, a read only memory 3_2 and a non-volatile memory 4_2. It further comprises a communication module 5_2.
  • the read only memory 3_2 of the access point 120 constitutes a recording medium in accordance with the invention, readable by the processor 1_2 and on which is recorded a computer program PROG_2 in accordance with the invention, comprising instructions for execution of steps of the defense method according to the invention.
  • the PROG_2 program defines functional modules of the access point 120, which rely on or control the hardware elements 1_2 to 5_2 of the access point 120 mentioned above, and which include in particular:
  • reception module MOD_RX_2 configured to receive, after a connection has been established between the access point 120 and the client device 110 (in accordance with the connection method mentioned above), a set of disconnection requests,
  • an evaluation module MOD_EVAL_2 configured to evaluate at least one criterion defined from a metric based on said set of requests or on at least one other disconnection request received after the reception of said set of requests, so as to allow detection of a malicious disconnection attempt
  • an execution module MOD_EXEC_2 configured to execute, if at least one criterion is satisfied for said access point 120, a protection process against said malicious disconnection attempt, so as to maintain a connection between the access point 120 and client device 110.
  • the communication module 5_2 notably allows the access point 120 to communicate with the client device 110, and therefore integrates the means configured in hardware and/or software manner described above to implement said second set of steps ( transmission of frames T2, T4, T6, and reception of frames T1, T3, T5) of the connection method.
  • the communication module 5_2 also allows the access point 120 to communicate with entities of the local network other than the client device 110, and in particular integrates said communication module for this purpose. 15 reception MOD_RX_2 (the disconnection request(s) received being likely to be illegitimate, and therefore transmitted by a third party entity).
  • a general implementation of the defense method will now be described, as executed by the system 100 of FIG. 2. Particular modes of implementation are described later. It should be noted that said defense method is implemented after the establishment of a connection between the client device 110 and the access point 120. In other words, the implementation of the connection method precedes that of the connection method. defence, and it is now considered that the client device 110 and the access point 120 are connected to each other via a so-called "initial" connection, so as to be able to exchange data on the CAN communication channel in accordance with a Wi-Fi protocol mentioned above.
  • FIG. 5 represents, in the form of a flowchart, the main steps of the defense method according to the invention as they are implemented by the system 100 of FIG. 2.
  • the defense method comprises, initially, an analysis phase executed by at least one of the two entities 110, 120 receiving one or more disconnection requests (it being understood that only one of said two entities 110, 120 or said two entities 110, 120 can receive disconnection requests).
  • disconnection requests are received from a third party entity leading an attack (malicious disconnection attempt), and hereinafter referred to as "attacker ATT" (without however said requests, and therefore a fortiori the ATT attacker itself, are authenticated)
  • the analysis phase executed by an entity 110, 120 makes it possible to detect the illegitimate nature of said requests, and therefore ultimately the attack carried out by the ATT attacker.
  • the method comprises another phase executed by said at least one entity of the system 100 and which corresponds to the implementation of a protection process against said attack.
  • Said protection process aims to allow the maintenance of a connection between the client device 110 and the access point 120, so that the latter can continue to communicate with each other, even possibly in a degraded manner.
  • degraded reference is made here for example to a communication carried out late, this delay coming from the time that it was necessary to allocate to detect a malicious disconnection attempt.
  • the attacker ATT transmits to the client device 110 (respectively to the access point 120) a set ENS_1 of disconnection requests (respectively a set ENS_2 of disconnection requests).
  • the defense method comprises a step E10 of reception, by the client device 110, of the set ENS_1.
  • Said step E10 is implemented by the reception module MOD_RX_l equipping the client device 110.
  • the defense method also includes a step E20 of reception, by the access point 120, of the set ENS_2. Said step E20 is implemented by the reception module MOD_RX_2 equipping the access point 120.
  • steps E10 and E20 are implemented in parallel, which is due to the fact that the sets ENS_1 and ENS_2 are assumed to be sent simultaneously by the attacker ATT. It should however be noted that nothing excludes considering asynchronous receptions of said sets ENS_1 and ENS_2 (for example consecutive receptions) in the event that the attacker ATT does not send said sets ENS_1 and ENS_2 simultaneously.
  • the defense method also comprises a step E30 of evaluation, by the client device 110, of at least one criterion CRIT1 J (i being an integer index greater than or equal to 1) defined from a metric MET1 J based on said set ENS_1 of requests or indeed on at least one other disconnection request received after the reception of said set ENS_1 of requests, so as to allow the detection of a malicious disconnection attempt.
  • Said step E30 is implemented by the evaluation module MOD_EVAL_1 equipping the client device 110.
  • the defense method also comprises a step E40 of evaluation, by the access point 120, of at least one criterion CRIT2J (j being an integer index greater than or equal to 1) defined from a metric MET2J based on said set ENS_2 of requests or indeed on at least one other disconnection request received after the reception of said set ENS_2 of requests, so as to allow the detection of a malicious disconnection attempt.
  • Said step E40 is implemented by the evaluation module MOD_EVAL_2 equipping the access point 120.
  • the invention does not exclude the fact of considering criteria based on the same metric, but nevertheless distinct from one another (distinct threshold values).
  • the metric or metrics used for the implementation of step E30 can be entirely or partly distinct from the metric or metrics used for the implementation of step E40.
  • the defense method comprises a step E50 of execution, by the client device 110, of a process of protection against the malicious disconnection attempt which targets it as well as the point of access 120, so as to maintain a connection between said two entities 110, 120.
  • Said step E50 is implemented by the execution module MOD_EXEX_1 equipping the client device 110.
  • the defense method includes a step E60 of execution, by the access point 120, of a process of protection against the disconnection attempt which targets it as well as the client device 110, here too with the aim of maintaining a connection between said two entities 110, 120.
  • Said step E60 is implemented by the execution module MOD_EXEX_2 equipping the access point 120.
  • protection processes respectively executed by the client device 110 and the access point 120 may differ from each other. These aspects are described in more detail later.
  • the metric or metrics used for the implementation of step E30 can be entirely or partly distinct from the metric or metrics used for the implementation of step E40.
  • a metric applicable to one of the two entities 110, 120 of the system 100 can also be applied, according to entirely similar technical arrangements, to the other of said two entities 110, 120.
  • FIG. 6 schematically represents a first particular mode of implementation of the method of FIG. 5.
  • step E30 is executed using a metric MET1_1 corresponding to the reception rate DEB_RX of the requests belonging to the set ENS_1 of requests received by the client device 110.
  • the criterion CRIT1_1 associated with said metric MET1_1 is as to satisfies it if said reception rate DEB_RX is greater than a given threshold Sl_l.
  • disconnection requests REQ_DECl_k (k being an integer index), forming said set ENS_1, are received continuously (i.e. over time) by the client device 110, after an exchange of data with the access point 120 (this data exchange is symbolized by arrows bearing the references DATAI and DATA2).
  • Each disconnection request REQ_DECl_k has:
  • MAC_SRC origin of said request REQ_DECl_k
  • an address corresponding to a unique identifier of the access point 120 namely in this example the hardware address MAC_2 (“MAC” being the acronym of the English expression "Media Access Control") of said access point 120,
  • REQ_DECl_k disconnection requests actually originate from the attacker ATT, and that they are therefore indeed illegitimate requests since they usurp the identity of the access point 120.
  • the reception rate DEB_RX of said disconnection requests is equal to twelve requests per second, even though the threshold S1_1 associated with the criterion CRIT1_1 is set at ten disconnection requests per second.
  • FIG. 7 schematically represents a second particular mode of implementation of the method of FIG. 5.
  • step E30 is executed using a metric MET1_2 corresponding to the power level in reception of the requests belonging to the set ENS_1 of requests received by the client device 110, called “disconnection level”.
  • said disconnection level corresponds to a level of “RSSI” type (acronym of the English expression “Received Signal Strength Indication”), denoted below RSSI_DEC.
  • Criterion CRIT1_2 associated with said metric MET1_2 is satisfied if the difference between said RSSI disconnection level and the reception power level RSSI_RX of valid data frames (“DATA2” data in FIG. 7) received by said device client 110 prior to receipt of said set ENS_1 is, in absolute value and for a determined duration, greater than a given threshold Sl_2.
  • the RSSI_DEC disconnection level is equal to -50 dBm for a duration of 1 second (three requests REQ_DEC1_1, REQ_DEC1_2 and REQ_DEC1_3 are received by the client device 110 for 1 second, and each of these requests is associated with a disconnection level RSSI_DEC is equal to -50 dBm).
  • the power level in reception RSSI_RX prior to the reception of said disconnection requests is equal to -80 dBm.
  • the difference between the RSSI_DEC and RSSI_RX levels, in absolute value and for 1 second, is therefore equal to 30, even though the threshold S1_2 associated with the criterion CRIT1_2 is fixed at 10 dBm per second.
  • the threshold S1_2 is exceeded, and the criterion CRIT1_2 is therefore satisfied, such that a malicious disconnection attempt is detected (in this case, the client device 110 detects that it is under attack).
  • FIG. 8 schematically represents a third particular mode of implementation of the method of FIG. 5.
  • FIGS. 6 and 8 use the same notation formalism.
  • the defense method further comprises, when the reception rate DEB_RX of the requests belonging to the set ENS_1 of requests received by the client device 110 has reached a first given threshold S1_3 (said reception rate DEB_RX is here evaluated during the reception step E10), steps implemented by said client device 110 and comprising: an activation (step Eli) of a monitor mode.
  • steps implemented by said client device 110 comprising: an activation (step Eli) of a monitor mode.
  • the client device 110 is able to listen (“to sniff”) the traffic of the local network 130. It is noted that the fact of activating said monitor mode, on the part of the device client 110, leads de facto to the (voluntary) disconnection of the client device 110, the access point 20
  • switching to monitor mode refers to the disconnection of the Wi-Fi card previously used to allow the latter to communicate with the access point 120, following the initial connection). All the technical aspects related to the activation of such a monitor mode, as well as the capabilities of the client device 110 once configured in this monitor mode, are well known to those skilled in the art and are therefore not described further. detail here,
  • step E12 - monitoring (step E12) of the network traffic on said CAN communication channel, so as to be able to detect at least one disconnection request, called a "falsified request", emitted by a source usurping the identity of the client device 110 and intended for the access point 120.
  • step E30 is executed using a metric MET1_3 corresponding to the number N_FAL of falsified requests detected by the client device 110 (these are requests usurping the identity of the client device 110, intended for the access point 120 and detected after switching to monitor mode).
  • the criterion CRIT1_3 associated with said metric MET1_3 is for its part satisfied if said number N_FAL is greater than a second given threshold S1_4.
  • the threshold S1_3 is exceeded, and the criterion CRIT1_3 is therefore satisfied, such that a malicious disconnection attempt is detected (in this case, the client device 110 detects that the access point 120 is under attack).
  • first threshold S1_3 (respectively a second threshold S1_4) equal to two disconnection requests per second (respectively equal to 0) only constitutes one example of implementation of said third mode of implementation.
  • no limitation is attached to the value of said first threshold Sl_3 (respectively to the value of said second threshold Sl_4) ⁇
  • the implementation of said third mode is not limited either by the fact of considering a metric corresponding to the number of falsified requests detected by the client device 110.
  • a metric corresponding to the reception rate of falsified requests detected by the client device 110 the threshold taken into account for the criterion associated with this other metric being for example equal to ten falsified requests detected in 1 second. 21
  • a reconnection to said access point 120 should be considered for said client device 110 being given that an objective of the method of defense is to maintain a connection between these two entities.
  • Such a reconnection can be envisaged during the execution of the protection process (step E50) if the latter consists for example of ignoring the disconnection requests received, or even at the end of said protection process if the latter consists of example in a modification of at least one communication parameter used by one of said two entities 110, 120 to transmit data after the establishment of the initial connection.
  • the reconnection mechanism as such is known to those skilled in the art (awaiting receipt of a beacon frame, called “beacon frame” in English, procedure of "handshake in 4 stages”, etc.).
  • FIG. 9 schematically represents a fourth particular mode of implementation of the method of FIG. 5.
  • FIGS. 6 and 9 use the same notation formalism.
  • the defense method further comprises, when the reception rate DEB_RX of the requests belonging to the set ENS_1 of requests received by the client device 110 has reached a first given threshold S1_5 (said reception rate DEB_RX is here evaluated during the reception step E10), steps implemented by said client device 110 and comprising:
  • step E12 of the network traffic on said CAN communication channel, so as to be able to detect at least one valid data packet transmitted by the access point 120, and intended for the client device 110.
  • step E30 is executed using a metric MET1_4 corresponding to the rate DEB_VAL of valid data packets detected by the client device 110.
  • the criterion CRIT1_4 associated with said metric MET1_4 is satisfied if said rate DEB_VAL is greater than a second given threshold S1_6.
  • the threshold S1_6 is exceeded, and the criterion CRI1_4 is therefore satisfied, such that a malicious disconnection attempt is detected.
  • first threshold Sl_5 (respectively a second threshold Sl_6) equal to two disconnection requests per second (respectively equal to three valid packets) only constitutes an example of implementation of said fourth mode of implementation .
  • no limitation is attached to the value of said first threshold S1_5 (respectively to the value of said second threshold S1_6).
  • such a fourth mode of implementation finds a preferential (but not exclusive) application when the client device 110 is equipped with a plurality of network cards (in this case, these are cards Wi-Fi, as for example in the case of a Wi-Fi repeater), it being understood that monitor mode is activated by disconnecting the Wi-Fi card previously used to allow the latter to communicate with the access point 120, following the initial connection.
  • a plurality of network cards in this case, these are cards Wi-Fi, as for example in the case of a Wi-Fi repeater
  • steps E50 and E60 are described allowing the execution, by each of the entities 110, 120 of the system 100, of a process of protection against the attack carried out by the attacker ATT.
  • FIG. 10 schematically represents a fifth particular mode of implementation of the method of FIG. 5.
  • FIG. 10 and any one of FIGS. 6, 7, 8 and 9 use the same notation formalism.
  • the access point 120 transmits to the client device 110 a message MESS_DEF (step E00 of the defense method in said fifth mode of setting implemented).
  • Said MESS_DEF message is preferably transmitted in an encrypted manner and comprises the protection processes that each of the entities 110, 120 is intended to apply in the event that a malicious disconnection attempt targeting at least one of the said two entities 110, 120 is detected.
  • the message MESS_DEF allows the access point 120 to inform the client device 110 that, in the event of detection of an attack, each entity 110, 120 must modify a communication parameter used by said entity 110, 120 to transmit data after initial connection establishment. More particularly, the access point 120 here modifies its hardware address MAC_2 to MAC_4 and the client device 110 must modify its hardware address MAC_1 to MAC_3. In other words, each of the two entities 110, 120 of the system 100 modifies its hardware address.
  • the message MESS_DEF and therefore a fortiori the protection processes that it contains, have here been stored by said access point 120 prior to the implementation of the defense process.
  • This storage is for example performed in the non-volatile memory 4_2 of the access point 120, during the design and manufacture of the latter.
  • said MESS_DEF message transmitted by the access point 120 to the client device 110 can correspond to a standardized message registered in the standard on which the communication protocol used by said two entities 110, 120 is based.
  • the client device 110 memorizes the protection process which is transmitted to it during the implementation of the defense method, since it is the access point 120 which is at the origin of this standardized transmission.
  • each of the two entities 110, 120 is targeted by a disconnection attempt detected according to an implementation conforming to said third mode (FIG. 8) and in which the metric taken into account is the number of requests falsified 24 detected by each of the two entities 110, 120. It is further considered that a criterion common to said two entities 110, 120 is associated with said metric, this criterion being satisfied if said number of falsified requests detected is greater than or equal to 1 .
  • the client device 110 implements reception steps E10, activation of a monitor mode Eli and monitoring E12,
  • the access point 120 implements reception steps E20, activation of a monitor mode E21 (similar to step Eli) and monitoring E22 (similar to step E12).
  • each entity 110, 120 detects a falsified request:
  • the client device 110 detects a REC_DEC1 request usurping the identity of said client device 110 and addressed to the access point 120,
  • the access point 120 detects a REC_DEC2 request usurping the identity of said access point 120 and addressed to the client device 110.
  • each entity 110, 120 detects an attack and therefore executes the protection process associated with it, that is to say a change of hardware address.
  • a communication parameter modified by the access point 120 can correspond to any one of the communication parameters among:
  • a unique identifier of said access point 120 such as for example the hardware address MAC_2 of the latter, an identifier of the BSSID (Basic Service Set Identifier) type, an identifier of the ESSID (Extended Service Set Identifier) type in English), etc. ; and or
  • the CAN communication channel associated with said initial connection For example, in the case of a local Wi-Fi network using the 2.4 GHz frequency band, there are thirteen usable channels, the CAN channel being one of said thirteen channels; and or
  • an identifier of the communication network such as an identifier of the “SSID” type (acronym for the English expression “Service Set Identifier”); and or 25
  • a time datum contained in frames transmitted by said access point 120 such as for example an indication of availability ("uptime” in English") contained in a header referring to a timestamp of the BSS type ("BSS timestamp in English, where “BSS” corresponds to the acronym of the English expression “Basic Service Cet”); and or
  • a unique identifier and/or the CAN communication channel are modified as a priority, because this makes it possible to increase the security of the existing connection (or of a future connection if applicable) between the access point 120 and the client device 110. It is noted that these provisions are further combined with the fact that the hardware address of the client device 110 can also be modified within the framework of the execution of the protection process dedicated to said client device 110.
  • the fifth mode of implementation of FIG. 10 has also been described by considering that the sender of the message MESS_DEF is the access point 120. Of course, it is also possible to envisage this role of sender being played by the client device 110.
  • the client device 110 can itself execute a protection process, this protection process having been for example transmitted by the access point 120 via a message similar to the message MESS_DEF mentioned above.
  • These provisions can be transposed symmetrically in the case where the access point 120 is the only 26 attacked, detects this attack, and executes a protection process transmitted by the client device 110.
  • a protection process can be executed by the access point 120 after the client device 110 has notified said access point 120, for example by means of of an appropriate alert message.
  • the hardware architecture of the client device 110 differs from that described above with reference to FIG. 3, and that the client device 110 therefore comprises a reception module, an evaluation module and no runtime module (or a runtime module that remains inactive here).
  • the access point 120 for its part comprises an execution module configured to execute, upon receipt of said alert message, the protection process associated with it.
  • these provisions can be transposed to the case where the access point 120 is the only one attacked, detects this attack, and the client device 110 executes a protection process after having been notified by the access point 120.
  • At least one of said two entities 110, 120 (ideally the two entities 110, 120) is able to detect a malicious disconnection attempt which targets it, and that, following attack detection, at least one of said two entities 110, 120 is able to execute a protection process, so as to maintain a connection between said two entities 110, 120.
  • each of said two entities 110, 120 executes a protection process (it being understood that said two entities 110, 120 are attacked or only one of said two entities is attacked), and each process protection performed by one entity 110, 120 includes a role reversal with the other entity 110, 120.
  • the access point 120 is configured as (i.e. plays the role of) client device, and the client device 110 is configured as (i.e. acts as) an access point.
  • a protection process is executed by said client device 110 (respectively by said point access 120) and consists in ignoring the disconnection request(s) received. Otherwise, in this mode, the client device 110 (respectively the access point 120) does not modify any communication parameter, so that it can continue to communicate “normally” with the point 27 access 120 (respectively with the client device 110). “Normally” refers to the fact that the detected attack is ignored.
  • a protection process is executed by each of said two entities 110, 120 and consists in ignoring the request or requests for disconnection received. This mode is therefore based on bases similar to those mentioned in the previous mode, with the difference that this time the two entities 110, 120 of the system 100 are attacked and both ignore the disconnection requests that they receive.
  • Still other variants remain possible, such as for example maintaining several connections between the client device 110 and the access point 120 once an attack has been detected, so as to increase the difficulty of carrying out an attack for the user.
  • ATT attacker or even that the client device 110 and/or the access point transmit deliberately erroneous frames so as to confuse the ATT attacker.
  • the invention has also been described so far considering that neither of said two entities 110, 120 is configured in software and hardware to implement PMF protection.
  • the solution proposed by the invention is particularly simple to implement, the firmware of the Wi-Fi cards equipping the two entities 110, 120 not needing to be modified.
  • the invention nevertheless remains applicable, at the cost of a more complex technical implementation, in cases where at least one entity 110, 120 of the system 100 can implement PMF protection (it being understood that an entity capable of to implement a PMF protection cannot activate it if the other entity is not able to manage this PMF protection).

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 un procédé de défense contre une tentative de déconnexion entre deux entités correspondant à un point d'accès réseau (120) et un dispositif client (110), ledit procédé comportant, après l'établissement d'une connexion initiale entre lesdites deux entités, un ensemble d'étapes mises en œuvre par une ou bien chacune desdites deux entités : une réception (E10, E20) d'un ensemble de requêtes de déconnexion (ENS_1, ENS_2), une évaluation (E30, E40) d'au moins un critère (CRIT1_i, CRIT2_i) défini à partir d'une métrique basée sur ledit ensemble de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante. Ledit procédé comporte en outre, si au moins un critère est satisfait pour au moins une desdites deux entités, une étape d'exécution (E50, E60), par au moins une desdites deux entités, d'un processus de protection contre ladite tentative de déconnexion malveillante.

Description

1
Procédé de défense contre une tentative de déconnexion entre deux entités, système associé
Technique antérieure
La présente invention appartient au domaine général des télécommunications. Elle concerne, notamment, un procédé de défense contre une tentative de déconnexion entre deux entités correspondant à un point d'accès réseau et un dispositif client, ainsi qu'un système configuré pour mettre en œuvre ledit procédé de défense. L'invention trouve une application particulièrement avantageuse, bien que nullement limitative, dans le contexte de l'« Internet des objets »
(« Internet of Things » ou IoT dans la littérature anglo-saxonne) pour un point d'accès réseau et un dispositif client aptes à échanger des données entre eux conformément à un protocole Wi-Fi (marque déposée).
De manière conventionnelle, lorsqu'un dispositif client souhaite se connecter à un réseau de communication, comme par exemple un réseau local utilisé à titre domestique ou bien au sein d'une entreprise, il cherche en premier lieu à établir une connexion avec un point d'accès réseau approprié.
On note que l'expression « point d'accès réseau » (ou encore plus simplement « point d'accès » dans la suite de la description) fait classiquement référence à un équipement configuré pour contribuer au déploiement dudit réseau de communication, en offrant des services de communication à un ou plusieurs dispositifs clients équipés d'interfaces réseau et situés dans la zone de couverture radio (domicile, entreprise, etc.) dudit point d'accès. On note également qu'un point d'accès peut prendre des formes variées, selon la nature du réseau déployé. A titre d'exemple nullement limitatif, il peut s'agir d'un routeur, d'un commutateur réseau, d'un serveur, d'une box internet Wi-Fi, etc.
La connexion entre un dispositif client et un point d'accès s'appuie sur des messages standardisés échangés entre ces derniers. De tels messages consistent en l'envoi de paquets de données, sous la forme de trames conformes à un protocole de communication déterminé, et qui correspondent, en règle générale, à des requêtes et des réponses à ces requêtes.
Ainsi, et à titre d'exemple, la figure 1 représente schématiquement des messages échangés dans le cadre d'une connexion entre un dispositif client 10 correspondant à un terminal utilisateur de type ordinateur portable et un point d'accès 20 correspondant à une box internet Wi-Fi à usage domestique. Le protocole utilisé pour la transmission de ces messages est un protocole Wi-Fi répondant à une norme IEEE 802.11 (ISO/CEI 8802-11).
Tel qu'illustré par la figure 1, les messages échangés pour établir la connexion entre le dispositif client 10 et le point d'accès 20 comportent successivement dans cet ordre : 2
- une trame Tl émise par le dispositif client 10 et correspondant à une requête d'interrogation (« PROBE REQUEST » en anglais), ainsi qu'une trame T2 émise par le point d'accès 20, sur réception de la trame Tl, et correspondant à une réponse à ladite requête d'interrogation
(« PROBE RESPONSE » en anglais). Lesdites trames Tl et T2 définissent une phase de découverte des capacités de connexion du dispositif client 10 et du point d'accès 20 ;
- une trame T3 émise par le dispositif client 10 et correspondant à une requête d'authentification (« AUTHENTICATION REQUEST » en anglais), ainsi qu'une trame T4 émise par le point d'accès 20, sur réception trame T3, et correspondant à une réponse à ladite requête d'authentification
(« AUTHENTICATION RESPONSE » en anglais). Lesdites trames T3 et T4 définissent une phase d'authentification permettant de valider que le dispositif client 10 est en mesure de se connecter au point d'accès 20 ;
- une trame T5 émise par le dispositif client 10 et correspondant à une requête d'association
(« ASSOCIATION REQUEST » en anglais), ainsi qu'une trame T6 émise par le point d'accès 20, sur réception de ladite trame T5, et correspondant à une réponse à ladite requête d'association (« ASSOCIATION RESPONSE » en anglais). Lesdites trames T5 et T6 définissent une phase d'association effective entre le dispositif client 10 et point d'accès 20,
En définitive, la transmission des trames Tl à T6 forme un procédé, dit « procédé de connexion », permettant l'établissement d'une connexion (i.e. d'une liaison point à point) entre le dispositif client 10 et le point d'accès 20. On note qu'à la suite de la trame T6, des messages additionnels standardisés Ml, M2, M3 et M4 sont encore transmis entre le dispositif client 10 et le point d'accès 20, de sorte à s'échanger des clés de session leur permettant de chiffrer leurs échanges subséquents. Cet échange de clé de session correspond à une procédure dite de « poignée de main en 4 étapes » (« 4-way handshake » en anglais).
Bien entendu, une fois ladite connexion établie, celle-ci peut être rompue. Cela peut se faire dans un contexte légitime où le dispositif client 10 transmet au point d'accès 20 (respectivement le point d'accès 20 transmet au dispositif client 10) une trame correspondant à une requête de déconnexion (« DEAUTH E NTICATIO N REQUEST » en anglais).
Cela peut aussi se faire dans un contexte illégitime où une entité tierce, distincte du dispositif client 10 et du point d'accès 20, usurpe par exemple l'identité du point d'accès 20 pour transmettre au dispositif client 10 une ou plusieurs requêtes de déconnexion (l'exemple inverse, dans lequel l'identité usurpée est celle du dispositif client 10, est bien entendu aussi envisageable). Dit encore autrement, le dispositif client 10 et/ou le point d'accès 20 peuvent chacun faire l'objet, de la part de ladite entité tierce, d'une tentative de déconnexion malveillante.
Une telle attaque (tentative de déconnexion malveillante) est en outre facilitée par le fait que, dans le cadre des protocoles Wi-Fi répondant à des normes IEEE 802.11 (ISO/CEI 8802-11) antérieures 3 à 2009, les requêtes de déconnexion ne font l'objet d'aucune protection permettant de garantir la légitimité de la ou des entités qui les émettent.
Dans le but de corriger cette carence technique, des solutions ont été proposées. En particulier, il a été proposé de compléter les normes du groupe IEEE 802.11 par un amendement noté 802. llw- 2009. Ce dernier fournit une solution, dite « PMF » (acronyme de l'expression anglaise « Protected Management Frame »), permettant de chiffrer et authentifier, et donc a fortiori sécuriser, les données contenues dans des trames dites « de gestion », dont font partie lesdites trames Tl à T6 ainsi que les requêtes de déconnexion.
Cette solution PMF n'en reste pas moins peu déployée à ce jour, la faute notamment à une implémentation technique particulièrement complexe et contraignante puisqu'elle exige de modifier le micrologiciel (« firmware » en anglais) intégré à la ou les cartes réseau Wi-Fi de chacune des entités destinées à être connectées ensemble, en l'espèce ici le dispositif client 10 et le point d'accès 20. Par ailleurs, quand bien même une entité serait configurée de manière idoine, la solution PMF n'est pas nécessairement activée par cette entité. En effet, l'activation peut entraîner une modification de certaines valeurs de paramètres dans les messages envoyés par l'entité en question (ex : trame PROBE RESPONSE envoyée par le point d'accès 20). Une telle modification peut causer des problèmes d'interopérabilité avec des clients n'implémentant pas la solution PMF.
En définitive, et à ce jour, il n'existe pas de solution de défense contre les tentatives de déconnexion qui soit à la fois efficace et simple à implémenter. Ceci est problématique dans la mesure où ce type d'attaque génère des désagréments, en particulier une coupure de service, mais peut également être à l'origine de conséquences plus fâcheuses comme par exemple un vol de données personnelles si une clé Wi-Fi est transmise en clair lors d'un ré-appairage consécutif à une déconnexion malveillante. On comprend en outre que cette problématique est d'autant plus prégnante dans le contexte actuel de l'IoT où chaque objet de la vie courante a vocation à devenir un objet communicant.
Par ailleurs, bien qu'ayant été décrite jusque-là en considérant le seul exemple d'un protocole Wi- Fi, cette problématique peut également être envisagée lors de l'utilisation d'autres protocoles, comme par exemple un protocole propriétaire présentant des lacunes similaires (absence d'authentification des requêtes de déconnexion, implémentation complexe et contraignante d'une solution de sécurisation).
Exposé de l'invention
La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l'art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permette de fournir 4 une protection efficace et simple à implémenter contre les tentatives de déconnexion malveillantes susceptibles d'affecter un point d'accès et/ou un dispositif client.
On note que les termes « protection efficace » font référence ici à une protection fournie non seulement dans le cas où les requêtes de déconnexion ne sont pas protégées (authentifiées), mais également dans le cas inverse où lesdites requêtes de déconnexion sont a priori protégées, étant donné qu'un risque d'attaque, rendant caduque cette protection, ne peut jamais être complètement exclu.
A cet effet, et selon un premier aspect, l'invention concerne un procédé de défense contre une tentative de déconnexion entre deux entités correspondant à un point d'accès réseau et un dispositif client, ledit procédé comportant, après l'établissement d'une connexion initiale entre lesdites deux entités pour échanger des données sur un canal de communication conformément à un protocole de communication déterminé, un ensemble d'étapes mises en œuvre par une ou bien chacune desdites deux entités, ledit ensemble d'étapes comprenant :
- une réception d'un ensemble de requêtes de déconnexion,
- une évaluation d'au moins un critère défini à partir d'une métrique basée sur ledit ensemble de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante.
Ledit procédé comporte en outre, si au moins un critère est satisfait pour au moins une desdites deux entités, une étape d'exécution, par au moins une desdites deux entités, d'un processus de protection contre ladite tentative de déconnexion malveillante, de sorte à maintenir une connexion entre lesdites deux entités.
Ainsi, dans son principe général, le procédé de défense selon l'invention comporte, dans un premier temps, une phase d'analyse (évaluation d'au moins un critère) exécutée par au moins une desdites deux entités (dispositif client, point d'accès) recevant une ou plusieurs requêtes de déconnexion. De cette manière, si des requêtes de déconnexion sont reçues en provenance d'une entité tierce menant une attaque (tentative de déconnexion malveillante), la phase d'analyse permet de détecter le caractère illégitime desdites requêtes, et donc in fine l'attaque menée par l'attaquant. Bien entendu, à l'inverse, si une phase d'analyse réalisée par une entité ne conclut pas à la détection d'une tentative de déconnexion malveillante, alors la connexion entre les deux entités est rompue de manière légitime.
Par ailleurs, dans le cas où au moins une des deux entités a été en mesure de détecter une attaque, le procédé de défense selon l'invention comporte une autre phase correspondant à la mise en œuvre d'un processus de protection contre ladite attaque. Ledit processus de protection vise à permettre le maintien d'une connexion entre le dispositif client et le point d'accès, de sorte 5 que ces derniers puissent continuer à communiquer entre eux, même éventuellement de manière dégradée.
Par « dégradée », on fait référence ici par exemple à une communication réalisée en retard, ce retard provenant du temps qu'il a été nécessaire d'allouer pour détecter une tentative de déconnexion malveillante.
En outre par « maintien d'une connexion entre le dispositif client et le point d'accès », on fait référence soit au maintien de la connexion initiale, soit au maintien d'une connexion réalisée ultérieurement à ladite connexion initiale, suite par exemple à une déconnexion volontaire d'au moins une desdites deux entités. Une telle déconnexion volontaire est par exemple déclenchée suite à l'activation, par au moins une desdites deux entités, d'un mode moniteur, comme cela est décrit plus en détail ci-après en référence à des modes particuliers de mise en œuvre de l'invention.
En d'autres termes, le fait d'exécuter un processus de protection après qu'une attaque ait été détectée peut être vu comme la mise en œuvre d'un plan de secours permettant de contourner ladite attaque.
Une telle mise en œuvre (première phase pour détecter une attaque, puis deuxième phase pour protéger contre cette attaque) est particulièrement avantageuse en ce qu'elle peut être implémentée de manière plus simple que les solutions de l'art antérieur. En effet, le procédé de défense selon l'invention peut être mis en œuvre au niveau applicatif (i.e. dans un processeur exécutant des étapes du procédé de défense et équipant une entité). Autrement dit, il n'est pas nécessaire de modifier le firmware de la ou les cartes de communication (comme par exemple des cartes Wi-Fi) équipant le dispositif client et/ou le point d'accès. En conséquence, la solution proposée par l'invention offre la possibilité de déployer facilement une protection efficace contre des tentatives de déconnexion malveillantes.
On comprend également que la facilité d'implémentation logicielle de la solution proposée par l'invention a également un impact positif en termes de coût en comparaison avec les solutions de l'art antérieur.
Dans des modes particuliers de mise en œuvre, le procédé de défense peut comporter en outre l'une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles.
Dans des modes particuliers de mise en œuvre, une métrique correspond au débit de réception des requêtes appartenant à l'ensemble de requêtes reçu par une entité, le critère associé à ladite métrique étant satisfait si ledit débit de réception est supérieur à un seuil donné.
Dans des modes particuliers de mise en œuvre, une métrique correspond au niveau de puissance en réception des requêtes appartenant à l'ensemble de requêtes reçu par une entité, dit « niveau 6 de déconnexion », le critère associé à ladite métrique étant satisfait si l'écart entre ledit niveau de déconnexion et le niveau de puissance en réception de trames de données valides reçues par ladite entité antérieurement à la réception dudit ensemble de requêtes est, en valeur absolue et pendant une durée déterminée, supérieur à un seuil donné.
Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre, lorsque le débit de réception des requêtes appartenant à l'ensemble de requêtes reçu par une desdites deux entités, dite « première entité », a atteint un premier seuil donné, des étapes mises en œuvre par ladite première entité et comprenant :
- une activation d'un mode moniteur,
- une surveillance du trafic réseau sur ledit canal de communication, de sorte à pouvoir détecter au moins une requête de déconnexion, dite « requête falsifiée », émise par une source usurpant l'identité de ladite première identité et destinée à l'autre desdites deux entités, dite « deuxième entité »,
De plus, dans ces modes particuliers de mises en œuvre, une métrique correspond au nombre ou au débit de requêtes falsifiées détectées par ladite première entité, le critère associé à ladite métrique étant satisfait si ledit nombre ou ledit débit est supérieur à un deuxième seuil donné.
De manière connue en soi, en activant ledit mode moniteur (« monitor » en anglais, d'autres appellations pouvant encore être rencontrées, comme par exemple : Radio Frequency Monitoring, RF Monitor, rfmon, RFMON, Air Monitor, Network Monitor, NetMon, ou encore surveillance RF), une entité équipée d'une carte réseau idoine (par exemple une carte réseau Wi-Fi) est en mesure d'écouter (« to sniff » en anglais) le trafic Wi-Fi sur le canal de son choix, y compris celui du réseau de communication auquel elle était attachée avant l'activation dudit mode moniteur.
Dans des modes particuliers de mise en œuvre, une métrique correspond au nombre de requêtes falsifiées détectées par ladite première entité, le critère associé à ladite métrique étant satisfait si ledit nombre est supérieur ou égal à 1.
Dans des modes particuliers de mise en œuvre, ledit procédé comporte en outre, lorsque le débit de réception des requêtes appartenant à l'ensemble de requêtes reçu par une desdites deux entités, dite « première entité », a atteint un premier seuil donné, des étapes mises en œuvre par ladite première entité et comprenant :
- une activation d'un mode moniteur,
- une surveillance du trafic réseau sur ledit canal de communication, de sorte à pouvoir détecter au moins un paquet de données valide émis par l'autre desdites deux entités, dite « deuxième entité », et destiné à ladite première entité,
De plus, dans ces modes particuliers de mises en œuvre, une métrique correspond au débit de paquets de données valides détectés par ladite première entité, le critère associé à ladite métrique étant satisfait si ledit débit est supérieur à un deuxième seuil donné. 7
Dans des modes particuliers de mise en œuvre, un processus de protection exécuté par une entité comporte une modification d'au moins un paramètre de communication utilisé par l'une desdites deux entités pour transmettre des données après l'établissement de ladite connexion initiale.
Le fait de modifier au moins un paramètre de communication correspond à une stratégie de défense permettant de contourner l'attaque en cours, plutôt que de chercher à mener une opposition frontale face à cette attaque. En ce sens, une telle stratégie tient plus d'un comportement de « fuite » et/ou de « camouflage » vis-à-vis de l'attaque en cours, que d'un comportement de contre-attaque. En conséquence, il ne s'agit pas ici d'essayer d'identifier l'attaquant, mais plutôt de lui échapper, tout en essayant de maintenir une connexion.
Dans des modes particuliers de mise en œuvre, un processus de protection est exécuté par le dispositif client, un paramètre modifié correspondant à un identifiant unique dudit dispositif client.
Dans des modes particuliers de mise en œuvre, un processus de protection est exécuté par le point d'accès, au moins un paramètre modifié correspondant :
- à un identifiant unique dudit point d'accès, et/ou
- au canal de communication associé à ladite connexion initiale, et/ou
- à un identifiant du réseau de communication, et/ou
- à une donnée temporelle contenue dans des trames émises par ledit point d'accès, et/ou
- à une puissance émettrice dudit point d'accès, et/ou
- à une fréquence de saut.
On note que le fait de modifier, côte point d'accès, un identifiant unique (comme par exemple une adresse matérielle) et/ou le canal de communication correspond à une mise en œuvre préférée dans la mesure où cela permet d'accroitre la sécurité de la connexion existante (ou d'une future connexion le cas échéant) entre le point d'accès et le dispositif client. Ces avantages sont encore renforcés lorsqu'un identifiant unique du dispositif client est également modifié.
Dans des modes particuliers de mise en œuvre, chacune desdites deux entités exécute un processus de protection comportant une inversion de rôle, de sorte que le point d'accès soit configuré en tant que dispositif client, et que le dispositif client soit configuré en tant que point d'accès.
Dans des modes particuliers de mise en œuvre :
- si au moins un critère est satisfait pour une entité uniquement, un processus de protection est exécuté par ladite entité et consiste à ignorer la ou les requêtes de déconnexion reçues, ou
- si au moins un critère est satisfait pour chacune desdites deux entités, un processus de protection est exécuté par chacune desdites deux entités et consiste à ignorer la ou les requêtes de déconnexion reçues.
Dans des modes particuliers de mise en œuvre, l'exécution d'un processus de protection est itérée. 8
Ces itérations peuvent par exemple être effectuées de manière périodique au sein d'une même session de communication. Le fait d'itérer un processus de protection (par exemple en modifiant de manière régulière au moins un paramètre de communication et/ou en réalisant de manière régulière une inversion de rôle) permet de consolider la défense pouvant être mise en œuvre, et in fine améliorer la sécurité de la connexion entre le dispositif client et le point d'accès.
Dans des modes particuliers de mise en œuvre :
- un processus de protection exécuté par une entité est mémorisé par ladite entité préalablement à la mise en œuvre dudit procédé de défense, et/ou
- pour une desdites deux entités, dite « deuxième entité », exécutant un processus de protection, ledit procédé de défense comporte une étape de transmission d'un message de l'autre desdites deux entités, dite « première entité », vers ladite deuxième entité, ledit message comportant ledit processus de protection, ladite transmission étant mise en œuvre suite à l'établissement de la connexion initiale et de manière chiffrée.
Dans des modes particuliers de mise en œuvre, le protocole de communication est un protocole Wi-Fi.
Selon un deuxième aspect, l'invention concerne un programme d'ordinateur comportant des instructions pour la mise en œuvre d'étapes de réception, d'évaluation et d'exécution d'un procédé de défense selon l'invention lorsque ledit programme d'ordinateur est exécuté par un ordinateur.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
Selon un troisième aspect, l'invention concerne un support d'informations ou d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur selon l'invention.
Le support d'informations ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 9
Selon un quatrième aspect, l'invention concerne un point d'accès réseau apte à être connecté à un dispositif client pour échanger des données sur un canal de communication conformément à un protocole de communication déterminé, ledit point d'accès comportant :
- un module de réception configuré pour recevoir, après qu'une connexion ait été établie entre ledit point d'accès et le dispositif client, un ensemble de requêtes de déconnexion,
- un module d'évaluation configuré pour évaluer au moins un critère défini à partir d'une métrique basée sur ledit ensemble de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante.
Selon un cinquième aspect, l'invention concerne un dispositif client apte à être connecté à un point d'accès réseau pour échanger des données sur un canal de communication conformément à un protocole de communication déterminé, ledit dispositif client comportant :
- un module de réception configuré pour recevoir, après qu'une connexion ait été établie entre ledit point d'accès et le dispositif client, un ensemble de requêtes de déconnexion,
- un module d'évaluation configuré pour évaluer au moins un critère défini à partir d'une métrique basée sur ledit ensemble de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante.
Selon un sixième aspect, l'invention concerne un système pour la défense contre une tentative de déconnexion entre deux entités correspondant à un point d'accès réseau et un dispositif client, lesdites entités étant aptes à être connectées entre elles pour échanger des données sur un canal de communication conformément à un protocole de communication déterminé, et dans lequel :
- ledit point d'accès est conforme à l'invention et/ou ledit dispositif client est conforme à l'invention,
- au moins une desdites deux entités comporte un module d'exécution configuré pour exécuter, si au moins un critère est satisfait pour au moins une desdites deux entités, un processus de protection contre ladite tentative de déconnexion malveillante, de sorte à maintenir une connexion entre le point d'accès et le dispositif client.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- la figure 1 représente schématiquement un procédé de connexion, conforme à l'état de la technique, entre un dispositif client et un point d'accès, ledit procédé de connexion comportant des échanges de messages selon un protocole Wi-Fi ; 10
- la figure 2 représente schématiquement, dans son environnement, un mode particulier de réalisation d'un système de défense selon l'invention ;
- la figure 3 représente schématiquement un exemple d'architecture matérielle d'un dispositif client appartenant au système de défense de la figure 2 ;
- la figure 4 représente schématiquement un exemple d'architecture matérielle d'un point d'accès appartenant au système de défense de la figure 2 ;
- la figure 5 représente, sous forme d'ordinogramme, les principales étapes d'un procédé de défense selon l'invention telles qu'elles sont mises en œuvre par le système de défense de la figure 2 ;
- la figure 6 représente schématiquement un premier mode particulier de mise en œuvre du procédé de la figure 5 ;
- la figure 7 représente schématiquement un deuxième mode particulier de mise en œuvre du procédé de la figure 5 ;
- la figure 8 représente schématiquement un troisième mode particulier de mise en œuvre du procédé de la figure 5 ;
- la figure 9 représente schématiquement un quatrième mode particulier de mise en œuvre du procédé de la figure 5 ;
- la figure 10 représente schématiquement un cinquième mode particulier de mise en œuvre du procédé de la figure 5 ;
Description des modes de réalisation
La figure 2 représente schématiquement, dans son environnement, un mode particulier de réalisation d'un système 100 selon l'invention.
A cet effet, et tel qu'illustré par la figure 2, le système 100 comporte deux entités, à savoir un dispositif client 110 et un point d'accès réseau 120.
Pour la suite de la description, on considère de manière nullement limitative que le dispositif client 10 est un terminal mobile détenu par un utilisateur, comme par exemple un téléphone intelligent ou « smartphone », une tablette numérique, un ordinateur portable, etc. On considère également que le point d'accès 120 est une passerelle réseau permettant de relier un réseau de communication local à usage privé domestique 130 (réseau de type « LAN », acronyme de l'expression anglaise « Local Area Network ») au réseau public internet (réseau de type « WAN », acronyme de l'expression anglaise « Wide Area Network », non représenté sur la figure 2). On note que ledit point d'accès 120 est encore connu sous la dénomination « box Internet ». 11
Il est également considéré pour la suite de la description que les données (messages) échangées entre le dispositif client 110 et le point d'accès 120, via un canal de communication CAN du réseau local 130 déployé par le point d'accès 120, le sont sous forme de paquets encapsulés dans des trames (par exemple des requêtes et des réponses à ces requêtes). Lesdites trames sont conformes à un protocole Wi-Fi répondant à une norme IEEE 802.11 (ISO/CEI 8802-11). Enfin, on considère par ailleurs qu'aucune desdites deux entités 110, 120 n'est configurée de manière logicielle et matérielle pour mettre en œuvre une protection PMF.
Il convient toutefois de noter que le fait de considérer que le dispositif client 110 et le point d'accès 120 correspondent respectivement à un terminal mobile et une box Internet ne constitue qu'un choix d'implémentation de l'invention. D'une manière générale, aucune limitation n'est attachée aux natures respectives dudit dispositif client 110 (terminal fixe par exemple, comme un PC fixe) et dudit point d'accès 120 (serveur dédié par exemple).
On note également que le fait de considérer un point d'accès 120 offrant une connectivité vers des serveurs distants (exemple : réseau public internet, comme évoqué ci-avant) ne constitue d'une variante d'implémentation de l'invention. L'invention n'exclue pas d'envisager d'autres modes dans lesquels le dispositif client 110 se destine uniquement à communiquer avec le point d'accès 120 via le réseau local 130 déployé par ce dernier, i.e. sans chercher à être connecté avec un autre réseau susceptible d'être placé derrière le point d'accès 120 (exemple : un drone joue le rôle de point d'accès Wi-Fi afin qu'un téléphone mobile puisse s'y connecter pour le piloter, toutes les communications demeurant entre ces deux seules entités, le drone n'offrant aucune connectivité avec des serveurs distants).
En outre, rien n'exclut d'envisager un protocole de communication autre qu'un protocole Wi-Fi, comme par exemple un protocole propriétaire. L'invention n'exclut d'ailleurs pas non plus que le protocole de communication repose sur une technologie filaire (fibre optique, câble Ethernet, bus KNX, etc.).
Enfin, il importe également de noter que l'exemple de la figure 2 est donné à titre purement illustratif, et que le nombre de points d'accès ainsi que le nombre de dispositifs clients pouvant appartenir au système 100 ne sont pas des facteurs limitants de l'invention.
De manière conventionnelle, le dispositif client 110 et le point d'accès 120 sont configurés de sorte à pouvoir réaliser des traitements leur permettant d'établir une connexion entre eux, en mettant en œuvre un procédé de connexion tel que celui décrit en référence à la figure 1 (transmission des trames Tl à T6).
A cet effet, le dispositif client 110 comporte par exemple un ou plusieurs processeurs et des moyens de mémorisation (disque dur magnétique, mémoire électronique, disque optique, etc.) dans lesquels sont mémorisés des données et un programme d'ordinateur, sous la forme d'un ensemble d'instructions de code de programme à exécuter pour mettre en œuvre un premier 12 ensemble d'étapes (émission des trames Tl, T3, T5, et réception des trames T2, T4, T6) dudit procédé de connexion.
Alternativement ou en complément, le dispositif client 110 comporte également un ou des circuits logiques programmables, de type FPGA, PLD, etc., et/ou circuits intégrés spécialisés (ASIC), et / ou un ensemble de composants électroniques discrets, etc. adaptés à mettre en œuvre ledit premier ensemble d'étapes du procédé de connexion.
En d'autres termes, le dispositif client 110 comporte un ensemble de moyens configurés de façon logicielle (programme d'ordinateur spécifique) et/ou matérielle (FPGA, PLD, ASIC, etc.) pour mettre en œuvre ledit premier ensemble d'étapes du procédé de connexion.
De manière similaire, le point d'accès 120 comporte par exemple un ou plusieurs processeurs et des moyens de mémorisation (disque dur magnétique, mémoire électronique, disque optique, etc.) dans lesquels sont mémorisés des données et un programme d'ordinateur, sous la forme d'un ensemble d'instructions de code de programme à exécuter pour mettre en œuvre un deuxième ensemble d'étapes (émission des trames T2, T4, T6, et réception des trames Tl, T3, T5) dudit procédé de connexion.
Alternativement ou en complément, le point d'accès 120 comporte également un ou des circuits logiques programmables, de type FPGA, PLD, etc., et/ou circuits intégrés spécialisés (ASIC), et / ou un ensemble de composants électroniques discrets, etc. adaptés à mettre en œuvre ledit deuxième ensemble d'étapes du procédé de connexion.
En d'autres termes, le point d'accès 120 comporte un ensemble de moyens configurés de façon logicielle (programme d'ordinateur spécifique) et/ou matérielle (FPGA, PLD, ASIC, etc.) pour mettre en œuvre ledit deuxième ensemble d'étapes du procédé de connexion.
Conformément à l'invention, le système 100 est en outre configuré pour réaliser des traitements permettant de fournir, une fois le dispositif client 110 et le point d'accès 120 connectés entre eux, une défense contre une attaque consistant en une tentative de déconnexion malveillante, en mettant en œuvre un procédé de défense selon l'invention. Une telle défense vise en particulier à maintenir une connexion entre le dispositif client 110 et le point d'accès 120 de sorte qu'ils puissent continuer à communiquer entre eux.
On note que par « tentative de déconnexion malveillante », il est fait référence, d'une manière générale, à une attaque ciblant le dispositif client 110 et/ou le point d'accès 120. Dit encore autrement, le dispositif client 110 et le point d'accès 120 peuvent recevoir chacun une ou plusieurs requêtes de déconnexion illégitimes (i.e. émises par une entité tierce non authentifiée à l'origine de l'attaque en question).
Pour la suite de la description, on considère de manière nullement limitative que le dispositif client 110 et le point d'accès 120 contribuent tous les deux au procédé de défense, et sont 13 respectivement configurés de manière idoine pour mettre en œuvre des étapes dudit procédé de défense. De cette manière, le dispositif client 110 (respectivement le point d'accès 120) peut réaliser des traitements permettant de maintenir une connexion avec le point d'accès 120 (respectivement avec le dispositif client 110).
Rien n'exclut cependant d'envisager d'autres modes de réalisation dans lesquels seulement une entité parmi le dispositif client 110 et le point d'accès 120 participe aux traitements faisant l'objet du procédé de défense. Dans ce cas, on comprend que l'expression « tentative de déconnexion malveillante » fait plus spécifiquement référence à une attaque ciblant l'entité qui met en œuvre des étapes du procédé de défense.
La figure 3 représente schématiquement un exemple d'architecture matérielle du dispositif client 110 appartenant au système 100 de la figure 2.
Tel qu'illustré par la figure 3, le dispositif client 110 dispose de l'architecture matérielle d'un ordinateur. Ainsi, le dispositif client 110 comporte, notamment, un processeur 1_1, une mémoire vive 2_1, une mémoire morte 3_1 et une mémoire non volatile 4_1. Il comporte en outre un module de communication 5_1.
La mémoire morte 3_1 du dispositif client 110 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 1_1 et sur lequel est enregistré un programme d'ordinateur PROG_l conforme à l'invention, comportant des instructions pour l'exécution d'étapes du procédé de défense selon l'invention. Le programme PROG_l définit des modules fonctionnels du dispositif client 110, qui s'appuient ou commandent les éléments matériels 1_1 à 5_1 du dispositif client 110 cités précédemment, et qui comprennent notamment :
- un module de réception MOD_RX_l configuré pour recevoir, après qu'une connexion ait été établie entre le point d'accès 120 et le dispositif client 110 (conformément au procédé de connexion mentionné ci-avant), un ensemble de requêtes de déconnexion,
- un module d'évaluation MOD_EVAL_l configuré pour évaluer au moins un critère défini à partir d'une métrique basée sur ledit ensemble de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante,
- un module d'exécution MOD_EXEC_l configuré pour exécuter, si au moins un critère est satisfait pour ledit dispositif client 110, un processus de protection contre ladite tentative de déconnexion malveillante, de sorte à maintenir une connexion entre le point d'accès 120 et le dispositif client 110.
Il est à noter que d'une manière générale, dans la présente description, un « ensemble de requêtes de déconnexion » peut comporter une ou plusieurs requêtes de déconnexion.
Le module de communication 5_1 permet notamment au dispositif client 110 de communiquer avec le point d'accès 120, et intègre dès lors les moyens configurés de manière matérielle et/ou 14 logicielle décrits ci-avant pour mettre en œuvre ledit premier ensemble d'étapes (émission des trames Tl, T3, T5, et réception des trames T2, T4, T6) du procédé de connexion. Le module de communication 5_1 permet également au dispositif client 110 de communiquer avec des entités du réseau local autres que le point d'accès 120, et intègre notamment à cet effet ledit module de réception MOD_RX_l (la ou les requêtes de déconnexion reçues étant susceptibles d'être illégitimes, et donc transmises par une entité tierce).
Le point d'accès 120 dispose d'une architecture matérielle similaire à celle du dispositif client 110.
La figure 4 représente schématiquement un exemple d'architecture matérielle du point d'accès 120 appartenant au système 100 de la figure 2.
Tel qu'illustré par la figure 4, le point d'accès 120 dispose de l'architecture matérielle d'un ordinateur. Ainsi, le point d'accès 120 comporte, notamment, un processeur 1_2, une mémoire vive 2_2, une mémoire morte 3_2 et une mémoire non volatile 4_2. Il comporte en outre un module de communication 5_2.
La mémoire morte 3_2 du point d'accès 120 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 1_2 et sur lequel est enregistré un programme d'ordinateur PROG_2 conforme à l'invention, comportant des instructions pour l'exécution d'étapes du procédé de défense selon l'invention. Le programme PROG_2 définit des modules fonctionnels du point d'accès 120, qui s'appuient ou commandent les éléments matériels 1_2 à 5_2 du point d'accès 120 cités précédemment, et qui comprennent notamment :
- un module de réception MOD_RX_2 configuré pour recevoir, après qu'une connexion ait été établie entre le point d'accès 120 et le dispositif client 110 (conformément au procédé de connexion mentionné ci-avant), un ensemble de requêtes de déconnexion,
- un module d'évaluation MOD_EVAL_2 configuré pour évaluer au moins un critère défini à partir d'une métrique basée sur ledit ensemble de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante,
- un module d'exécution MOD_EXEC_2 configuré pour exécuter, si au moins un critère est satisfait pour ledit point d'accès 120, un processus de protection contre ladite tentative de déconnexion malveillante, de sorte à maintenir une connexion entre le point d'accès 120 et le dispositif client 110.
Le module de communication 5_2 permet notamment au point d'accès 120 de communiquer avec le dispositif client 110, et intègre dès lors les moyens configurés de manière matérielle et/ou logicielle décrits ci-avant pour mettre en œuvre ledit deuxième ensemble d'étapes (émission des trames T2, T4, T6, et réception des trames Tl, T3, T5) du procédé de connexion. Le module de communication 5_2 permet également au point d'accès 120 de communiquer avec des entités du réseau local autres que le dispositif client 110, et intègre notamment à cet effet ledit module de 15 réception MOD_RX_2 (la ou les requêtes de déconnexion reçues étant susceptibles d'être illégitimes, et donc transmises par une entité tierce).
On va maintenant décrire une mise en œuvre générale du procédé de défense, telle qu'exécutée par le système 100 de la figure 2. Des modes particuliers de mise en œuvre sont décrits ultérieurement. Il est à noter que ledit procédé de défense est mis en œuvre après l'établissement d'une connexion entre le dispositif client 110 et le point d'accès 120. Autrement dit, la mise en œuvre du procédé de connexion précède celle du procédé de défense, et on considère désormais que le dispositif client 110 et le point d'accès 120 sont connectés entre eux via une connexion dite « initiale », de sorte à pouvoir échanger des données sur le canal de communication CAN conformément à un protocole Wi-Fi mentionné ci-avant.
La figure 5 représente, sous forme d'ordinogramme, les principales étapes du procédé de défense selon l'invention telles qu'elles sont mises en œuvre par le système 100 de la figure 2.
Dans son principe général, le procédé de défense comporte, dans un premier temps, une phase d'analyse exécutée par au moins une des deux entités 110, 120 recevant une ou plusieurs requêtes de déconnexion (étant entendu que l'une seule desdites deux entités 110, 120 ou bien lesdites deux entités 110, 120 peuvent recevoir des requêtes de déconnexion). De cette manière, si des requêtes de déconnexion sont reçues en provenance d'une entité tierce menant une attaque (tentative de déconnexion malveillante), et dénommée ci-après « attaquant ATT » (sans pour autant que lesdites requêtes, et donc a fortiori l'attaquant ATT lui-même, ne soient authentifiées), la phase d'analyse exécutée par une entité 110, 120 permet de détecter le caractère illégitime desdites requêtes, et donc in fine l'attaque menée par l'attaquant ATT. On comprend bien entendu que, à l'inverse, si une phase d'analyse réalisée par une entité 110, 120 ne conclut pas à la détection d'une tentative de déconnexion malveillante, alors la connexion entre les deux entités 110, 120 est rompue de manière légitime (le dispositif client 110 pouvant bien sûr se reconnecter ultérieurement au point d'accès 120, sauf dans le cas où il aurait été placé sur une liste d'exclusion par ce dernier).
Par ailleurs, dans le cas où au moins une des deux entités 110, 120 du système 100 a été en mesure de détecter une attaque menée par l'attaquant ATT, le procédé comporte une autre phase exécutée par ladite au moins une entité du système 100 et qui correspond à la mise en œuvre d'un processus de protection contre ladite attaque. Ledit processus de protection vise à permettre le maintien d'une connexion entre le dispositif client 110 et le point d'accès 120, de sorte que ces derniers puissent continuer à communiquer entre eux, même éventuellement de manière dégradée. Par « dégradée », on fait référence ici par exemple à une communication réalisée en retard, ce retard provenant du temps qu'il a été nécessaire d'allouer pour détecter une tentative de déconnexion malveillante. 16
Pour la suite de la description du procédé de défense de la figure 5, on considère de manière nullement limitative qu'un attaquant ATT réalise une tentative de déconnexion malveillante qui vise les deux entités 110, 120 du système 100. A cet effet, l'attaquant ATT transmet au dispositif client 110 (respectivement au point d'accès 120) un ensemble ENS_1 de requêtes de déconnexion (respectivement un ensemble ENS_2 de requêtes de déconnexion).
Dès lors, et tel qu'illustré par la figure 5, le procédé de défense comporte une étape E10 de réception, par le dispositif client 110, de l'ensemble ENS_1. Ladite étape E10 est mise en œuvre par le module de réception MOD_RX_l équipant le dispositif client 110.
Le procédé de défense comporte également une étape E20 de réception, par le point d'accès 120, de l'ensemble ENS_2. Ladite étape E20 est mise en œuvre par le module de réception MOD_RX_2 équipant le point d'accès 120.
On note que dans le procédé de défense de la figure 5, les étapes E10 et E20 sont mises en œuvre en parallèle, ce qui est dû au fait que les ensembles ENS_1 et ENS_2 sont supposés émis simultanément par l'attaquant ATT. Il convient toutefois de noter que rien n'exclut d'envisager des réceptions asynchrones desdites ensembles ENS_1 et ENS_2 (par exemple des réceptions consécutives) dans l'hypothèse où l'attaquant ATT n'émet pas lesdits ensembles ENS_1 et ENS_2 de manière simultanée.
Le procédé de défense comporte également une étape E30 d'évaluation, par le dispositif client 110, d'au moins un critère CRIT1 J (i étant un indice entier supérieur ou égal à 1) défini à partir d'une métrique MET1 J basée sur ledit ensemble ENS_1 de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble ENS_1 de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante. Ladite étape E30 est mise en œuvre par le module d'évaluation MOD_EVAL_l équipant le dispositif client 110.
De manière similaire à l'étape E30, le procédé de défense comporte également une étape E40 d'évaluation, par le point d'accès 120, d'au moins un critère CRIT2J (j étant un indice entier supérieur ou égale à 1) défini à partir d'une métrique MET2J basée sur ledit ensemble ENS_2 de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble ENS_2 de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante. Ladite étape E40 est mise en œuvre par le module d'évaluation MOD_EVAL_2 équipant le point d'accès 120.
Il est à noter que, dans le cadre de la présente invention, le nombre de métriques pouvant être envisagé, aussi bien dans l'étape E30 que dans l'étape E40, est supérieur ou égal à 1. On comprend dès lors que deux critères respectivement associés à deux métriques distinctes diffèrent nécessairement l'un de l'autre. 17
Il peut également être noté que l'invention n'exclut pas le fait d'envisager des critères s'appuyant sur la même métrique, mais néanmoins distincts entre eux (valeurs de seuil distinctes). En outre, la ou les métriques utilisées pour la mise en œuvre de l'étape E30 peuvent être en tout ou partie distinctes de la ou les métriques utilisées pour la mise en œuvre de l'étape E40.
Pour la description du procédé de défense de la figure 5, on suppose que, une fois lesdites étapes E30 et E40 exécutées, au moins un critère CRIT1J est satisfait pour le dispositif client 110, mais aussi qu'au moins un critère CRIT2J est satisfait pour le point d'accès 120.
Dès, et tel qu'illustré par la figure 5, le procédé de défense comporte une étape E50 d'exécution, par le dispositif client 110, d'un processus de protection contre la tentative de déconnexion malveillante qui le vise ainsi que le point d'accès 120, de sorte à maintenir une connexion entre lesdites deux entités 110, 120. Ladite étape E50 est mise en œuvre par le module d'exécution MOD_EXEX_l équipant le dispositif client 110.
De manière similaire à l'étape E50, le procédé de défense comporte une étape E60 d'exécution, par le point d'accès 120, d'un processus de protection contre la tentative de déconnexion qui le vise ainsi que le dispositif client 110, là aussi dans l'objectif de maintenir une connexion entre lesdites deux entités 110, 120. Ladite étape E60 est mise en œuvre par le module d'exécution MOD_EXEX_2 équipant le point d'accès 120.
Il importe de noter que les processus de protection respectivement exécutés par le dispositif client 110 et le point d'accès 120 peuvent différer l'un de l'autre. Ces aspects sont décrits plus en détails ultérieurement.
Des modes particuliers de mise en œuvre du procédé de défense de la figure 5 sont maintenant décrits. Plus particulièrement, et dans un premier temps, il est décrit des modes particuliers de mise en œuvre dans lesquels des métriques distinctes sont utilisées lors de l'exécution des étapes E30 et E40 (figures 6, 7, 8 et 9).
Comme mentionné ci-avant, la ou les métriques utilisées pour la mise en œuvre de l'étape E30 peuvent être en tout ou partie distinctes de la ou les métriques utilisées pour la mise en œuvre de l'étape E40. En tout état de cause, une métrique applicable à l'une des deux entités 110, 120 du système 100 peut également être appliquée, suivant des dispositions techniques tout à fait similaires, à l'autre desdites deux entités 110, 120. Pour cette raison, et de sorte à simplifier la description, les modes particuliers décrits ci-après, pour détailler des exemples de métriques, concernent uniquement l'étape E30, étant entendu que ces modes peuvent être envisagés de manière équivalente (i.e. en inversant les rôles respectifs du dispositif client 110 et du point d'accès 120) en ce qui concerne l'étape E40.
La figure 6 représente schématiquement un premier mode particulier de mise en œuvre du procédé de la figure 5. 18
Dans ledit premier mode, l'étape E30 est exécutée en utilisant une métrique MET1_1 correspondant au débit de réception DEB_RX des requêtes appartenant à l'ensemble ENS_1 de requêtes reçu par le dispositif client 110. Le critère CRIT1_1 associé à ladite métrique MET1_1 est quant à lui satisfait si ledit débit de réception DEB_RX est supérieur à un seuil donné Sl_l.
A titre d'exemple nullement limitatif, et tel qu'illustré par la figure 6, des requêtes de déconnexion REQ_DECl_k (k étant un indice entier), formant ledit ensemble ENS_1, sont reçues de manière continue (i.e. au fil de l'eau) par le dispositif client 110, après un échange de données avec le point d'accès 120 (cet échange de données est symbolisé par des flèches portant les références DATAI et DATA2).
Chaque requête de déconnexion REQ_DECl_k a :
- pour adresse source MAC_SRC (i.e. de provenance de ladite requête REQ_DECl_k), une adresse correspondant à un identifiant unique du point d'accès 120, à savoir dans cet exemple l'adresse matérielle MAC_2 (« MAC » étant l'acronyme de l'expression anglaise « Media Access Control ») dudit point d'accès 120,
- pour adresse destination MAC_DST, une adresse correspondant à un identifiant unique du dispositif client 110, à savoir dans cet exemple l'adresse matérielle MAC_1 dudit dispositif client 110.
Il importe de noter que les requêtes de déconnexion REQ_DECl_k ont pour origine réelle l'attaquant ATT, et qu'il s'agit donc bien de requêtes illégitimes puisqu'elles usurpent l'identité du point d'accès 120.
Dans l'exemple de la figure 6, le débit de réception DEB_RX desdites requêtes de déconnexion est égal à douze requêtes par seconde, alors même que le seuil Sl_l associé au critère CRIT1_1 est fixé à dix requêtes de déconnexion par seconde.
Aussi, au bout d'une seconde de réception de requêtes de déconnexion, douze requêtes de déconnexion REQ_DEC1_1,..., REQ_DEC1_12 sont reçues par le dispositif client 110. En conséquence, le seuil Sl_l est dépassé, et le critère CRIT1_1 est donc satisfait, de sorte qu'une tentative de déconnexion malveillante est détectée (en l'espèce, le dispositif client 110 détecte qu'il est attaqué).
Bien entendu, le fait de considérer un seuil Sl_l égal à dix requêtes de déconnexion par seconde ne constitue qu'un exemple d'implémentation dudit premier mode de mise en œuvre. D'une manière générale, aucune limitation n'est attachée à la valeur dudit seuil Sl_l.
La figure 7 représente schématiquement un deuxième mode particulier de mise en œuvre du procédé de la figure 5.
On note que les éléments similaires entre les figures 6 et 7 reprennent le même formalisme de notation. 19
Dans ledit deuxième mode, l'étape E30 est exécutée en utilisant une métrique MET1_2 correspondant au niveau de puissance en réception des requêtes appartenant à l'ensemble ENS_1 de requêtes reçu par le dispositif client 110, dit « niveau de déconnexion ». Dans l'exemple de la figure 7, ledit niveau de déconnexion correspond à un niveau de type « RSSI » (acronyme de l'expression anglaise « Received Signal Strength Indication »), noté ci-après RSSI_DEC.
Le critère CRIT1_2 associé à ladite métrique MET1_2 est quant à lui satisfait si l'écart entre ledit niveau de déconnexion RSSI et le niveau de puissance en réception RSSI_RX de trames de données valides (données « DATA2 » dans la figure 7) reçues par ledit dispositif client 110 antérieurement à la réception dudit ensemble ENS_1 est, en valeur absolue et pendant une durée déterminée, supérieur à un seuil donné Sl_2.
Dans l'exemple de la figure 7, le niveau de déconnexion RSSI_DEC est égal à -50 dBm pendant une durée de 1 seconde (trois requêtes REQ_DEC1_1, REQ_DEC1_2 et REQ_DEC1_3 sont reçues par le dispositif client 110 pendant 1 seconde, et chacune de ces requêtes est associé à un niveau de déconnexion RSSI_DEC est égal à -50 dBm). En comparaison, le niveau de puissance en réception RSSI_RX antérieur à la réception desdites requêtes de déconnexion est égal à -80 dBm. L'écart entre les niveaux RSSI_DEC et RSSI_RX, en valeur absolue et pendant 1 seconde, est donc égal à 30, alors même que le seuil Sl_2 associé au critère CRIT1_2 est fixé à 10 dBm par seconde.
En conséquence, le seuil Sl_2 est dépassé, et le critère CRIT1_2 est donc satisfait, de sorte qu'une tentative de déconnexion malveillante est détectée (en l'espèce, le dispositif client 110 détecte qu'il est attaqué).
Bien entendu, le fait de considérer un seuil Sl_2 égal à 10 dBm par seconde ne constitue qu'un exemple d'implémentation dudit deuxième mode de mise en œuvre. D'une manière générale, aucune limitation n'est attachée à la valeur dudit seuil Sl_2.
La figure 8 représente schématiquement un troisième mode particulier de mise en œuvre du procédé de la figure 5.
On note que les éléments similaires entre les figures 6 et 8 reprennent le même formalisme de notation.
Dans ledit troisième mode, le procédé de défense comporte en outre, lorsque le débit de réception DEB_RX des requêtes appartenant à l'ensemble ENS_1 de requêtes reçu par le dispositif client 110 a atteint un premier seuil donné Sl_3 (ledit débit de réception DEB_RX est ici évalué pendant l'étape E10 de réception), des étapes mises en œuvre par ledit dispositif client 110 et comprenant : - une activation (étape Eli) d'un mode moniteur (« monitor » en anglais). Une fois configuré dans ledit mode moniteur, le dispositif client 110 est en mesure d'écouter (« to sniff » en anglais) le trafic du réseau local 130. On note que le fait d'activer ledit mode moniteur, de la part du dispositif client 110, entraîne de facto la déconnexion (volontaire) du dispositif client 110, le point d'accès 20
120 étant informé de cette déconnexion (bien entendu, si le dispositif client 110 est équipé de plusieurs cartes réseau Wi-Fi, le passage en mode moniteur fait référence à la déconnexion de la carte Wi-Fi jusqu'alors utilisée pour permettre à ce dernier de communiquer avec le point d'accès 120, suite à la connexion initiale). Tous les aspects techniques liés à l'activation d'un tel mode moniteur, ainsi qu'aux capacités du dispositif client 110 une fois configuré dans ce mode moniteur, sont bien connus de l'homme du métier et ne sont donc pas décrits plus en détail ici,
- une surveillance (étape E12) du trafic réseau sur ledit canal de communication CAN, de sorte à pouvoir détecter au moins une requête de déconnexion, dite « requête falsifiée », émise par une source usurpant l'identité du dispositif client 110 et destinée au point d'accès 120.
En outre, dans ledit troisième mode, l'étape E30 est exécutée en utilisant une métrique MET1_3 correspondant au nombre N_FAL de requêtes falsifiées détectées par le dispositif client 110 (il s'agit de requêtes usurpant l'identité du dispositif client 110, destinées au point d'accès 120 et détectées après le passage en mode moniteur). Le critère CRIT1_3 associé à ladite métrique MET1_3 est quant à lui satisfait si ledit nombre N_FAL est supérieur à un deuxième seuil donné Sl_4.
Dans l'exemple de la figure 8, le premier seuil Sl_3 est égal à deux requêtes de déconnexion par seconde. Aussi, et comme illustré en figure 8, trois requêtes REQ_DEC1_1, REQ_DEC1_2 et REQ_DEC1_3 sont reçues par le dispositif client 110 pendant 1 seconde (DEB_RX = 3), de sorte que, sur réception de ladite troisième requête REQ_DEC1_3, le dispositif client 110 passe en mode moniteur et surveille le trafic réseau. Lors de cette surveillance, il détecte une requête de déconnexion REQ_DEC2_1 destinée au point d'accès 120 et usurpant l'identité dudit dispositif client 110 (N_FALS = 1), alors même que le seuil Sl_4 associé au critère CRIT1_3 est fixé à 0.
En conséquence, le seuil Sl_3 est dépassé, et le critère CRIT1_3 est donc satisfait, de sorte qu'une tentative de déconnexion malveillante est détectée (en l'espèce, le dispositif client 110 détecte que le point d'accès 120 est attaqué).
Bien entendu, le fait de considérer un premier seuil Sl_3 (respectivement un deuxième seuil Sl_4) égal à deux requêtes de déconnexion par seconde (respectivement égal à 0) ne constitue qu'un exemple d'implémentation dudit troisième mode de mise en œuvre. D'une manière générale, aucune limitation n'est attachée à la valeur dudit premier seuil Sl_3 (respectivement à la valeur dudit deuxième seuil Sl_4)·
Par ailleurs, la mise en œuvre dudit troisième mode n'est pas non plus limitée par le fait de considérer une métrique correspondant au nombre de requêtes falsifiées détectées par le dispositif client 110. Rien n'exclut en effet de considérer une autre métrique, comme par exemple une métrique correspondant au débit de réception de requêtes falsifiées détectées par le dispositif client 110, le seuil pris en compte pour le critère associé à cette autre métrique étant par exemple égal à dix requêtes falsifiées détectées en 1 seconde. 21
On note également que dans la mesure où le dispositif client 110 est ici déconnecté du point d'accès 120 (en raison du passage en mode moniteur), il convient d'envisager une reconnexion audit point d'accès 120 pour ledit dispositif client 110 étant donné qu'un objectif du procédé de défense est de maintenir une connexion entre ces deux entités. Une telle reconnexion peut être envisagée au cours de l'exécution du processus de protection (étape E50) si ce dernier consiste par exemple à ignorer les requêtes de déconnexion reçues, ou bien encore à l'issue dudit processus de protection si ce dernier consiste par exemple en une modification d'au moins un paramètre de communication utilisé par l'une desdites deux entités 110, 120 pour transmettre des données après l'établissement de la connexion initiale. De tels exemples de processus de protection sont décrits plus en détails ultérieurement. En tout état de cause, le mécanisme de reconnexion en tant que tel est connu de l'homme de l'art (attente de réception d'une trame balise, dite « beacon frame » en anglais, procédure de « poignée de main en 4 étapes », etc.).
La figure 9 représente schématiquement un quatrième mode particulier de mise en œuvre du procédé de la figure 5.
On note que les éléments similaires entre les figures 6 et 9 reprennent le même formalisme de notation.
Dans ledit quatrième mode, le procédé de défense comporte en outre, lorsque le débit de réception DEB_RX des requêtes appartenant à l'ensemble ENS_1 de requêtes reçu par le dispositif client 110 a atteint un premier seuil donné Sl_5 (ledit débit de réception DEB_RX est ici évalué pendant l'étape E10 de réception), des étapes mises en œuvre par ledit dispositif client 110 et comprenant :
- une activation (étape Eli) d'un mode moniteur,
- une surveillance (étape E12) du trafic réseau sur ledit canal de communication CAN, de sorte à pouvoir détecter au moins un paquet de données valide émis par le point d'accès 120, et destiné au dispositif client 110.
En outre, dans ledit quatrième mode, l'étape E30 est exécutée en utilisant une métrique MET1_4 correspondant au débit DEB_VAL de paquets de données valides détectés par le dispositif client 110. Le critère CRIT1_4 associé à ladite métrique MET1_4 est quant à lui satisfait si ledit débit DEB_VAL est supérieur à un deuxième seuil donné Sl_6.
Dans l'exemple de la figure 9, le premier seuil Sl_5 est égal à deux requêtes de déconnexion par seconde. Aussi, et comme illustré en figure 9, trois requêtes REQ_DEC1_1, REQ_DEC1_2 et REQ_DEC1_3 sont reçues par le dispositif client 110 pendant 1 seconde (DEB_RX = 3), de sorte que, sur réception de ladite troisième requête REQ_DEC1_3, le dispositif client 110 passe en mode moniteur et surveille le trafic réseau. Lors de cette surveillance, le dispositif client 110 détecte que le point d'accès 120 lui adresse cinq paquets de données valides PI, P2, P3 P4, P5 en une seconde 22
(DEB_VAL = 5), alors même que le seuil Sl_6 associé au critère CRIT1_4 est fixé à trois paquets de données valides par seconde.
En conséquence, le seuil Sl_6 est dépassé, et le critère CRI1_4 est donc satisfait, de sorte qu'une tentative de déconnexion malveillante est détectée.
Bien entendu, le fait de considérer un premier seuil Sl_5 (respectivement un deuxième seuil Sl_6) égal à deux requêtes de déconnexion par seconde (respectivement égal à trois paquets valides) ne constitue qu'un exemple d'implémentation dudit quatrième mode de mise en œuvre. D'une manière générale, aucune limitation n'est attachée à la valeur dudit premier seuil Sl_5 (respectivement à la valeur dudit deuxième seuil Sl_6).
On note par ailleurs qu'un tel quatrième mode de mise en œuvre trouve une application préférentielle (mais non exclusive) lorsque le dispositif client 110 est équipé d'une pluralité de cartes réseau (en l'espèce, il s'agit ici de cartes Wi-Fi, comme par exemple dans le cas d'un répéteur Wi-Fi), étant entendu que l'activation du mode moniteur s'effectue en déconnectant la carte Wi-Fi jusqu'alors utilisée pour permettre à ce dernier de communiquer avec le point d'accès 120, suite à la connexion initiale.
Lesdits premier, deuxième, troisième et quatrième modes de mise en œuvre ont été décrits de manière séparée et en supposant que la détection d'une tentative de déconnexion malveillante est effectuée par le dispositif client 110 (cette tentative pouvant viser le dispositif client 110 lui-même ou bien encore le point d'accès 120).
Cela étant, et comme déjà évoqué auparavant, ces modes s'appliquent tout autant (par inversion des rôles) au point d'accès 120, afin que ce dernier soit en mesure de détecter une tentative de déconnexion malveillante (cette tentative pouvant viser le point d'accès 120 lui-même ou bien encore le dispositif client 110).
En outre, quelle que soit l'entité 110, 120 du système 100 considérée, tout ou partie desdits premier, deuxième, troisième et quatrième modes de mise en œuvre peuvent être exécutés selon toutes combinaisons techniquement envisageables. Ainsi, si N modes (N compris entre 1 et 4) parmi lesdits premier, deuxième, troisième et quatrième modes sont combinés entre eux pour une entité 110, 120, une attaque peut être détectée par ladite entité 110, 120 si M critères (M compris entre 1 et N) sont satisfaits.
On va décrire maintenant encore d'autres modes particuliers de mise en œuvre du procédé de défense de la figure 5. Plus particulièrement, il est décrit des modes particuliers de mise en œuvre des étapes E50 et E60 permettant l'exécution, par chacune des entités 110, 120 du système 100, d'un processus de protection contre l'attaque menée par l'attaquant ATT.
Il convient de noter que les modes qui sont dorénavant décrits en lien avec les étapes E50 et E60 sont combinables (selon toutes combinaisons techniquement envisageables) avec tous les modes 23 précédemment décrits en référence aux figures 6, 7, 8 et 9 (premier, deuxième, troisième et quatrième modes).
La figure 10 représente schématiquement un cinquième mode particulier de mise en œuvre du procédé de la figure 5.
On note que les éléments similaires entre la figure 10 et l'une quelconque des figures 6, 7, 8 et 9 reprennent le même formalisme de notation.
Dans ledit cinquième mode de mise en œuvre, on observe tout d'abord que, suite à la mise en œuvre de la procédure de connexion (trames Tl à T6), de sorte à établir la connexion initiale, ainsi que de la mise en œuvre de la procédure de « poignée de main en 4 étapes » (« 4-way handshake » en anglais), le point d'accès 120 transmet au dispositif client 110 un message MESS_DEF (étape E00 du procédé de défense dans ledit cinquième mode de mise en œuvre).
Ledit message MESS_DEF est préférentiellement transmis de manière chiffrée et comporte les processus de protection que chacune des entités 110, 120 est destinée à appliquer au cas où une tentative de déconnexion malveillante visant au moins l'une desdites deux entités 110, 120 est détectée.
Dans ledit cinquième mode de mise en œuvre, le message MESS_DEF permet au point d'accès 120 d'informer le dispositif client 110 que, en cas de détection d'attaque, chaque entité 110, 120 doit modifier un paramètre de communication utilisé par ladite entité 110, 120 pour transmettre des données après l'établissement de la connexion initiale. Plus particulièrement, le point d'accès 120 modifie ici son adresse matérielle MAC_2 en MAC_4 et le dispositif client 110 doit modifier son adresse matérielle MAC_1 en MAC_3. Autrement dit, chacune des deux entités 110, 120 du système 100 modifie son adresse matérielle.
Il est à noter que le message MESS_DEF, et donc a fortiori les processus de protection qu'il contient, ont ici été mémorisés par ledit point d'accès 120 préalablement à la mise en œuvre du procédé de défense. Cette mémorisation est par exemple effectuée dans la mémoire non volatile 4_2 du point d'accès 120, lors de la conception et la fabrication de ce dernier.
En alternative, ledit message MESS_DEF transmis par le point d'accès 120 au dispositif client 110 peut correspondre à un message normalisé inscrit dans le standard sur lequel se base le protocole de communication utilisé par lesdites deux entités 110, 120. Dans ce cas, seul le dispositif client 110 mémorise le processus de protection qui lui est transmis lors de la mise en œuvre du procédé de défense, étant donné que c'est le point d'accès 120 qui est à l'origine de cette transmission standardisée.
Dans ledit cinquième mode de mise en œuvre, chacune des deux entités 110, 120 est visée par une tentative de déconnexion détectée suivant une mise en œuvre conforme audit troisième mode (figure 8) et dans laquelle la métrique prise en compte est le nombre de requêtes falsifiées 24 détectées par chacune des deux entités 110, 120. Il est considéré en outre qu'un critère commun auxdites deux entités 110, 120 est associé à ladite métrique, ce critère étant satisfait si ledit nombre de requêtes falsifiées détectées est supérieur ou égal à 1.
Aussi, et comme illustré par la figure 10 :
- le dispositif client 110 met en œuvre des étapes de réception E10, d'activation d'un mode moniteur Eli et de surveillance E12,
- le point d'accès 120 met en œuvre des étapes de réception E20, d'activation d'un mode moniteur E21 (similaire à l'étape Eli) et de surveillance E22 (similaire à l'étape E12).
De plus, chaque entité 110, 120 détecte une requête falsifiée :
- le dispositif client 110 détecte une requête REC_DEC1 usurpant l'identité dudit dispositif client 110 et adressée au point d'accès 120,
- le point d'accès 120 détecte une requête REC_DEC2 usurpant l'identité dudit point d'accès 120 et adressée au dispositif client 110.
En conséquence, chaque entité 110, 120 détecte une attaque et exécute donc le processus de protection qui lui est associé, c'est-à-dire un changement d'adresse matérielle.
En définitive, et comme illustré par la figure 10, une nouvelle procédure de connexion est mise en œuvre suite à l'exécution desdits processus de protection, cette nouvelle procédure de connexion s'appuyant sur les nouvelles adresses matérielles désormais utilisées (on rappelle que pour détecter des requêtes falsifiées, chaque entité 110, 120 passe ici en mode moniteur et par conséquent se déconnecte de l'autre entité 110, 120). Une connexion est donc maintenue entre le dispositif client 110 et le point d'accès 120, étant entendu qu'il s'agit là d'une connexion ultérieure à ladite connexion initiale.
Le cinquième mode de mise en œuvre de la figure 10 a été décrit en considérant que le paramètre de communication modifié par le point d'accès 120, lorsqu'il exécute le processus de protection qui lui est dédié, correspond à son adresse matérielle initiale MAC_2 (modification de MAC_2 en MAC_4)· Le procédé de défense n'est toutefois pas limité à une telle modification. A titre d'exemple nullement limitatif, un paramètre de communication modifié par le point d'accès 120 peut correspondre à l'un quelconque des paramètres de communication parmi :
- un identifiant unique dudit point d'accès 120, comme par exemple l'adresse matérielle MAC_2 de ce dernier, un identifiant de type BSSID (« Basic Service Set Identifier » en anglais), un identifiant de type ESSID (« Extended Service Set Identifier » en anglais), etc. ; et/ou
- le canal de communication CAN associé à ladite connexion initiale. Par exemple, dans le cas d'un réseau local Wi-Fi exploitant la bande fréquentielle 2,4 GHz, il existe treize canaux exploitables, le canal CAN faisant partie desdits treize canaux ; et/ou
- un identifiant du réseau de communication, comme par exemple un identifiant de type « SSID » (acronyme de l'expression anglaise « Service Set Identifier ») ; et/ou 25
- une donnée temporelle contenue dans des trames émises par ledit point d'accès 120, comme par exemple une indication de disponibilité (« uptime » en anglais ») contenue dans un en-tête se référant à un horodatage de type BSS (« BSS timestamp » en anglais, où « BSS » correspond à l'acronyme de l'expression anglaise « Basic Service Cet ») ; et/ou
- une puissance émettrice dudit point d'accès 120, et/ou
- une fréquence de saut de type « FH » (acronyme de l'expression anglaise « Frequency Hopping »).
Rien n'exclut d'envisager, suivant d'autres exemples non détaillés ici, encore d'autres paramètre de communication susceptibles d'être modifiés dans le cadre du processus de protection exécuté par le point d'accès 120 (numéro de série ou « serial number » en anglais, nom de modèle ou « model name » en anglais, etc.).
De plus, aucune limitation n'est attachée au nombre de paramètres de communication pouvant être modifiés par le point d'accès 120 lors d'une même exécution du processus de protection, en particulier parmi ceux cités ci-avant. Préférentiellement, un identifiant unique et/ou le canal de communication CAN sont modifiés en priorité, car cela permet d'accroitre la sécurité de la connexion existante (ou d'une future connexion le cas échéant) entre le point d'accès 120 et le dispositif client 110. On note que ces dispositions se combinent en outre au fait que l'adresse matérielle du dispositif client 110 peut également être modifiée dans le cadre de l'exécution du processus de protection dédié audit dispositif client 110.
Le cinquième mode de mise en œuvre de la figure 10 a également été décrit en considérant que l'émetteur du message MESS_DEF est le point d'accès 120. Bien entendu, il est aussi possible d'envisager que ce rôle d'émetteur soit joué par le dispositif client 110.
Il faut aussi noter que la mise en œuvre de deux processus de protection, par respectivement le point d'accès 120 et le dispositif client 110, ne constitue qu'une variante d'implémentation de l'invention. Ainsi, rien n'exclut d'envisager des modes dans lequel une seule desdites deux entités 110, 120 exécute un processus de protection. D'ailleurs, il est possible d'envisager l'exécution d'un processus de protection par une seule des deux entités 110, 120 :
- lorsqu'une tentative de déconnexion malveillante vise les deux entités 110, 120, ou
- lorsqu'une tentative de déconnexion malveillante vise une seule desdites deux entités 110, 120, étant entendu que l'unique entité 110, 120 exécutant un processus de protection peut correspondre ou non à l'unique entité attaquée.
Par exemple, si le dispositif client 110 est le seul attaqué et détecte cette attaque, il peut lui-même exécuter un processus de protection, ce processus de protection ayant été par exemple transmis par le point d'accès 120 via un message similaire au message MESS_DEF mentionné ci-avant. Ces dispositions sont transposables de manière symétrique au cas où le point d'accès 120 est le seul 26 attaqué, détecte cette attaque, et exécute un processus de protection transmis par le dispositif client 110.
En alternative, si le dispositif client 110 est le seul attaqué et détecte cette attaque, un processus de protection peut être exécuté par le point d'accès 120 après que le dispositif client 110 ait averti ledit point d'accès 120, par exemple au moyen d'un message d'alerte idoine. On comprend que, dans cette alternative, l'architecture matérielle du dispositif client 110 diffère de celle décrite ci- avant en référence à la figure 3, et que le dispositif client 110 comporte dès lors un module de réception, un module d'évaluation et aucun module d'exécution (ou bien un module d'exécution qui reste ici inactif). Par contre, le point d'accès 120 comporte quant à lui un module d'exécution configuré pour exécuter, sur réception dudit message d'alerte, le processus de protection qui lui est associé. Là encore, ces dispositions sont transposables au cas où le point d'accès 120 est le seul attaqué, détecte cette attaque, et le dispositif client 110 exécute un processus de protection après avoir été averti par le point d'accès 120.
En résumé, au sens de la présente invention, ce qui importe avant tout est qu'au moins une desdites deux entités 110, 120 (idéalement les deux entités 110, 120) soit en mesure de détecter une tentative de déconnexion malveillante qui la vise, et que, suite à une détection d'attaque, au moins une desdites deux entités 110, 120 soit en mesure d'exécuter un processus de protection, de sorte à maintenir une connexion entre lesdites deux entités 110, 120.
Il est à noter qu'encore d'autres modes de mises en œuvre du procédé défense (non illustrés sur les figures) peuvent être envisagés, notamment en termes d'exécution de processus de protection. De tels autres modes sont combinables (selon toutes combinaisons techniquement possibles) avec les modes décrits jusqu'à présent.
Ainsi, dans un autre mode particulier de mise en œuvre, chacune desdites deux entités 110, 120 exécute un processus de protection (étant entendu que lesdites deux entités 110, 120 sont attaquées ou bien une seule desdites deux entités est attaquée), et chaque processus de protection exécuté par une entité 110, 120 comporte une inversion de rôle avec l'autre entité 110, 120. De cette manière, le point d'accès 120 est configuré en tant que (i.e. joue un rôle de) dispositif client, et le dispositif client 110 est configuré en tant que (i.e. joue un rôle de) point d'accès.
Selon encore un autre mode de mise en œuvre, si au moins un critère est satisfait pour le dispositif client 110 uniquement (respectivement le point d'accès 120 uniquement), un processus de protection est exécuté par ledit dispositif client 110 (respectivement par ledit point d'accès 120) et consiste à ignorer la ou les requêtes de déconnexion reçues. Autrement, dans ce mode, le dispositif client 110 (respectivement le point d'accès 120) ne modifie aucun paramètre de communication, de sorte à pouvoir continuer à communiquer « normalement » avec le point 27 d'accès 120 (respectivement avec le dispositif client 110). Par « normalement », on fait référence au fait que l'attaque détectée est ignorée.
Selon encore un autre mode particulier de mise en œuvre, si au moins un critère est satisfait pour chacune desdites deux entités 110, 120, un processus de protection est exécuté par chacune desdites deux entités 110, 120 et consiste à ignorer la ou les requêtes de déconnexion reçues. Ce mode repose donc sur des bases similaires à celles évoquées dans le mode précédent, à la différence que cette fois-ci les deux entités 110, 120 du système 100 sont attaquées et ignorent toutes les deux les requêtes de déconnexion qu'elles reçoivent.
Encore d'autres variantes restent envisageables, comme par exemple maintenir plusieurs connexions entre le dispositif client 110 et le point d'accès 120 une fois qu'une attaque a été détectée, de sorte à augmenter la difficulté de réalisation d'une attaque pour l'attaquant ATT, ou bien encore que le dispositif client 110 et/ou le point d'accès émettent des trames volontairement erronées de sorte à désorienter l'attaquant ATT.
On note par ailleurs que l'invention a été décrite jusqu'à présent en considérant que lorsqu'un processus de protection est exécuté par une entité 110, 120, cette exécution n'a lieu qu'une seule fois. L'invention n'est toutefois pas limitée par de telles dispositions. A cet effet, il est possible d'envisager que l'exécution d'un processus de protection soit itérée, par exemple de manière périodique au sein d'une même session de communication. Le fait d'itérer un processus de protection (par exemple en modifiant de manière régulière au moins un paramètre de communication et/ou en réalisant de manière régulière une inversion de rôle) permet de consolider la défense pouvant être mise en œuvre par le système 100, et in fine améliorer la sécurité de la connexion entre le dispositif client 110 et le point d'accès 120.
Enfin, l'invention a aussi été décrite jusqu'à présent en considérant qu'aucune desdites deux entités 110, 120 n'est configurée de manière logicielle et matérielle pour mettre en œuvre une protection PMF. De cette manière, la solution proposée par l'invention est particulièrement simple à implémenter, le firmware des cartes Wi-Fi équipant les deux entités 110, 120 ne nécessitant pas d'être modifié. L'invention n'en reste pas moins applicable, au prix d'une implémentation technique plus complexe, dans les cas où au moins une entité 110, 120 du système 100 peut mettre en œuvre une protection PMF (étant entendu qu'une entité apte à mettre en œuvre une protection PMF ne peut pas l'activer si l'autre entité n'est pas en mesure de gérer cette protection PMF).

Claims

28 Revendications
1. Procédé de défense contre une tentative de déconnexion entre deux entités correspondant à un point d'accès réseau (120) et un dispositif client (110), ledit procédé comportant, après l'établissement d'une connexion initiale entre lesdites deux entités pour échanger des données sur un canal de communication (CAN) conformément à un protocole de communication déterminé, un ensemble d'étapes mises en œuvre par une ou bien chacune desdites deux entités, ledit ensemble d'étapes comprenant :
- une réception (E10, E20) d'un ensemble de requêtes de déconnexion (ENS_1, ENS_2),
- une évaluation (E30, E40) d'au moins un critère (CRIT1 J, CRIT2J) défini à partir d'une métrique basée sur ledit ensemble de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante, ledit procédé comportant en outre, si au moins un critère est satisfait pour au moins une desdites deux entités, une étape d'exécution (E50, E60), par au moins une desdites deux entités, d'un processus de protection contre ladite tentative de déconnexion malveillante, de sorte à maintenir une connexion entre lesdites deux entités.
2. Procédé selon la revendication 1, dans lequel une métrique (MET1_1) correspond au débit de réception (DEB_RX) des requêtes appartenant à l'ensemble de requêtes (ENS_1) reçu par une entité, le critère (CRIT1_1) associé à ladite métrique étant satisfait si ledit débit de réception est supérieur à un seuil donné (Sl_l).
3. Procédé selon l'une quelconque des revendications 1 à 2, dans lequel une métrique (MET1_2) correspond au niveau de puissance en réception des requêtes appartenant à l'ensemble de requêtes (ENS_1) reçu par une entité, dit « niveau de déconnexion » (RSSI_DEC), le critère (CRIT1_2) associé à ladite métrique étant satisfait si l'écart entre ledit niveau de déconnexion et le niveau de puissance en réception de trames de données valides reçues par ladite entité antérieurement à la réception dudit ensemble de requêtes est, en valeur absolue et pendant une durée déterminée, supérieur à un seuil donné (Sl_2).
4. Procédé selon l'une quelconque des revendications 1 à 3, ledit procédé comportant en outre, lorsque le débit de réception (DEB_RX) des requêtes appartenant à l'ensemble de requêtes (ENS_1) reçu par une desdites deux entités, dite « première entité », a atteint un premier seuil donné (Sl_3), des étapes mises en œuvre par ladite première entité et comprenant :
- une activation (Eli) d'un mode moniteur,
- une surveillance (E12) du trafic réseau sur ledit canal de communication, de sorte à pouvoir détecter au moins une requête de déconnexion, dite « requête falsifiée », émise par une source 29 usurpant l'identité de ladite première identité et destinée à l'autre desdites deux entités, dite « deuxième entité », et dans lequel une métrique (MET1_3) correspond au nombre (N_FAL) ou au débit de requêtes falsifiées détectées par ladite première entité, le critère (CRIT1_3) associé à ladite métrique étant satisfait si ledit nombre ou ledit débit est supérieur à un deuxième seuil donné (Sl_4).
5. Procédé selon l'une quelconque des revendications 1 à 4, ledit procédé comportant en outre, lorsque le débit de réception (DEB_RX) des requêtes appartenant à l'ensemble de requêtes (ENS_1) reçu par une desdites deux entités, dite « première entité », a atteint un premier seuil donné (Sl_5), des étapes mises en œuvre par ladite première entité et comprenant :
- une activation (Eli) d'un mode moniteur,
- une surveillance (E12) du trafic réseau sur ledit canal de communication, de sorte à pouvoir détecter au moins un paquet de données valide émis par l'autre desdites deux entités, dite
« deuxième entité », et destiné à ladite première entité, et dans lequel une métrique (MET1_4) correspond au débit de paquets de données valides (DEB_VAL) détectés par ladite première entité, le critère (CRIT1_4) associé à ladite métrique étant satisfait si ledit débit est supérieur à un deuxième seuil donné (Sl_6).
6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel un processus de protection exécuté par une entité comporte une modification d'au moins un paramètre de communication utilisé par l'une desdites deux entités pour transmettre des données après l'établissement de ladite connexion initiale.
7. Procédé selon la revendication 6, dans lequel un processus de protection est exécuté par le dispositif client (110), un paramètre modifié correspondant à un identifiant unique (MAC_1) dudit dispositif client.
8. Procédé selon l'une quelconque des revendications 6 et 7, dans lequel un processus de protection est exécuté par le point d'accès (120), au moins un paramètre modifié correspondant :
- à un identifiant unique (MAC_2) dudit point d'accès, et/ou
- au canal de communication (CAN) associé à ladite connexion initiale, et/ou
- à un identifiant du réseau de communication, et/ou
- à une donnée temporelle contenue dans des trames émises par ledit point d'accès, et/ou
- à une puissance émettrice dudit point d'accès, et/ou
- à une fréquence de saut.
9. Procédé selon l'une quelconque des revendications 1 à 8, dans lequel chacune desdites deux entités exécute un processus de protection comportant une inversion de rôle, de sorte que le point 30 d'accès (120) soit configuré en tant que dispositif client, et que le dispositif client (110) soit configuré en tant que point d'accès.
10. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel :
- si au moins un critère est satisfait pour une entité uniquement, un processus de protection est exécuté par ladite entité et consiste à ignorer la ou les requêtes de déconnexion reçues, ou
- si au moins un critère est satisfait pour chacune desdites deux entités, un processus de protection est exécuté par chacune desdites deux entités et consiste à ignorer la ou les requêtes de déconnexion reçues.
11. Procédé selon l'une quelconque des revendications 1 à 10, dans lequel l'exécution d'un processus de protection est itérée.
12. Programme d'ordinateur comportant des instructions pour la mise en œuvre d'étapes de réception, d'évaluation et d'exécution d'un procédé de défense selon l'une quelconque des revendications 1 à 11 lorsque ledit programme est exécuté par un ordinateur.
13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur selon la revendication 12.
14. Entité (110, 120), dite « première entité », apte à être connectée à une autre entité (110,
120), dite « deuxième entité », pour échanger des données sur un canal de communication (CAN) conformément à un protocole de communication déterminé, ladite première entité comportant :
- un module de réception (MOD_REX_l, MOD_REX_2) configuré pour recevoir, après qu'une connexion ait été établie entre lesdites première et deuxième entités, un ensemble de requêtes de déconnexion (ENS_1, ENS_2),
- un module d'évaluation (MOD_EVAL_l, MOD_EVAL_2) configuré pour évaluer au moins un critère (CRIT1 J, CRIT2J) défini à partir d'une métrique basée sur ledit ensemble de requêtes ou bien sur au moins une autre requête de déconnexion reçue après la réception dudit ensemble de requêtes, de sorte à permettre la détection d'une tentative de déconnexion malveillante.
15. Système (100) pour la défense contre une tentative de déconnexion entre deux entités correspondant à un point d'accès réseau (120) et un dispositif client (110), lesdites entités étant aptes à être connectées entre elles pour échanger des données sur un canal de communication (CAN) conformément à un protocole de communication déterminé, et dans lequel :
- ledit point d'accès est conforme à la revendication 14 et/ou ledit dispositif client est conforme à la revendication 14,
- au moins une desdites deux entités comporte un module d'exécution (MOD_EXEC_l, 31
MOD_EXEC_2) configuré pour exécuter, si au moins un critère (CRIT1J, CRIT2J) est satisfait pour au moins une desdites deux entités, un processus de protection contre ladite tentative de déconnexion malveillante, de sorte à maintenir une connexion entre le point d'accès et le dispositif client.
EP22726270.6A 2021-05-10 2022-05-09 Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe Pending EP4338375A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2104907A FR3122796A1 (fr) 2021-05-10 2021-05-10 Procédé de défense contre une tentative de déconnexion entre deux entités, système associé
PCT/FR2022/050877 WO2022238644A1 (fr) 2021-05-10 2022-05-09 Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe

Publications (1)

Publication Number Publication Date
EP4338375A1 true EP4338375A1 (fr) 2024-03-20

Family

ID=76601402

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22726270.6A Pending EP4338375A1 (fr) 2021-05-10 2022-05-09 Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe

Country Status (5)

Country Link
US (1) US20240244076A1 (fr)
EP (1) EP4338375A1 (fr)
CN (1) CN117296296A (fr)
FR (1) FR3122796A1 (fr)
WO (1) WO2022238644A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7971253B1 (en) * 2006-11-21 2011-06-28 Airtight Networks, Inc. Method and system for detecting address rotation and related events in communication networks
US10243974B2 (en) * 2016-02-19 2019-03-26 Hewlett Packard Enterprise Development Lp Detecting deauthentication and disassociation attack in wireless local area networks
CN106658484A (zh) * 2016-11-15 2017-05-10 乐视控股（北京）有限公司 防无线网络攻击的方法、终端和无线接入点

Also Published As

Publication number Publication date
CN117296296A (zh) 2023-12-26
US20240244076A1 (en) 2024-07-18
WO2022238644A1 (fr) 2022-11-17
FR3122796A1 (fr) 2022-11-11

Similar Documents

Publication Publication Date Title
FR2872983A1 (fr) Systeme de pare-feu protegeant une communaute d'appareils, appareil participant au systeme et methode de mise a jour des regles de pare-feu au sein du systeme
EP3122061A1 (fr) Transmission de données chiffrées depuis des compteurs électriques intelligents
EP3386162A1 (fr) Communication sécurisée de bout en bout pour capteur mobile dans un réseau iot
WO2009115755A2 (fr) Procédé d'authentification, système d'authentification, terminal serveur, terminal client et programmes d'ordinateur correspondants
EP2294850B1 (fr) Procede pour securiser des echanges entre un noeud demandeur et un noeud destinataire
EP3991391A1 (fr) Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
EP3695571B1 (fr) Dispositif et procédé de transmission de données
FR3118383A1 (fr) Procédé d’apprentissage collaboratif entre une pluralité de nœuds d’un réseau d’un modèle de détection d’anomalies
EP2186252A2 (fr) Procede de distribution de cles cryptographiques dans un reseau de communication
EP4222994A1 (fr) Procedes de configuration d'un equipement utilisateur, de negociation avec une entite du reseau, et de gestion d'une connexion, et dispositifs associes
EP1849261A1 (fr) Procede, dispositif et programme de detection d'usurpation d'adresse dans un reseau sans fil
WO2022238644A1 (fr) Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe
EP4133707A1 (fr) Procede mis en oeuvre par une entite intermediaire pour gerer une communication entre deux dispositifs de communication
EP3530036B1 (fr) Procédé d'appairage auprès d'une passerelle
CA3153796A1 (fr) Procede de connexion d'un noeud de communication, et noeud de communication correspondant
FR3093833A1 (fr) Procédé d’optimisation d’échanges de données dans une infrastructure d’objets connectés
EP3747238B1 (fr) Agrégation d'une pluralité de connexions radio dans un réseau sans fil
EP1867132B1 (fr) Procede et dispositifs de controle de presence d'un terminal sur un point d'acces a un reseau de telephonie
WO2024105111A1 (fr) Procédé de distribution de clefs de session dans un réseau de télécommunication, procédés associés de traitement dans un client et un serveur, module client et serveurs associés
FR3116978A1 (fr) Contrôle d’accès à un réseau de communication local, et passerelle d’accès mettant en œuvre un tel contrôle
WO2022117941A1 (fr) Procédé de détection d'un équipement malveillant dans un réseau de communication, équipement de communication et programme d'ordinateur correspondants
EP4068818A1 (fr) Procédé de gestion de sécurité dans un système de communication de données, et système pour la mise en oeuvre du procédé
EP3970336A1 (fr) Procede de gestion d'une information de securite dans un reseau de communication, dispositif, equipement d'acces audit reseau et programmes d'ordinateur correspondants
FR3100685A1 (fr) Procédé de communication sans-fil entre un objet client et un objet serveur
FR2924294A1 (fr) Procede de transmission et systeme de telecommunications

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231129

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)