FILTERING ACCESS TO AN OBJECT CONNECTED TO A LOCAL COMMUNICATION NETWORK

Description

technical field

[0001] The field of the invention is that of local communication networks, such as enterprise communication networks or home communication networks. More specifically, the invention relates to the interaction, with such local communication networks, of communicating or connected objects, or IoT (for the English "Internet of Things", in French "Internet des Objets"), such as computers, tablets, smartphones, but also webcams, weather stations, sensors, thermostats, drones, smoke detectors, connected light bulbs, etc. Previous art

[0002] Such connected devices are becoming increasingly prevalent in the daily lives of users and businesses. While these devices provide users with access to exciting new services, they also exacerbate the vulnerabilities of the communication networks in which they are integrated, thereby increasing the attack surface for potentially malicious individuals or systems targeting these networks.

[0003] One of the key moments when a local communication network is vulnerable is when a new object is paired with that local network, especially when it uses a wireless communication technology, such as Wi-Fi ®< or the communication protocol defined in the IEEE 802.15.4 standard, also called "Thread".

[0004] Indeed, during this pairing step, the user sends the newly connected device the information necessary for its connection to the local communication network and to the wider Internet-type communication network to which it provides access. This information includes, for example: The name of the local communication network (or SSID for "Service Set Identifier" in the case of a Wi-Fi ®< network) and the password to access this network; Some information related to the user's account (for example, the identifier of their Google ®<, Amazon ®< or Apple ®< account); Some technical information, such as the time configuration, a private cryptography key, or an operational security certificate, as offered in the Matter ®< connectivity protocol supported by the "Connectivity Standards Alliance" (CSA) group of companies.

[0005] This is the principle, for example, of the AllJoyn® protocol, which offers an "Onboarding Service", allowing new equipment to easily join an existing WiFi® communication network, as illustrated in relation to the [ Fig.1 ].

[0006] We consider a connected object, or IoT, 11, in this case a connected light bulb, for example of the LIFX® brand. A local communication network, for example home, is accessible via a residential gateway (or Home Gateway HGW) 10. This network can include various connected objects or equipment, such as a laptop, a tablet, and a smartphone 12.

[0007] According to the AllJoyn®< “Onboarding Service”, a device wishing to pair with this local communication network must publish a network, that is, create a WiFi®< access point, whose SSID (Service Set Identifier, in accordance with the IEEE 802.11 standard) contains an AJ_ prefix or a _AJ suffix. This access point can be secure or open. This corresponds to a preliminary step E1, not shown on the [ Fig.1 For example, the connected bulb 11 publishes a WiFi ®< network "Lifi-A0_AJ".

[0008] In parallel, a user must launch, for example with their smartphone 12, a dedicated "onboarding" service application. Upon launching this application, the smartphone 12 disables its Wi-Fi® connection with the HGW 10 home gateway (step E2) in order to listen for connected devices awaiting pairing. During step E3, it connects to the access point created by the smart bulb 11 and sends the bulb the data necessary for pairing with the HGW 10 home gateway, namely a Wi-Fi® key and the gateway password. This data is entered, for example, by the user on the smartphone 12's communication interface. It may also have been previously stored on the device. These AllJoyn® exchanges are encrypted but not authenticated.

[0009] Upon receipt, the connected bulb 11 can, during an E4 step, connect to the HGW 10 residential gateway, using this pairing data.

[0010] At the end of this pairing phase, the smartphone 12 can then disconnect from the WiFi ®< network “Lifi-A0_AJ”, to reconnect to the local communication network of the residential gateway HGW 10.

[0011] This solution requires user intervention, who must take an active step to launch the "Onboarding Service" application, in order to authorize their smartphone to scan for any AllJoyn ®< networks that may be present and to disconnect the WiFi ®< connection with the residential gateway.

[0012] It is not very secure, since it does not implement verification of the authenticity of the communicating object to be paired: there is therefore a risk that the mobile phone 12 will transmit confidential pairing data to a malicious communicating object.

[0013] More generally, and regardless of the implementation of the AllJoyn® protocol or any other alternative connection protocol, this pairing step is crucial because it can jeopardize user privacy and / or the security of their local communication network, for two main reasons: On the one hand, if this pairing step fails in terms of securing the exchanges, sensitive data and information can be transmitted unencrypted between the user and the connected device. This data can then be easily accessed by a malicious third party, who can use it for fraudulent purposes. On the other hand, even if this pairing step is correctly carried out, in compliance with strict confidentiality rules, the existence of vulnerabilities or security flaws in the connected device can also make this sensitive data accessible to a malicious third party.

[0014] Indeed, some connected devices have a low level of security, or send user data to third-party platforms without their consent.

[0015] To date, the pairing procedure recommended by manufacturers of connected objects generally does not include security measures: the user is simply invited to download the manufacturer's application of the connected object on their smartphone or tablet, and to follow the proposed pairing procedure, which consists of a direct exchange of various data between the connected object and the user's terminal.

[0016] The main reasons for this lack of security measures are twofold: firstly, manufacturers generally believe that the connected devices they sell, and the pairing application they offer, present no security issues or breaches of user privacy; if such problems exist, they are usually unaware of them. Secondly, manufacturers generally want to maintain control over their ecosystem, i.e., all the connected devices and equipment they sell that communicate with each other, and are reluctant to introduce a third-party security mechanism or equipment.

[0017] Therefore, there is a need for a technique to secure the pairing of a connected object to a local communication network. This technique must strengthen the security of the local communication network, regardless of any potential vulnerabilities in the connected object, while respecting the privacy of network users and the confidentiality of their personal information. Specifically, there is a need for such a technique to filter access for connected objects to a local communication network, based on their potential vulnerabilities. There is also a need for such a technique to be easily implemented with the deployment of the Matter® standard. Finally, there is a need for such a technique to have a minimal impact on the user experience compared to existing solutions.Finally, there is a need for such a technique that allows connected objects to be connected to a secure ecosystem, such as that of the local communication network access provider.

[0018] It should be noted that, by ecosystem, we mean here, and throughout the rest of this document, a set of equipment which share common parameters of security and / or respect for privacy and / or eco-design, and which are able to communicate with each other.

[0019] Throughout this document, pairing of a connected object means both pairing the object to a local communication network (to communicate with other equipment on the local network or to the wide area network Internet), and a commissioning request in an application ecosystem (for example a "Fabric" according to the Matter® protocol).

[0020] Document EP2922328 discloses a method for pairing a TER-V terminal to a local network (access to which is managed by a residential gateway TER-1) by delegating pairing authorization to a trusted TER-2 terminal (typically a smartphone) already connected to the local network. Description of the invention

[0021] The invention is defined by the claims.

[0022] The invention addresses this need by proposing a method for filtering access to an object connected to a local communication network, implemented by a local network routing device, which includes the following steps: detection of a connected object awaiting pairing within the local network; assignment of a trust score to the connected object, based on information relating to the connected object; notification, to at least one trusted device on the local network, of the pairing request of the connected object and the assigned trust score; upon receipt of a pairing refusal from the trusted device, blocking access of the connected object to the local network.

[0023] Thus, the invention is based on a completely new and inventive approach to pairing a connected object with a local communication network.

[0024] Indeed, the invention proposes, on the one hand, to involve a local network routing equipment in the pairing procedure which, according to the prior art, is set up directly between the connected object and the user's terminal, and on the other hand, to assign a trust score to the connected object, so as to allow an informed choice by the user regarding the authorization of this connected object to access the network.

[0025] Such an intelligent network access filtering mechanism has the advantage of being easily implemented with the deployment of the Matter® standard, which standardizes pairing commands. It should be noted that Matter® is designed to connect IPv6 devices using Ethernet, Wi-Fi®, or Thread® protocols at the link layer.

[0026] Furthermore, this solution does not impact the user experience, but improves the protection of their privacy, as well as the security of their network, by allowing the blocking of network access from potentially dangerous equipment.

[0027] Furthermore, it is quick to implement: as soon as it detects the presence of a connected object awaiting pairing, the routing equipment can execute the various steps, and this is faster than the time it takes a user to download the connected object manufacturer's application on their smartphone or tablet and launch a standard, direct pairing procedure. This ensures that the routing equipment can implement this secure pairing procedure, instead of the standard pairing procedure offered by the IoT manufacturer.

[0028] In addition, the routing equipment can advantageously support several communication protocols (Wi-Fi ®< , Bluetooth ®< , Ethernet...), and therefore detect the pairing attempt of a new IoT, regardless of the communication protocol it uses.

[0029] According to a first feature of the invention, information relating to the connected object is received from the connected object and / or obtained by the routing equipment on a request addressed to a remote server.

[0030] Indeed, some information can be received directly from the connected device by the routing equipment, as it is transmitted by the device during its pairing attempt. Other information can be retrieved by the routing equipment at the IP (Internet Protocol) level, for example, from a certificate on a web server, which may contain interesting information about the connected device and useful for determining its trust score.

[0031] For example, such information relating to the connected object belongs to the group including: a MAC address of the connected object; a signal strength received from the connected object; a connection identifier of the connected object; a product identifier of the connected object; a manufacturer identifier of the connected object; a validity period of a security certificate associated with the connected object; a security level of a security certificate associated with the connected object; an identifier of the organization that issued a security certificate associated with the connected object.

[0032] According to another feature of the invention, the assigned confidence score results from an aggregation of at least some of the elements belonging to the group comprising: a vulnerability score of the connected object; a score of respect for the privacy of a user of the connected object; an eco-design score of the connected object.

[0033] Indeed, the assigned trust score can take into account the evaluation of various aspects of the connected device's strengths and weaknesses, in the areas of security and resistance to malicious attacks, respect for user privacy, and also the connected device's environmental impact. Other aspects could also be considered, such as the manufacturer's corporate social responsibility, etc.

[0034] To facilitate the user's decision-making regarding whether or not to block the connected device's access to the network, it is advantageous to aggregate these various assessments into a single trust score, which is then transmitted to the user's trusted device. This trust score could, for example, be a value chosen from the triplet "good, medium, bad," or a color chosen from the palette "green, yellow, red." The user can then quickly make an informed decision, based on this simple and accessible trust score, regarding whether or not to allow the connected device to pair with their local communication network.

[0035] According to one aspect, the trusted device to which the pairing request is notified is the trusted device closest to the connected object and / or a trusted device belonging to a local network administrator.

[0036] For example, the closest trusted device to the connected object is identified based on the RSSI (Received Signal Strength Indicator, which represents the strength of the received signal). It is indeed particularly convenient for the user to receive the pairing request on a device close to the connected object they are installing, which is highly likely to be their personal smartphone.

[0037] Alternatively, the pairing request is notified to a trusted device of the network administrator, for example the parents in the case of a home network, who can thus control the installation of new connected objects by the children, and object to it if necessary.

[0038] According to an optional variant, such an access filtering process also includes: an emission, to the trusted equipment, of a request to obtain a code associated with the connected object; a connection of the routing equipment, from the code obtained from the trusted equipment, to the connected object, in order to obtain information relating to the connected object.

[0039] For example, the request to obtain a code is a request to scan a QR code associated with the connected object, and the scanned QR code is received by the routing equipment from the trusted equipment.

[0040] This effectively ensures that the user of the trusted device is located near the connected object, and further strengthens the security of the pairing process by preventing a malicious third party outside the local communication network from remotely taking control of a connected object. For example, in the case of a camera installed at Alice's home, this prevents a malicious neighbor, Bob, from detecting the camera's presence, pairing it with his own network, and then viewing, without authorization, what is happening at Alice's home.

[0041] According to another optional variant, following the pairing of the connected object with the routing equipment of the local communication network, it includes an emission, to the trusted equipment, of a request to pair the connected object with the trusted equipment, and, in the event of receiving a request to pair with the trusted equipment, an emission, to the connected object, of a request to open a pairing sequence.

[0042] Thus, after pairing the connected object with the local communication network (and therefore after connecting the object to an ecosystem which includes the routing equipment, e.g. that of the operator or the access provider), the routing equipment can ask the user if they want this connected object to join other ecosystems (for example, that of the manufacturer or seller of the connected object).

[0043] This solution allows users to use their connected devices in multiple secure environments: for example, that of their internet service provider, but also potentially those of third parties. This avoids locking connected devices into a single ecosystem.

[0044] In this case, as an option, if the connected object paired with the routing equipment is unable to also be paired with the trusted equipment, the routing equipment acts as a proxy server between the trusted equipment and the connected object.

[0045] This is advantageous in the case of a connected object which, due to its communication protocol, can only pair with one ecosystem at a time, because the proxy role played by the routing equipment allows this limitation to be bypassed. The trusted device then connects to the routing equipment, believing it to be the connected object, and the routing equipment acts as a transparent intermediary between the IoT and the trusted device.

[0046] One advantage of routing equipment is that it acts as an access gateway to the local communication network. The access provider, which owns the gateway, can therefore remain an intermediary between its customer and the various connected devices they use.

[0047] The invention also relates to a computer program product comprising program code instructions for implementing an access filtering method as described above, when executed by a processor.

[0048] The invention also relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of the access filtering process according to the invention as described above.

[0049] Such a recording medium can be any entity or device capable of storing the program. For example, the medium may include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a USB flash drive or a hard drive.

[0050] On the other hand, such a recording medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means, so that the computer program it contains can be executed remotely. The program according to the invention can, in particular, be uploaded to a network, for example, the Internet.

[0051] Alternatively, the 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 aforementioned access filtering process.

[0052] The invention further relates to routing equipment for a local communication network, which includes a processor configured to execute the following steps: detection of a connected object awaiting pairing within the local network; assignment of a trust score to the connected object, based on information relating to the connected object; notification, to a trusted device on the local network, of the pairing request of the connected object and the assigned trust score; upon receipt of a pairing refusal from the trusted device, blocking access of the connected object to the local network.

[0053] The invention further relates to a residential gateway that includes a processor configured to execute the following steps: detection of a connected object awaiting pairing within the local network; assignment of a trust score to the connected object, based on information relating to the connected object; notification, to a trusted device on the local network, of the pairing request of the connected object and the assigned trust score; upon receipt of a pairing refusal from the trusted device, blocking access of the connected object to the local network.

[0054] The aforementioned routing equipment, access gateway and corresponding computer program offer at least the same advantages as those conferred by the access filtering method according to the present invention. Presentation of the figures

[0055] Other objects, features and advantages of the invention will become more apparent upon reading the following description, given by way of simple illustration and not limitation, in relation to the figures, among which: [ Fig.1 ] illustrates a method for pairing a communicating object with a local communication network, implementing the prior art AllJoyn® Onboarding service; Fig. 2 ] presents a schematic view of a local communication network and the various communicating objects connected to it, according to an embodiment of the invention; [ Fig.3 ] presents in flowchart form the different stages of the access filtering process according to one embodiment of the invention; [ Fig. 4 ] presents a block diagram of a routing equipment implementing the [ Fig.3 ]. Detailed description of embodiments of the invention

[0056] The general principle of the invention is based on filtering the access of an object connected to a local communication network, by a routing equipment of this network, according to a decision of a user based on a confidence score assigned to the connected object by the routing equipment.

[0057] The remainder of this document focuses in more detail on describing the implementation of an embodiment of the invention within a home network, at a private user's premises, in which various devices form a star network around a central point, namely an access gateway, for example the Orange Livebox®. The invention is of course also applicable to any other type of local area network (LAN) to which a plurality of communication devices are connected.

[0058] Specifically, such a local network could have a Thread® mesh network structure, using a wireless radio protocol alternative to Wi-Fi®. It should be noted that Thread® technology is comparable to Zigbee®, but offers better performance in terms of energy consumption, is more robust, and is also easier to scale. In such a network, the access gateway, for example, the Orange® Livebox®, can act as a Thread® routing device. The following example of a star network organized around an access gateway can easily be extended to any other type of local network, and in particular a Thread® mesh network, in which the various stages of the access filtering process according to the invention are implemented by any one of the local network's routing devices.

[0059] In the domestic network schematically represented on the [ Fig. 2 A residential HGW gateway, model 10, allows a local communication network to be connected to a wide area network such as the Internet (not shown). Such an HGW 10 residential gateway integrates a DHCP server: it routes data packets on the network and can also act as a firewall, proxy, etc.

[0060] In the example of the [ Fig. 2 Many devices are present on the local network, namely: a connected light bulb 11; a smart phone (or “smartphone”) 12; a PC-type computer 13; a tablet 14; a weather station 15; a webcam 16; a thermostat 17; a laptop 18.

[0061] This list is by no means exhaustive, and many other communicating devices may be present on the user's local network. These communicating devices can be connected to the network via wired connections (Ethernet cable, USB port (Universal Serial Bus), etc.) or wirelessly (Wi-Fi, Bluetooth, Zigbee). They include all types of physical objects capable of communicating digitally on the local network for data exchange and that are compatible with the DHCP network. They also include software applications associated with certain non-IP (Internet Protocol) connected devices, operating on wireless technologies such as BLE (Bluetooth Low Energy), Z-Wave, Thread, etc.

[0062] Such communicating objects can be designated by the acronym IoT, for the English "Internet of Things", in French "Internet des objets".

[0063] We will look in more detail below at the attempt to pair these communicating objects on the user's local communication network, for example according to the WiFi ®< wireless radio transmission protocol.

[0064] We now present, in relation to the [ Fig.3 ], the different stages of the access filtering process for a referenced 16 IoT connected object (for example, the webcam of the [ Fig. 2 ]) to a local communication network according to an embodiment of the invention.

[0065] In this example, we assume that this process is implemented in an HGW access gateway referenced as 10, for example a Livebox ®< from Orange ®<.

[0066] We are interested in the arrival of the IoT connected object referenced 16 on the local network. When powered on, this connected object 16 enters pairing mode and broadcasts pairing requests to its surroundings. These requests can be carried, depending on the communication protocol embedded in the IoT 16, by a communication technology such as Wi-Fi®, Bluetooth®, or Ethernet, for example. This "advertising" phase is schematically represented as [ Fig.3 ] by the step referenced E51.

[0067] The HGW 10 residential gateway continuously detects (step E52) which objects are present around it. It is notably capable of detecting objects in pairing mode: at the Wi-Fi ®< level (for example in the Matter ®< standard, objects in pairing mode open an open access point Matter-xxx; in the proprietary Tuya ®< protocol, objects open an access point SmartLife-xxx); at the Bluetooth ®< level (for example, the object referenced 16 emits "advertising" packets with a specific name like DCS-xxx for D-Link ®< cameras); at the Ethernet level (for example, in the Matter standard, objects will emit specific mDNS queries).

[0068] During step E53, the HGW 10 gateway retrieves information about the IoT device 16 (for example, at the Wi-Fi radio layer: MAC address, SSID name, signal strength, etc.). Additionally, the HGW 10 gateway can also retrieve information at the IP layer if it is able to connect to the device. This information can, for example, be retrieved from a certificate located on a web server. This certificate may contain useful information such as the product ID of the connected device 16, the vendor ID of the connected device 16, the name of the issuing organization, the validity period, the security level, etc.

[0069] This information about the IoT device referenced as 16 can be retrieved directly from the device itself, or obtained from local and / or external sources. Based on the information thus collected, the HGW gateway 10 calculates, during a step referenced as E54, a trust score to be assigned to the device referenced as 16.

[0070] To do this, it can notably query remote or local databases to check if the manufacturer of the connected object 16, or the certificate associated with it, is "safe": Has the certificate been revoked? (Specifically, is it present on one or more Certificate Revocation Lists (CRLs), which are lists of digital certificates that have been revoked by the issuing Certificate Authority before their expected expiration date and are no longer considered trustworthy?) Is the certificate valid (for example, by querying the Matter® Distributed Compliance Ledger (DCL)?) The Matter DCL is a cryptographically secured, distributed storage network based on blockchain technology. It allows the Connectivity Standards Alliance (CSA) and authorized vendors to publish information about their Matter® devices. This information can then be retrieved using DCL clients.With all this device information stored in the DCL, Matter® ecosystems can consult the DCL to check the device's certification compliance status, or for example, obtain commissioning instructions, links to manuals, and product information.Does the product have any known public vulnerabilities (CVEs, for "Common Vulnerabilities and Exposures," which is a dictionary of publicly available information on security vulnerabilities, maintained by MITRE, an organization supported by the US Department of Homeland Security)? Does the manufacturer have a physical presence in Europe (which can be an important guarantee of compliance with the General Data Protection Regulation (GDPR), EU Regulation 2016 / 679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data); etc.

[0071] The HGW 10 gateway can also collect information on the manufacturing methods of the connected object 16: does it meet certain eco-design standards? has its manufacturer implemented a corporate social responsibility policy? what is its carbon footprint?

[0072] Based on the information received, the HGW 10 gateway assigns a trust score to the connected object referenced as 16. This score can take, for example, a value chosen from the triplet (low, medium, high), or a color chosen from the palette (red, yellow, green). This trust score aggregates, for example as a weighted average, the various scores obtained by the IoT connected object 16 in terms of security, privacy, eco-design, etc.

[0073] During step E55, the HGW gateway 10 transmits this trust score to at least one EQPT trust device 12, for example, the smartphone of the user who powered on the connected device 16, and / or that of the local network administrator, or an Orange TV set-top box. For the sake of simplicity, we will refer to a single EQPT trust device 12 hereafter; however, all the information below can be directly applied to cases where the HGW access gateway 10 is communicating with several distinct trust devices.

[0074] This trust score is transmitted in a notification that also asks the user to accept or reject the connection of this new object 16 to their local network. This notification may also ask the user if they want this object 16 to join the Orange trust ecosystem ("Fabric" in the Matter® standard; in this standard, "Fabric" refers to a logical collection of communicating nodes sharing a common root of trust and a common distributed configuration state). This notification, or "targeted advertising" (step E55), can be sent to the closest trusted device(s) to the referenced IoT device 16 (for example, using the RSSI, i.e., the signal strength received from the IoT device 16) or to the network administrators, for example, the "parents" in the case of a home network.The notification may contain a link to an Orange application and / or detailed information about the detected object referenced 16.

[0075] Depending on the decision of the user of the trusted equipment referenced 12, two situations may arise (ALT reference on the [ Fig.3 ]).

[0076] Based on the notification received at step E55 and its associated trust score, the user may decide to refuse to pair this new connected device with their local network because they deem it insufficiently trustworthy. In this case, the trusted EQPT device (reference 12) sends a refusal notification to the HGW gateway (reference 10) during step E56N.

[0077] This will most likely be the case if the trust score assigned by the HGW access gateway referenced 10 is "bad" or "red", but also, if the user is cautious, also in the case where the trust score is "medium" or "yellow".

[0078] During a step referenced E57N, the HGW 10 gateway then implements a blocking of access for the IoT object referenced 16 to the local communication network, or isolates it from the latter. To do this, the HGW 10 gateway can implement firewall rules using the IP address, or block the Wi-Fi connection using the MAC address, or not respond to DNS (Domain Name Server) queries, etc.

[0079] Alternatively, based on the notification received at step E55 and its associated trust score, the user can decide to pair this new connected device with their local network because they believe it can be trusted sufficiently. In this case, the trusted EQPT device (reference 12) sends an acceptance notification to the HGW gateway (reference 10) during step E56Y.

[0080] This will likely be the case if the received confidence score is "good" or "green"; it may also be the case if the received confidence score is "orange" or "medium", and the user decides so.

[0081] During a step referenced E57Y, the HGW 10 access gateway then sends the connected object 16 all the configuration parameters it needs to connect to the local network, such as the SSID, the network password, data relating to the "Fabric" of the Orange ®< ecosystem, etc. During a step referenced E58Y, the IoT connected object referenced 16 can then connect to the HGW 10 gateway, and access all the resources of the local network and the "Fabric" of the Orange ®< ecosystem.

[0082] We also represented, on the [ Fig.3 ], two optional variants OPT1 and OPT2 which can be implemented jointly, or independently of each other.

[0083] The variant referenced as OPT1 comprises a set of steps referenced E61 to E66 and aims to enhance the reliability of assigning the trust score to the connected object 16. To achieve this, during a step referenced as E61, the HGW gateway 10 sends a code entry notification to the EQPT trust device referenced as 12. For example, the HGW gateway 10 may ask the user to scan a QR code present on the connected object referenced as 16, or to manually enter a code that will allow the HGW gateway 10 to connect to the connected object referenced as 16 to retrieve a certificate (for example, the "Device Attestation Certificate" in the Matter® standard).

[0084] The use of a QR code has several advantages. First of all, this step imposed on the user allows verification that they are indeed near the IoT connected object referenced 16. In addition, this QR code can contain various useful information, such as the Matter ®< certificate, but also the different “advertising” channels (Wi-Fi ®< , Bluetooth ®< ...) that the IoT connected object incorporates.

[0085] Thus, during a step referenced E62, the user uses the EQPT trusted equipment referenced 12 to scan the QR code present on the IoT connected object referenced 16. The information it contains is transmitted to the EQPT trusted equipment referenced 12 during a step referenced E63, then transferred during a step referenced E64 to the HGW access gateway referenced 10.

[0086] According to the Matter® standard, this QR code, printed on the IoT connected object referenced as 16, allows the user to obtain all the information necessary to configure the device. The QR code contains a base38-encoded binary code including the following values: Vendor ID Version Product ID Custom Feed Discovery Capabilities Discriminator Access Code Padding TLV Data (optional) (used to configure the custom feed).

[0087] During a step referenced E65, the HGW access gateway referenced 10 uses the received QR code to connect to the IoT connected object referenced 16. During a step referenced E66, the IoT connected object referenced 16 transmits advanced information to the HGW access gateway referenced 10, for example the Matter®< certificate.

[0088] The variant referenced OPT2, which may or may not be combined with the variant referenced OPT1, includes a set of steps referenced E71 to E75 and aims to extend the pairing of the IoT connected object referenced 16 to several ecosystems.

[0089] Indeed, once the IoT device referenced as 16 is connected to the Orange®< ecosystem (or "Fabric" in the Matter®< standard), the HGW access gateway referenced as 10 can ask the user if they want this device referenced as 16 to join other ecosystems or "Fabrics" (e.g., those of Amazon®<, Google®<, Apple®<, etc.). It's important to remember that Matter®< treats networks as shared resources: it does not stipulate ownership or exclusive access to networks. Consequently, it is possible to run several Matter networks, called "fabrics," on the same set of constituent networks.

[0090] Thus, during a step referenced E71, the HGW access gateway referenced 10 sends a notification to the EQPT trusted equipment referenced 12 asking it if a connection to a third-party ecosystem is desired.

[0091] In the event of a positive response from the EQPT trusted equipment referenced 12 during a step referenced E72, the HGW access gateway referenced 10 sends (step referenced E73), to the IoT connected object referenced 16, a request to open a new pairing procedure (for example, using the "Basic Commissioning Method" or "Enhanced Commissioning Method" procedure in Matter ®< , in French, "Basic Commissioning Method" or "Enhanced Commissioning Method").

[0092] During a step referenced E74, the IoT connected object referenced 16 then launches a new phase of "advertising" (in Wi-Fi ®< , in Bluetooth ®< , etc. depending on the communication channels at its disposal), aimed at the trusted EQPT equipment referenced 12. The latter, during a step referenced E75, sends back to it the configuration parameters necessary for it to join the chosen third-party ecosystem, for example the Amazon Fabric ®< .

[0093] It should be noted that, within the framework of this OPT2 variant, if the IoT connected object referenced 16 is not able to open a new pairing procedure (e.g. because its proprietary protocol does not allow it, for example the Tuya® protocol), the HGW access gateway referenced 10 can simulate the IoT connected object referenced 16 with the EQPT trusted equipment referenced 12, and play the role of a proxy server between these two devices.

[0094] We now present, in relation to the [ Fig. 4 ], the hardware structure of a routing device, for example a residential HGW gateway referenced 10, implementing the steps of the flowchart of the [ Fig.3 ], in any of its embodiments.

[0095] Such a residential gateway HGW 10 comprises a random access memory 33 (e.g., RAM), a processing unit 32 equipped, for example, with a processor, and controlled by a computer program stored in a read-only memory 31 (e.g., ROM or a hard drive). At initialization, the code instructions of the computer program are, for example, loaded into the random access memory 33 before being executed by the processor of the processing unit 32.

[0096] The term unit can refer to a software component as well as a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally to any element of a program capable of implementing a function or a set of functions.

[0097] RAM 33 contains, in particular, the information collected on the connected object referenced 16 during step E53, as well as the various parameters necessary for calculating the trust score, and the calculated trust score itself. The processor of the processing unit 32 manages the sending and receiving of the various notifications addressed to the EQPT trust device referenced 12 and to the IoT connected object referenced 16 according to the flowchart of the [ Fig.3 ], as well as the calculation of the confidence score during the step referenced E54.

[0098] There [ Fig. 4 ] illustrates only one particular way, among several possible ways, of implementing the HGW 10 residential gateway, so that it carries out the steps of the process detailed above, in relation to the [ Fig.3 ] (in any of the different embodiments, or in a combination of these embodiments). Indeed, these steps can be carried out interchangeably on a reprogrammable computing machine (a PC, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or an ASIC, or any other hardware module).

[0099] In the case where the HGW 10 residential gateway is made with a reprogrammable computing machine, the corresponding program (i.e. the sequence of instructions) may be stored in a removable storage medium (such as, for example, a floppy disk, a CD-ROM or a DVD-ROM) or not, this storage medium being readable partially or totally by a computer or a processor.

[0100] The different implementation methods have been described above in relation to a residential gateway of the Livebox ®< type, but can more generally be implemented in all Wi-Fi ®< or Thread ®< gateways, routers or access points (Wi-Fi ®< repeater, 4G access point...)

Claims

1. Method for filtering access of a connected object (16) to a local communication network, implemented by a routing equipment (10) of said local network, characterized in that it comprises steps of: - detecting (E52) a connected object (16) waiting for pairing within said local network; - assigning (E54) a confidence score to said connected object, based on information relating to said connected object; - providing notification (E55), to at least one trusted equipment (12) of said local network, of the pairing request of said connected object and of said assigned confidence score; - receiving a notification of pairing refusal (E56N) or of pairing acceptance (E56Y), from said at least one trusted equipment (12), established on the basis of said pairing request of said connected object and of said assigned confidence score; - if said received notification is a pairing refusal notification (E56N), blocking (E57N) an access of said connected object (16) to said local network; - if said received notification is a pairing acceptance notification (E56Y), transmitting to said connected object (16) a set of configuration parameters for connecting to said local network.

2. Access filtering method according to Claim 1, characterized in that said information relating to said connected object (16) is received (E53) from said connected object and / or obtained by said routing equipment upon request addressed to a remote server.

3. Access filtering method according to either one of Claims 1 and 2, characterized in that said information relating to said connected object belongs to the group containing: - a MAC address of said connected object; - a strength of a signal received from said connected object; - a connection identifier of said connected object; - a product identifier of said connected object; - a manufacturer identifier of said connected object; - a period of validity of a security certificate associated with said connected object; - a security level of a security certificate associated with said connected object; - an identifier of the organization that issued a security certificate associated with said connected object.

4. Access filtering method according to any one of Claims 1 to 3, characterized in that said assigned confidence score results from an aggregation of at least some of the elements belonging to the group containing: - a vulnerability score of said connected object; - a score of respect for the privacy of a user of said connected object; - an ecodesign score of said connected object.

5. Access filtering method according to any one of Claims 1 to 4, characterized in that said at least one trusted equipment to which said pairing request is notified is said trusted equipment closest to said connected object or a trusted equipment belonging to an administrator of said local network.

6. Access filtering method according to any one of Claims 1 to 5, characterized in that it also comprises: - sending (E61), to said at least one trusted equipment (12), a request to obtain a code associated with said connected object; - connecting (E65) said routing equipment, using said code obtained from said at least one trusted equipment, to said connected object, in order to obtain said information relating to said connected object.

7. Access filtering method according to Claim 6, characterized in that said request to obtain a code is a request to scan a QR-code associated with said connected object, and in that the scanned QR-code is received (E63) by said routing equipment from said at least one trusted equipment.

8. Access filtering method according to any one of Claims 1 to 7, characterized in that, when said received notification is a pairing acceptance notification (E56Y), at the end of pairing of said connected object with said routing equipment of said local communication network, it comprises sending (E71), to said at least one trusted equipment, an expression of a wish to pair said connected object with said at least one trusted equipment, and, in the event of receipt (E72) of a wish to pair with said at least one trusted equipment, sending (E73), to said connected object, a request to open a pairing sequence.

9. Access filtering method according to Claim 8, characterized in that, if said connected object paired with said routing equipment is unsuitable for also being paired with said at least one trusted equipment, said routing equipment acts as a proxy server between said at least one trusted equipment and said connected object.

10. Access filtering method according to any one of Claims 1 to 9, characterized in that said routing equipment is an access gateway to said local communication network.

11. Computer program product comprising program code instructions for implementing an access filtering method according to any one of Claims 1 to 10 when it is executed by a processor integrated into a routing equipment (10).

12. Routing equipment (10) of a local communication network, characterized in that it comprises a processor configured to execute steps of: - detecting (E52) a connected object (16) waiting for pairing within said local network; - assigning (E54) a confidence score to said connected object, based on information relating to said connected object; - providing notification (E55), to at least one trusted equipment (12) of said local network, of the pairing request of said connected object and of said assigned confidence score; - receiving a notification of pairing refusal (E56N) or of pairing acceptance (E56Y), from said at least one trusted equipment (12), established on the basis of said pairing request of said connected object and of said assigned confidence score; - if said received notification is a pairing refusal notification (E56N), blocking (E57N) an access of said connected object (16) to said local network; - if said received notification is a pairing acceptance notification (E56Y), transmitting to said connected object (16) a set of configuration parameters for connecting to said local network.

13. Residential gateway (HGW), characterized in that it comprises a processor configured to execute steps of: - detecting a connected object waiting for pairing within said local network; - assigning a confidence score to said connected object, based on information relating to said connected object; - providing notification, to at least one trusted equipment (12) of said local network, of the pairing request of said connected object and of said assigned confidence score; - receiving a notification of pairing refusal (E56N) or of pairing acceptance (E56Y), from said at least one trusted equipment, established on the basis of said pairing request of said connected object and of said assigned confidence score; - if said received notification is a pairing refusal notification (E56N), blocking (E57N) an access of said connected object (16) to said local network; - if said received notification is a pairing acceptance notification (E56Y), transmitting to said connected object (16) a set of configuration parameters for connecting to said local network.

14. Method for pairing a connected object (16) to a local communication network, implemented by a local communication system comprising a routing equipment (10) and at least one trusted equipment (12), characterized in that it comprises steps of: - said routing equipment (10) detecting (E52) a connected object (16) waiting for pairing within said local network; - said routing equipment (10) assigning (E54) a confidence score to said connected object, based on information relating to said connected object; - said routing equipment (10) providing notification (E55), to said at least one trusted equipment (12), of the pairing request of said connected object and of said assigned confidence score; - said at least one trusted equipment (12) sending a notification of pairing refusal (E56N) or of pairing acceptance (E56Y), established on the basis of said pairing request of said connected object and of said assigned confidence score; - said routing equipment (10) receiving said pairing refusal notification (E56N) or pairing acceptance notification (E56Y); - if said received notification is a pairing refusal notification (E56N), said routing equipment (10) blocking (E57N) an access of said connected object (16) to said local network; - if said received notification is a pairing acceptance notification (E56Y), said routing equipment (10) transmitting to said connected object (16) a set of configuration parameters for connecting to said local network.