Mitigating denial of service attacks in a device provisioning protocol (DPP) network

Abstract

Embodiments of the present disclosure relate to mitigating denial of service attacks in a device provisioning protocol (DPP) network. Systems and methods are provided for mitigating denial of service attacks that can disrupt systems and methods that log Internet of Things (IoT) devices onto a network and ensure that legitimate IoT devices are logged in. An example implementation includes receiving, at an access point (AP), a chirp signal from a device, the chirp signal containing a data hash that includes a first public key of the IoT device. Upon verifying the first public key, the AP generates a context based on the first public key received from an authenticator. The context includes information for logging in the IoT device without subsequent communication between the AP, a provisioner, and the authenticator. The AP can use the context to create and transmit an authentication authorization request in response to the chirp signal. In some examples, a chirp table can be created by the provisioner for tracking service APs. The chirp table can be used to provision APs for future chirp signals as needed.

Description

Background Technology

[0001] Internet of Things (IoT) devices are hardware devices that connect to the internet to transmit data to other devices. Examples of IoT devices can include, but are not limited to, sensors, actuators, gadgets, appliances, or machines with internet connectivity. IoT devices are typically equipped with an Internet Protocol (IP) address for connecting to the internet. Protocols such as the Device Procurement Protocol (DPP) can be used to perform procurement and connect IoT devices to wireless networks. DPP is a mechanism promulgated by the Wi-Fi Alliance, a global network of companies aimed at promoting the global adoption of Wi-Fi. Once connected to the internet, IoT devices are able to transmit data and / or receive control signals over wireless networks (e.g., Wi-Fi networks). Attached Figure Description

[0002] This disclosure is described in detail with reference to the following figures, based on one or more different implementations. These figures are provided for illustrative purposes only and depict only typical or example implementations.

[0003] Figure 1 This is a system for enabling IoT devices to log in to a wireless network using the Device Procurement Protocol (DPP), based on the implementation disclosed herein.

[0004] Figure 2 A message flow diagram describing the operation sequence for logging into an IoT device is shown.

[0005] Figure 3 A message flow diagram 300 is shown, which describes the sequence of operations for an example denial-of-service (DoS) attack.

[0006] Figure 4 A message flow diagram is shown, based on the implementation disclosed herein, describing the sequence of operations for mitigating DoS attacks when logging an IoT device into a wireless network.

[0007] Figure 5A and Figure 5B A message flow diagram is shown, based on the implementation disclosed herein, describing the sequence of operations for mitigating DoS attacks on multiple access points within a wireless network.

[0008] Figure 6 This is a flowchart describing the methods performed by the configurator to maintain the DPP chirp table, according to the implementation disclosed herein.

[0009] Figure 7 An example backend network insight dashboard system is shown, which transmits monitoring / test information or data to the frontend network insight system according to the implementation disclosed herein.

[0010] Figure 8This is an example flowchart illustrating example operations for mitigating DoS attacks on a network, based on the implementation disclosed herein.

[0011] Figure 9 This is an example computational component that, based on the implementation disclosed in this paper, can be used to implement various features of DoS attack mitigation.

[0012] Figure 10 This is an example flowchart illustrating example operations for detecting DoS attacks on a network, based on the implementation disclosed herein.

[0013] Figure 11 These are example computer systems that can be used to implement the various features of DoS detection and mitigation disclosed herein.

[0014] These accompanying drawings are not exhaustive and do not limit this disclosure to the exact form disclosed. Detailed Implementation

[0015] When an IoT device (e.g., a sensor or device) wants to establish network connectivity, IoT device provisioning is performed. The IoT device needs to be authenticated and configured to log in to the network. Once authenticated and configured, the IoT device can connect to a wireless network (e.g., a Wi-Fi network) and perform any subsequent logins, such as connecting to a cloud platform.

[0016] The user interface for IoT devices may be limited or nonexistent, posing significant challenges to their access to Wi-Fi networks. Typically, users must manually connect and configure the IoT device from a smartphone or a separate computer. In some cases, manual configuration by a wireless network provider's customer service representative may also be required. This type of manual configuration is impractical for distributing large numbers of IoT devices, as it would consume several man-hours.

[0017] Furthermore, in many cases, the allocation mechanism is insecure, and there is a possibility of data corruption on the IoT device or the IoT cloud platform when the IoT device connects to the wireless network. Therefore, a secure, fast, and user-friendly mechanism is needed to allocate security credentials to IoT devices and then use those credentials to connect the IoT device to the wireless network.

[0018] Based on various aspects of this disclosure, examples for connecting IoT devices to wireless networks are provided. In some examples, as described herein, the allocation of IoT devices and the connection of IoT devices to wireless networks are based on the Device Allocation Protocol (DPP).

[0019] DPP (Distribution Protocol Configuration) overcomes the challenges of logging into IoT devices by facilitating the provisioning of undistributed devices through DPP messages communicated between the Configurator and an Access Point (AP) in the wireless network. The Configurator is the entity that provides security credentials to IoT devices. The Configurator establishes trust in the IoT device's public bootstrapping (“bootstrapping”) key. The AP can act as an agent (i.e., a proxy device) for the Configurator and communicates with an authentication server to obtain the IoT device's public bootstrapping key. The AP can then authenticate and authorize the IoT device using the public bootstrapping key before connecting it to the wireless network. The IoT device can then connect to the wireless network via the AP based on network permission.

[0020] In some examples, the allocation of unallocated IoT devices can be initiated via a DPP presence notification message (also known as a chirp signal or chirp) transmitted from the unallocated IoT device to the AP. However, reliance on DPP presence notification messages opens the possibility of denial-of-service (DoS) attacks, which can disrupt a DPP network by bombarding it with DPP presence notification messages. DPP presence notification messages contain a data hash that includes the IoT device's public bootstrap key. Even if the attacking device does not know the IoT device's bootstrap key, the DPP presence notification message (including the hash) can be spoofed by the attacking device. Traditionally, the AP responds to the first received DPP presence notification message by sending a DPP authorization request message to the authentication server, which includes the hash from the DPP presence notification. The authentication server maintains a database containing chirped hashes of the public bootstrap keys of all IoT devices and checks this database to verify the chirped hashes. If a match is found, the authentication server sends the IoT device's public bootstrap key to the AP. The Access Point (AP) constructs a DPP authentication request based on a public bootstrap key. This DPP authentication request contains a hash of the public bootstrap key obtained from the authentication server. This DPP authentication request is sent to the IoT device to be decoded using a corresponding private key known only to the IoT device, and a DPP authentication response is constructed and sent to the AP. However, an attacking device can send a spoofed DPP presence notification message, including a chirped hash, which the AP responds to with a DPP authorization request. The attacking device cannot respond to the DPP authorization request because it does not know the IoT device's private key; however, the AP will not respond to any subsequent DPP presence notification messages (valid or invalid) until the timeout period has elapsed. Therefore, a legitimate IoT device may be unable to be provisioned and log in. Furthermore, the attacking device can transmit multiple DPP presence notification messages that repeat this process, further delaying or potentially preventing IoT devices from logging in.

[0021] The technology disclosed herein mitigates the aforementioned technical deficiencies of traditional login processes by altering how the AP processes received DPP presence notification messages. According to various implementations disclosed herein, the AP generates a context as part of the allocation to the IoT device in response to receiving a first public key (e.g., a public bootstrap key according to various implementations) from an authentication server. For example, the AP may receive a chirp signal including a data hash containing the first public key of the IoT device and send a chirp event message (e.g., a message indicating that a chirp signal has been received) to a configurator, which allocates the AP (the same or different APs) for logging into the IoT device associated with the hash public bootstrap key included in the chirp signal. The serving AP then receives the first public key for logging into the associated IoT device from the authentication server based on the chirp hash. The serving AP then generates a context for logging into the IoT device corresponding to the first public key (e.g., the public bootstrap key), which includes all the information required to implement the login of the corresponding IoT device.

[0022] Note that the chirp signal may have been received by the AP from the corresponding IoT device or by an attacking device that spoofed an earlier chirp signal from that IoT device. However, as mentioned above, the attacking device will not have the IoT's private bootstrap key.

[0023] The AP responds to received chirps by using the context to generate an authentication request (e.g., a DPP authentication request according to various implementations) that includes a hash of the first public key. In response to each chirp in the received chirps, the AP forwards the authentication request to the device that sent the chirp. In the case of receiving a chirp from an IoT device, the IoT device can decode the authentication request using its first private key (e.g., a private bootstrap key) and send an authentication response to the AP (e.g., a DPP authentication response in the case of a DPP authentication request). The AP can then log in to the IoT device, for example, according to the DPP protocol. In the case of chirps from an attacking device, the attacking device cannot decode the hash and cannot respond. Therefore, by responding to each incoming chirp (instead of waiting for a timeout period), the IoT device can be logged in even if its chirp is sent to the AP simultaneously and / or subsequently by the attacker. In some implementations, after the AP receives an authentication response from the IoT device, the AP ignores future chirp signals containing a hash of the public bootstrap key of the IoT device by suppressing the sending of any further authentication requests and / or reporting of chirp events.

[0024] In some cases, an attacking device or IoT device may hop through multiple channels, each served by a different AP. This hopping may include broadcasting chirps on different channels, received by the individual APs, each sending a corresponding chirp event to the configurator. Where applicable, the configurator assigns one AP (referred to herein as the serving AP) to serve the chirp signal by sending a chirp accept message while simultaneously sending chirp event reject messages to the other APs. In a single AP deployment in DPP, the problem persists because an attacker can overwhelm the AP with chirp messages from multiple MAC addresses, and the AP cannot identify the actual device. However, according to the various implementations disclosed herein, as described above, each AP receiving the chirp signal creates a context for the chirp signal through communication with an authentication server. Therefore, when the serving AP serves the IoT device (and ignores further chirps), any other AP can similarly ignore future chirps from the attacking device and / or the IoT device. According to the example implementation, the configurator can store a chirp table (sometimes referred to as the DPP chirp table in the context of DPP messages) to track which AP is the serving AP, is already a serving AP, and stores the context therein. The chirp table can be used to serve APs that will chirp in the future as needed.

[0025] Some implementations disclosed herein can be configured to operate in conjunction with or under the permissions of a cloud-based network insight system. According to some implementations, the configurator can be part of the cloud-based network insight system and can establish wireless connections to / from the network insight system, which in turn can wirelessly connect to the network insight dashboard system. That is, the network insight system can be a “back-end” system connected to or including the configurator, while the network insight dashboard system can be a “front-end” system. The back-end network insight system can communicate with the configurator and / or the access point (AP) to receive data and metrics for monitoring and tracking network performance. The network insight dashboard system can receive information or data about one or more aspects of the network collected by the back-end network insight system, where the AP is a result of network monitoring or testing aspects, applications running on the network, etc. Users, such as network administrators, can then view or obtain such information or data via the network insight dashboard system, for example, in response to detecting a DoS attack on the network in response to conditions indicating a DoS attack. The network insight dashboard system can be used to illustrate parameters (e.g., operational parameters) or information regarding the configuration used by the network insight system to detect such conditions.

[0026] While the following description is based on DPP messages, the scope of this disclosure should not be construed as limited to specific DPP protocols and / or messages. The reference to DPP messages is used as specific examples of potential sources of DoS attacks that can be mitigated, for example, within DPP.

[0027] Figure 1 This document discloses a system 100 for enabling IoT devices to log in to wireless network 116 using DPP, based on the implementation disclosed herein. In some examples, system 100 may include IoT device 102, authentication server 104, one or more access points (APs), such as APs 106A, 106B, 106C…106N (collectively referred to as AP 106), and configurator 108. AP 106 and configurator 108 may communicate with each other via wired or wireless network. In some implementations, configurator 108 and AP 106 may co-reside in the same physical enclosure. For example, configurator 108 and / or AP 106 may be logical entities or functions described by the services they provide, and the physical representation or network deployment of these logical entities or functions need not be limited to physical devices. During the initial phase, when IoT device 102 is not configured to access wireless network 116, IoT device 102 may communicate with configurator 108 via AP 106 using DPP messages. Once assigned, IoT device 102 can connect to wireless network 116.

[0028] In the example implementation, system 100 may be part of a distributed setup, such as a university network or an enterprise network. In some cases, certain enterprise networks may treat IoT devices as untrusted devices and restrict network access. Such restrictions may limit the types of applications an enterprise can implement through IoT devices. In some examples, DPP-based allocation of IoT device 102 by authentication server 104, as described herein, can ensure secure authentication and configuration of IoT device 102. DPP-based allocation by authentication server 104 allows users to define access policies for IoT device 102 before connecting it to wireless network 116. In various implementations, configurator 108 and authentication server 104 may be part of a cloud platform associated with the enterprise. The term "network access" as used herein can refer to access to a wireless network such as wireless network 116.

[0029] Examples of wireless network 116 may include, but are not limited to, Internet Protocol (IP) or non-IP-based wireless local area networks (WLANs), metropolitan area networks (MANs), wide area networks (WANs), storage area networks (SANs), personal area networks (PANs), cellular communication networks, and the Internet. In some examples, wireless network 116 may include an access point (AP) 106 to facilitate data communication. Communication on the wireless network can be performed according to various communication protocols, such as, but not limited to, Transmission Control Protocol (TCP) and Internet Protocol (IP), User Datagram Protocol (UDP), IEEE 802.11, and / or cellular communication protocols. Communication on wireless network 116 may be implemented via wireless communication technologies (e.g., Wi-Fi, cellular communication, satellite communication, Bluetooth, etc.). In some examples, wireless network 116 may be enabled via a dedicated communication link, which includes, but is not limited to, communication links established via Bluetooth, cellular communication, optical communication, radio frequency communication, etc.

[0030] Based on some examples, Figure 1 The IoT device 102 shown may be configured with security credentials to access the wireless network 116 by transmitting data and DPP messages to the configurator 108 via one or more APs in AP 106. Examples of IoT devices 102 may include, but are not limited to, location tags, activity monitors, connected thermostats, monitoring cameras, sensor devices, or any electronic or mechanical device with internet connectivity. Figure 1 The system 100 depicts a single IoT device 102, but without limiting the scope of this disclosure, the system 100 may include more than one IoT device.

[0031] Furthermore, in some examples, the authentication server 104 can be implemented as a standalone server, may be part of a cloud, or may coexist with another logical entity. In some other examples, the authentication server 104 can be implemented as a hardware system / device, such as, but not limited to, a computer system, mobile device, blade server, computer device, workstation, storage system, or converged or hyperconverged system. In some other examples, the authentication server 104 can be implemented as a software resource, such as, but not limited to, software applications, virtual machines (VMs), containers, containerized applications, or container sets. During operation, the authentication server 104 can facilitate the authentication and / or authorization of the IoT device 102 and manage the login of the IoT device 102 using DPP. DPP is a standardized protocol that allows the IoT device 102 to be assigned for network access using a controller (e.g., configurator 108).

[0032] In some examples, authentication server 104 may maintain bootstrap information for IoT device 102 to facilitate authentication and / or authorization of IoT device 102 and manage login of IoT device 102 to wireless network 116. The term "bootstrap information" as used herein may refer to information such as, but not limited to, the public bootstrap key of IoT device 102. In some examples, the IoT device supplier may embed a bootstrap key pair in the IoT device during manufacturing. The public bootstrap key of IoT device 102 may be registered with external cloud IoT platform 110 or obtained through other means. In some examples, authentication server 104 may query external cloud IoT platform 110 to obtain the bootstrap information of IoT device 102. In response, authentication server 104 may receive the public bootstrap key from external cloud IoT platform 110. In some examples, the bootstrap information may also include the Extended Service Set Identifier (ESSID) of wireless network 116.

[0033] In some examples, authentication server 104 may include a database 105 for storing bootstrap information of IoT device 102. Database 105 may periodically synchronize with external cloud IoT platform 110 to receive and update bootstrap information. In some examples, where the bootstrap information of IoT device 102 is not integrated into external cloud IoT platform 110, the bootstrap information of IoT device 102 may be received out-of-band. For example, the bootstrap information may exist on IoT device 102 in the form of a tag (e.g., a Quick Response (QR) code). A user may use a mobile application to scan the tag to receive the public bootstrap key of IoT device 102. The mobile application may update the public bootstrap key of IoT device 102 at authentication server 104.

[0034] Furthermore, in some examples, AP 106 can be part of a wireless local area network (WLAN) and can provide wireless services to IoT device 102 in the areas covered by each AP 106. Examples of AP 106 may include, but are not limited to, routers, network switches, network gateways, etc. In some examples, one AP 106 can act as a bridge for connecting IoT devices, such as IoT device 102, to wireless network 116. AP 106 can be distributed throughout the area where network access is required. Therefore, IoT device 102 can be deployed in an area served by one or more AP 106.

[0035] In some examples, configurator 108 can assign security credentials to IoT device 102. In some examples, configurator 108 can be implemented using a processor or microcontroller and / or any other electronic components, or devices or systems that can facilitate various computing, data storage, and / or data processing. In some other examples, configurator 108 can be deployed as a software resource, such as a virtual machine (VM), container, containerized application, or container set. Configurator 108 can establish trust in the public bootstrap key of IoT device 102 and authenticate IoT device 102 using the DPP authentication protocol. Figure 2 Describe more details about certification using DPP.

[0036] During operation, configurator 108 can select an AP as the serving AP to perform DPP authentication protocol and DPP configuration control from AP 106 in wireless network 116. The serving AP can be selected based on the Received Signal Strength Indicator (RSSI) and / or the current load of AP 106. RSSI can indicate the radio frequency (RF) signal strength at the corresponding AP 106 in wireless network 116. In some systems, when there is a high density of APs 106 in system 100, configurator 108 can select a specific AP to configure IoT device 102 with connectors (i.e., security credentials). For example, in a high-density deployment of APs in a warehouse, configurator 108 can select an AP present at the login location in the warehouse to help allocate connectors for IoT device 102. As will be understood, selecting an appropriate AP as a proxy (e.g., serving AP) for configurator 108 can reduce the time required to load IoT device 102 onto wireless network 116.

[0037] For illustrative purposes, AP 106B can be selected by configurator 108 based on one or more of the criteria described above. Therefore, AP 106B is referred to hereinafter as serving AP 106B. The terms "AP 106B" and "serving AP 106B" are used interchangeably hereinafter, referring to the AP selected by configurator 108. Serving AP 106B can act as a proxy for configurator 108 for authenticating and configuring IoT device 102 to access wireless network 116. Authentication and configuration of IoT device 102 are performed using the DPP authentication protocol and the DPP configuration protocol, respectively. Specifically, serving AP 106B facilitates the exchange of DPP messages and information between IoT device 102 and configurator 108. Serving AP 106B communicates with IoT device 102 through the DPP communication channel 118 between IoT device 102 and serving AP 106B. DPP communication channel 118 is a dedicated communication medium established between IoT device 102 and serving AP 106B after verifying the public bootstrap key of IoT device 102. A single channel (or a small number of possible channels) can be predefined by AP 106 as DPP communication channel 118. Serving AP 106B can obtain DPP messages on DPP communication channel 118. Serving AP 106B can act as a proxy device for transmitting DPP messages between IoT device 102 and configurator 108. Serving AP 106B can also act as an authenticator to authenticate IoT device 102 on behalf of authentication server 104.

[0038] In some examples, AP 106 may include a corresponding database 107 for storing context 109 for logging into IoT devices. Database 107 may be periodically updated using authentication server 104 to receive and update bootstrapping information for logging into the corresponding IoT devices. For example, as part of the DPP authentication protocol, authentication server 104 transmits bootstrapping information to serving AP 106B. Serving AP 106B generates context 109B for logging into IoT devices corresponding to a public bootstrapping key and stores context 109B in database 107B. Context 109B includes all necessary information for the allocation and login of the corresponding IoT device. For example, context 109B may be configured based on a chirped hash (e.g., SHA256(“chirp”|B RThe bootstrap information is indexed and includes a public bootstrap key, an Extended Service Set Identifier (ESSID), an AKM, a random number, a DPP protocol key, and capabilities (e.g., as a configurator or registrant). The public bootstrap key, SSID, and Authentication and Key Management (AKM, a field in the 802.11 header that allows the AP to announce what type of security it is providing and allows a device to choose one if it is providing more than one security) received from the authentication server 104 can be used in response to a chirped hash and to construct the following DPP message. The random number, DPP protocol key, and capabilities can be generated by AP 106B in response to a chirped HAS and to construct the following DPP message. Furthermore, in some examples, bootstrap information can be provided as part of the DPP authentication process to one or more of the remaining APs 106 (e.g., non-serving APs), and each of the remaining APs 106 can similarly generate a context 109 for assigning to the IoT device corresponding to the bootstrap information.

[0039] In some examples, configurator 108 may include a database 112 for storing DPP chirp tables (or multiple DPP chirp tables) for tracking APs serving IoT devices. The DPP chirp tables may include an entry for each IoT device that has logged into the network. The DPP chirp tables can be provided and updated to maintain a mapping between each IoT device and a list of currently serving APs, any APs previously selected as serving APs (referred to as the served APs), and neighboring APs. IoT devices can be identified by hashes such as their public bootstrap keys. In the event of an IoT device (or any device) hopping between channel frequencies on one or more APs 106, configurator 108 can access the DPP chirp tables to update and maintain the mapping for selecting serving APs.

[0040] Figure 2 A message flow diagram 200 is shown, describing the sequence of operations for logging an IoT device into a wireless network. For illustrative purposes, reference will be made to... Figure 1 The message flow diagram 200 is described using system 100 as a reference. Therefore, for example, message flow diagram 200 provides a sequence of operations for enabling IoT device 102 to log in to wireless network 116. Message flow diagram 200 includes interactions between various entities in system 100, such as IoT device 102, authentication server 104, configurator 108, and serving AP 106B, divided into three phases: initial setup phase 204, allocation phase 206, and network access phase 208. Although message flow diagram 200 is described with reference to system 100, the scope of this disclosure should not be construed as limited to… Figure 1The specific details of system 100 (e.g., the number and arrangement of AP 106, configurator 108, IoT device 102 and authentication server 104).

[0041] During the initial setup phase 204, AP 106B can be configured to listen for DPP messages broadcast on a specific communication channel. Although the initial setup phase 204 is described for AP 106B, it is understood that in some deployments, several APs in wireless network 116 may be configured with corresponding DPP connectors to support DPP communication. For example, in step 210, AP 106B and configurator 108 can establish communication using a network (e.g., a wireless or wired network). Furthermore, at step 212, AP 106B can receive configuration information from configurator 108. The configuration information may include AP 106B's DPP connector. The DPP connector may be a security credential provided to AP 106B by configurator 108. AP 106B can use the DPP connector to establish communication with IoT device 102. In this example, the configuration information may include information about the channel to be used by AP 106B. Once configured, AP 106B can announce its ability to communicate via DPP. In the example, IoT device 102 can scan for channels advertised from AP 106B. Similarly, some or all of the APs in AP 106 can be configured with appropriate DPP connectors and channel connectivity information to support DPP communication.

[0042] In the allocation phase 206, IoT device 102 can be authorized and allocated the security credentials required for network access. IoT device 102 can scan all supported channels upon power-up or at periodic intervals and periodically broadcast DPP presence notification messages. In some implementations, IoT device 102 broadcasts DPP presence notification messages at fixed periodic intervals (e.g., 2 seconds in some examples) while hopping between multiple channel frequencies on one or more APs 106. In one example, the DPP presence notification message can be carried by an 802.11 action frame. The DPP presence notification message includes a hash containing data including the public bootstrap key of IoT device 102. The hash of the data including the public bootstrap key can be an identifier of IoT device 102. For example, the hash of the public bootstrap key included in the presence notification is provided as SHA256 (“chirp”|B R ), where B R This is the public bootstrap key, "chirp" represents additional data, and SHA256 is an example hash function applied to data including the public bootstrap key. The hash transmitted in the DPP authentication request is provided as SHA256(B). RAt step 214, configurator 108 may receive a list of DPP presence notification messages conforming to the DPP protocol from IoT device 102 via AP 106 in wireless network 116. The DPP presence notification messages transmitted by IoT device 102 may be received by AP 106, where DPP capabilities are configured during initial setup phase 204. AP 106 may listen for DPP presence notification messages and may report device chirp events to configurator 108. Configurator 108 may monitor these device chirp events and, at step 216, select an AP (e.g., AP 106B) to initiate DPP communication for IoT device 102.

[0043] After detecting the trusted public bootstrap key of IoT device 102 in step 214, the DPP authentication protocol is initiated at AP 106B by sending a DPP bootstrap authorization request to authentication server 104 in step 218 to check whether the public bootstrap key included in the hash of the data is registered. The serving AP 106B can generate the DPP bootstrap authorization request using a hash of data including the public bootstrap key present in the DPP presence notification message transmitted by IoT device 102. For example, AP 106B constructs a hash including the SHA256(“chirp”|B) received in step 214. R The DPP bootstrap authorization request.

[0044] At step 220, authentication server 104 may verify whether the public bootstrap key in the hash of the data received in the DPP bootstrap authorization request is registered with authentication server 104. For example, authentication server 104 checks database 105 to verify B. RRegistered. Based on successful verification of the bootstrap information, authentication server 104 can authenticate IoT device 102 and verify that IoT device 102 is an authorized (e.g., legitimate) device that can be assigned to access wireless network 116. To verify the public bootstrap key of IoT device 102, authentication server 104 can synchronize with an external cloud IoT platform to periodically receive the public bootstrap key of IoT device 102. If the public bootstrap key of IoT device 102 is registered with external cloud IoT platform 110, authentication server 104 can transmit a positive DPP bootstrap authorization response to service AP 106B containing the bootstrap information (e.g., public bootstrap key) of IoT device 102 and the ESSID of wireless network 116. In some examples, service AP 106B can receive the public bootstrap key to authorize IoT device 102. Because authentication server 104 maintains the public bootstrap key of IoT device 102, duplicate bootstraps of the same IoT device 102 can be avoided when IoT device 102 disconnects and reconnects to system 100. Furthermore, connecting / reconnecting IoT device 102 to wireless network 116 involves little or no human interaction.

[0045] At step 222, the serving AP 106B constructs a DPP authentication request using the public bootstrap key from the authentication server 104. The DPP authentication request includes a hash of the public bootstrap key received from the authentication server 104 and is provided to the IoT device 102. The IoT device 102 can use its private bootstrap key to decode the authentication request and, upon successful decoding, sends a DPP authentication response to the AP 106B. For example, the DPP authentication request may include encrypted data, such as a random number and capabilities. The IoT device 102 decrypts the encrypted data to retrieve the random number and capabilities used to construct the DPP authentication response. At step 222, the DPP authentication protocol is completed. When the AP 106B receives a positive DPP authorization response from the IoT device 102, the AP 106B can complete the DPP authentication of the IoT device 102. The IoT device 102 can generate a public network access key after successful verification of its public bootstrap key.

[0046] At step 224, the DPP configuration protocol is initiated. Once IoT device 102 is authenticated by serving AP 106B, IoT device 102 can send a DPP configuration request to serving AP 106B. The DPP configuration request is sent to serving AP 106B to receive the security credentials of IoT device 102 for network access.

[0047] At step 226, using the public network access key of IoT device 102, the serving AP 106B can generate a connector for IoT device 102 while the DPP configuration request is pending (as shown in step 226). In some examples, the connector for IoT device 102 may include the public network access key of IoT device 102. At step 228, the serving AP 106B may transmit a request to configurator 108 for signing the connector. At step 230, configurator 108 may sign the connector using its configurator login key and send the signed connector back to AP 106B. At step 232, by generating the signed connector, the DPP configuration of IoT device 102 with secure credentials is completed, and the signed connector can be provided to IoT device 102, which can use the signed connector to connect to wireless network 116.

[0048] In other embodiments, the credentials provided to the authenticated IoT device during the configuration state may be a password, with or without a username, or they may be a certificate.

[0049] At step 234, the serving AP 106B may transmit a DPP identity binding request to the authentication server 104 to bind the hash of the public network access key of the IoT device 102 to the hash of the public bootstrap key of the IoT device 102. The hash of the public network access key of the IoT device 102 may be referred to as the connector identifier of the IoT device 102. The binding of the connector identifier hash and the hash of the public bootstrap key of the IoT device 102 allows the authentication server 104 to perform additional verification during network access phase 208, including hashes of data containing the public bootstrap key and connector identifier required by DPP.

[0050] During network access phase 208, IoT device 102 may obtain access to wireless network 116 via any AP 106 using the connector received by IoT device 102 from serving AP 106B, without limiting the scope of this disclosure. However, for simplicity of illustration, in Figure 2 In the network access phase 208 shown, IoT device 102 is described as connecting to wireless network 116 via serving AP 106B.

[0051] In step 236, IoT device 102 can discover any number of APs 106 and transmit a peer discovery request and wait for a peer discovery response. In some examples, IoT device 102 can transmit a peer discovery request to AP 106B. The peer discovery request may include the connector of IoT device 102 (e.g., a signed connector received from the serving AP 106B). The serving AP 106B can verify the connector of IoT device 102 based on the configurator signing key of configurator 108. After successful connector verification, AP 106B can generate a DPP network access authorization request including the connector identifier and transmit it to authentication server 104.

[0052] In step 238, based on the validity of the connector identifier of IoT device 102, authentication server 104 can authenticate and authorize IoT device 102 to access the network. Authentication server 104 can respond with a DPP network access authorization response in the form of allow or deny. Authentication server 104 can verify the hash of the public network access key of IoT device 102 and the hash of the public bootstrap key of IoT device 102 to determine whether to allow or deny IoT device 102 to access the network. Based on the DPP network access authorization response from authentication server 104, in step 240, serving AP 106B can transmit a peer discovery response, which is a response to the peer discovery request received from the IoT device in step 236.

[0053] The serving AP 106B can generate a peer discovery response based on the DPP network access authorization response received from the authentication server 104. At steps 240, 242, and 244, if the authentication server 104 allows the IoT device 102 to access the wireless network 116, the IoT device 102 can export its pairwise master key (PMK) / PMK identity (PMKID), perform IEEE-802.11 authentication, association, and a four-way handshake with the serving AP 106B to obtain access to the wireless network 116.

[0054] As will be understood, in the examples presented herein, authentication server 104 can provide a zero-contact dispensing experience for dispensing security credentials to IoT device 102 and using those credentials to connect IoT device 102 to wireless network 116. When IoT device 102 is brought into system 100 and powered on, the sequence of operations described in message flow diagram 200 can be executed. The entire process from powering on IoT device 102 to connecting to wireless network 116 can be completed in a short time without any human intervention. Furthermore, in some examples, once IoT device 102 is connected to wireless network 116, its network behavior can be continuously monitored. If any security threat is detected, the authentication server 104 can be notified by a monitoring device (not shown). Monitoring of IoT device 102 may include determining several parameters, such as vulnerabilities and risks associated with IoT device 102, the owner of IoT device 102, network behavior, and operating system state. Furthermore, in some examples, the authentication server 104 can evaluate notifications from monitoring devices based on configurable policies (described later) and can change the network access permissions of connected IoT devices 102 by issuing a Change of Authorization (CoA) to service AP 106B. This helps to quickly isolate any compromised IoT devices and prevent security threats from spreading through system 100.

[0055] As described above, at step 214, IoT device 102 broadcasts a DPP presence notification message containing a data hash including the public bootstrap key of IoT device 102. As a result of the broadcast, any device and / or individual listening on the channel frequency transmitting the DPP presence notification can receive the DPP presence notification, including malicious entities. Malicious entities can obtain the DPP presence notification legitimately broadcast by IoT device 102 and use the obtained DPP presence notification to perform a DoS attack on network 116. For example, a malicious entity can manipulate an attacking device (e.g., another IoT device or any device capable of wireless communication on the network) to generate and transmit multiple repetitions of the obtained DPP presence notification from random MAC addresses, thereby bombarding network 116 and blocking the channel frequency, preventing it from being accessed by other legitimate IoT devices. During the rationing phase 206, the MAC address of the device sending the DPP message to the serving AP 106B cannot be verified, therefore system 100 cannot distinguish between the attacking device and a legitimate IoT device, such as IoT device 102. Bootstrap authentication typically does not include MAC addresses. Furthermore, MAC addresses themselves are susceptible to spoofing, and should not be relied upon as identities at least during the authentication process following the presence of a notification message from the DPP at steps 214 to 222. Therefore, even if a MAC address is provided during bootstrapping authentication, it may be untrusted.

[0056] Figure 3 The description of the interruption is shown. Figure 2 The message flow diagram 300 shows the operation sequence of a DoS attack on a wireless network during the allocation phase 206. For illustrative purposes, reference will be made to... Figure 1 The message flow diagram 300 is described using system 100. The message flow diagram 300 includes interactions between various entities in system 100 that are subjected to a DoS attack during the allocation phase 206, such as attack device 302, IoT device 102, authentication server 104, configurator 108, and another AP such as AP 106B and AP 106.

[0057] As described above, a malicious user can use attack device 302 (or another device) to listen to DPP messages broadcast on communication channels of various frequencies on network 116. Specifically, a malicious user can obtain information from IoT device 102, for example... Figure 2 During step 214, one or more DPP presence notification messages are broadcast, and the obtained DPP notification messages contain a hash of data including the public bootstrap key of IoT device 102. However, malicious users and any devices attempting to obtain DPP notification messages will not be able to access (at least through DPP message exchange) the private bootstrap key of IoT device 102.

[0058] Subsequently, as Figure 3 As shown, a malicious user can operate the attack device 302 to execute a DoS attack. In step 310, the attack device 302 scans all supported channels, and... Figure 2 At step 214, a DPP presence notification message is broadcast in the same manner as that of IoT device 102. The DPP presence notification message from attacking device 302 is referred to herein as a spoofed DPP presence notification message because it originates from an invalid / attacking device 302. The spoofed DPP presence notification message includes a data hash containing the public bootstrap key of IoT device 102 (e.g., SHA256 in the example above; or chirp|B in the example above). R This message is then broadcast to AP 106, for example, AP 106B. In some cases, attack device 302 can periodically broadcast spoofed DPP presence notification messages on one or more channel frequencies, thereby bombarding network 116 with a large number of repetitive DPP messages from potentially many different MAC addresses, thus confusing the MAC addresses of genuine IoT devices.

[0059] At step 312, configurator 108 can receive a DPP presence notification message, still conforming to the DPP protocol, from attacking device 302 via AP 106 in wireless network 116. The DPP presence notification message from attacking device 302 appears compliant by spoofing a compliant and legitimate DPP notification message from IoT device 102. The DPP presence notification message is received by AP 106, which reports device chirp events to configurator 108. Configurator 108 can monitor these device chirp events, and at step 314, configurator 108 can select an AP (e.g., AP 106B) to initiate DPP communication.

[0060] At step 316, a DPP bootstrap authentication protocol is initiated at AP 106B to establish trust in the public bootstrap key of IoT device 102 included in the DPP presence notification message, as referenced above. Figure 2 As described. For example, DPP bootstrapping authentication is initiated by sending a DPP bootstrapping authorization request to authentication server 104 to check whether the public bootstrapping key of IoT device 102, included in the hash of the data, has been registered (see [link to documentation]). Figure 2 Step 218). The serving AP 106B can generate a DPP bootstrapping authorization request using a hash of data including the public bootstrapping key of IoT device 102, based on the hash present in the DPP presence notification transmitted by the attacking device 302. The authentication server 104 can verify whether the public bootstrapping key has been registered based on the hash of the data received in the DPP bootstrapping authorization request. Based on the successful verification of the public bootstrapping key, the authentication server 104 can authenticate the DPP presence notification message and verify that the attacking device 302 can be assigned to access wireless network 116 (see step 218). Figure 2 Step 220). After successfully verifying the public bootstrap key of IoT device 102, authentication server 104 sends a positive DPP bootstrap authorization response to service AP 106B containing the bootstrap information of IoT device 102 (i.e., the public bootstrap key) and the ESSID of wireless network 116.

[0061] At step 318, the serving AP 106B provides the attacking device 302 with a hash of the public bootstrap key received from the authentication server 104 by sending a DPP authentication request to the attacking device 302. The attacking device does not have the private bootstrap key of the IoT device 102. Therefore, the attacking device 302 cannot decode or respond to the DPP authentication request.

[0062] However, configurator 108 only responds to the same chirp event after the set timeout period. During this timeout period, at step 320, configurator 108 rejects all chirp events that include the same hash. In the example implementation, the time interval can be 30 seconds; however, this disclosure should not be construed as being limited to this particular interval, as other intervals can be applied depending on the needs of a particular application. Therefore, as Figure 3 As shown, when IoT device 102 broadcasts a subsequent DPP announcement message containing a hash of its public key, these subsequent DPP announcement messages are rejected by configurator 108. As a result, legitimate IoT device 102 is prevented from obtaining DPP authentication requests that allow it to log in to IoT device 102.

[0063] For example, at steps 322 and 328, IoT device 102 periodically broadcasts DPP presence notification messages to AP 106B and any other AP 106 on different frequency channels. At step 326, IoT device 102 waits for a period of time between each DPP presence notification message. At steps 324 and 330, each AP 106B and AP 106 reports a device chirp event to configurator 108. However, due to a spoofed DPP notification message from attacking device 302, the chirp events at steps 324 and 330 are rejected by configurator 108 via chirp event rejection messages, and IoT device 102 cannot log in to network 116.

[0064] Furthermore, the attacking device 302 can examine the time interval between AP (e.g., AP 106A and / or AP 106) processing and sending DPP authentication requests, and increase the rate of spoofed DPP presence notification messages to clog the network and further exhaust AP resources. Additionally, the attack may exhaust the resources of the configurator 108 because when AP 106 receives a DPP presence notification message, it continuously forwards chirp event messages to the configurator 108, which requires resources for resolution and addressing. Therefore, the legitimate IoT device 102 will not receive the DPP authentication request and will not be logged in. Figure 3 The DoS attack shown could cause downtime and data loss on network 116. Furthermore, in large network deployments, it can be difficult to narrow down the scope and locate the malicious entity, thus increasing downtime.

[0065] Figure 4 A message flow diagram 400, illustrating an operational sequence for mitigating DoS attacks when logging an IoT device into a wireless network, is shown according to an implementation disclosed herein. Thus, for example, message flow diagram 400 provides a mechanism to enable the IoT device 102 to log into the wireless network 116 while mitigating DoS attacks. Figure 3The described sequence of operations for a DoS attack. Message flow diagram 400 includes interactions between various entities in system 100, such as IoT device 102, authentication server 104, configurator 108, and service AP 106B, during allocation phase 406. Allocation phase 406 is similar to allocation phase 206, except as provided herein, and initial setup phase 204 and network access phase 208 are combined as described above. Figure 2 It will be carried out as described above. For illustrative purposes, reference will be made to... Figure 1 The system 100 is used to describe the message flow diagram 400; however, the scope of this disclosure should not be construed as limited to Figure 1 Details of system 100 (e.g., the number and arrangement of AP 106, configurator 108, IoT device 102 and authentication server 104).

[0066] As referenced above Figure 3 As described, attack device 302 can acquire and spoof DPP notification messages containing hashes of the public bootstrap keys of IoT devices such as IoT device 102. At step 410, attack device 302 scans all supported channels and broadcasts spoofed DPP presence notification messages, as described above. Figure 3 Step 310 is described. The spoofed DPP presence notification message contains a hash of data including the public bootstrap key of IoT device 102.

[0067] At step 412, configurator 108 can receive a spoofed DPP presence notification message, still conforming to the DPP protocol, via AP 106 in wireless network 116. At step 412, AP 106 receives the DPP presence notification message and reports a device chirp event to configurator 108. Configurator 108 can monitor the device chirp event, and at step 414, can select an AP (e.g., AP 106B) to initiate DPP communication. At step 416, the configurator notifies the serving AP 106B to initiate DPP communication.

[0068] At step 418, a DPP bootstrap authentication protocol is initiated at AP 106B to establish trust in the public bootstrap key of IoT device 102 included in the DPP presence notification message from attacking device 302. For example, as described above, DPP bootstrap authentication is initiated by transmitting a DPP bootstrap authorization request to authentication server 104 to check whether the public bootstrap key of IoT device 102 has been registered (see [link to documentation]). Figure 2Step 218). The serving AP 106B can generate a DPP bootstrapping authorization request using a hash of data including the public bootstrapping key of the IoT device 102 present in the DPP presence notification message transmitted in step 410. The authentication server 104 can verify that the public bootstrapping is registered based on the hash of the data received in the DPP bootstrapping authorization request. Based on the successful verification of the public bootstrapping key, the authentication server 104 can authenticate the DPP presence notification message and verify that the attacking device 302 can be assigned to access the wireless network 116 (see step 218). Figure 2 Step 220). After successfully verifying the public bootstrap key of IoT device 102, authentication server 104 sends a positive DPP bootstrap authorization response to service AP 106B containing bootstrap information of IoT device 102 (e.g., public bootstrap key) and ESSID of wireless network 116.

[0069] At step 420, the serving AP 106B generates a context based on bootstrap information received from the authentication server 104, which is stored in a database (e.g., Figure 1 In database 107B). Specifically, in response to receiving a bootstrap authentication response from authentication server 104, service AP 106B creates a context using the public bootstrap key included in the bootstrap information. This context includes all necessary information on the IoT device (e.g., IoT device 102) corresponding to the bootstrap information for completing rationing phase 206. Using this context, AP 106B does not need to communicate with configurator 108 and / or authentication server 104 in response to subsequent DPP presence notification messages. For example, the context includes an indication of whether AP 106B needs to respond to the chirped hash (e.g., SHA256(“chirp”|B)) received from configurator 108. RThe first flag indicates whether AP 106B is selected to respond to the chirped hash. If AP 106B is not selected to respond to the chirped hash, it should ignore the chirp directly. However, if AP 106B is selected to respond to the chirped hash, it does not need to communicate further with configurator 108. This context may also include a constructed DPP authentication request, from which AP 106B can directly respond to the chirped HAS without reconstruction via communication with configurator 108 and / or authentication server 104. This context may also include a list of MAC addresses from which AP 106B has received the same chirped hash. In some cases, if the length of the MAC list exceeds a threshold, a DoS attack can be inferred. This context may also include a second flag indicating whether AP has received a DPP authentication response from a legitimate IoT device (e.g., in response to a DPP authentication request). The second flag indicates that a DPP authentication response has been received, and AP ignores chirped hashes received from other IoT devices. Therefore, for example, when the AP106B receives a subsequent DPP presence notification message with the same chirped hash, the AP106B can directly respond to the DPP authentication request without additional computation and / or communication, thereby reducing resource consumption. This context can be referenced and used to log in to the appropriate IoT device in response to a subsequently received DPP presence notification message.

[0070] In the example implementation, this can be achieved by including a chirped hash (e.g., SHA256(“chirp”|B) in the DPP presence notification message). R This can be used to index the context. The context may include definitions of whether AP 106B should respond to a received DPP presence notification (e.g., ...). Figure 2 The context may include the syntax or code of the decision made by the configurator 108. This context may also include the public bootstrap key ESSID from the authentication server 104. This context may also include a random number generated by AP 106B, the DPP protocol key, and / or capabilities. This context may also include the DPP authentication request.

[0071] Then, at step 422, the serving AP 106B provides the attacking device 302 with a DPP authentication request that includes a hash of the public bootstrap key. At step 424, since the attacking device 302 does not possess the private bootstrap key of the IoT device 102, the attacking device 302 is unable to decode the DPP authentication request and does not (and cannot) respond.

[0072] Subsequently, in step 426, for example, as described above... Figure 2As described, IoT device 102 broadcasts one or more DPP presence notifications. In one example, the DPP presence notification may be carried by an 802.11 action frame. At step 428, the serving AP 106B checks the database to determine if a context exists for logging into IoT device 102. If no context exists (e.g., in the case of the first DPP presence notification received by AP 106B at step 426), the sequence executes steps 412 to 420 as described above to create a context. If the context does exist, it is accessed to retrieve bootstrap information and a DPP authentication request is generated. At step 430, the serving AP 106B transmits the DPP authentication request to IoT device 102, which includes a hash of the public bootstrap key contained in the context. At step 434, IoT device 102 can decode the authentication request using its private bootstrap key and sends a DPP authentication response to AP 106B upon successful decoding of the authentication request. When an affirmative DPP authorization response is received from IoT device 102, AP 106B can establish a DPP communication channel 118 between the selected AP 106B and IoT device 102. IoT device 102 can generate a public network access key after its public bootstrap key is successfully verified.

[0073] In step 438, as referenced above... Figure 2 As described in step 224, the DPP configuration protocol is initiated in step 440. Simultaneously, in steps 432a to 432n, the attacking device 302 (or other attacking device) may broadcast subsequent spoofed DPP presence notification messages, each of which may contain a hash of data including the public key of IoT device 102. Similar to step 428, in response to each DPP presence notification message, the serving AP 106B checks the database to determine if a context for logging into IoT device 102 exists. Due to the existence of the context for IoT device 102, in steps 436a to 436n, the serving AP 106B may suppress the reporting of chirp events. In some cases, as described above, the serving AP 106B may use this context to send a DPP authentication request. However, in other cases, due to the existence of the context for IoT device 102 and the receipt of a DPP authentication response from the serving AP 106B by IoT device 102, the serving AP 106B may ignore subsequent DPP presence notification messages by suppressing the sending of any further DPP authentication requests.

[0074] Therefore, message flow diagram 400 is combined with the above. Figure 2The same approach is continued, while ignoring any future DPP presence notification messages with existing context. For example, by storing the context including bootstrapping information received from authentication server 104, at step 412, the service AP 106B of the implementation disclosed herein does not need to report to configurator 108 chirp events that might have been rejected due to earlier chirp events (e.g., chirp event rejection messages to the AP). Therefore, service AP 106B is able to complete the login of IoT device 102 while ignoring attacking devices and mitigating DoS attacks.

[0075] Figure 5A and Figure 5B A message flow diagram 500, based on the implementation disclosed herein, describes a sequence of operations for mitigating a DoS attack across multiple access points (APs). Message flow diagram 500 provides a series of operations for enabling an IoT device to log in to the wireless network 116 when the attacking device 302 hops between multiple channel frequencies on one or more APs 106, while mitigating [the impact of attacks on] [other targets]. Figure 3 Described DoS attack. In Figure 5A and Figure 5B In the illustrative example, attack device 302 is shown hopping between AP106B and 106A; however, the scope of this disclosure should not be construed as limited to details (e.g., the number of APs shown) and may include hopping between multiple APs 106. Furthermore, message flow diagram 500 includes interactions between various entities in system 100 during the allocation phase, such as... Figure 3 The attack devices are 302 and configurator 108, AP 106B and AP 106A. For illustrative purposes, references will be made to... Figure 1 The system 100 is used to describe the message flow diagram 500; however, the scope of this disclosure should not be construed as limited to Figure 1 Details of system 100 (e.g., the number and arrangement of AP 106 and configurator 108).

[0076] like Figure 5A and Figure 5B As shown, the configurator 108 can maintain a DPP chirp table 580 (also called a chirp table) to map IoT devices recorded based on their IoT device identifiers (e.g., the corresponding hash of their respective bootstrap keys) to a list of current services (e.g., serving APs), APs that have previously served / configured the corresponding IoT devices, and a list of neighboring APs. For example, as Figure 5A and Figure 5BAs shown, example DPP chirp table 580 includes entries for mapping APs to identifiers of IoT devices (e.g., STAs in this example). Table 580 includes: a serving AP column, which includes a field indicating the currently selected AP for serving identifier STA; a served AP column, which includes a field listing APs that previously served identifier STA; and a neighboring AP column, which lists APs that have reported chirp events to configurator 108, including the identifier STA. Thus, table 580 associates each corresponding IoT device identifier with a serving AP, a served AP, and neighboring APs. During the operation shown in message flow diagram 500, DPP chirp table 580 is updated to DPP chirp tables 580A through 580D, and will be collectively referred to as DPP chirp table 580. Figure 5A and Figure 5B Table 580 shown depicts a single IoT device identifier for illustrative purposes only. Table 580 may include a separate entry for each IoT device identifier that has reported a chirp event to configurator 108.

[0077] In message flow diagram 500, for this illustrative example, AP 106A and AP 106B operate at different frequencies, and attack device 302 sends DPP chirp signals (e.g., DPP presence notification messages) at different frequencies before receiving a DPP authentication request, for example, as described above. Figure 3 As described. In this illustrative example, a timeout period of X seconds is provided for the allocation phase (where X is an integer to be selected for a given application), such that if all DPP chirp signals received by the serving AP are from an illegitimate / invalid device (e.g., the serving AP does not receive a DPP authentication response within the timeout period), the configurator 108 will select another AP to allocate to the IoT device identified by the DPP chirp signal.

[0078] At steps 510, 520, and 530, the attacking device 302 broadcasts as referenced above. Figure 3 The DPP chirp signal is described above. For example, in steps 510 and 530, one or more spoofed DPP chirp signals are broadcast on the first channel frequency, which are received by AP 106B. During the same time period, in step 520, the attacking device 302 broadcasts one or more spoofed DPP chirp signals received by AP 106A on the second channel frequency. The spoofed DPP presence notification message includes the identifier of the IoT device (e.g., a hash of data including the IoT device's public bootstrap key, denoted as "STA" or station).

[0079] At step 512, configurator 108 can receive a list of DPP chirp signals from attacking device 302 via AP 106B. AP 106B can listen for DPP chirp signals from attacking device 302 and report device chirp events to configurator 108. Configurator 108 can monitor these chirp events and, at step 514, select an AP (e.g., AP 106B) to initiate DPP communication based on the identifiers of IoT devices included in the DPP chirp signals. Furthermore, at step 515, DPP chirp table 580 is updated to include identifiers of IoT devices (e.g., STAs), and AP 106B is selected as the serving AP. Additionally, the served AP field and neighboring AP field of the IoT device identifier are updated to include AP 106B.

[0080] As referenced above Figures 2 to 3 As described, a DPP bootstrap authentication protocol is initiated at AP 106B to establish trust in the identifier of the IoT device included in the DPP chirp signal. Based on successful identifier verification, the authentication server ( Figure 5A and Figure 5B (Not shown) can authenticate DPP chirp signals and verify that attack device 302 can be assigned to access wireless network 116. After successfully verifying the identifier, the authentication server transmits an affirmative DPP bootstrapping authorization response with bootstrapping information to the serving AP 106B.

[0081] At step 516, the serving AP 106B generates a context based on bootstrap information received from the authentication server, such as information about... Figure 4 Step 420 is described. Specifically, in response to receiving a bootstrap authentication response, the serving AP 106B uses the public bootstrap key included in the bootstrap information to create a context.

[0082] At step 518, the serving AP 106B provides the hash of the public bootstrap key to the attacking device 302 by sending a DPP authentication request. The attacking device does not possess the private bootstrap key of the IoT device. Therefore, the attacking device 302 cannot decode the hash of the public bootstrap key and cannot respond to the DPP authentication request.

[0083] As described above, at step 520, the attacking device 302 broadcasts a spoofed DPP chirp signal received by AP 106A on the second channel frequency. At step 522, the configurator 108 receives a list of DPP chirp signals from the attacking device 302 via AP 106A. The configurator 108 monitors these chirp events, and at step 526, the configurator 108 rejects the chirp event via a chirp event rejection message because it includes the identifier of an IoT device that has already been assigned to AP 106B. At step 524, the configurator 108 adds AP 106A to the DPP chirp table as a neighboring AP based on received chirp events with the same hash.

[0084] At step 528, AP 106A generates a context based on the received bootstrapping information, such as regarding Figure 4 Step 420 is described. For example, AP 106A uses a chirped event rejection message to construct a context for discarding (or ignoring) future DPP chirped signals that contain the same chirped hash.

[0085] At step 530, AP 106B receives one or more subsequent DPP chirp signals broadcast on the first channel frequency from attacking device 302. Due to the context present at AP 106B, at step 532, the serving AP 106B provides the hash of its public bootstrap key to attacking device 302 by sending a DPP authentication request. Again, attacking device 302 cannot respond to the DPP authentication request.

[0086] At step 534, AP 106A receives one or more subsequent DPP chirp signals broadcast on the second channel frequency from attack device 302. Since there is context at AP 106A and AP 106A is not assigned to serve IoT devices, at step 536, AP 106A ignores the DPP chirp signals and suppresses the transmission of DPP authentication requests or the reporting of chirp events.

[0087] After the timeout period has elapsed, at step 538, APs 106A and 106B remove the context from their respective databases (e.g., by deleting the context). Then, in response to a subsequent DPP chirp signal from attacking device 302 during the second time period, message flow diagram 500 can be repeated. Furthermore, configurator 108 deselects AP 106B as the serving AP from DPP chirp table 580 (e.g., DPP chirp table 580b), while maintaining a list of served APs and neighboring APs from DPP chirp table 580A. When a serving AP is cleared, the entries for the served AP and neighboring APs are compared; if they have the same entry, the served AP is cleared. Otherwise, as shown in DPP chirp table 580B, the served AP entry is maintained.

[0088] During the second time period following the timeout of AP 106B during the first iteration of message flow 500, any new chirp event from AP 106B will be rejected via a chirp event rejection message. For example, at step 540, AP 106B receives a DPP chirp signal and reports it as a chirp event to configurator 108 at step 542. At step 546, configurator 108 checks DPP chirp table 580 and verifies that AP 106B has been assigned to serve the IoT device identified by the chirp event, and that the AP list in the served AP field for that identifier does not match the AP list in the neighbor AP field (e.g., != operator). As a result, at step 544, configurator 108 rejects the chirp event via a chirp event rejection message. At step 548, AP 106B generates a context based on the received bootstrapping information, for example, as described above.

[0089] A new DPP chirp signal will be received from another AP, and the DPP chirp table 580 for the IoT device identifier can be updated. For example, in step 550, AP 106A receives a DPP chirp signal from attacking device 302, and reports the chirp signal as a chirp event in step 552. Configurator 108 checks the DPP chirp table 580 and confirms that AP 106A is not listed in the Served AP field for the identifier STA. Configurator 108 accepts the chirp event, and at step 554, selects AP 106A to initiate DPP communication based on the hash of the data of the public bootstrap key included in the DPP chirp signal. At step 556, the DPP chirp table 580 is updated to include AP 106A as a serving AP and listed in the Served AP field (see DPP chirp table 580C). In step 558, AP 106A generates a context based on the bootstrap information received, for example as described above, and in step 560 transmits a DPP authentication request to attack device 302. As before, attack device 302 is unable to decode or respond to the DPP authentication request.

[0090] After the second timeout period, in step 562, APs 106A and 106B remove their contexts from their respective databases. Following step 562, any new DPP chirp signal including the identifier STA is accepted because the AP list in the served AP field matches the AP list in the neighboring APs, which clears the served AP field to restart the sequence (see DPP chirp table 580D). Thus, for example, in step 564, a DPP chirp signal is received at AP 106B, which reports chirp event 566 to configurator 108. At this point, all APs listed in the neighboring AP entries match the APs already assigned to serve the identified IoT device. Therefore, in step 568, the served AP field is cleared while the neighboring AP list is maintained. Then, in step 570, the configurator reselects AP 106B as the serving AP and accepts the chirp in step 572 to initialize DPP communication based on the IoT device identifier included in the DPP chirp signal. At step 574, AP 106B generates a context based on the bootstrap information received, for example as described above, and sends a DPP authentication request to attack device 302 at step 576. As before, attack device 302 cannot decode the hash of the public bootstrap key and cannot respond to the DPP authentication request. This sequence can be repeated at step 578 to select different APs as needed.

[0091] Therefore, in Figure 5A and Figure 5B In the example multi-AP scenario shown, the disclosed implementation ensures that a legitimate IoT device can eventually be assigned. For example, if AP 106B hears a DPP chirp signal from a legitimate IoT device during the first timeout period, AP 106B can be assigned within the first X seconds. Furthermore, if AP 106A hears a DPP chirp signal from a legitimate IoT device during the second timeout period, AP 106A can be assigned within the second X seconds.

[0092] Figure 6 This is a flowchart describing a method 600, according to the disclosure herein, for implementing operations performed by a configurator maintaining a DPP chirp table. Method 600 provides a sequence of operations for monitoring and mapping serving APs and served APs in a wireless network, while the device hops between multiple channel frequencies on multiple APs. Specifically, method 600 shows operations for determining whether to accept or reject chirp events received from the device via an AP and updating the DPP chirp table 630. Method 600 includes operations performed by a configurator, such as configurator 108, during a allocation phase based on interactions with AP 106 of system 100. For illustrative purposes, reference will be made to... Figure 1 The method 600 is described using system 100; however, the scope of this disclosure should not be construed as limited to system 100. Figure 1 Details of system 100 (e.g., the number and arrangement of AP 106 and configurator 108).

[0093] At box 602, configurator 108 receives chirp events from AP 106 (e.g., AP 106A in this example). For example, as described above, a chirp event can be reported by one of APs in AP 106 in response to receiving a DPP chirp signal. At box 604, the DPP chirp table is accessed and updated, for example, by removing any obsolete APs from the table (e.g., an AP that has not reported a chirp event for a defined time period should be removed from the list of neighboring APs and served as "obsolete APs") and adding AP 106A to the neighboring AP field associated with the identifier of the IoT device included in the chirp event. For example, as... Figure 6 As shown, example DPP chirp table 630 includes entries for mapping APs to identified IoT devices, such as a hash of their public bootstrap key (e.g., STA1 in this example). Table 630 includes a serving AP column with a field indicating the identifier of the IoT device currently being served (e.g., AP 106B in this example), a served AP column with a field indicating any APs that have previously served the identified IoT device, and a neighboring AP column with a field listing all known APs that have reported chirp events including the identifier of the IoT device. Thus, table 630 associates the IoT device identifier with the serving AP, the served AP, and the neighboring AP. In the illustrative example, with box 602 being the first instance of AP 106A reporting a chirp event including STA1, AP 106A is added to the neighboring APs in box 604.

[0094] At box 606, configurator 108 checks the serving AP field in DPP chirp table 630 to look for the IoT device identifier included in the chirp event received at box 602. If the serving AP field is populated with entries (e.g., not empty), the method proceeds to box 608, where the configurator compares the AP listed in the serving AP field with the AP that sent the chirp event at box 602. If the serving AP equals (e.g., matches) the AP that sent the chirp event (e.g., AP 106A in this example), then at box 610, the configurator accepts the chirp event and instructs AP 106A to initialize DPP communication based on the IoT device identifier included in the DPP chirp signal (e.g., as referenced). Figure 5A and Figure 5B (as described in steps 514, 554, and 572). Otherwise, at box 612, configurator 108 rejects the chirping event (e.g., as referenced). Figure 5A and Figure 5B(as described in steps 526 and 544).

[0095] Returning to box 606, if the serving AP entry is not populated with entries (e.g., empty), the method proceeds to box 614, where the configurator 108 searches the serving AP field of the IoT device's identifier for the AP (e.g., AP 106A) that sent the chirp event in box 602. If AP 106A is not listed as a served AP in the DPP chirp table 630, the configurator 108 accepts the chirp event at box 616 and instructs AP 106A to initialize DPP communication based on a hash of the data included in the DPP chirp signal (e.g., as referenced). Figure 5A and Figure 5B (As described in steps 514, 554, and 572). Additionally, in box 616, the DPP chirp table 630 is updated to include AP 106A in the Service AP field, and the Service AP field associated with the identifier of the IoT device included in the chirp event received at box 602 is also included in the Service AP field.

[0096] If, at box 614, configurator 108 locates AP 106A in the Serving AP field of the IoT Device Identifier, then at box 618, configurator 108 compares the AP listed in the Serving AP field with the AP listed in the Neighboring AP field. If the entries are the same, then at box 620, configurator 108 updates the DPP chirp table 630 by clearing the Served AP field and proceeds to box 616. Otherwise, configurator 108 rejects the chirp event at box 622, the same as in box 612.

[0097] Figure 7 An example is shown where sensor 710 transmits monitoring / test information or data to a front-end network insight dashboard system 730, where dashboard 736 may be implemented or presented to a user via a back-end network insight system 720. For example, the network (e.g., Figure 1The owner or administrator of network 116 may be interested in determining the current state / status of the network, applications running on it, etc. Sensor 710 may be connected to or otherwise communicatively coupled to backend network insight system 720 via device gateway 722 (e.g., via wired or wireless connection). Sensor 710 may be implemented, for example, as a configurator (e.g., configurator 108 described herein) and / or an access point (e.g., access point 106 described herein). Sensor 710 may transmit monitoring information / data 711 to backend network insight system 720 in response to detecting certain conditions in the network. API gateway 724 of backend network insight system 720 may then forward or transmit the monitoring information / data 725 to dashboard system 730. Monitoring or test information / data may be presented to the user via dashboard 736 of dashboard system 730 (which may be a computer, workstation, laptop computer, or other computing / processing system or component capable of receiving and presenting such information / data).

[0098] In the example where sensor 710 is implemented as configurator 108, a DPP chirp table can be used to detect conditions indicating an attack on network 116. For example, as described above, sensor 710 can use the DPP chirp table to detect conditions suggesting a DoS attack by identifying multiple APs that have failed to successfully log on (e.g., have not received a DPP authentication response in response to a DPP authentication request). That is, sensor 710 can use a DPP chirp table maintained in a database coupled thereto to track the number of APs that have been assigned a service IoT device identifier but have not received a DPP authentication response within the timeout period. For example, refer to... Figure 5A and Figure 5B Taking the sequence as an example, APs 106A and 106B did not receive a DPP authentication response throughout the entire sequence without a timeout period, and as a result, APs 106A and 106B were listed in the served APs and neighboring APs (e.g., according to...). Figure 6 (The method is as follows). If, for a given IoT identifier entry, the number of APs listed in the Service AP field exceeds a set AP threshold number (e.g., configured by the user via the front-end network insight dashboard system 730), the configurator 108 determines that a condition indicating a DoS attack exists and transmits a notification of the detected condition to the front-end network insight dashboard system 730, which notifies the user of the potential DoS attack. Otherwise, if the number of APs is below the threshold, this may indicate other problems, such as poor signal strength. The AP threshold number can be set to any positive integer as needed to identify an attack. The user can then perform remedial actions to locate and resolve the potential attack.

[0099] In another example, sensor 710 can be implemented as AP 106, and sensor 710 can be configured to track multiple DPP presence notification messages received in a set time unit. If the number of DPP presence notification messages received by sensor 710 exceeds a threshold number of DPP presence notification messages, sensor 710 determines that a condition indicating a potential DoS attack is in progress and generates a notification to report the detected DoS attack to the user. As another example, sensor 710 can determine that a condition indicating a potential DoS attack exists when sensor 710 receives the same DPP presence notification messages (e.g., containing the same chirped hash) from different MAC addresses from a threshold number of sources. For example, sensor 710 transmits the notification directly or indirectly (e.g., via configurator 108) to backend network insight system 720. Backend network insight system 720 then forwards or transmits the notification as information / data 725 to dashboard system 730. The time unit and the threshold number of DPP presence notification messages can be set by the user through dashboard system 730. By receiving notifications from one or more specific sensors 710 implemented as AP 106, the location of a malicious entity (e.g., a source of a DoS attack) can be narrowed down to the location of one or more APs that have detected conditions indicating an attack.

[0100] In some examples, sensor 710 can be implemented in combination as configurator 108 and AP 106. In such a configuration, sensor 710 can detect multiple conditions to better assist users in predicting and resolving detected DoS attacks on the network. For example, configurator 108 can detect attackers hopping frequencies on multiple APs via a DPP chirp table, which may not meet the condition of detecting attacks at each AP individually. Instead, each AP 106 can detect attackers locally (e.g., on the AP itself). Therefore, sensors 710 can operate together to provide network-wide detection of potential DoS attacks, which users can identify and implement remedial actions to avoid downtime and data loss in the network.

[0101] Figure 8 This is a flowchart illustrating an example operation for mitigating DoS attacks on a network according to an embodiment disclosed herein. Figure 8 Process 800 is shown, which can be implemented, for example, stored in... Figure 1 The instructions in the memory of access point 106, when executed by one or more processors, perform the operation of process 800.

[0102] At box 802, the AP receives a message from the configurator indicating that the AP has been configured for logging into IoT devices. This message may contain a data hash including the IoT device's first public key (e.g., a data hash including the public bootstrap key, such as SHA256 (“chirp”)|B RThe message can be received based on a chirp event received by the configurator from the AP or another AP, which is a chirp signal received by the AP or the other AP in response to the AP receiving a chirp signal containing a hash of data including the first public key of the IoT device. For example, the chirp signal could be a DPP presence notification message, and the message received from the configurator could be a DPP initialization message accepting the chirp event, as described above regarding... Figure 2 and Figure 4-6 The AP can be, for example, AP 106B, and the configurator can be... Figure 1 The configurator 108. The AP can receive chirp signals from IoT devices or other devices such as attack devices.

[0103] At box 804, based on the data hash assigned for logging into the IoT device, the AP receives verification of the IoT device's first public key from the authentication server, based on a data hash including the IoT device's first public key. For example, the authentication server could be... Figure 1 The authentication server 104 can perform DPP bootstrap authentication, as per [reference needed]. Figures 2 to 4 As described.

[0104] At box 806, the AP generates a context based on the first public key. This context includes the information needed to log the IoT device onto the network (e.g., network 116). For example, the context can be used to log the IoT device without subsequent communication with the configurator and authenticator. (See above regarding...) Figure 4 Generate the context as described in Figure 5.

[0105] Then, at box 808, the AP transmits an authorization request based on the context, in response to each of the plurality of first chirp signals. For example, the AP generates the authorization request without reporting the chirp event to the configurator, and determines at the AP to send the authorization request (e.g., a DPP authorization request), for example, as combined above. Figure 3 and Figure 4 As described. The authorization request includes a hash of the first public key, which the attacking device cannot decipher due to the lack of the corresponding first private key. Therefore, the attacking device will not send an authentication response. However, the AP can use this context to send a subsequent authentication request in response to receiving a subsequent chirp signal, and, in the case of a valid IoT device with the first private key, receive the authentication response and establish a communication channel with the IoT device (e.g., DPP communication channel 118).

[0106] Figure 9 This is an example computational component, based on the implementation disclosed in this paper, that can be used to implement various features of DoS attack mitigation. Now refer to... Figure 9 The computing component 900 can be, for example, a server computer, a controller, or any other similar computing component capable of processing data. Specifically, Figure 9 It is possible Figure 1 This is implemented in access point 106. Figure 9 In the example implementation, computing component 900 includes hardware processor 902 and machine-readable storage medium 904.

[0107] Hardware processor 902 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in machine-readable storage medium 904. Hardware processor 902 may fetch, decode, and execute instructions, such as instructions 906 to 912, to control a burst preloading process or operation for estimating available bandwidth. As an alternative to or supplement to retrieving and executing instructions, hardware processor 902 may include one or more electronic circuits comprising electronic components for the function of executing one or more instructions, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other electronic circuits.

[0108] Machine-readable storage media, such as machine-readable storage media, can be any electrical, magnetic, optical, or other physical storage device that contains or stores executable instructions. Therefore, machine-readable storage media 904 can be, for example, random access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable read-only memory (EEPROM), storage devices, optical discs, etc. In some implementations, machine-readable storage media 904 can be a non-transient storage medium, where the term "non-transient" excludes transient propagation signals. As described in detail below, machine-readable storage media 904 can be encoded with executable instructions, such as instructions 906 to 912.

[0109] Hardware processor 902 can execute instruction 906 to receive a chirp signal from the device, the chirp signal containing a data hash including the first public key of the IoT device (e.g., a data hash including a public bootstrap key, such as SHA256 (“chirp”|B R The first public key is used to log in to the IoT device corresponding to the hash. For example, the chirp signal could be a DPP presence notification message received from the IoT device or another device, such as the attacking device.

[0110] Hardware processor 902 can execute instruction 908 to receive verification of the first public key of the IoT device from the authentication server based on the hash in the received chirp signal. For example, in response to receiving a chirp signal, hardware processor 902 can execute instruction to transmit the chirp event to a configurator. The configurator can accept the chirp event and assign it to hardware processor 902 to serve the IoT device corresponding to the first public key, or reject the chirp event. In either case, hardware processor 902 can execute instruction to transmit a key authorization request to the authentication server (e.g., as described above) in response to receiving a response to the chirp event from the configurator. Figure 2 and Figure 4 The aforementioned bootstrap key authentication request.

[0111] Hardware processor 902 executes instructions 910 to generate a context based on a first public key. This context includes information needed to log IoT devices onto a network (e.g., network 116). For example, the context can be used to adapt IoT devices without subsequent communication with configurators and authenticators. (See above regarding...) Figure 4 Generate the context as described in Figure 5.

[0112] Hardware processor 902 can execute instructions 912 to transmit an authorization request based on context in response to each of a plurality of first chirp signals. The authorization request includes a hash of the first public key. For example, hardware processor 902 can execute instructions to generate an authorization request without reporting the chirp event to the configurator and determine the transmission of the authorization request (e.g., a DPP authorization request), for example, as described above regarding... Figure 3 and Figure 4 As described. Because the attacking device cannot decode the hash included in the authorization request, it does not send an authentication response. However, the hardware processor 902 can execute instructions to use the context to send a subsequent authentication request in response to receiving a subsequent chirp signal, and in the case of a valid IoT device with the first private key, receive the authentication response and establish a communication channel with the IoT device (e.g., DPP communication channel 118).

[0113] Figure 10 This is a flowchart illustrating example operations for detecting DoS attacks on a network, based on various implementations disclosed herein. Figure 10 Process 108 is shown, which can be implemented, for example, stored in... Figure 1 The instructions on the memory of the configurator 108, when executed by one or more processors, perform the operation of the execution process 1000.

[0114] At box 1002, a chirp table is generated, including entries for multiple IoT device identifiers. For example, see Figure 5 above. Figure 6 The described DPP chirp table. Each entry in the chirp table includes a serving access point field, a served access point field, and a neighboring access point field associated with the corresponding IoT device identifier.

[0115] At box 1004, configurator 108 receives multiple chirp event messages from multiple APs 106 on network 116 in response to chirps from one or more devices (e.g., IoT devices and / or other devices). Each chirp includes an identifier for the IoT device, such as a hash of the IoT device's first public key (e.g., a public bootstrap key). In some cases, the chirp can be spoofed and communicated by an attacker 302.

[0116] At box 1006, configurator 108 determines whether to accept or reject each of a plurality of chirp event messages based on a chirp table of identifiers of reference IoT devices. For example, the configurator locates the identifier of the IoT device in the chirp table and determines, based on the chirp table, whether to accept or reject each chirp event sent by the corresponding AP, for example, as shown above with reference to Figure 5 and... Figure 6 As described.

[0117] At box 1008, the configurator updates the chirp table by populating the service access point field, the served access point field, and the neighbor access point field associated with the identifier of the IoT device based on multiple chirp events. For example, as described above in conjunction with Figure 5 and Figure 6 The described method utilizes access points to update fields associated with the identifier of an IoT device in a chirp event.

[0118] In box 1010, the configurator detects denial-of-service attacks by monitoring the access point field being served. For example, as referenced above. Figure 7 As described, configurator 108 checks whether the number of access points listed in the service access point field of the chirp table exceeds a set threshold number of access points. If the number in the service access point field exceeds the threshold, the configurator determines that conditions indicating a DoS attack exist on the network. In response to this detection, the configurator can notify the user of a potential DoS attack via a front-end dashboard system, such as regarding... Figure 7 As described.

[0119] Figure 11 A block diagram of an example computer system 1100 in which various implementations described herein may be implemented is shown. The computer system 1100 includes a bus 1102 or other communication mechanism for transmitting information, and one or more hardware processors 1104 coupled to the bus 1102 for processing information. The hardware processors 1104(s) may be, for example, one or more general-purpose microprocessors. The computer system 1100 may be implemented as... Figure 1One or more of the following: IoT device 102, access point 106, configurator 108, authentication server 104, etc.

[0120] Computer system 1100 also includes main memory 1106, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 1102, for storing information and instructions to be executed by processor 1104. Main memory 1106 can also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 1104. When these instructions are stored in storage media accessible to processor 1104, they present computer system 1100 as a special-purpose machine customized to perform the operations specified in the instructions.

[0121] Computer system 1100 also includes a read-only memory (ROM) 1108 or other static storage device coupled to bus 1102 for storing static information and instructions of processor 1104. Storage devices 1110, such as disks, optical discs, or USB thumb drives (flash drives), may be provided and coupled to bus 1102 for storing information and instructions.

[0122] Computer system 1100 can be coupled via bus 1102 to a display 1112 for displaying information to a computer user, such as a liquid crystal display (LCD) (or touchscreen). Input device 1114, including alphanumeric keys and other keys, is coupled to bus 1102 for transmitting information and command selections to processor 1104. Another type of user input device is cursor control 1116, such as a mouse, trackball, or arrow keys, for transmitting directional information and command selections to processor 1104 and for controlling cursor movement on display 1112. In some implementations, the same directional information and command selections as cursor control can be achieved by receiving touches on a touchscreen without a cursor.

[0123] The computing system 1100 may include a user interface module to implement a GUI that can be stored in a mass storage device as executable software code that can be executed by the computing device(s). This module and other modules may include, for example, components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0124] Generally, the terms "component," "engine," "system," "database," and "data storage" used in this article can refer to logic implemented in hardware or firmware, or to a set of software instructions that may have entry and exit points written in a programming language such as Java, C, or C++. Software components can be compiled and linked into executable programs installed in dynamic link libraries, or can be written in interpreted programming languages ​​such as BASIC, Perl, or Python. It should be understood that software components can be invoked from other components or themselves, and / or can be invoked in response to detected events or interrupts. Software components configured to execute on a computing device can be provided on a computer-readable medium such as an optical disc, digital video disc, flash drive, magnetic disk, or any other tangible medium, or as a digital download (and can be initially stored in a compressed or installable format that requires installation, decompression, or decryption before execution). Such software code can be stored, in part or in whole, on a storage device executing the computing device. Software instructions can be embedded in firmware such as an EPROM. It should also be understood that hardware components may include connected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.

[0125] Computer system 1100 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in combination with the computer system, make computer system 1100 a special-purpose machine or program it as such. According to one embodiment, the techniques herein are executed by computer system 1100 in response to processor(s) 1104 executing one or more sequences of one or more instructions contained in main memory 1106. Such instructions may be read into main memory 1106 from another storage medium, such as storage device 1110. Execution of the instruction sequence contained in main memory 1106 causes processor(s) 1104 to perform the process steps described herein. In alternative implementations, hardwired circuitry may be used in place of or in combination with software instructions.

[0126] As used herein, the term "non-transient medium" and similar terms refer to any medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such non-transient media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks, such as storage device 1110. Volatile media include dynamic memory, such as main memory 1106. Common forms of non-transient media include, for example, floppy disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassette tapes, and their networked versions.

[0127] Non-transient media differ from transmission media, but can be used in conjunction with them. Transmission media participate in the transmission of information between non-transient media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including the wires that constitute bus 1102. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0128] Computer system 1100 also includes a communication interface 1118 coupled to bus 1102. Network interface 1118 provides bidirectional data communication coupling with one or more network links connected to one or more local networks. For example, communication interface 1118 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, network interface 1118 may be a Local Area Network (LAN) card to provide data communication connectivity to a compatible LAN (or a WAN component communicating with a WAN). Wireless links may also be implemented. In any such implementation, network interface 1118 transmits and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

[0129] Network links typically provide data communication to other data devices via one or more networks. For example, a network link can provide a connection to a host computer or to a data device operated by an Internet Service Provider (ISP) via a local network. The ISP then provides data communication services through a global packet data communication network now commonly referred to as the "Internet." Both local networks and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. Signals carried by various networks and on network links and through communication interface 1118 carry digital data to and from computer system 1100; these are examples of transmission media.

[0130] Computer system 1100 can transmit messages and receive data, including program code, through multiple networks, network links, and communication interface 1118. In the example of the Internet, the server can transmit request code for the application through the Internet, ISP, local network, and communication interface 1118.

[0131] The received code may be executed by processor 1104 when it is received, and / or stored in storage device 1110 or other non-volatile memory for later execution.

[0132] Each process, method, and algorithm described in the foregoing sections can be implemented in a code component executed by one or more computer systems or computer processors, including computer hardware, and can be fully or partially automated by them. One or more computer systems or computer processors can also operate to support the execution of related operations in a “cloud computing” environment or as “Software as a Service” (SaaS). These processes and algorithms can be implemented, partially or entirely, in dedicated circuitry. The various features and processes described above can be used independently of each other or can be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process blocks may be omitted in some implementations. The methods and processes described herein are not limited to any particular sequence, and the blocks or states associated with them can be executed in other suitable sequences, or can be executed in parallel, or in some other way. Blocks or states can be added to or removed from the disclosed example implementations. The execution of certain operations or processes can be distributed among computer systems or computer processors, residing not only within a single machine but also deployed across multiple machines.

[0133] As used herein, circuits can be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms can be used to construct the circuit. In implementation, the various circuits described herein can be implemented as discrete circuits, or the described functions and features can be shared partially or wholly among one or more circuits. Even though various features or elements of a function can be described or claimed separately as separate circuits, these features and functions can be shared among one or more common circuits, and such description should not require or imply the need for separate circuits to implement these features or functions. In the case of implementing circuits wholly or partially using software, such software can be implemented to operate with a computing or processing system (such as computer system 1100) capable of performing the functions described therefor.

[0134] As used herein, the term “or” can be interpreted as inclusive or exclusive. Furthermore, descriptions of resources, operations, or structures in the singular form should not be construed as excluding the plural form. Conditional languages, such as “may,” “can,” “able,” or “possibly,” among others, are generally intended to convey that some implementations include certain features, elements, and / or steps that others do not, unless specifically stated or otherwise understood in the context in which they are used.

[0135] Unless otherwise expressly stated, the terms and phrases used in this document, and their variations thereof, should be interpreted as open-ended, not restrictive. Adjectives such as “routine,” “traditional,” “normal,” “standard,” “known,” and similar terms should not be interpreted as limiting the described items to a given time period or items available at a given time, but should be understood to include routine, traditional, normal, or standard techniques that may be available or known now or in the future. In some cases, the appearance of expanded words and phrases such as “one or more,” “at least,” “but not limited to,” or other similar phrases should not be interpreted as indicating an intention to or requirement of a narrower scope where such expanded phrases might not be available.

Claims

1. A method for authentication, comprising: The access point (AP) receives from the configurator a message indicating that the AP is configured for logging into an Internet of Things (IoT) device, the message containing a data hash including a first public key of the IoT device, and receives the message based on another message received by the configurator from the AP or the other AP in response to the AP or another AP receiving the data hash including the first public key of the IoT device; Based on the data hash of the IoT device, which is assigned for logging into the IoT device, the AP receives the first public key of the IoT device from the authentication server for verification. The AP generates a context based on the first public key, wherein the context includes information for logging the IoT device onto the network without subsequent communication between the AP and the configurator, and between the AP and the authentication server; as well as In response to each of a plurality of first chirps, the AP transmits an authentication request based on the context, the authentication request including the hash of the first public key; The AP receives one or more of the plurality of first chirp signals from a device other than the IoT device; After receiving the one or more first chirp signals, the AP receives the chirp signal from the IoT device among the plurality of first chirp signals; The AP receives an authentication response from the IoT device based on an authorization request in response to the chirp signal from the IoT device; as well as The AP logs the IoT device onto the network based on the received authentication response.

2. The method according to claim 1, further comprising: The AP receives an authentication response from the IoT device based on one of the authentication requests. After receiving the authentication response, the AP receives multiple second chirp signals; as well as In response to receiving the authentication response, the plurality of second chirp signals are ignored.

3. The method according to claim 2, further comprising: The AP logs the IoT device onto the network based on the received authentication response.

4. The method of claim 1, wherein the generation of the context by the AP is in response to the verification by the AP receiving the first public key of the IoT device from the authentication server.

5. The method according to claim 1, further comprising: The AP receives a chirp signal from a device other than the IoT device, which includes the first public key of the IoT device; as well as In response to receiving the chirp signal, the chirp event is reported to the configurator.

6. The method according to claim 1, further comprising: After the timeout period has elapsed: Delete the aforementioned context; In response to receiving a subsequent chirp signal, report the subsequent chirp event to the configurator; Receive a chirp event rejection message from the configurator; as well as In response to the chirp event rejection message, another context is generated based on the first public key, wherein the other context includes information for logging the IoT device onto the network.

7. The method of claim 1, wherein the chirp signal and each of the plurality of first chirp signals is a Device Procurement Protocol (DPP) presence notification message.

8. The method of claim 1, wherein the first public key is a public bootstrap key.

9. An access point, comprising: Memory, storing instructions; as well as One or more processors, communicatively coupled to the memory and configured to execute instructions stored in the memory to: Receive a chirp signal from the device, the chirp signal containing a data hash including a first public key of the Internet of Things (IoT) device, the first public key being used to log the IoT device onto the network; Based on the received chirp signal, and based on the data hash including the first public key of the IoT device, the authentication server receives the verification of the first public key of the IoT device; A context is generated based on the first public key, wherein the context includes information for logging the IoT device onto the network without subsequent communication with the configurator and the authentication server; and In response to each of a plurality of first chirps, an authentication request is transmitted based on the context, the authentication request including the hash of the first public key; Receive a chirp event rejection message from the configurator; as well as In response to the chirp event rejection message, another context is generated based on the first public key, wherein the other context includes information for logging the IoT device onto the network.

10. The access point according to claim 9, wherein the chirp signal and each of the plurality of first chirp signals is a Device Provisioning Protocol (DPP) presence notification message.

11. The access point of claim 9, wherein the chirp signal is received from a device other than the IoT device.

12. The access point of claim 9, wherein the one or more processors are further configured to execute the instructions to: In response to receiving the chirp signal, a chirp event is transmitted to the configurator; and Based on the response to the chirp event received from the configurator, a key authorization request is transmitted to the authentication server. The verification response from the authentication server to the first public key of the IoT device is in response to the key authorization request.

13. The access point of claim 9, wherein the one or more processors are further configured to execute the instructions to: Receive an authentication response from the IoT device based on one of the authentication requests; After receiving the authentication response, receive a plurality of second chirp signals; and In response to receiving the authentication response, the plurality of second chirp signals are ignored.

14. The access point of claim 13, wherein the one or more processors are further configured to execute the instructions to: The IoT device is logged into the network based on the received authentication response.

15. The access point of claim 9, wherein the one or more processors are further configured to execute the instructions to: Receive one or more of the plurality of first chirp signals from a device other than the IoT device; After receiving one or more first chirp signals, the chirp signal from the plurality of first chirp signals is received from the IoT device; Based on the authorization request in response to the chirp signal from the IoT device, an authentication response is received from the IoT device; as well as The IoT device is logged into the network based on the received authentication response.

16. The access point of claim 9, wherein the context is generated in response to the verification received from the authentication server of the first public key of the IoT device.

Images