CONNECTING INTERNET OF THINGS (I0T) DEVICES TO A WIRELESS NETWORK

Abstract

A procedure (400) comprising the following: Received (402) by an authentication server (104; 602), a Device Provisioning Protocol (DPP) network access authorization request from an access point (AP) (106; 702) communicating with an IoT device (102), wherein the DPP network access authorization request includes a connect ID, the connect ID being a hash of a public network access key of the IoT device; Determine (404), through the authentication server, a validity of the connection ID; and in response to a determination that the connection identifier is valid, Determine (408), by the authentication server, a configurable policy from a set of configurable policies applicable to the IoT device, wherein the configurable policy includes network permissions, Transmitted (410), by the authentication server, which grants network permissions to the AP to connect the IoT device to a wireless network (116), Received, by the authentication server, a DPP bootstrap authorization request from the AP communicating with the IoT device, wherein the DPP bootstrap authorization request includes a hash of a public bootstrapping key of the IoT device; Determine, via the authentication server, whether the hash of the public bootstrapping key is valid; and In response to a determination that the hash of the public bootstrapping key is valid, the authentication server transmits the public bootstrapping key for the IoT device to the AP.

Description

BACKGROUND

[0001] An Internet of Things (IoT) device is a hardware device that connects to the internet to transmit data to other devices or people. Examples of IoT devices include sensors, actuators, gadgets, appliances, or machines that support internet connectivity. IoT devices are typically equipped with an Internet Protocol address (hereinafter referred to as an "IP") to establish a connection to the internet. Once connected, IoT devices can transmit data and / or receive control signals over a wireless network (e.g., a Wi-Fi network).

[0002] US 2019 / 0 306 710 A1 describes systems, methods, and devices, including computer programs encoded on computer storage media, for onboarding one or more multi-AP devices using a Device Provisioning Protocol (DPP) and a multi-AP communication protocol. In one aspect of US 2019 / 0 306 710 A1, a first multi-AP device can, during an onboarding process, determine DPP configuration information derived using the DPP. The first multi-AP device can establish a multi-AP network configuration between the first multi-AP device and a second multi-AP device using the multi-AP communication protocol, based at least partially on the DPP configuration information. In another aspect of US 2019 / 0 306 710 A1, the DPP configuration information can be remotely retrieved by the network operator prior to device provisioning.In one aspect of US 2019 / 0306710A1, a configuration station (STA) can be delegated by the network operator as a DPP configuration station and integrate one or more STAs into the multi-AP network using the DPP and the multi-AP communication protocol.

[0003] US 2016 / 0112406A1 describes systems and procedures for implementing access control in an industrial control system. A first component of an industrial control system can be connected to a second component of the same system. A digital certificate can be generated for the first component, containing both authentication and authorization information associated with that component. The first component can transmit the digital certificate to the second component, and the second component can extract the authorization information from the certificate. Using this extracted authorization information, the second component can identify a set of access rights and authorize the first component to access the second component based on those rights.

[0004] US 2019 / 0356482A1 describes a network capable of operating a wireless access point with credentials. An unconfigured device can support a Device Provisioning Protocol (DPP) and record bootstrap public keys and initiator private keys. The network can record public bootstrap keys and private responder keys and operate a DPP server. A responder proxy can establish a secure and mutually authenticated connection to the network. The network can (i) derive temporary public and private keys of the responder, (ii) record the initiator's bootstrap key, and (iii) select a responder mode for the responder. The network can derive an encryption key that includes at least (i) the recorded initiator's public bootstrap key and (ii) the derived temporary private key of the responder.The network can encrypt login credentials with at least the derived encryption key and send the encrypted credentials via the responder proxy to the initiator, which can forward the encrypted credentials to the device and thus support device configuration. SHORT DESCRIPTION

[0005] A method according to claims 1 to 5, an access point according to claims 6 to 12 and an authentication server according to claims 13 to 17 is disclosed. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] These and other features, aspects, and benefits of the present specification will be better understood if the following detailed description is read with reference to the accompanying drawings, in which identical symbols represent identical parts in the drawings, wherein: Fig. is a system for integrating an IoT device into a wireless network using a Device Provisioning Protocol (DPP), according to an example; Fig. shows a message flow diagram that illustrates a sequence of operations for onboarding an IoT device according to an example; Fig. is a flowchart that illustrates a procedure for an AP to provide proof of security for an IoT device according to an example; Fig. is a flowchart that represents a procedure with operations performed by an authentication server for connecting an IoT device to a wireless network according to an example; Fig. is a flowchart that represents a procedure with operations performed by an AP for connecting an IoT device to a wireless network according to an example; Fig. is a block diagram of an authentication server according to an example; and Fig. This is a block diagram of an access point according to an example.

[0007] In the drawings, identical reference numbers may denote similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to make the example shown clearer. Furthermore, the drawings contain examples and / or embodiments that correspond to the description; however, the description is not limited to the examples and / or embodiments shown in the drawings. DETAILED DESCRIPTION

[0008] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and in the following description to indicate identical or similar parts. However, it is expressly stated that the drawings are for illustration and description purposes only. Although several examples are described in this document, modifications, adaptations, and other embodiments are possible. Accordingly, the following detailed description does not limit the disclosed examples. Instead, the proper scope of the disclosed examples can be defined by the accompanying claims.

[0009] The terminology used here serves only to describe examples and is not intended to be restrictive. The singular forms "ein," "ein," and "die" used here also include the plural forms, unless the context clearly indicates otherwise. The term "plural" used here is defined as two or more than two. The term "ein Weitere" used here means at least one second or more. The term "und / oder," as used here, refers to and includes all possible combinations of one or more of the listed elements. The term "umfasst" used here means "umfasst" but is not limited to; the term "klusiv" means "klusiv" but is not limited to. The term "basierend auf" means at least partially based on.

[0010] To illustrate the present disclosure, certain examples are given with reference to the information contained in the Fig. The components shown are described. However, the functionality of the components shown may overlap and be present in a smaller or larger number of elements and components. Furthermore, all or part of the functionality of the elements shown may coexist or be distributed across multiple geographically dispersed locations. In addition, the described examples can be implemented in various environments and are not limited to the examples shown. The examples in the Fig. , Fig. , Fig. and Fig. The described processes are examples and not to be understood as limitations. Additional or fewer processes or combinations of processes can be used or varied without exceeding the scope of the presented examples. This disclosure therefore contains only examples of implementations, and many variations and changes to the described examples are possible. Such modifications and variations are to be included within the scope of this disclosure and are protected by the following claims.

[0011] IoT device provisioning occurs when an IoT device (e.g., a sensor or other device) is registered with a cloud platform. The IoT device must be authenticated and configured to become part of the cloud platform. Once authenticated and configured, the IoT device can connect to a wireless network (e.g., a Wi-Fi network) and send data to the cloud platform.

[0012] IoT devices may have limited or no user interfaces, which presents various challenges when integrating them into a Wi-Fi network. Typically, a user must manually connect and configure an IoT device using a smartphone or a separate computer. In some cases, the IoT device may also be manually configured by a mobile network operator's customer service representative. This type of manual deployment is undesirable for deploying a large number of IoT devices, as it would require several hours of work.

[0013] If a provisioning mechanism is insecure, there is also a risk that data on the IoT device or the IoT cloud platform will be compromised when the IoT device connects to the wireless network. Therefore, a secure, fast, and user-friendly mechanism is desirable that equips an IoT device with a security credential and then connects the IoT device to a wireless network using that credential.

[0014] In accordance with aspects of this disclosure, examples of connecting an IoT device to a wireless network are presented. In some examples, the provisioning of the IoT device with a security credential and the connection of the IoT device to the wireless network, as described herein, is based on a Device Provisioning Protocol (DPP). The DPP refers to a mechanism disclosed by the Wi-Fi Alliance, a global network of companies that aims to accelerate global Wi-Fi adoption, for integrating IoT devices into a cloud IoT platform.

[0015] In some examples, DPP messages from the IoT device can be used to communicate with a configurator via an access point (AP) in the wireless network. The configurator can be an entity that provides the IoT device with security credentials. The configurator can establish trust in a public bootstrapping key of the IoT device. The AP can act as an agent (i.e., a proxy device) of the configurator and communicate with an authentication server. The AP can authenticate and authorize the IoT device before connecting it to the wireless network. The authentication server can receive a network access authorization request from the AP containing a port identifier. The port identifier can include a hash of the IoT device's public network access key.If the port identifier in a network access authorization request is determined to be valid, the authentication server allows the IoT device to access the wireless network and selects a configurable policy applicable to the IoT device from a set of configurable policies. The authentication server then transmits the network permissions defined in the configurable policy to the access point (AP). Based on these network permissions, the IoT device can then connect to the wireless network via the AP.

[0016] The examples described here can enable the rapid integration of IoT devices into a wireless network by equipping each device with a connector. The connector can serve as a security credential for the IoT device. For example, it can contain a key for accessing the IoT device's public network. In some examples, the connector can be signed by the wireless network configurator. The IoT devices can then connect to the wireless network via these connectors. This type of onboarding can lead to greater adoption of IoT devices. Providing the connector via a DPP (Dynamic Gateway Protocol) from an access point (AP) without accessing the wireless network itself can ensure that the IoT device is secure when it connects.Furthermore, in some examples, the use of configurable policies can give a user the ability to define policies for the IoT devices before the IoT devices connect to the wireless network.

[0017] Fig. Figure 100 shows a system that, according to an example, enables the integration of IoT devices into a wireless network 116 using DPP. In some examples, the system 100 can include an IoT device 102, an authentication server 104, one or more access points (APs), such as APs 106A, 106B, 106C... 106N (hereinafter collectively referred to as APs 106), and a configurator 108. The APs 106 and the configurator 108 can communicate with each other via a wired network. In an initial phase, when the IoT device 102 is not yet enabled to access the wireless network 116, the IoT device 102 can communicate with the configurator 108 via the APs 106 using DPP messages. After deployment, the IoT device 102 can be connected to the wireless network 116.

[0018] In a sample implementation, System 100 might be part of a distributed environment, such as a university network or a corporate network. In some cases, certain corporate networks consider IoT devices untrusted and restrict network access. Such restrictions can limit the types of applications the organization can implement with IoT devices. In some examples, the DPP-based provisioning of the IoT device 102 by the authentication server 104, as described here, can ensure secure authentication and configuration of the IoT device 102. DPP-based provisioning by the authentication server 104 allows users to define access policies for the IoT device 102 before it connects to the wireless network 116.In an implementation, the Configurator 108 and the Authentication Server 104 can be part of a cloud platform connected to a company. The term "network access" used here can refer to access to a wireless network such as the wireless network 116.

[0019] Examples of wireless networks 116 can include, but are not limited to, an Internet Protocol (IP) or non-IP-based wireless LAN (WLAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Storage Area Network (SAN), a Personal Area Network (PAN), a cellular communication network, and the Internet. In some examples, wireless network 116 may include access points 106 to facilitate data communication. Communication over wireless network 116 can be in accordance with various communication protocols, such as, but are not limited to, Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), IEEE 802.11, and / or cellular communication protocols. Communication over wireless network 116 can be via wireless communication technologies (e.g., Wi-Fi, cellular communication, satellite communication, Bluetooth, etc.).In some examples, the wireless network 116 can be activated via private communication links, including but not limited to communication links established via Bluetooth, cellular communication, optical communication, radio frequency communication, and the like.

[0020] The in Fig. The IoT device 102 shown can be configured with security authorization to access the wireless network 116 by transmitting data and DPP messages via one or more of the APs 106 to the configurator 108, according to some examples. Examples of the IoT device 102 could be, but are not limited to, a location tag, an activity monitor, a connected thermostat, a surveillance camera, a sensor device, or any electronic or mechanical device that supports internet connectivity. Although a single IoT device 102 in the system 100 of Fig. As shown, in some other examples the System 100 may include more than one IoT device without limiting the scope of the present disclosure.

[0021] In some examples, the authentication server 104 can be implemented as a standalone server or be part of a cloud. In other examples, the authentication server 104 can be implemented as a hardware system / device, such as a computer system, mobile device, blade server, computer unit, workstation, storage system, or converged or hyperconverged system, but not limited to these. In other examples, the authentication server 104 can be implemented as a software resource, such as a software application, virtual machine (VM), container, containerized application, or pod. During operation, the authentication server 104 can facilitate the authentication and / or authorization of the IoT device 102 and manage the onboarding of the IoT device 102 using DPP. DPP is a standardized protocol that allows the IoT device 102 to be accessed via a controller (e.g., a network interface).the configurator 108) can be provided for network access.

[0022] In some examples, the authentication server 104 can manage bootstrapping information for the IoT device 102 to facilitate authentication and / or authorization of the IoT device 102 and to manage the onboarding of the IoT device 102 to the wireless network 116. The term "bootstrapping information" as used here can refer to, but is not limited to, information such as a public bootstrapping key for the IoT device 102. In some examples, IoT device manufacturers can embed bootstrapping key pairs into the IoT device during manufacturing. The public bootstrapping key of the IoT device 102 can be registered with an external cloud IoT platform 110. In some examples, the authentication server 104 can query the external cloud IoT platform 110 to obtain the bootstrapping information for the IoT device 102.In response, the authentication server 104 can obtain the public bootstrapping key from the external cloud IoT platform 110.

[0023]

[0019] In some examples, the authentication server 104 can contain a database (not shown) with the bootstrapping information of the IoT device 102. The database can be regularly synchronized with the external cloud IoT platform 110 to receive and update the bootstrapping information. In some examples where the bootstrapping information of the IoT device 102 is not integrated into the external cloud IoT platform 110, the bootstrapping information of the IoT device 102 can be received by out-of-band means. For example, the bootstrapping information on the IoT device 102 can be in the form of a tag (e.g., a Quick Response (QR) code). A user can scan the tag with a mobile application to obtain the public bootstrapping key of the IoT device 102.The mobile application can update the public bootstrapping key of the IoT device 102 on the authentication server 104.

[0024] In some examples, IoT device 102 might be an unmanaged device not assigned to any user. Therefore, defining an access policy for IoT device 102 can be beneficial for general network security. Accordingly, in some examples, authentication server 104 can store access policies for IoT device 102 in the policy database (not shown). The policy database can contain user configuration files (or "configuration profiles") for IoT device 102. A user can configure an access policy for IoT device 102 based on a role assigned to IoT device 102. In some examples, the policy database can contain configurable policies that can be applied to IoT device 102 based on the role assigned to IoT device 102 by authentication server 104.For example, if a voice-activated printer (an example IoT device 102) is deployed to connect to a corporate network, it can be configured to operate during office hours and for specific users before connecting to the network. In one example scenario, printing can be considered a role assigned to the voice-activated printer, and corresponding permissions can be defined for the device in the form of an access policy. The access policy can specify permissions such as which users are allowed to use the voice-activated printer and the time periods during which it may be used.

[0025] Furthermore, in some examples, the APs 106 can be part of a wireless local area network (WLAN) and provide wireless services to the IoT device 102 within an area covered by the respective APs 106. Examples of APs 106 include, but are not limited to, routers, network switches, network gateways, and similar devices. In some examples, one of the APs 106 can act as a bridge to connect an IoT device, such as the IoT device 102, to the wireless network 116. The APs 106 can be distributed across an area where network access is desired. Accordingly, the IoT device 102 can be deployed in the area served by one or more of the APs 106.

[0026] In some examples, the Configurator 108 can equip the IoT Device 102 with a security credential. In some examples, the Configurator 108 can be implemented using a processor or microcontroller and / or other electronic component, device, or system capable of performing various calculations, data storage, and / or data processing. In certain other examples, the Configurator 108 can be deployed as a software resource, such as a virtual machine (VM), container, containerized application, or pod. The Configurator 108 can establish trust in the IoT Device 102's public bootstrapping key and authenticate the IoT Device 102 using a DPP authentication protocol. Further details on DPP authentication are provided in conjunction with Fig. described.

[0027] During operation, the Configurator 108 can select an access point (AP) from the APs 106 in the wireless network 116 to perform the DPP authentication protocol and DPP configuration control. The AP can be selected based on the Received Signal Strength Indicator (RSSI) and / or the current utilization of the APs 106. The RSSI can indicate the radio frequency (RF) signal strength of the wireless network 116 at the respective APs 106. In certain systems with a high density of APs 106 in the system 100, the Configurator 108 can select a specific AP for configuring the IoT device 102 with a connector (i.e., a security attestation). For example, in a high-density deployment of APs in a warehouse, the Configurator 108 can select an AP located at an onboarding site within the warehouse to assist in provisioning the connector for the IoT device 102.As can be seen, selecting a suitable AP as a representative of the configurator 108 can reduce the time required to integrate the IoT device 102 into the wireless network 116.

[0028] For illustrative purposes, the AP 106B can be selected by the Configurator 108 based on one or more of the criteria mentioned above. Accordingly, the AP 106B will be referred to below as the selected AP 106B. The terms "AP 106B" and "selected AP 106B" are used interchangeably below and refer to an AP selected by the Configurator 108. The selected AP 106B can act as an agent of the Configurator 108 for the authentication and configuration of the IoT device 102 for access to the wireless network 116. Authentication and configuration of the IoT device 102 is performed via the DPP authentication protocol and a DPP configuration protocol, respectively. In particular, the selected AP 106B facilitates the exchange of DPP messages and information between the IoT device 102 and the Configurator 108.The selected AP 106B communicates with the IoT device 102 via a DPP communication channel 118 between the IoT device 102 and the AP 106B. DPP communication channel 118 is a dedicated communication medium established between the IoT device 102 and the AP 106B after verification of the public bootstrapping key of the IoT device 102. A single channel (or a small list of possible channels) can be predefined by the AP 106 as DPP communication channel 118. The selected AP 106B can retrieve DPP messages via DPP communication channel 118. The selected AP 106B can act as a proxy device for transmitting DPP messages between the IoT device 102 and the configurator 108. The selected AP 106B can act as an authenticator to authenticate the IoT device 102 on behalf of the authentication server 104.

[0029] In Fig. A message flow diagram 200 is shown, illustrating a sequence of operations for integrating the IoT device 102 into the wireless network 116 according to an example. The message flow diagram 200 shows the interactions between various units, such as the IoT device 102, the authentication server 104, the configurator 108, and the selected AP 106B, within the system 100 in three stages: an initial setup stage 204, a deployment stage 206, and a network access stage 208. For illustration, the message flow diagram 200 is shown below. Fig. with reference to System 100 of Fig. described, however, the scope of the present disclosure should not be considered to include the specific features (e.g., the number and arrangement of the APs 106, the configurator 108, the IoT device 102, and the authentication server 104) of the system 100 of Fig. be interpreted in a limited way. Initial setup phase 204

[0030] During the initial setup phase 204, the AP 106B can be configured to listen for DPP messages transmitted over specific communication channels. Although the initial setup phase 204 is described for the AP 106B, multiple APs in the wireless network 116 can be configured with corresponding DPP ports to support DPP communication. For example, in step 210, the AP 106B and the configurator 108 can establish communication over a network (such as a wired network). Furthermore, in step 212, the AP 106B can receive configuration information from the configurator 108. This configuration information can include a DPP port on the AP 106B. The DPP connector can be a security attestation provided to the AP 106B by the configurator 108. The AP 106B can use the DPP connector to establish communication with the IoT device 102.In one example, the configuration information can include details regarding the channels to be used by AP 106B. After configuration, AP 106B can announce its ability to communicate via DPP. For example, IoT device 102 can scan the channels for advertisements from AP 106B. Similarly, some or all APs 106 can be configured with appropriate DPP ports and channel connection information to support DPP communication. Deployment Phase 206.

[0031] In deployment phase 206, the IoT device 102 can be authorized and equipped with the security credentials required for network access. Upon power-up or at regular intervals, the IoT device 102 can scan all supported channels and periodically send DPP presence messages. For example, the DPP presence messages can be transmitted via 802.11 action frames. The DPP presence messages can include the hash of the IoT device 102's public bootstrapping key. The hash of the public bootstrapping key can be the identifier of the IoT device 102. In step 214, the configurator 108 can receive a list of presence messages, compliant with the DPP protocol, from the IoT device 102 via the access points 106 in the wireless network 116.The DPP presence messages sent by the IoT device 102 can be received by the APs 106, which have DPP capability preconfigured, during the initial setup phase 204. The APs 106 can listen for the DPP presence messages and report a device chirp to the configurator 108. The configurator 108 can monitor these DPP presence messages to detect the IoT device 102 within its radio coverage area. In step 216, the configurator 108 can select an AP (e.g., AP 106B) to initiate DPP communication with the IoT device 102.

[0032] The DPP authentication protocol is initiated at AP 106B to establish trust in the public bootstrapping key of IoT device 102 by sending a DPP bootstrap authorization request to authentication server 104 in step 218 to verify that the hash of the public bootstrapping key of IoT device 102 is registered. The selected AP 106B can generate the DPP bootstrap authorization request using the hash of the public bootstrapping key contained in the DPP presence messages transmitted by IoT device 102.

[0033] Furthermore, in step 220, authentication server 104 can verify the hash of the public bootstrapping key received in the DPP bootstrap authorization request. Based on the successful verification of the bootstrapping information, authentication server 104 can authenticate IoT device 102 and verify that it is an authorized device that can be deployed to access wireless network 116. To verify the public bootstrapping key of IoT device 102, authentication server 104 can be synchronized with an external cloud IoT platform to receive the public bootstrapping key at regular intervals.If the hash of the public bootstrapping key of the IoT device 102 is registered with the external cloud IoT platform 110, the authentication server 104 can send a positive DPP bootstrap authorization response containing bootstrapping information (i.e., the public bootstrapping key) of the IoT device 102 and the Extended Service Set Identification (ESSID) of the wireless network 116 to the selected access point 106B. In some examples, the selected access point 106B can obtain the public bootstrapping key to authorize the IoT device 102. Because the authentication server 104 manages the public bootstrapping key of the IoT device 102, repeated bootstrapping for the same IoT device 102 can be avoided if the IoT device 102 disconnects and reconnects to the system 100.Furthermore, no or minimal human interaction is required to connect or reconnect the IoT device 102 to the wireless network 116.

[0034] Furthermore, in step 222, the selected AP 106B can forward the public bootstrapping key received from the authentication server 104 to the IoT device 102. The DPP authentication protocol is completed in step 222. Upon receiving a positive DPP bootstrap authorization response at AP 106B, AP 106B can establish the DPP communication channel 118 between the selected AP 106B and the IoT device 102. After successful verification of the public bootstrap key of the IoT device 102, the IoT device 102 can generate a public network access key.

[0035] Step 224 initiates the DPP configuration protocol. Once the IoT device 102 is authenticated by the selected AP 106B, the IoT device 102 can send a DPP configuration request to the selected AP 106B. The DPP configuration request is sent to the selected AP 106B to obtain security authorization for the IoT device 102 to access the network.

[0036] Furthermore, in step 226, the selected AP 106B can create a connector for the IoT device 102 using the key for accessing the public network of the IoT device 102, while the DPP configuration request is pending (shown in step 226). In some examples, the connector for the IoT device 102 can contain the key for accessing the public network of the IoT device 102. In step 228, the selected AP 106B can send a request to the configurator 108 to sign the connector. Furthermore, in step 230, the configurator 108 can sign the connector using a configurator login key and send the signed connector back to the AP 106B.In step 232, with the generation of the signed connector, the DPP configuration of the IoT device 102 is completed with the security attestation, and the signed connector can be made available to the IoT device 102, which can be used by the IoT device 102 to establish a connection to the wireless network 116.

[0037] Additionally, in step 234, the selected AP 106B can transmit a DPP identity binding request to the authentication server 104 to join a hash of the public network access key of the IoT device 102 with the hash of the public bootstrapping key of the IoT device 102. The hash of the public network access key of the IoT device 102 can be referred to as the port identifier of the IoT device 102. Joining a hash value of the port identifier and a hash value of the public bootstrapping key of the IoT device 102 allows the authentication server 104 to perform an additional verification of the hash value of the public bootstrapping key and the port identifier, as required by DPP, during network access level 208.

[0038] During the network access phase 208, the IoT device 102 can access the wireless network 116 via any of the APs 106 using the connection that the IoT device 102 has received from the selected AP 106B, without limiting the scope of this disclosure. For the sake of simplicity, the IoT device 102 is referred to in the Fig. However, the network access level 208 shown is described as connecting to the wireless network 116 via the selected AP 106B.

[0039] In step 236, the IoT device 102 can discover any number of APs 106, send a peer discovery request, and wait for a peer discovery response. In some examples, the IoT device 102 can send the peer discovery request to AP 106B. The peer discovery request can include the connector of the IoT device 102 (for example, the signed connector received from the selected AP 106B). The selected AP 106B can validate the connector of the IoT device 102 based on the configurator signature key of the configurator 108. If the connector is successfully validated, the selected AP 106B can generate a DPP network access authorization request with the connector identifier and send it to the authentication server 104.

[0040] Furthermore, in step 238, authentication server 104 can authenticate and authorize network access to IoT device 102 based on the validity of the port identifier of IoT device 102. Authentication server 104 can respond with a DPP network access authorization response in the form of an approval or denial. Authentication server 104 can validate the hash of IoT device 102's public network access key and verify the hash of IoT device 102's public bootstrapping key to decide whether to allow or deny network access for IoT device 102. Based on the DPP network access authorization response from authentication server 104, the selected AP 106B can transmit the peer discovery response in step 240, which is a response to the peer discovery request received by the IoT device in step 236.

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

[0042] As can be seen, in the examples presented here, the authentication server 104 can provide a zero-touch provisioning experience for deploying the security credential to the IoT device 102 and connecting the IoT device 102 to the wireless network 116 using the security credential. When the IoT device 102 is brought into the system 100 and powered on, the sequence of operations described in the message flow diagram 200 can be performed. The entire process, from powering on the IoT device 102 to connecting to the wireless network 116, can be completed within a short timeframe without requiring any manual intervention. Furthermore, in some examples, once the IoT device 102 is connected to the wireless network 116, its network behavior can be continuously monitored.The authentication server 104 can be notified by a monitoring device (not shown) when a security threat is detected. Monitoring the IoT device 102 can include determining several parameters, such as the vulnerability associated with the IoT device 102 and the risk, the owner of the IoT device 102, network behavior, and operating system status. Furthermore, in some examples, the authentication server 104 can evaluate notifications from the monitoring device based on configurable policies (described later) and modify the network access permissions for the connected IoT device 102 by issuing a Change of Authorization (CoA) to the selected AP 106B. This helps to quickly isolate a compromised IoT device and prevents security threats from spreading within the system 100.

[0043] Fig. The diagram shows a flowchart illustrating Procedure 300 for providing a security attestation through an access point in a network, as illustrated by an example. The diagram in Fig. The described procedure 300 can be implemented at the selected AP in the form of executable instructions stored on a machine-readable medium and executed by a processing resource (e.g., a processor), and / or in the form of electronic circuits. In some examples, the procedures in the blocks of Fig. The processes shown are from the selected AP 106B. Fig. be carried out.

[0044] In block 302, the selected AP can send a DPP bootstrap authorization request to the authentication server. The DPP bootstrap authorization request can contain a hash of an IoT device's public bootstrapping key. The DPP bootstrap authorization request is generated to verify the hash of the IoT device's public bootstrapping key, which was received from the IoT device's presence messages. Verifying the hash value of the public bootstrapping key is a step in configuring the IoT device with the security credential. In response to the DPP bootstrap authorization request, the selected AP can receive either a positive or a negative bootstrap authorization response from authentication server 104.

[0045] Furthermore, the selected AP can perform a check in block 304 to determine whether the positive DPP bootstrap authorization response was received from the authentication server. The positive bootstrap authorization response indicates that the hash of the IoT device's public bootstrapping key was successfully verified by the authentication server and that the IoT device can be equipped with a port to access a wireless network. If block 304 detects that the positive DPP bootstrap authorization response was not received (i.e., the negative response was received), the selected AP can inform the IoT device in block 306 that it is not a registered IoT device and cannot be authenticated.However, if block 304 indicates that the positive DPP bootstrap authorization response has been received, the selected AP can receive a wireless network ESSID, a public bootstrapping key for the IoT device, and policies for the IoT device in block 308. The public bootstrapping key is received by the selected AP from the authentication server after verifying the hash of the IoT device's public bootstrapping key.

[0046] In block 310, the selected AP can establish a DPP communication channel between the IoT device and the selected AP. This DPP communication channel allows the selected AP to exchange DPP configuration messages between a configurator and the IoT device. The selected AP can also act as a proxy device for transmitting DPP messages between the IoT device and the configurator.

[0047] In block 312, the selected AP can initialize a DPP configuration protocol to provision the IoT device with the ESSID and connector. The selected AP can then generate the connector for the IoT device using the IoT device's public network access key to grant network access. The connector can be generated after verifying the hash value of the public bootstrapping key. The public network access key is generated by the IoT device after successful verification of its public bootstrapping key. The connector generated at the selected AP can be signed by the configurator using the configurator's sign-in key. The connector is a security credential associated with the IoT device and can be used by the IoT device to request access to wireless network 116.

[0048] In block 314, after provisioning the IoT device with the connector, the selected access point (AP) can send a DPP identity binding request to the authentication server to bind a hash of the IoT device's public bootstrapping key with a hash of the IoT device's public network access key as an identity for use during network access. Binding the hash value of the IoT device's public bootstrapping key and the hash value of the IoT device's public network access key allows the authentication server to simultaneously validate the port identifier and verify the public bootstrapping key.

[0049] Fig. This shows a flowchart illustrating a Procedure 400 process performed by an authentication server to connect an IoT device to a wireless network, in accordance with an example. The diagram in Fig. The described Procedure 400 can be implemented as executable instructions stored on a machine-readable medium and executed by a processing resource (such as a processor), and / or as electronic circuitry on the authentication server. In one example, the steps of Procedure 400 can be performed after the security credentials have been provided to the IoT device. In another example, the steps of Procedure 400 can be performed when a previously configured IoT device attempts to reconnect to the wireless network. In cases where the IoT device disconnects from the wireless network and attempts to reconnect, it can request network access from each of the access points (APs) in the wireless network using the same connector, without requiring the IoT device to be equipped with a new connector.In some examples, the steps described in Procedure 400 may be replaced by those in . Fig. The authentication server 104 shown will be used.

[0050] In block 402, the authentication server can receive a DPP network access authorization request from an access point (AP) communicating with the IoT device. The network access authorization request is generated by the AP upon receiving a DPP peer discovery request (with connector) from the IoT device. The network access authorization request can contain a port identifier of the IoT device.

[0051] In block 404, the authentication server can perform a check to determine the validity of the port identifier in the DPP network access authorization request. The authentication server can verify the IoT device's public network access key by comparing it to a hash of the public network access key stored on the authentication server. In some implementations, the authentication server can also check the status of the IoT device's antivirus and anti-malware capabilities, along with the port identifier, before granting network access. If block 404 determines that the port identifier is invalid, the authentication server can (in block 406) deny the network access authorization request. In some cases, network access for the IoT device can be temporarily revoked or permanently removed by adding the IoT device to a blocklist.The deny list can be managed by the authentication server. When an IoT device is logged out or removed from the external cloud IoT platform, the information is synchronized with the authentication server. The IoT device's port identifier is then moved to the deny list. The IoT device can be moved to the blocklist automatically, without administrator intervention, if network access for the IoT device is revoked or if the IoT device is logged out of the external cloud IoT platform.

[0052] If block 404 determines that the port identifier is valid, the authentication server can, in block 408, select a configurable policy applicable to the IoT device from a set of configurable policies. In some examples, each configurable policy can be associated with the role of the IoT device. In other examples, the authentication server can assign a role to the IoT device. Based on the IoT device's role, the authentication server can select a configurable policy from the set of configurable policies that can apply to the IoT device.

[0053] In one example, configurable policies could be access policies that users (such as an administrator) can define for IoT devices according to the device's role. In some examples, configurable policies can be modifiable. The wireless network administrator can modify the configurable policy as needed. Each configurable policy can contain network permissions for the IoT device. These network permissions define the rights and privileges for the IoT device. For example, if a camera device is deployed to connect to a wireless network, a configurable policy related to video capture devices can apply to the camera device. This configurable policy can include network permissions.For example, network permissions can include specifying the users who can access the camera device and the operations that users are allowed to perform through the camera device.

[0054] In block 410, the authentication server transmits the network permissions defined in the configurable policies to the access point (AP). Based on these network permissions defined in the configurable policy for the IoT device, the IoT device can connect to the wireless network via the AP. Once the IoT device is connected to the wireless network via a Wi-Fi connection between the AP and the IoT device, it can send and / or receive data over the wireless network. In the context of Fig. In some examples, the IoT device 102 can connect to the wireless network 116 via the AP based on the network permissions defined in the configurable policy.

[0055] In addition to validating the connection identifier for providing network access to the IoT device, the authentication server can also verify the hash of the IoT device's public bootstrapping key in some examples. The authentication server can receive a hash of a public bootstrapping key from the access point (AP) communicating with the IoT device. The authentication server can determine whether the hash of the public bootstrapping key is valid and then transmit the public bootstrapping key to the AP. The operations performed by the AP and the authentication server to verify the hash of the IoT device's public bootstrapping key are described in the Fig. and Fig. Described in detail.

[0056] Fig. Figure 500 shows a flowchart illustrating a Procedure 500 performed by an access point (AP) to connect an IoT device to a wireless network, as an example. Procedure 500 can also be referred to as the DPP network discovery phase. In Block 502, the AP can receive a DPP peer discovery request frame from the IoT device. The DPP peer discovery request frame can be sent by the IoT device to discover APs and other devices on the wireless network. The peer discovery request frame can include a port from the IoT device.

[0057] Furthermore, the access point (AP) can determine in block 504 whether the IoT device's connector is valid. The AP can determine that the connector is valid if it has been signed by a wireless network configurator. If block 504 determines that the connector is not valid (i.e., not signed by the wireless network configurator), the AP can (in block 506) reject the peer discovery request and send an error message to the IoT device. This type of connector validation ensures that the IoT device can only connect to the network (e.g., the wireless network) for which it is intended. If block 504 determines that the connector is signed by the wireless network configurator, the AP can validate that the IoT device's connector has been provisioned for access to the wireless network.

[0058] If block 508 determines that the connector is valid (i.e., signed by the wireless network configurator), the access point can generate a DPP network access authorization request and send it to an authentication server (in block 508). The network access authorization request can include the port identifier of the IoT device. In System 100 of Fig. Each of the APs 106 that receives the Peer Discovery Request Frame can transmit the Connector Identifier of the IoT device 102 in the DPP network access authorization request to the authentication server 104.

[0059] Furthermore, the access point (AP) in block 510 can obtain network permissions for the IoT device from the authentication server if the port identifier has been successfully validated by the authentication server. For example, the network permissions can define the behavior of the IoT device when it connects to the wireless network. In another example, the network permissions can specify time intervals within a day during which data transmission from the IoT device is permitted.

[0060] Furthermore, the access point (AP) in block 512 can set an access policy for the IoT device based on network permissions. For example, the access policy can specify a periodic interval at which the IoT device can transmit data. Setting the access policy for the IoT device allows the user to control the actions performed by the IoT device. For instance, the access policy can define access permissions for the IoT device to specific data within a cloud IoT platform. Additionally, in some examples, once the access policy is set, the AP in block 514 can transfer its DPP interface to the IoT device and establish a Wi-Fi connection between the AP and the IoT device, thus connecting the IoT device to the wireless network. In one example, Fig. The IoT device 102 can be connected to the wireless network 116 via a Wi-Fi connection between an AP 106C and the IoT device 102.

[0061] In some examples, an access point (AP) that provides the IoT device with the connector may be separate from an AP that connects the IoT device to the wireless network. As in the Fig. and Fig. As described, for example, the selected AP 106B can act as an agent of the configurator 108 and configure the IoT device 102 with the connector, while the selected AP 106B or another AP of the APs 106 can assist in connecting the IoT device 102 to the wireless network 116. In certain other examples, the selected AP 106B (as in Fig. (explained) involved in both the provision of the connector and the connection of the IoT device 102 to the wireless network.

[0062] Fig. This is a block diagram 600 showing an authentication server 602 coded with example instructions to connect an IoT device to a wireless network using DPP, as shown in an example. The authentication server 602 can be an example of the one in Fig. The authentication server shown, 104, or another computer device with similar capabilities, is shown.

[0063] The authentication server 602 can contain the processor 604, the machine-readable medium 606, and the policy database 608. The processor 604 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that processes signals based on operating instructions. In some examples, the machine-readable medium 606 can be any electronic, magnetic, optical, or other physical storage device capable of storing data and / or executable instructions. Therefore, the machine-readable medium 606 could be, for example, random-access memory (RAM), electrically erasable programmable solid-state memory (EEPROM), a storage drive, flash memory, compact disc storage (CD-ROM), and the like.As described in detail here, the machine-readable medium 606 can be encoded with executable instructions 610, 612 and 614 (hereinafter collectively referred to as instructions 610-614) for authentication and connection of the IoT device to the wireless network.

[0064] The policy database 608 can contain a set of configurable policies defined using one or more configuration files or configuration profiles for a variety of IoT devices. A user can configure policies for the IoT device 102 based on the IoT device's role. In some examples, the policy database 608 can be stored on the machine-readable medium 606.

[0065] The processor 604 can be connected to the machine-readable medium 606. The processor 604 can be configured to execute the instructions 610-614 (i.e., programming or software code) stored on the machine-readable medium 606 to authenticate the IoT device and connect it to the wireless network. In some examples, the processor 604 can retrieve, decode, and execute the instructions 610-614 stored on the machine-readable medium 606 to authenticate the IoT device and connect it to the wireless network. In certain examples, alternatively or in addition to retrieving and executing the instructions 610-614, the processor 604 can include at least one integrated circuit, other control logic, other electronic circuits, or combinations thereof, comprising a set of electronic components for performing the functions to be performed by the authentication server 602.

[0066] In some examples, instructions 610, when executed by processor 604, can cause processor 604 to receive a DPP network access authorization request from an access point. Furthermore, instructions 612, when executed by processor 604, can cause processor 604 to determine whether a port identifier in the DPP network access authorization request is valid. Additionally, in some examples, instructions 614, when executed by processor 604, can cause processor 604 to select a configurable policy applicable to the IoT device from a set of configurable policies in response to the determination that the port identifier is valid.

[0067] It is clear that integrating the IoT device using DPP communication leads to faster and more secure deployment of the IoT device, without the need for manual configuration. Furthermore, once the IoT device is configured with the connector, it does not need to be reconfigured each time it reconnects to the wireless network. Additionally, the IoT devices can be monitored, and network policies for the IoT device can be changed instantly using configurable policies.

[0068] Fig. This is a Block Diagram 700 showing an AP 702 coded with example instructions for connecting the IoT device to the wireless network, according to an example. The AP 702 can represent an example of one of the APs 106 or another computer device with similar capabilities. The AP 702 can include the Processor 704 and the Machine-Readable Medium 706, which are representative of examples of the Processor 704 and the Machine-Readable Medium 606. Fig. The details of the machine-readable medium 706 are not repeated here. The machine-readable medium 706 can be encoded with executable instructions 710, 712, and 714 (hereafter collectively referred to as instructions 710-714) for setting up the access policy based on network permissions that connect the IoT device to the wireless network. The processor 704 can be coupled to the machine-readable medium 706 and configured to execute instructions 710-714 (i.e., programming or software code) stored in the machine-readable medium 706 to set up the access policy and connect the IoT device to the wireless network. In some examples, the processor 704 can retrieve, decode, and execute instructions 710-714 stored in the machine-readable medium 706 to set up the access policy and connect the IoT device to the wireless network based on the network permissions.In certain examples, the processor 704 may, alternatively or additionally to fetching and executing instructions 710-714, contain at least one integrated circuit, other control logic, other electronic circuits, or combinations thereof, comprising a set of electronic components for performing the functions to be carried out by the AP 702. Although not shown, in some examples the machine-readable medium 706 may be encoded with certain additional executable instructions to perform operations in one or more blocks in the Fig. and Fig. to carry out the described procedures 300 and 500 without limiting the scope of the present disclosure.

[0069] In some examples, instructions 710, when executed by processor 704, can cause processor 704 to forward a DPP network access permission request to an authentication server. Furthermore, instructions 712, when executed by processor 704, can cause processor 704 to obtain network permissions for the IoT device when a port identifier in the DPP network access permission request is validated by an authentication server. Additionally, in some examples, instructions 714, when executed by processor 704, can cause processor 704 to connect the IoT device to the wireless network after an access policy for the IoT device has been established based on the network permissions.

[0070] The foregoing description includes numerous details to facilitate understanding of the subject matter disclosed herein. However, the implementation can also be carried out without some or all of these details. Other implementations may involve modifications, combinations, and variations of the details described above. The following claims are intended to cover such modifications and variations.

Claims

[1] A method (400) comprising the following: Received (402) by an authentication server (104; 602), a Device Provisioning Protocol (DPP) network access authorization request from an access point (AP) (106; 702) communicating with an IoT device (102), wherein the DPP network access authorization request includes a connect ID, the connect ID being a hash of a public network access key of the IoT device; Determine (404), through the authentication server, a validity of the connection ID; and in response to a determination that the connection identifier is valid, Determine (408), by the authentication server, a configurable policy from a set of configurable policies applicable to the IoT device, wherein the configurable policy includes network permissions, Transmitted (410), by the authentication server, which grants network permissions to the AP to connect the IoT device to a wireless network (116), Received, by the authentication server, a DPP bootstrap authorization request from the AP communicating with the IoT device, wherein the DPP bootstrap authorization request includes a hash of a public bootstrapping key of the IoT device; Determine, via the authentication server, whether the hash of the public bootstrapping key is valid; and In response to a determination that the hash of the public bootstrapping key is valid, the authentication server transmits the public bootstrapping key for the IoT device to the AP. [2] Method according to claim 1, wherein determining the configurable policy assignment, by the authentication server, comprises assigning a role to the IoT device, wherein the configurable policy applicable to the IoT device is determined based on the role of the IoT device. [3] Method according to claim 1, wherein determining whether the hash of the public bootstrapping key is valid further comprises determining whether the public bootstrapping key is registered with an external cloud IoT platform (110). [4] The method according to claim 3, further comprising receiving, by the authentication server, the public bootstrapping key from one of the external cloud IoT platforms or a mobile application. [5] The method according to claim 1, further comprising binding, by the authentication server, the hash of the public network access key of the IoT device with the hash of the public bootstrapping key of the IoT device. [6] An access point (AP) (106; 702) for connecting an IoT device (102) to a wireless network (116), wherein the AP comprises: a processor (704); and a machine-readable medium (706) that stores instructions which, when executed by the processor, cause the processor to: to transmit a Device Provisioning Protocol (DPP) network access authorization request to an authentication server (104; 602) (710), wherein the DPP network access authorization request is generated based on a DPP peer discovery request received at the AP from the IoT device; To receive network permissions for the IoT device from the authentication server (712) after a connection identifier in the DPP network access permission request has been validated by the authentication server; to connect the IoT device to the wireless network (714) after an access policy has been set based on network permissions, to transmit a DPP bootstrap authorization request for the IoT device to the authentication server, whereby the DPP bootstrap authorization request is generated to verify a hash of a public bootstrapping key of the IoT device; and to create a connector for the IoT device based on a positive bootstrap authorization response received at the AP, where the positive bootstrap authorization response indicates that the hash of the public bootstrapping key has been successfully verified by the authentication server. [7] The AP according to claim 6, wherein the machine-readable medium stores additional instructions which, when executed by the processor, cause the processor to transmit a DPP identity binding request to the authentication server to associate the binding identifier with the hash of the public bootstrapping key, wherein the binding identifier is a hash of a public network access key of the IoT device. [8] The AP according to claim 6, wherein the machine-readable medium stores additional instructions which, when executed by the processor, cause the processor to exchange DPP configuration messages between a wireless network configurator (108) and the IoT device. [9] The AP according to claim 8, wherein the connector of the IoT device is signed by the configurator. [10] The AP according to claim 9, wherein the machine-readable medium stores additional instructions which, when executed by the processor, cause the processor to generate the DPP network access authorization request based on a validation of the connector, wherein the AP validates the connector based on a configurator signature key of the configurator. [11] The AP according to claim 8, wherein the machine-readable medium stores additional instructions which, when executed by the processor, cause the processor to establish a DPP communication channel (118) between the IoT device and the AP, wherein the DPP communication channel is established based on the positive bootstrap authorization response. [12] The AP according to claim 11, wherein the IoT device communicates with the AP via the DPP communication channel to provide the IoT device with access to the wireless network. [13] An authentication server (104; 602) comprising the following: a processor (604); and a machine-readable medium (606) that stores instructions which, when executed by the processor, cause the processor to: to receive a Device Provisioning Protocol (DPP) network access authorization request from an access point (AP) (610), wherein the AP generates the DPP network access authorization request upon receiving a DPP peer discovery request from an IoT device (102); to determine (612) whether a connection identifier is valid in the DPP network access authorization request, wherein the connection identifier is a hash of a public network access key of the IoT device; in response to a determination that the connection identifier is valid, to determine a configurable policy from a set of configurable policies (614) applicable to the IoT device, and to transmit network permissions to the AP to connect the IoT device to a wireless network (116), wherein the network permissions are defined in the configurable policy, to receive a DPP bootstrap authorization request from the AP communicating with the IoT device, wherein the DPP bootstrap authorization request includes a hash of a public bootstrapping key of the IoT device; to determine whether the hash of the public bootstrapping key is valid; and In response to a determination that the hash of the public bootstrapping key is valid, transmit the public bootstrapping key for the IoT device to the AP. [14] The authentication server according to claim 13, wherein the instructions for determining the configurable policy further comprise additional instructions which, when executed by the processor, cause the processor to assign a role to the IoT device, wherein the configurable policy applicable to the IoT device is determined based on the role of the IoT device. [15] The authentication server according to claim 13, wherein the machine-readable medium stores additional instructions which, when executed by the processor, cause the processor to determine whether the public bootstrapping key of the IoT device is registered with an external cloud IoT platform (110). [16] The authentication server according to claim 13, wherein the machine-readable medium stores additional instructions which, when executed by the processor, cause the processor to bind the hash of the public network access key of the IoT device with the hash of the public bootstrapping key of the IoT device. [17] The authentication server according to claim 13, wherein the DPP peer discovery request includes a connector of the IoT device.

Images