Network security systems and methods using recurrent device attestation

Abstract

Some embodiments improve network security of an IoT device via cyclic re-authentication of a network node. The frequency of re-authentication may depend on the network roles of respective devices (e.g., routers and end nodes) and / or connection measurements (e.g., node degrees) of the respective nodes, where highly connected nodes are re-authenticated more frequently than the end nodes. Some embodiments employ a pebble ripple authentication procedure in which a management device transmits authentication probes to devices via one-to-one messaging (e.g., unicast), and the respective devices reply via one-to-many messaging (e.g., multicast). The management device then authenticates the identification and / or functionality of the respective device according to the timing of a plurality of replies from the authenticated device, each reply passing through the network via a distinct route.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202580006344.X (22) Application Date 2025.01.10 (30) Priority Data 63 / 624,895 2024.01.25 US 18 / 928,773 2024.10.28 US (85) PCT International Application Entering National Phase Date 2026.05.25 (86) PCT International Application Application Data PCT / EP2025 / 050537 2025.01.10 (87) PCT International Application Publication Data WO2025 / 157593 EN 2025.07.31 (71) Applicant: Bitvane Intellectual Property Management Ltd. Address: Nicosia, Cyprus (72) Inventors: B. Gunther, B. Senter, G.M. Trive (74) Patent Agency: Beijing Law Alliance Intellectual Property Agency Co., Ltd. 11287 Patent Attorney: Zhang Shijun (51) Int.Cl. H04W 12 / 065 (2006.01) H04L 9 / 40 (2006.01) (54) Invention Title: Network Security System and Method Using Cyclic Re-authentication (57) Abstract: Some embodiments improve the network security of IoT devices through cyclic re-authentication of network nodes. The frequency of re-authentication may depend on the network role of the corresponding device (e.g., router and terminal node) and / or the connectivity measurement (e.g., node degree) of the corresponding node, wherein highly connected nodes are re-authenticated more frequently than terminal nodes. Some embodiments employ a pebble ripple authentication procedure in which a management device sends authentication probes to the device via one-to-one messaging (e.g., unicast), and the corresponding device responds via one-to-many messaging (e.g., multicast). The management device then authenticates the identification and / or functionality of the corresponding device based on the timing of multiple responses from the authenticated device, each response traversing the network via a different route.Claims 2 pages, Description 14 pages, Drawings 8 pages, CN 122250088 A 2026.06.19 CN 1 22 25 00 88 A 1. A security device connected to a computer network interconnecting a plurality of client devices, the security device including at least one hardware processor configured to: perform cyclic authentication of a selected device among the plurality of client devices, wherein: the cyclic authentication includes a plurality of authentication sessions, each authentication session including message exchange between the security device and the selected device, and the length of a time interval between two consecutive sessions in the plurality of authentication sessions is determined based on a connectivity measurement of the selected device within the computer network; and in response to a failure of the cyclic authentication, determine whether the failure indicates a computer security threat. 2. The security device of claim 1, wherein the computer network includes a plurality of nodes interconnected by a plurality of edges, and wherein the connectivity measurement of the selected device is determined based on the node degree of a selected node among the plurality of nodes, the selected node including the selected device. 3. The security device of claim 2, wherein the length of the time interval is further constrained between a predetermined upper bound and a predetermined lower bound. 4. The security device of claim 2, wherein the length of the time interval is further determined according to: , where d represents the node degree of the selected node, dmin and dmax are predetermined lower and upper bounds of the node degree, respectively, and Tmin and Tmax are predetermined lower and upper bounds of the length of the time interval. 5. The security device of claim 1, wherein the connectivity measurement of the selected device is determined based on the count of devices among the plurality of client devices with which the selected device communicates via the computer network. 6. The security device of claim 1, wherein the connectivity measurement of the selected device is determined based on whether the selected device is configured to relay incoming communications to other devices among the plurality of client devices. 7. The security device of claim 1, wherein the connectivity measurement of the selected device is determined based on whether the selected device is battery powered. 8. The security device of claim 1, wherein the connectivity measurement of the selected device is determined based on whether the selected device is used to communicate with the selected device. 9. The security device of claim 1, wherein the length of the time interval is further determined based on whether the selected device includes a mobile computing device.10. The security device of claim 1, wherein the authentication session in the plurality of authentication sessions includes the security device sending an authentication probe to the selected device and determining whether the authentication session is successful based on the timing of a plurality of dissimilar examples of responses to the authentication probe, each dissimilar example of the response being received from the selected device via a dissimilar route traversing the computer network. 11. A computer-implemented method for protecting a plurality of client devices from a computer security threat, the plurality of client devices being interconnected by a computer network, the method comprising employing at least one hardware processor of a security device connected to the computer network to: perform cyclic authentication of a selected device among the plurality of client devices, wherein: the cyclic authentication comprises a plurality of authentication sessions, each authentication session comprising message exchange between the security device and the selected device, and the length of the time interval between two consecutive sessions in the plurality of authentication sessions is determined based on a connectivity measurement of the selected device within the computer network; and in response to a failure of the cyclic authentication, determining whether the failure indicates a computer security threat. 12. The method of claim 11, wherein the computer network comprises a plurality of nodes interconnected by a plurality of edges, and wherein the connectivity measurement of the selected device is determined based on the node degree of a selected node among the plurality of nodes, the selected node comprising the selected device. 13. The method of claim 12, wherein the length of the time interval is further constrained between a predetermined upper bound and a predetermined lower bound. 14. The method of claim 12, wherein the length of the time interval is further determined based on: , where d represents the node degree of the selected node, dmin and dmax are predetermined lower and upper bounds of the node degree, respectively, and Tmin and Tmax are predetermined lower and upper bounds of the length of the time interval. 15. The method of claim 11, wherein the connectivity measurement of the selected device is determined based on the count of devices among the plurality of client devices with which the selected device communicates via the computer network. 16. The method of claim 11, wherein the connectivity measurement of the selected device is determined based on whether the selected device is configured to relay incoming communications to other devices among the plurality of client devices. 17. The security device of claim 11, wherein the connectivity measurement of the selected device is determined based on whether the selected device is battery powered. 18. The method of claim 11, wherein the connectivity measurement of the selected device is determined based on the type of network protocol used to communicate with the selected device.19. The security device of claim 11, wherein the length of the time interval is further determined based on whether the selected device includes a mobile computing device. 20. The method of claim 11, wherein the authentication session in the plurality of authentication sessions includes the security device transmitting an authentication probe to the selected device and determining whether the authentication session is successful based on the timing of a plurality of dissimilar examples of responses to the authentication probe, each dissimilar example of the response being received from the selected device via a dissimilar route traversing the computer network. 21. A non-transitory computer-readable medium storing instructions, which, when executed by at least one hardware processor of a security device connected to a computer network interconnecting a plurality of client devices, cause the security device to: perform cyclic authentication of a selected device among the plurality of client devices, wherein: the cyclic authentication comprises a plurality of authentication sessions, each authentication session including message exchange between the security device and the selected device, and the length of the time interval between two consecutive sessions in the plurality of authentication sessions is determined based on a connectivity measurement of the selected device within the computer network; and in response to a failure of the cyclic authentication, determine whether the failure indicates a computer security threat. Claims 2 / 2 Page 3 CN 122250088 A Network Security System and Method Using a Looping Device for Authentication Cross-Reference to Related Applications

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 624,895, filed January 25, 2024, entitled “Network Security Systems and Methods,” the contents of which are incorporated herein by reference. Background Art

[0002] The present invention relates to computer security, and more particularly, to protecting network nodes from threats such as malware, intrusion, and deception.

[0003] A wide variety of devices, informally referred to as the Internet of Things (IoT), are currently being connected to communication networks and the Internet. Such devices include, in particular, smartphones, smartwatches, game consoles, various computing devices embedded in vehicles, home appliances such as TVs, speakers and other multimedia devices, smart lights, home robots, refrigerators, ovens, surveillance cameras, various sensors, thermostats, sprinklers, etc. Another exemplary category of IoT devices includes a variety of small, portable electronic devices that facilitate everyday tasks such as scanning barcodes, paying for groceries, unlocking house and car doors, and starting a car engine, among others. Other exemplary IoT devices are used for marketing and / or influencing consumer behavior and include wireless beacons that temporarily connect to a customer's mobile phone to display advertisements or various other notifications.Some of these devices may collect data about the corresponding customer and / or the corresponding mobile phone in a way that is difficult to detect, such as registering the person's location, schedule, purchasing habits, contacts, etc.

[0004] The proliferation of IoT devices has also driven innovation in networking and communication protocols that enable such devices to connect to local networks and the Internet. For example, the Zigbee® and Bluetooth® Low Energy (BLE) protocols are specifically designed for interconnecting battery-powered IoT devices. Other emerging protocols and networking technologies, such as Thread and Matter, are geared towards device interoperability across heterogeneous networks, various equipment vendors, and various carrier media.

[0005] As more and more IoT devices come online, they become targets of computer security threats such as malware and hacking. Without protection, IoT devices can expose the public to significant risks ranging from burglary to data theft, fraud, and privacy breaches. Typical attack examples include using rogue devices to impersonate legitimate IoT devices, thereby deceiving network controllers / administrators into granting access to existing networks. For example, a rogue device can then be used to control other devices on the network (e.g., unlock a door, start a car engine, etc.), monitor other devices or users, and steal valuable data from the corresponding network.

[0006] In view of the above, there is great interest in developing methods to protect IoT devices and communication networks from attacks and manipulations by malicious actors. Summary of the Invention

[0007] According to one aspect, a security device is connected to a computer network interconnecting multiple client devices. The security device includes at least one hardware processor configured to perform cyclic authentication of a selected device among the multiple client devices and, in response to a failure of the cyclic authentication, determine whether the failure indicates a computer security threat. The cyclic authentication includes multiple authentication sessions, each authentication session including message exchange between the security device and the selected device. The length of the time interval between two consecutive sessions in the multiple authentication sessions is determined based on connectivity measurements of the selected device within the computer network.

[0008] According to another aspect, a computer-implemented method for protecting a plurality of client devices from computer security threats, the plurality of client devices being interconnected by a computer network, the method comprising employing at least one hardware processor of a security device connected to the computer network to perform cyclic authentication of selected devices among the plurality of client devices and, in response to a failure of the cyclic authentication, determining whether the failure indicates a computer security threat. The cyclic authentication includes a plurality of authentication sessions, each authentication session including message exchange between the security device and the selected devices.The length of the time interval between two consecutive sessions in the plurality of authentication sessions is determined based on connectivity measurements of the selected device within the computer network.

[0009] According to another aspect, a non-transitory computer-readable media storage instruction, when executed by at least one hardware processor of a security device connected to a computer network interconnecting a plurality of client devices, causes the security device to perform cyclic authentication of a selected device among the plurality of client devices and, in response to a failure of the cyclic authentication, determine whether the failure indicates a computer security threat. The cyclic authentication includes a plurality of authentication sessions, each authentication session including message exchange between the security device and the selected device. The length of the time interval between two consecutive sessions in the plurality of authentication sessions is determined based on connectivity measurements of the selected device within the computer network. Brief Description of the Drawings

[0010]

[0011] The foregoing aspects and advantages of the invention will be better understood after reading the following detailed description and referring to the drawings, in which:

[0012] FIG1 illustrates a plurality of interconnected client devices protected from computer security threats according to some embodiments of the invention.

[0013] FIG2 illustrates exemplary components of a security device according to some embodiments of the invention.

[0014] FIG3 illustrates a general computer network and a pair of independent management domains according to some embodiments of the invention.

[0015] FIG4 illustrates an exemplary sequence of steps performed by a security agent according to some embodiments of the present invention.

[0016] FIG5 illustrates another exemplary sequence of steps performed by a security agent according to some embodiments of the present invention.

[0017] FIG6 illustrates a computer network as a graphical representation of a set of nodes connected by edges according to some embodiments of the present invention.

[0018] FIG7 illustrates two dissimilar routes connecting a pair of nodes in a general network according to some embodiments of the present invention.

[0019] FIG8-A illustrates one-to-one messaging between two network nodes according to some embodiments of the present invention.

[0020] FIG8-B illustrates one-to-many messaging according to some embodiments of the present invention.

[0021] FIG9 illustrates an exemplary behavioral authentication procedure according to some embodiments of the present invention.

[0022] FIG10 illustrates a set of exemplary authentication responses and two alternative versions of reference response patterns associated with corresponding authenticable devices according to some embodiments of the present invention.

[0023] FIG11 illustrates an alternative exemplary behavioral authentication procedure using a monitoring device to register authentication responses according to some embodiments of the present invention.

[0024] FIG12 illustrates an exemplary hardware configuration of a computing device programmed to perform some of the methods described herein.Specification 2 / 14 Page 5 CN 122250088 A Detailed Description

[0025] In the following description, it should be understood that all referenced connections between structures may be direct valid connections or indirect valid connections through intermediate structures. A group of elements comprises one or more elements. It should be understood that any reference to an element refers to at least one element. Multiple elements comprise at least two elements. Any use of 'or' signifies non-exclusive or. Unless otherwise required, any method steps described need not necessarily be performed in the specific order stated. A first element derived from a second element (e.g., data) encompasses a first element equal to the second element, as well as a first element generated by processing the second element and optionally other data. Making a decision or decision based on parameters encompasses making a decision or decision based on parameters and optionally other data. Unless otherwise specified, some quantity / data indicators may be the quantity / data itself or indicators different from the quantity / data itself. A computer program is a sequence of processor instructions that performs a task. The computer program described in some embodiments of the invention may be a separate software entity or sub-entity (e.g., subroutine, library) of other computer programs. In this document, a database refers to any organized, searchable collection of data. A network service is an application that provides data storage, manipulation, presentation, communication, or other capabilities over a computer network. Examples of network services include printing, file sharing, Dynamic Host Configuration Protocol (DHCP), and Domain Name Service (DNS), among others. The terms 'device discovery' and 'service discovery' are used interchangeably herein. Mobile computing devices encompass smartphones, tablets, laptops, and wearable computing devices such as smartwatches. Computer-readable media encompasses non-transitory media (e.g., magnetic, optical, and semiconductor storage media (e.g., hard disk drives, optical discs, flash memory, DRAM)) and communication links (e.g., conductive cables and fiber optic links). According to some embodiments, the present invention particularly provides a computer system comprising hardware (e.g., one or more processors) programmed to perform the methods described herein and computer-readable media encoded with instructions for performing the methods described herein.

[0026] FIG1 illustrates a plurality of protected client devices 12a to q according to some embodiments of the present invention. Exemplary client devices 12a to q include personal computers, enterprise mainframes, mobile computing platforms (e.g., laptops, tablets, smartphones), entertainment devices (e.g., TVs, game consoles), wearable devices (e.g., smartwatches, fitness trackers), home appliances (e.g., smart lighting systems, door locks, thermostats, refrigerators), network equipment (e.g., routers, switches, etc.), and substantially any other electronic device including a processor, memory, and a communication interface that enables the corresponding device to communicate with other devices / computer systems.

[0027] Exemplary client devices 12a to q are interconnected to a local network 14 and further interconnected to an extended network 15, which may include a wide area network and / or the Internet. The exemplary local network 14 includes home networks, enterprise networks, and others. Networks 14 and 15 include a set of links 13, which generally represent hardware and software interfaces enabling the transfer of data between client devices 12a to q and other entities connected to the respective networks. For example, links 13 may include hardware and software components that implement the physical layer, data link layer, network layer, and / or transport layer functions of an Open Systems Interconnection (OSI) model for electronic communications. Links 13 may be implemented using any carrier media and any wired or wireless communication standards and protocols known in the art, such as Ethernet®, Wi-Fi®, Bluetooth®, Bluetooth® Low Energy (BLE), ZigBee®, Thread, etc.

[0028] Some client devices, such as the exemplary devices 12g, 12h, 12j, and 12k in FIG1, may include routers that provide data routing and / or network address assignment services (e.g., DHCP) for individual client devices. Some of these devices may act as gateways to subnets and / or subsets of client devices. In some embodiments implementing a version of the Thread network standard / protocol, such gateway devices may include border routers. In one such instance, a subset of client devices 12k-m-n-p are interconnected via Ethernet® links, and device 12k includes a border router that enables communication between such devices and another part of network 14 using wireless (e.g., Wi-Fi® links). Furthermore, in Thread-compliant embodiments, some client devices, referred to as Router-Conforming Terminal Devices (REEDs), may sometimes act as routers, relaying received communications to other devices on network 14. Meanwhile, some client devices, referred to as Sleeping Terminal Devices (SEDs), communicate only occasionally and only via router devices.

[0029] FIG1 further illustrates a content server 22 connected to an extended communication network 15. Server 22 includes a set of computer systems providing client systems 12a to q with access to remote resources (e.g., Internet content) and / or various online / cloud services (e.g., device management and configuration) and others.

[0030] Security device 20 (FIG. 1) is configured to provide network diagnostic services and / or protect client devices 12a to q from computer security threats. In some embodiments, device 20 includes security agents 32 (FIG. 2) configured to implement security and / or network diagnostic services (e.g., authentication of protected client devices 12a to q).Device 20 may further include a network filter 34 configured to control communication between selected client devices and / or between selected client devices and remote content server 20. For example, network filter 34 may prevent selected client devices from accessing remote resources, such as blacklisted Internet domains / web pages. In another instance, filter 34 may prevent selected client devices from communicating with other devices and / or accessing extended network 15 in response to determining that a corresponding client device is infected with malware or has been hacked. In some embodiments illustrated in FIG1, device 20 is placed at a network gateway location such that traffic between protected clients 12a to 12q and extended network 15 passes through device 20, thereby facilitating the operation of network filter 34. The functionality of device 20 is described in detail below.

[0031] In some embodiments, security agent 32 and / or network filter 34 may be implemented as software, i.e., a set of computer programs that execute on the hardware processor of device 20. However, those skilled in the art will recognize that, in alternative embodiments, some or all of the functionality of agent 32 and / or filter 34 may be implemented in hardware (e.g., application-specific integrated circuits—ASICs, field-programmable gate arrays—FPGAs, etc.) or a combination of hardware and software.

[0032] Figure 1 further illustrates a security server 24 connected to a communication network 15. Server 24 generally represents a group of communication-coupled computer systems that may or may not be physically close to each other. In some embodiments, security device 20 may cooperate with server 24 to protect client devices 12a to q. In other words, computer security activities may be divided between device 20 and server 24. For example, device 20 may collect data from individual devices 12a to q and transmit such data to server 24. The collected data may, in particular, include a set of static attributes / characteristics of the respective device, the results of authentication procedures implemented to authenticate or verify the integrity of the respective device, device behavior data, etc. Server 24 may then process the data and respond to device 20 with security indicators indicating whether the respective device may be malicious / cracked. Parameters of the security services performed by server 24 and / or security device 20 may be defined according to service agreements and / or subscriptions.

[0033] Various data collected and / or used by security server 24 may be stored in a security database 26 communication-coupled to server 24. Database 26 can be stored in any format known in the field and allows for selective insertion and retrieval of information.

[0034] Some of the client devices connected to the local network 14 can be divided among a set of management domains, as illustrated in FIG3. In this document, a management domain refers to a selected subset of devices that collectively provide a particular service or function.In one such instance, one management domain may include a lighting controller and multiple smart lights in the home, another management domain may include a smart door lock and an electronic key for operating the corresponding lock, and yet another management domain may include a smartphone and a smart speaker that plays music under the control of the corresponding smartphone. The actual implementation of a management domain varies depending on the communication protocol, standard, and / or application. For example, a management domain established according to the Bluetooth® communication protocol may consist of a master device and a set of slave devices. In Matter-compliant embodiments, a management domain is often referred to as a 'fabric'.

[0035] Figure 3 illustrates an exemplary network and a pair of exemplary management domains 16a to b. Each domain 16a to b includes a corresponding domain administrator device 12s to t, which includes a device with network management privileges exceeding those of other members of the corresponding domain. For example, in some embodiments and protocols, the administrator device is the sole member of the corresponding domain, which can add members to and / or remove members from the domain in a procedure commonly referred to as commissioning. In some embodiments, the domain administrator device possesses a cryptographic certificate that enables the corresponding device to establish encrypted communication channels with other members of the corresponding domain. In such embodiments, all encrypted communication implemented within the corresponding domain is encrypted using a key derived from the domain administrator's cryptographic certificate. In some embodiments, the domain administrator device may selectively invoke specific functions among other members of the corresponding domain. In one such instance, the domain administrator device includes an example of a smartphone that executes a lighting controller configured to actuate multiple smart lights.

[0036] Some client devices may belong to multiple management domains simultaneously, such as the exemplary device 12r in FIG3. In one such instance, device 12r includes a thermostat that can be independently controlled by two administrator devices 12s to t (e.g., one running the Apple® Home app and the other running the Google® Home app).

[0037] FIG4 illustrates an exemplary sequence of steps performed by security device 20 to protect client devices 12a to q from computer security threats according to some embodiments of the present invention. Step 102 may include implementing a device and / or service discovery procedure. Device and service discovery is well-known in the field and includes basic interactions between networked devices through which one device (typically an administrator device) becomes aware that another device is connected to a network and / or performs network services such as printing or DNS. For example, device / service discovery occurs when a new device is introduced to a network, such as when a user brings a new smart TV home and attempts to connect it to an existing home network.Device / service discovery typically involves at least one of the devices connected to network 14 transmitting some form of notification message containing a device identifier (e.g., Media Access Control - MAC address, network address, manufacturer, device model), an indicator of the functionality of the corresponding device (e.g., smart speaker, printer, door lock) or an indicator of a network service (e.g., DNS) performed by the corresponding device, and / or a set of communication parameter values ​​(e.g., radio channel, password parameters, an indicator of whether the corresponding device supports a specific communication protocol (e.g., TCP or UDP), etc.). In response, another network device registers such indicators and may configure some parameters for communicating with the notifying device based on the received notification message. Depending on the protocol and device type, device / service discovery may be initiated by any of the devices participating in the discovery process. Device / service discovery may be fully automated or may include steps performed by a human operator. An exemplary assisted discovery process may include displaying a configuration interface to a human operator and receiving input from the human operator via the corresponding interface.

[0038] Step sequence 104-106-108 may then be performed on each discovered device. In some embodiments, security device 20 establishes a separate security management domain (e.g., a Matter structure) independent of other domains currently defined on network 14, which is used for network diagnostics and computer security activities, as described herein. Step 108 adds selected devices to the security management domain. In embodiments implementing a version of the Matter standard and protocol, step 108 may include a device debugging procedure as described, for example, in Chapter 5 of the Matter specification version 1.0 from the Connectivity Standards Consortium. In some such embodiments, security device 20 is assigned a separate encryption certificate, which it uses during debugging to establish a secure communication channel (i.e., a set of keys for encrypting and decrypting messages) with the device being debugged. The corresponding channel may then be used for one-to-one messaging between the corresponding device and security device 20, as described in more detail below. In some embodiments, security device 20 attempts to add all client devices 12a to q connected to local network 14 to the security management domain. In alternative embodiments, the devices are added only if certain eligibility criteria are verified for the client devices, such as based on device type or functionality, or whether the corresponding device is Matter compliant. In some embodiments, manual input may be required to confirm the inclusion of the selected device in the security management domain. For example, a human operator may select the device to be included in the security domain.

[0039] In some Matter-compliant embodiments, step 108 further includes a device authentication procedure. Hereinafter, authentication refers to a procedure by which the management device (security device 20 in this document) obtains proof of a particular attribute, quality, or function of a device currently being configured into a security management device.Examples of authenticable attributes are identification indicators (e.g., supplier and / or product identifiers, MAC addresses, etc.) and indicators of whether the corresponding device conforms to a specific protocol or standard (e.g., Matter), as well as others. In one example of an authentication session, device 20 establishes a secure communication channel with the device currently being debugged and receives from the corresponding device a value containing authenticable attributes and other digital authentication certificates. In some embodiments, as part of the device authentication process, the authentication certificate may be encrypted and verified by the security device 20.

[0040] Some embodiments rely on the observation that, as is generally specified in current communication standards and protocols, a single device authentication process / session can make local network 14 vulnerable to computer security threats, such as intrusion (hacking) and malware. Once a device is authenticated, it is generally trusted by the corresponding domain management device and other devices on network 14, meaning that it can participate in communication with other devices, access various remote resources and services, etc. However, the trust established through authentication may be exploited by unethical entities that attempt to control the device after its authentication. In one scenario, a hacker gains control in response to a legitimate user inadvertently installing malware on a device, such as via a spear-phishing attack. In another scenario, an intruder can use a rogue electronic device to connect to network 14 by impersonating an authenticated device. Thus, the intruder can gain control of at least a portion of the network and use it for malicious purposes (e.g., unlocking doors, accessing sensitive data, etc.). Even without an attack, some IoT devices occasionally update their software and / or some of their operational attributes, causing their profiles to no longer conform to the initially authenticated profile.

[0041] Some embodiments directly address such drawbacks by implementing repeated re-authentication of selected devices. In some embodiments, each client device 12a to q included in the security management domain is periodically re-authenticated and / or re-authenticated in response to triggering events such as network reconfiguration (e.g., changes in network topology, moving a device from one room to another, etc.), the introduction of a new device into the security management domain, software updates, security incidents, etc.

[0042] In some embodiments that perform periodic re-authentication, each member of the security management domain is repeatedly re-authenticated at a pre-sequential interval Ta. The re-authentication interval Ta can measure the time elapsed between two consecutive authentication sessions, such as between the start of one session (e.g., initiation, first step) and the start of the next session. Alternatively, Ta can measure the time elapsed between the end of one session (completion, final step, etc.) and the start of the next session, or in any other way that indicates the interval between consecutive authentications of the same device.

[0043] The re-authentication interval Ta may be specific to each authenticated client device and may vary depending on various device attributes, such as the device type of the respective device (e.g., media player vs. smartphone vs. lighting controller). In one such embodiment, a router may be re-authenticated more frequently than a smart bulb, based on the observation that the router is more important to the functionality of the local network and therefore any attack or failure on the router would have more serious consequences than an attack or failure on the lighting fixture. Alternatively or additionally, the re-authentication interval Ta may vary based on the anticipated likelihood that the software running on the respective device will change within the interval Ta. In one such instance, a smartphone may be re-authenticated more frequently than a door lock, based on the observation that a smartphone is more likely to receive software updates and / or install new applications than a door lock. The re-authentication interval Ta may also vary depending on whether the respective device is battery-powered. For example, to extend battery life, battery-powered devices may be re-authenticated less frequently than plug-in devices.

[0044] Other exemplary criteria for determining the re-authentication interval Ta may include the type of network link connecting the respective device to other devices on the network. For example, Ta may vary depending on whether the corresponding link is transient or persistent and / or depending on the protocol / standard (e.g., WiFi® and BLE) that manages communication on the corresponding link.

[0045] The re-authentication interval Ta may be further determined based on whether the authenticated device includes a mobile computing device (e.g., a smartphone, etc.), based on the observation that such devices physically follow their owners and their movement is likely to change the network topology. Therefore, some embodiments re-authenticate mobile devices more frequently than fixed devices such as personal computers, thermostats, etc.

[0046] In some embodiments, the re-authentication interval Ta may be determined based on connectivity measurements of the corresponding authenticated device within the network. Basic exemplary connectivity measurements may be determined based on the count of client devices 12a to q that the corresponding device communicates with via network 14. In one such embodiment, a master device controlling multiple IoT devices (lights, thermostats, speakers, door locks, etc.) may be re-authenticated more frequently than each corresponding controlled device.

[0047] Some embodiments determine connectivity measurements based on the node degree of the corresponding client device in the graph representation of network 14. Figure 6 shows network 14 as an exemplary abstract representation of a graph comprising a set of nodes (e.g., nodes 42a to d) interconnected by edges 44. In a graph theory analogy, each client device 12a to q in Figure 1 may represent a graph node, and each network link 13 may correspond to a graph edge. In graph theory, the count of edges connected to a node is called the degree of the corresponding node. In the example of Figure 6, nodes 42a, 42b, 42c, and 42d have degrees of 1, 5, 4, and 1, respectively.

[0048] In some embodiments, highly connected devices (i.e., devices with relatively high node degree) may be re-authenticated more frequently than devices with fewer links (i.e., devices with relatively low node degree), based on the observation that attacks or failures on highly connected devices have more severe consequences than attacks or failures on more peripheral devices. In exemplary Thread-compliant embodiments, routers may be re-authenticated more frequently than router-compliant endpoint devices (REEDs), which in turn may be re-authenticated more frequently than dormant endpoint devices (SEDs).

[0049] Some embodiments further impose predetermined upper and / or lower limits on Ta to avoid re-authentication that is too frequent (and thus impacts performance and user experience) or too sparse (and thus compromises security). In one such example,

[0050]

[0051] where d represents the degree of the corresponding node / client device, and Tmax and Tmin represent the upper and lower bounds of the re-authentication time interval, respectively. An exemplary practical value for Tmin is 1 hour, and an exemplary practical value for Tmax is 72 hours. Meanwhile, dmin≥0 and dmax represent predetermined lower and upper bounds of the node degree, respectively. For example, in one embodiment where dmin=0 and dmax=4, all nodes with a degree greater than or equal to 4 can re-authenticate equally frequently.

[0052] The node degree (i.e., the count of links connecting the selected device to other devices on network 14) and / or other indicators of connectivity and topology can be determined remotely by security device 20, for example, based on routing tables, neighbor tables, and / or by querying various network services, such as ThreadNetworkDiagnostics in Matter and Thread compliant embodiments (other protocols and network standards may have similar services and / or allow similar information to be recovered from individual nodes). In some embodiments, device 20 performs such determination periodically and / or in response to specific events (e.g., security events, the addition of new devices to the security management domain, etc.) to obtain the latest Ta value for all authenticable nodes. In an exemplary Thread compliant embodiment, SED can receive node degree d=0, and REED can receive node degree d=1.

[0053] In some embodiments, step 110 determines whether a device re-authentication condition is met, such as whether a specific event has occurred or whether the time elapsed since the last authentication of the selected device exceeds the authentication interval Ta of the respective device. If so, steps 112-114 (FIG. 4) perform a re-authentication procedure on the selected device. The procedure itself may implement any authentication method known in the art, such as certificate-based authentication involved in device commissioning (as described in Chapter 5 of the Matter specification, version 1.0 from the Connectivity Standards Consortium).

[0054] FIG. 5 illustrates an exemplary sequence of steps for implementing a re-authentication procedure / session according to some embodiments of the invention.The steps described can be implemented by components of security device 20, such as device authentication engine 36 (Figure 2). Conventional authentication typically involves sending a certificate request to an authenticable device and authenticating various attributes of the corresponding device based on the content of the received certificate. In contrast to this conventional authentication, the procedure illustrated in Figure 5 relies on the timing of the received response, rather than the content of the response or the content of the response other than that in the response on page 7 / 14 of the corresponding specification, 10 CN 122250088 A. This timing-based authentication is referred to herein as behavioral authentication because it typically authenticates the behavior of the corresponding device in the corresponding network context. In other words, behavioral authentication checks whether the behavior of the corresponding device is as expected (e.g., similar to the behavior of the corresponding device observed in a previous authentication session).

[0055] The behavioral authentication described herein relies on the observation that IoT networks are likely to have a relatively high overall connectivity compared to conventional WiFi® and Ethernet® based networks. Modern network standards such as Thread enable some devices to act as ad-hoc routers, thereby forwarding received messages to neighboring devices and thus bypassing conventional network hubs. Therefore, current and future IoT networks are more likely to have a mesh topology rather than the hierarchical, star topology typical of older networking standards. A characteristic of mesh topologies is that multiple routes may connect a pair of nodes, as illustrated in Figure 7, where dissimilar routes 46a and 46b, shown as dashed lines, traverse a common network connecting the same pair of nodes. Routes in this document represent a set of consecutive network edges traversing the network between the start and end nodes.

[0056] Furthermore, most IoT devices can switch between multiple transport layer protocols (e.g., TCP, UDP) depending on the task and situation. In other words, IoT devices are typically capable of communicating via both one-to-one and one-to-many messaging. Figures 8-A to 8-B illustrate one-to-one and one-to-many messaging according to some embodiments of the invention. In one-to-one messaging (Figure 8-A), there is only one sender (exemplary node 42d) and one receiver (exemplary node 42e). The message follows a single route between the sender and receiver. The corresponding route is typically determined by a routing algorithm and is not always the same. One-to-one messaging, also known as unicast in the field, typically involves establishing a connection / communication channel between the sender and receiver through an initial exchange called a handshake. The corresponding communication channel may be encrypted. Exemplary transport protocols for one-to-one messaging include several versions of the Transmission Control Protocol (TCP) and others.

[0057] In contrast, in one-to-many messaging (Figure 8-B), the sending node 42d transmits a message to multiple other nodes in the network, which in turn forward the message to other network nodes (e.g., their direct neighbors), etc.In one-to-many messaging, multiple instances of the original message traverse the network concurrently, with at least some eventually reaching the selected destination node. In other words, multiple instances of the message follow disparate network routes between the sender and the selected destination. One-to-many messaging includes multicast and broadcast schemes and does not require establishing a channel / connection between the sender and receiver. Exemplary transport protocols for one-to-many messaging include several versions of User Datagram Protocol (UDP) and others.

[0058] Some embodiments of the present invention explicitly use the one-to-many messaging capabilities of IoT devices to perform the behavioral authentication described herein, in conjunction with the mesh topology of the network. The method illustrated in FIG5 relies on receiving multiple instances of messages originating from the device currently being authenticated, each instance following a different route across the network. Collecting multiple instances of the corresponding messages enables the security device to efficiently detect changes in both the device itself and the topology of network 14. Such changes may be benign but may also act as indicators of potential attacks, malicious activity, or network failures.

[0059] In step 130 (FIG. 5), the security device 20 may generate a session ID that uniquely identifies the current authentication session / attempt. The session ID can be generated in any way known in the domain, such as by hashing. Then, in step 132, device 20 may send an authentication probe to the selected client device for authentication (see step 112 in FIG. 4). The authentication probe includes an electronic message delivered via a one-to-one messaging protocol and contains the session ID determined in step 130. This one-to-one messaging protocol may include establishing a secure communication channel between device 20 and the corresponding client device, for example, via a Certificate Authentication Session Establishment (CASE) protocol. During the initial commissioning of the corresponding device, the cryptographic parameters of the CASE-established channel may be negotiated between device 20 and the corresponding client device (e.g., see the description of step 108 in FIG. 4). The authentication probe may then be transmitted in encrypted form, such that the session ID is only available to the device being authenticated.

[0060] In some embodiments, the authentication probe transmitted in step 132 is further intentionally configured to cause the authenticated device to respond via a one-to-many messaging protocol. Some embodiments utilize the following observation: Device / service discovery procedures are typically implemented via one-to-many messaging (page 8 / 14 of the specification, CN 122250088 A), and thus authentication probes are carefully crafted to trigger at least a portion of the device / service discovery procedure within the authenticated client device. An exemplary service discovery procedure using one-to-many messaging is described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 6763 entitled "DNS-based Service Discovery." Therefore, exemplary embodiments may configure authentication probes to put the authenticated device into device / service discovery mode, i.e., to announce its attributes and / or available services.In embodiments implementing a version of the Matter protocol, the authentication probe may be configured to put the authenticated device into a debug mode, which may include a device / service discovery procedure, including broadcasting a Domain Name Service-Service Discovery (DNS-SD) record. For example, the authentication probe may include an OpenCommissioningWindow command, as described, for example, in Chapters 11.18.8.1 and 5.6.4 of the Matter specification version 1.0 from the Connectivity Standards Consortium, and others. According to the Matter standard, the OpenCommissioningWindow command includes a 16-bit discriminator typically used as a device identifier. Some embodiments may use a corresponding discriminator field to encode the session ID (see step 130 above).

[0061] In response to launching the authentication probe, the sequence of steps 134-136-138 may listen for responses from the client device being authenticated. Since responses are sent via one-to-many messaging, the security device 20 may typically receive multiple responses, each response Ri including a distinct example of a response message from the currently authenticated device (as described above with respect to Figure 8-B). Figure 9 illustrates behavioral authentication according to some embodiments of the present invention, wherein device 20 sends an authentication probe to a selected client device 12, generally representing any of the client devices 12a to 12q of Figure 1. In response to the probe, device 20 receives a set of authentication responses Ri, wherein each response traverses the network via a dissimilar route connecting device 20 to device 12.

[0062] Some embodiments perform behavioral authentication based on the timing of the authentication responses Ri. Timing generally refers to any time measurement herein, including moments and amounts of time. For example, the timing of responses Ri may include the moment ti when the corresponding response arrives at / registers at security device 20 or another listening device 60, as described below with respect to Figure 11. Alternatively, as illustrated, for example, in Figure 9, timing may refer to the time delay dti of receiving the corresponding response Ri, the delay being determined relative to a reference event (e.g., transmitting an authentication probe or the target device transmitting a response while being authenticated). In yet another exemplary embodiment, the timing of the responses may include the amount of time required to separate the corresponding response from a previously received response. Those skilled in the art will appreciate that other interpretations of 'tiing' may be used without prejudice to the scope of the invention.

[0063] In some embodiments, step 136 ensures that device 20 listens for responses only within a finite time interval, which is referred to herein as an authentication window (see, for example, FIG. 9). In Matter-compliant embodiments, the authentication window may be consistent with the device debugging window described in the Matter specification.The authentication window typically ranges from a few seconds to a few minutes and can be determined by the device authentication engine 36, for example, based on actual testing, the device type of device 12 (e.g., routers and light bulbs), whether the corresponding device is battery-powered (such devices may respond slower than plug-in devices), the communication protocol used by device 12 (e.g., BLE devices may respond slower than devices using WiFi®), etc. The range of the authentication window can also be selected so as not to overlap with the authentication windows of other authentication sessions.

[0064] In response to each received reply Ri, step 139 may register a set of values ​​characterizing the corresponding reply, such as a timestamp indicating the time the corresponding reply arrived and an identifier of the messenger device from which the corresponding reply was received. In one-to-many messaging, the messenger device is not the same device as the currently authenticated device 12, but another network device that forwards the message en route to the security device 20, and thus can act as an indicator of the network route followed by the corresponding reply. Alternatively or additionally, each reply Ri may be associated with an identifier of the network route the corresponding message travels between the authenticated device and device 20 or some other monitoring device. For example, routes can be determined based on routing tables and / or neighbor tables; popular network communication protocols contain commands and / or data structures that can be used to determine such routes. In some embodiments, step 139 may further associate the corresponding response Ri with the corresponding authentication session (e.g., via session ID) and / or with device 12 (via a suitable device identifier). Specification 9 / 14 pages 12 CN 122250088 A

[0065] In some embodiments, the response Ri from client device 12 is configured to include the same session ID received as part of the authentication probe. For example, in a Matter-compliant embodiment, the DNS-SD message output by device 12 includes the value of the 'discriminator' field received using the OpenCommissioningWindow command. In some embodiments, step 140 determines whether the session ID contained in the received response Ri matches the session ID sent as part of the authentication probe. A mismatch may indicate that the corresponding response belongs to another authentication session. When engine 36 performs concurrent authentication of multiple devices, step 142 may sort the responses by their respective session IDs. However, since the session ID is transmitted to device 12 via a one-to-one communication that can be further encrypted, in principle, no other network device besides device 12 should know the correct value of the corresponding session ID. Therefore, a mismatch between the probed and responded session ID values ​​can indicate a computer security threat (e.g., a rogue device masquerading as the device currently authenticating). Therefore, some embodiments conclude authentication failure (step 150) in response to a session ID mismatch.

[0066] When the time elapsed since the authentication probe was launched exceeds the size of the authentication window, step 144 may compare the characteristics of the received response with a reference response pattern associated with the corresponding authenticated device 12. Alternative embodiments may process responses immediately without waiting for the authentication window to expire. Figure 10 shows an exemplary response timeline including multiple responses Ri, each delayed by a corresponding amount dti relative to the launch time of the authentication probe. Figure 10 further illustrates two alternative exemplary reference response patterns 50a to b according to some embodiments of the invention. Each reference response pattern 50a to b includes a data structure indicating a typical or expected timing of the authentication response characteristics of the currently authenticated client device 12. Patterns 50a to b are determined based on multiple previous authentication sessions of the corresponding device.

[0067] In some embodiments, reference response pattern 50a may include multiple tuples:

[0068]

[0069] wherein each tuple {Ti,Si} describes dissimilar responses Ri by the average time delay Ti of the corresponding response relative to the launch time of the authentication probe and a variability measurement (e.g., standard deviation) Si of the corresponding time delay. Optionally, each tuple may further include an identifier mi of the messenger device that forwards the corresponding reply en route to security device 20. Alternatively, if this identifier is available, mi may identify the route taken by the corresponding reply Ri across network 14. Those skilled in the art will appreciate that the form of the reference reply pattern shown in Equation [2] is merely illustrative and not intended to be limiting. Any of several alternative examples may be employed in the embodiments. In one such alternative example, Ti may represent the time delay of separating two consecutive replies (e.g., separating reply Ri from reply Ri-1). In yet another illustrative example, the reference reply pattern 50b may be encoded as a probability measurement, such as a set of numbers indicating the likelihood that a reply will arrive within a time interval following the authentication probe launch. Optionally, the probability measurement may include another parameter mj such that it indicates the likelihood that a reply will arrive within a time interval via the messenger device or route mj.

[0070] In some embodiments, engine 36 may determine whether the current authentication reply conforms to the reference reply pattern of device 12 based on the count of replies Ri received within the current authentication window. Alternatively, some embodiments may associate each response with the network route that the corresponding response has traveled, and may determine whether the current response matches a reference response tap based on the order in which responses are received or registered. Other exemplary embodiments may assess the degree of match between the current response and the reference pattern based on the characteristics of each response received within the current authentication window. For example, for each response Ri, engine 36 may determine whether the time delay dti of receiving the corresponding response is within a predetermined amount of the expected or average time delay indicated in the reference response pattern.Using the exemplary representation and equation [2] in FIG10, engine 36 can determine that a registered response Ri conforms to the reference pattern if: for all i, specification 10 / 14 pages 13 CN 122250088 A

[0071] .

[0072] Some embodiments may further check whether each registered response Ri was received via the same messenger device indicated in the reference pattern. In the example illustrated in FIG10, responses R1 and R2 verify equation [3], while response R3 does not verify, so some embodiments may determine that the illustrated response timeline does not conform to pattern 50a.

[0073] In an alternative embodiment in which the reference response pattern includes a probability measurement, engine 36 may determine that a registered response conforms to the reference pattern if:

[0074]

[0075] where the time interval is selected such that and P represent a predetermined threshold (e.g., 80%). In other words, response Ri conforms to the reference response pattern only if the probability of receiving a response during that particular time interval exceeds the predetermined threshold.

[0076] If the response received during the current authentication response period conforms to the reference response pattern (step 146 in FIG. 5 returns "Yes"), step 148 may determine that authentication was successful. Otherwise, in step 150, engine 36 may conclude that authentication of device 12 has failed. In some embodiments, step 147 may update the device-specific reference response patterns 50a to b associated with values ​​registered in the current authentication session. For example, some embodiments may recalculate the average response delay Ti, delay variability measurement Si, messenger device identifier mi, and / or probability measurement based on the dti and / or mi values ​​measured in the current authentication session.

[0077] If the current re-authentication of device 12 is successful (step 116 in FIG. 4 returns "Yes"), then in step 118, security device 20 may register the latest authentication parameter values ​​(e.g., response delay dti, messenger device identifier mi, etc.) and associate them with the corresponding authenticated device.

[0078] When authentication fails, step 120 may execute a set of network diagnostics and / or failure mitigation procedures. The causes of failure can range from simple benign reasons to more serious and / or even malicious ones. An example of a benign cause is physically moving a client device (e.g., a smart speaker) from one room of a house to another. This movement may unintentionally alter the network topology, making the moved device now connect to security device 20 via a different router. Therefore, the movement can change the route through which various authentication responses reach device 20, which in turn may change the timing of the corresponding responses. In such cases, diagnostic and failure mitigation procedures may include notifying the network administrator, for example. In response to user input confirming device movement or a deliberate change in network topology, some embodiments may switch to a pattern acquisition mode, where some authentication sessions are not performed as planned, to determine a new reference response pattern for the affected device.

[0079] Another benign reason for re-authentication failure is a hardware or software malfunction of the device. The battery may be depleted; the software may crash or have vulnerabilities. Such failures are relatively easy to detect because the corresponding device may simply be unable to respond to the authentication probe. However, a failure of the messenger device of a router, for example, can cause the authentication response timing of multiple devices to change because the response messages will follow a route other than the previous one. Diagnostic and mitigation procedures specific to such situations may include identifying and fixing local problems (rebooting the corresponding device, replacing the battery, etc.).

[0080] Adding and removing devices from an existing network can change the response timing of multiple devices and may require relearning the reference response pattern of all affected devices. Even software or firmware updates may cause devices to behave differently, resulting in re-authentication failure.

[0081] Authentication failure can also signal a computer security threat. In one such instance, a rogue device may attempt to impersonate a legitimate client device. However, because the rogue device is located on the network differently from the legitimate device being impersonated, the authentication response from the rogue device will typically not match the reference response pattern of the legitimate device. This attack can be further detected by the session ID mismatch described above with respect to steps 140 to 142 in Figure 5, as per page 11 / 14 of the specification, CN 122250088 A.

[0082] A session ID mismatch can also indicate that a third party is attempting to add a corresponding device to a management domain that is different from the security domain managed by security device 20. This attempt may be legitimate or may indicate malicious intent, thus requiring further investigation.

[0083] Another example of an attack or malicious manipulation that leads to re-authentication failure includes denial of service, as described, for example, in the Common Vulnerability and Exposure (CVE®) record CVE-2024-3297, whereby a device may suddenly become unresponsive in response to malicious manipulation of a secure communication session due to the denial of service. Therefore, re-authentication failure of the corresponding device can be used to trigger an investigation.

[0084] The summary description of some possible causes of re-authentication failure shows that behavioral re-authentication according to some embodiments of the invention can provide efficient and timely warnings of network failures and a powerful tool for diagnosis and mitigation. Some embodiments can even automate diagnostics, failure mitigation, and / or security analysis performed in response to re-authentication failures. For example, in response to a re-authentication device failure, some embodiments can automatically attempt re-authentication using the behavior of other selected devices (e.g., a specific router, hub, device directly connected to the device that failed re-authentication, etc.). Some embodiments can further implement decision trees based on the type of device that failed re-authentication, whether the failure was an isolated event or whether other devices also failed re-authentication.

[0085] In a simple exemplary diagnostic procedure, in response to the failure to receive a specific response Ri, some embodiments may check whether the current route for receiving the response Ri is different from the expected route (as indicated, for example, in the reference response pattern of the corresponding device). Such determination may involve establishing / verifying routing tables or node neighbor tables for various nodes in the network. Determining that the route has not changed may indicate a failure along the corresponding route. Therefore, some embodiments may verify the functionality of each device along the corresponding route to identify a target device that is not behaving as expected. The target device may then be examined for failures, software updates, and computer security threats. Some embodiments may require re-authenticating the target device using a conventional, certificate-based authentication protocol.

[0086] The above description focuses on embodiments in which security device 20 sends out authentication probes and also listens for responses to the corresponding probes. However, some of the methods described above may be adapted to accommodate at least one listening device different from device 20. In one such exemplary embodiment illustrated in FIG11, a listening device 60 connected to network 14 may register a set of authentication responses Ri circulating on the network in response to authentication probes. As described herein, the listening device can facilitate device authentication and diagnostics of relatively large networks and / or remote portions of network 14. An exemplary listening device may include a border router of a Thread network.

[0087] The listener 60 may report received responses to the security device 20. For example, for each registered response Ri, a set of response parameter values ​​52 may include a timestamp indicating the moment the corresponding response was detected at the listener 60, an identifier mi of the messenger device that forwarded the corresponding response to the listener 60, and a session ID value included in the corresponding response. In response to receiving parameter values ​​52, the security device 20 may sort the corresponding data according to the session ID and calculate the response delay according to the corresponding timestamp.

[0088] When determining whether an authenticated response conforms to a reference response pattern for a target device, the device 20 may use data received from the listener 60 as a substitute for or supplement to responses registered by the device 20 itself. In an exemplary embodiment using both responses registered at the device 20 and responses registered at the listener 60, the reference response pattern may further include an identifier of the corresponding listening device. For example, pattern 50a in Figure 10 may include a set of tuples {Ti, Si, Li}, where Li identifies the listening device that registered the corresponding response.

[0089] Figure 12 shows an exemplary hardware configuration of a computing system 80 programmed to perform some of the methods described herein. The computer system 80 generally represents the security device 20, security server 24, and any client devices 12a to q in Figure 1. The illustrated computing device is a personal computer; other devices such as servers, mobile phones, tablet computers, and wearable devices may have slightly different configurations.

[0090] Processor 82 includes physical means (e.g., a microprocessor or multi-core integrated circuit formed on a semiconductor substrate) configured to perform computations and / or logical operations with a set of signals and / or data. Such signals or data may be encoded and transmitted to processor 82 in the form of processor instructions (e.g., machine code).

[0091] Memory unit 84 may include volatile computer-readable media (e.g., dynamic random access memory - DRAM) storing encoded data / signals / instructions accessed or generated by processor 82 during operation. Input device 86 may include a computer keyboard, mouse, microphone, and others, including corresponding hardware interfaces and / or adapters that allow users to introduce data and / or instructions into computer system 80. Output device 88 may include display devices (e.g., monitors, speakers, and others) and hardware interfaces / adapters (e.g., graphics cards) that enable the corresponding computing device to communicate data to the user. In some embodiments, input and output devices 86-88 share common hardware (e.g., a touchscreen). Storage device 92 includes a computer-readable medium that implements non-volatile storage, reading, and writing of software instructions and / or data. Exemplary storage devices include magnetic disks and optical disks and flash memory devices, as well as removable media such as CDs and / or DVDs and drives. Network adapter 94 enables computer system 80 to connect to electronic communication networks (e.g., networks 14 and 15 in FIG. 1) and / or other devices / computer systems.

[0092] Controller hub 90 generally refers to multiple systems, peripheral devices, and / or chipset buses and / or all other circuitry that enables communication between processor 82 and the remaining hardware components of computer system 80. For example, controller hub 90 may include memory controllers, input / output (I / O) controllers, and interrupt controllers. Depending on the hardware manufacturer, some of these controllers may be incorporated into a single integrated circuit and / or integrated with processor 82. In another example, controller hub 90 may include a northbridge connecting processor 82 to memory 84 and / or a southbridge connecting processor 82 to devices 86, 88, 92, and 94.

[0093] Embodiments of the present invention enable the protection of multiple client devices across complex communication networks from computer security threats, such as malware, hacking, device spoofing, and others. In one exemplary use case, a home network would include multiple devices comprising personal computers and smartphones, as well as various IoT devices (e.g., smart appliances, game consoles, and entertainment devices) interconnected. Client devices may communicate via different media and protocols, some wired and some wireless. Some devices may be battery-powered and communicate only occasionally over the corresponding network. The transport layer of such a network may be configured and operated according to a uniform standard / protocol (e.g., Thread and others).Furthermore, application layer protocols such as Matter can be used to enable dedicated functions such as network diagnostics and device actuation (e.g., unlocking a door, turning on a light, setting a thermostat, etc.).

[0094] In some embodiments, a security device protects the corresponding network from computer security threats. The security device may be installed in a gateway location between the protected network and an extended network (e.g., the Internet) (see Figure 1). This location facilitates secure operations, such as traffic filtering and DNS-based access control. In addition to such conventional security procedures, some embodiments also enhance network security through cyclic re-authentication of network nodes.

[0095] Various authentication methods and procedures are known in the art. Typical device authentication involves receiving a certificate via a point-to-point secure communication channel, which authenticates specific attributes of the corresponding device, such as identification, integrity, or specific aspects of the functionality of the corresponding device. Conventional authentication is typically performed only once, for example, when a new device is introduced into the network, because the secure cryptographic mechanisms involved in authentication inherently prevent device spoofing and tampering with certificates.

[0096] Compared to conventional authentication, embodiments of security devices perform cyclic re-authentication on each protected network node based on the observation that the composition and usage patterns of modern IoT networks change relatively rapidly. New devices are constantly added to the network, while other devices become obsolete and disconnected. Various network services are activated or deactivated. Some devices receive software updates over time periods of hours or days, which may change some of their attributes and functionality. As IoT devices become more powerful and complex, their attack surface may also increase, making them more vulnerable to malware. Cyclic re-authentication according to some embodiments of the invention enables security devices to track changes in individual devices and the entire network, and to adapt to these changes in a timely manner. Specification 13 / 14 pages 16 CN 122250088 A

[0097] Re-authentication may be triggered by specific events (e.g., security events, changes in network topology, software or firmware updates, installation of new software, etc.) or may be performed periodically, wherein the time interval between authentications is device-specific. The frequency of re-authentication may depend on the network role of the corresponding device (e.g., router and end node) and / or the connectivity measurement of the corresponding node (e.g., node degree), where highly connected nodes are re-authenticated more frequently than end nodes, depending on the observed failure or attack on highly connected nodes having a greater probability of disruption than failure or attack on other nodes.

[0098] In some embodiments, re-authentication verifies the behavior of each protected network node by determining whether the current response of the corresponding node to a cyclic stimulus matches the previously recorded response characteristics of the corresponding node. This authentication is referred to herein as behavioral authentication.Behavioral authentication procedures according to some embodiments of the present invention include a security device sending an authentication probe to a target device via one-to-one messaging (e.g., unicast), and the target device responding via one-to-many messaging (e.g., multicast). The security device may then authenticate the identity and / or functionality of the target device based on the timing of multiple response examples, each example traversing the network via a distinct route. For example, the security device may check whether the response to the current authentication probe matches the characteristics of a reference response pattern of the target device, which is determined based on previous authentication.

[0099] Intuitively, the behavioral authentication described herein is analogous to throwing pebbles into a pond and observing the resulting ripples. Therefore, device authentication based on the timing of responses to target probes is referred to herein as pebble-ripple authentication. When a pebble is thrown into a pond, the timing of the detected ripples encodes not only the location where the pebble hits the water, but also the location of various obstacles (e.g., islands and pond banks) reflecting the ripples on their path to the observer. By analyzing the timing of multiple ripples (i.e., multiple echoes of the pebble hitting the water), the observer can reconstruct the topography of the pond. Similarly, the use of pebble-ripple authentication in computer networks enables observers (e.g., security devices) to reconstruct the network's topology and connectivity, or at least reconstruct a portion of the network traversed by one-to-many messages between the authenticated device and the observer.

[0100] On average, the composition and topology of modern IoT networks are more dynamic than those of conventional networks. Some IoT devices connect only occasionally to conserve energy. In modern application layer protocols such as Matter, some devices may occasionally act as routers, thereby shortening established network routes. Mobile phones and wearable devices move around with their owners. Other devices, such as laptops, smart speakers, and game consoles, are frequently relocated, for example, from one room of a house to another. Such movement can alter the topology and / or local connectivity of the corresponding network. By inherently encoding information about the network's topology and connectivity, cyclic pebble-ripple authentication of selected network devices provides valuable early detection of changes to the corresponding network. Such changes can be benign (e.g., a smartphone moving from one room to another, a sensor's battery running out), but can also indicate malicious activity. Therefore, some embodiments use authentication failure as a triggering condition for forensic investigation.

[0101] Behavioral pebble-ripple authentication can be combined with conventional authentication. In one such instance, the response message from the authenticated device may contain authentication certificates or any other data regarding the attributes of the corresponding device. Thus, device attributes that can be authenticated via behavioral authentication include, in particular, identification, location, compliance with selected protocols (e.g., UDP, Matter), and network services provided by the corresponding device.

[0102] Those skilled in the art will understand that the above embodiments can be modified in many ways without departing from the scope of the invention. Therefore, the scope of the invention should be determined by the appended claims and their legal equivalents. Instruction manual, page 14 / 14, 17 CN 122250088 A, Figure 1; Instruction manual, Figure 1 / 8, page 18 CN 122250088 A, Figure 2; Figure 3; Instruction manual, Figure 2 / 8, page 19 CN 122250088 A, Figure 4; Instruction manual, Figure 3 / 8, page 20 CN 122250088 A, Figure 5; Instruction manual, Figure 4 / 8, page 21 CN 122250088 A, Figure 6; Figure 7; Figure 8-A; Instruction manual, Figure 5 / 8, page 22 CN 122250088 A, Figure 8-B; Figure 9; Instruction manual, Figure 6 / 8, page 23 CN 122250088 A, Figure 10; Instruction manual, Figure 7 / 8, page 24 CN 122250088 A, Figure 11; Figure 12; Instruction manual, Figure 8 / 8, page 25 CN 122250088 A.

Claims

1. A security device connected to a computer network interconnecting multiple client devices, the security device comprising at least one hardware processor configured to: Implement cyclic authentication for a selected device among the plurality of client devices, wherein: The circular authentication comprises multiple authentication sessions, each session including message exchange between the security device and the selected device, and The length of the time interval between two consecutive authentication sessions in the plurality of authentication sessions is determined based on connectivity measurements of the selected device within the computer network; and In response to the failure of the cyclic authentication, determine whether the failure indicates a computer security threat.

2. The security device of claim 1, wherein the computer network comprises a plurality of nodes interconnected by multiple edges, and wherein the connectivity measurement of the selected device is determined based on the node degree of a selected node among the plurality of nodes, the selected node including the selected device.

3. The safety device according to claim 2, wherein the length of the time interval is further constrained between a predetermined upper bound and a predetermined lower bound.

4. The safety device according to claim 2, wherein the length of the time interval is further determined according to: ， Where d represents the degree of the selected node, d min and d max These are the predetermined lower and upper bounds of the node degree, respectively, and T min and T max It is a predetermined lower and upper bound of the length of the time interval.

5. The security device of claim 1, wherein the connectivity measurement of the selected device is determined based on a count of devices among the plurality of client devices with which the selected device communicates via the computer network.

6. The security device of claim 1, wherein the connectivity measurement of the selected device is determined based on whether the selected device is configured to relay incoming communications to other devices among the plurality of client devices.

7. The safety device of claim 1, wherein the connectivity measurement of the selected device is determined based on whether the selected device is battery powered.

8. The security device of claim 1, wherein the connectivity measurement of the selected device is determined based on the type of network protocol used to communicate with the selected device.

9. The security device of claim 1, wherein the length of the time interval is further determined based on whether the selected device includes a mobile computing device.

10. The security device of claim 1, wherein the authentication session of the plurality of authentication sessions includes the security device transmitting an authentication probe to the selected device and determining whether the authentication session is successful based on the timing of a plurality of dissimilar examples of responses to the authentication probe, each dissimilar example of the response being received from the selected device via a dissimilar route traversing the computer network.

11. A computer-implemented method for protecting a plurality of client devices from computer security threats, said client devices being interconnected by a computer network, said method comprising employing at least one hardware processor of a security device connected to said computer network to: Implement cyclic authentication for a selected device among the plurality of client devices, wherein: The circular authentication comprises multiple authentication sessions, each session including message exchange between the security device and the selected device, and The length of the time interval between two consecutive authentication sessions in the plurality of authentication sessions is determined based on connectivity measurements of the selected device within the computer network; and In response to the failure of the cyclic authentication, determine whether the failure indicates a computer security threat.

12. The method of claim 11, wherein the computer network comprises a plurality of nodes interconnected by a plurality of edges, and wherein the connectivity measurement of the selected device is determined based on the node degree of a selected node among the plurality of nodes, the selected node including the selected device.

13. The method of claim 12, wherein the length of the time interval is further constrained between a predetermined upper bound and a predetermined lower bound.

14. The method of claim 12, wherein the length of said time interval is further determined according to: ， Where d represents the degree of the selected node, d min and d max These are the predetermined lower and upper bounds of the node degree, respectively, and T min and T max It is a predetermined lower and upper bound of the length of the time interval.

15. The method of claim 11, wherein the connectivity measurement of the selected device is determined based on a count of devices among the plurality of client devices with which the selected device communicates via the computer network.

16. The method of claim 11, wherein the connectivity measurement of the selected device is determined based on whether the selected device is configured to relay incoming communications to other devices among the plurality of client devices.

17. The safety device of claim 11, wherein the connectivity measurement of the selected device is determined based on whether the selected device is battery powered.

18. The method of claim 11, wherein the connectivity measurement of the selected device is determined based on the type of network protocol used to communicate with the selected device.

19. The security device of claim 11, wherein the length of the time interval is further determined based on whether the selected device includes a mobile computing device.

20. The method of claim 11, wherein the authentication session of the plurality of authentication sessions includes the security device sending an authentication probe to the selected device and determining whether the authentication session is successful based on the timing of a plurality of dissimilar examples of responses to the authentication probe, each dissimilar example of the response being received from the selected device via a dissimilar route traversing the computer network.

21. A non-transitory computer-readable medium storing instructions that, when executed by at least one hardware processor of a security device connected to a computer network interconnecting a plurality of client devices, cause the security device to: Implement cyclic authentication for a selected device among the plurality of client devices, wherein: The circular authentication comprises multiple authentication sessions, each session including message exchange between the security device and the selected device, and The length of the time interval between two consecutive authentication sessions in the plurality of authentication sessions is determined based on connectivity measurements of the selected device within the computer network; and In response to the failure of the cyclic authentication, determine whether the failure indicates a computer security threat.

Images