A method for configuring a simple registrant device

Abstract

Thus a method and suitably arranged apparatus for configuring communications in a wireless network is provided, comprising: executing a configuration protocol and during execution of the configuration protocol sending by a participant device a message containing an indication of a previous configuration attempt. The configuration device receiving the status of the previous configuration attempt is then able to act upon it and inform the user that the previous attempt failed. The information provided to the user will allow the user to understand why the device was unable to connect to the desired network and possibly alert them to the fact that they have not yet connected.

Description

Technical Field

[0001] The present invention relates to devices and methods for use in wireless networks, particularly those compliant with the IEEE 802.11 series of standards. Background Art

[0002] Figure 1 A wireless network 1 is shown comprising a first device 2 and another device 3. The first device 2 may have a central function and be similar to an access point (AP), a hub or a gateway device. For simplicity, the first device 2 will hereinafter be referred to as an AP, but other types of devices are certainly possible. A user (not shown) wishes to add two further devices to the network 1, namely a complex device 4 (here represented as a computer) and a simple device 5 (here represented as a toothbrush). Devices like the simple device 5 may typically not have any real user interface (UI) other than a light and are therefore often referred to as "headless" devices. The AP 2 has a processor 6 and the simple device 5 has a microcontroller and a small non-volatile memory 7 as well as a button 8 that can be used to reset the simple device 5. There is also a third device 9.

[0003] Some wireless networking standards allow one device to configure another device to establish a connection and communicate. This makes the task of adding or registering new devices to the network less onerous, as manual input is no longer required.

[0004] Devices with user interfaces, such as complex devices 5, can display the status of the connection to the AP after configuration and whether there are problems, for example, if the device cannot "find" the AP (or other device it expects to connect to). However, with simple (headless) devices, the only way for a user to observe a successful connection is to check the UI of the access point (AP), hub, or gateway. This is not the case with headless devices, that is, devices without a user interface. If, after configuration, these devices encounter problems when trying to connect to the network they are configured to connect to, users have no idea what went wrong and may not realize it unless they want to check the AP's UI.

[0005] Document US2017 / 257819 discusses pre-configuration of headless devices, but does not take into account previous connection attempts. Summary of the invention

[0006] Thus, there is provided a method of configuring a registrant device for communications in a wireless network, comprising executing a configuration protocol and sending, by the registrant device, a message containing an indication of a previous configuration attempt during execution of the configuration protocol.

[0007] A configuration device that receives the status of a previous configuration attempt is then able to take action thereon. For example, it can terminate configuration when it is not needed or notify the user that a previous attempt failed. The information provided to the user will allow the user to understand why the device failed to connect to the desired network and possibly alert them to the fact that they have not yet connected. This is particularly valuable when the device to join the network is a simple or headless device that is not able to directly notify the user. Such a device may appear to have been configured but failed to join. The user may be aware that the device failed to join but not know why, or worse, not realize it until some later time. Having such a timely indication can save the user a great deal of time and effort.

[0008] According to an embodiment, the message is one of an authentication request message, an authentication response message, an authentication confirmation message, or a configuration request message. During the configuration process, these messages are exchanged between the configuration device and the device to be registered. By including the indication in one or more of these messages, the headless device according to the embodiment can automatically notify and without a specific user investigating the configuration device according to the embodiment about the results of the previous attempt.

[0009] According to one embodiment, the configuring is part of establishing communications between the registrant device and another device in the wireless network.

[0010] According to one embodiment, the indication includes information about at least one of the following: the result of the previous configuration attempt, the actions performed as part of the previous configuration attempt, the network ID, and an indication of whether the previous configuration attempt performed can be reconfigured without a reset. Using the result of the previous attempt, the configuration device can decide which process to follow in the configuration and indicate the result to the user. Using the network ID, the configuration device can determine the reason for the connection failure for devices that failed to connect but still completed the configuration.

[0011] According to an embodiment, receiving a message containing an indication of a successful previous configuration attempt results in termination of the configuration protocol, thereby avoiding useless and possibly problematic reconfiguration attempts.

[0012] According to one embodiment, receipt of a message containing an indication of a previous configuration attempt causes the receiving device to display corresponding information on a user interface, thereby informing the user of the cause of the connection problem.

[0013] According to one embodiment, the indication is contained in a segment of an unencrypted message. This can reduce the computational load of the configurator at the expense of network security.

[0014] According to one embodiment, the indication is contained in a segment of the encrypted message. This has the advantage that it will be more difficult for another malicious device to gather information about the network (i.e. a particular device has attempted to join but failed for some reason) which could then be used as part of an attempt to penetrate the network.

[0015] According to another aspect, there is provided a registrant device arranged for communicating in a wireless network, configured to participate in a configuration protocol with a configurator device, the configuration protocol being arranged to configure the device to communicate in a wireless network and store indications of previous attempts to configure the device. By storing the results of previous attempts, the registrant device can provide information when retrying to configure it so that the user can be informed of the results.

[0016] According to one embodiment, the registrant device is configured to transmit the indication as part of a message of the configuration protocol.

[0017] According to an embodiment, the registrant device is also configured to erase the storage of the indication only after receiving a full reset. Thus, even if a partial reset is performed in preparation for its configuration, it will retain the indication so that during configuration, it can still send the indication.

[0018] According to an embodiment, the registrant is further configured to send instructions on how to reconfigure the registrant's device. The instructions on how to reconfigure include at least one of: an indication that a reset is required, a text description containing instructions, and a URL to a document describing how to reconfigure. The configurator (or any other device with a UI) can then display this information to the user so that they do not have to search for it. The instructions can include information on whether the reconfiguration overwrites the previous configuration or adds to the previous configuration.

[0019] Information for reconfiguring registrants can be displayed by the configurator or by a device connected to the configurator to save the user time looking up information. Additionally, an indication of whether the reconfiguration is adding to or overwriting an existing configuration allows a properly programmed configurator to decide whether to abort the reconfiguration on a properly configured device.

[0020] According to another aspect, there is provided a configurator device arranged to configure a device for communicating in a wireless network, configured to engage in a configuration protocol with a registrant device and, as part of the configuration protocol, detect in a message from the registrant device an indication of a previous attempt to configure the registrant device.

[0021] According to one embodiment, the configurator device is further configured to terminate the configuration protocol if the indication indicates that the configuration was successful. This may be useful in situations where a user simply wants to reconfigure because of a problem. The user may have been thinking that there was a problem with the connection, but may find that there was no problem with the configuration and therefore no need to redo or change it.

[0022] According to an embodiment, the configurator device determines from the message that a previous attempt to configure the registrant device has occurred, so as to display corresponding information on the user interface indicating that a previous attempt to configure the registrant device has occurred. The configurator device capable of detecting the indication can then notify the user of the content and respond according to the content by changing the flow of the configuration process. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The above and other objects, features and advantages of the disclosed apparatus, system and method will be better understood through an illustrative and non-limiting detailed description of embodiments of the apparatus and method with reference to the accompanying drawings, in which:

[0024] Figure 1 Indicates a wireless network for which you wish to configure a device to be added.

[0025] Figure 2 The flowchart of the configuration process according to the embodiment is shown.

[0026] Figure 3a FIG. 2 shows an exemplary 802.11 MAC frame that may be used in accordance with an embodiment.

[0027] Figure 3b represents attributes according to an embodiment for an 802.11 MAC frame. DETAILED DESCRIPTION

[0028] In the following description, the same reference numerals denote the same elements.

[0029] Figure 2 The flow chart of the configuration method of device control according to the embodiment is shown, in which a device, such as Figure 1 The third device 9 can be configured and connected to another device, such as Figure 1 The third device 9 and the devices 4 and 5 are according to an embodiment. As an example, the case of a simple device 5 will be discussed. It should be understood that although most of this description provides examples involving a network with devices such as AP 2, the process can work in a peer-to-peer situation.

[0030] An example of a device-controlled configuration method is the Device Configuration Protocol (DPP), which is used in networks using Wi-Fi or IEEE 802.11. In the Device Configuration Protocol (DPP), a device acting as a DPP configurator can securely configure any Wi-Fi-enabled device to connect to a Wi-Fi AP.

[0031] At S1, the process starts with two devices 9 and 5 in an unconnected state and device 5 is not configured. For the purpose of discussion, device 9 will be used to configure device 5 to join wireless network 1, so device 9 can be called a configurator and device 5 is called a registrant (because it is "registering" in wireless network 1).

[0032] In S2, often called "bootstrapping," one device obtains the boot public key (B R ) and used for the device to be configured. This is another way outside of wireless communication technology and is therefore often called "out-of-band" communication (OOB). Examples of this could be a user causing one device to read a QR code on the responder, NFC communication between two devices, or another wireless technology (such as Bluetooth). The boot process is initiated by user intervention. If the boot has been successful, the process reaches S3 and the devices 10, 5 are "booted", otherwise they are restored to the "start" state at S1. In either case, the registrant device (in this case the simple device 5) can record the results of the boot process in an appropriate memory, for example as a flag in a register in the memory. Typically, a simple device is programmed to wake up after manufacturing or after a reset, turn on its radio on the channel indicated in its QR code for configuration, and start listening for authentication request messages. (A non-simple device will often be set in this mode by its user, for example to reset it.)

[0033] At S4, devices 9, 5 perform an authentication process in which the devices establish "trust", i.e., the user is able to be confident that the device is the device they believe in, and not some other unknown (and potentially malicious) device "pretending" to be one or the other of the devices in question. A message is sent from one device requesting that authentication begin. The message can be sent by the device being configured (configurator) or the device to be configured (registrant). In this example, the third device 9 acts as the configurator and the simple device 5 acts as the registrant. It should be noted that the third device 9 is shown as being connected to the network 1, but this is not necessary for the working of the embodiment. The device that initiates wireless communication is called the initiator, and the device that responds is called the responder. In particular, the DPP protocol allows both the configurator and the registrant devices to act as the initiator of the DPP protocol, so that the other device automatically becomes the responder. Simple devices or headless devices typically assume the role of responder.

[0034] The other device responds to this message. If the authentication request message is correctly decoded and contains information indicating that the initiator is the device that the user believes it is and has the required capabilities, the response message indicates that the message has been "accepted" and contains the information required by the initiator to verify the credentials of the responder and that it also has the required capabilities. If neither device receives the required information from the other device, the process is aborted and the device returns to the boot state at S3. If the initiator is a registrant, the authentication request message may also include an additional portion indicating the results of a previous attempt to configure the registrant. If the responder is a registrant, the authentication response message may include an additional portion indicating the results of a previous attempt. It should be understood that the indication also indicates whether there was a previous attempt.

[0035] In the case of the DPP protocol, the first message is the Authentication Request message and the response message is the DPP Authentication Response. The responder checks that the DPP Authentication Request message contains a correctly generated cryptographic hash of the responder's public bootstrap key and whether it has a copy of the initiator's public bootstrap key. The responder sends a DPP Authentication Response message indicating whether the authentication can proceed. If not, for example because an attempt to decrypt the encrypted report in the DPP Authentication Request message failed, the process is aborted. The DPP Authentication Response contains a cryptographic hash of the responder's public bootstrap key and may contain a hash of the initiator's public bootstrap key. Again, for the initiator, the registrant may have obtained this public key via OOB communication. The initiator's public bootstrap key can then be used for mutual authentication. Without the initiator's public bootstrap key, only the initiator can authenticate the registrant, but not vice versa.

[0036] In the case of DPP, an indication of the result of a previous attempt may be in the form of a dedicated extra attribute, the frame body of a DPP Authentication Request or Response message. The format and content of the message will refer to Figure 3a and Figure 3b Have a discussion.

[0037] If the authentication response message indicates that the responder has accepted the authentication request message and the response meets the criteria imposed by the initiator's settings, the initiator issues an authentication confirmation message. If the relevant device finds that the authentication values ​​in the authentication response and confirmation messages are correct, then this part of the protocol (i.e., the authentication part) is successful, the flow goes to S6 and configuration can begin. The confirmation message may also contain an indication of the results of a previous configuration attempt, where the registrant was also the initiator.

[0038] In the case of the DPP protocol, the authentication confirmation message is a DPP authentication confirmation message.

[0039] At S7, the registrant device sends a configuration request message containing information about what type of configuration the registrant wants. If the configurator is able to approve the request, it sends a message with the information required by the registrant (e.g., a network key). The process then ends at S8 with the registrant successfully configured. According to an embodiment, the configuration request may contain an indication of the results of a previous configuration attempt.

[0040] In the case of DPP, the request message is a DPP Configuration Request, and the Configurator response is a DPP Configuration Response message. The DPP Configuration Response may contain the Service Set Identifier (SSID) of the network to which the registrant should connect, and may contain a DPP connector. The DPP connector can be treated as a certificate, digitally signed by the Configurator, and contains the Registrant's public network access key. The DPP Configuration Response message also contains the configured public signature key. Other devices that have been configured by the same Configurator can thus check whether they can trust the other device's public network access key. The DPP Configuration Response message may also contain the Wi-Fi password or pre-shared key (PSK) of the network. The Registrant sends a DPP Configuration Result message to the Configurator (depending on the version of DPP) to let it know whether it accepts the configuration. The Configurator's failure to receive this message may indicate to the Configurator that there is a Wi-Fi problem between the Configurator and the Registrant. The "thought configured" Registrant can then send its connector to AP 2 configured by DPP. If the connector signature is found to be correct and AP 2 has a matching connector, i.e. a connector for the same network signed by the same Configurator, then AP 2 sends its own connector to the Registrant. The registrant and AP 2 may calculate a symmetric key in a Diffie-Hellman fashion based on each other's network access keys in the connector and their own private network access keys.

[0041] If the registrant receives a Wi-Fi password or a Wi-Fi pre-shared key (PSK), the registrant attempts to associate with AP 2 in the normal manner through the 4-way handshake specified in [802.11].

[0042] On the other hand, if the registrant (in this example, the simple device 5) does not successfully connect, it gives up the attempt after its programmed timeout, it stores information about the configuration attempt and the connection failure and stops. The timeout can be long or indefinite. The user, when they realize that joining or connecting to the network 1 is not working, can try to understand the situation and retry the configuration, and then have the simple device 5 retry joining the network 1.

[0043] In the event that the configurator detects that the registrant has gone through a previous configuration attempt, there are a number of possibilities and these possibilities depend in part on how the registrant is arranged and what the previous results were.

[0044] Many devices, like the simple device 5, are arranged to hold only one configuration at a time. Furthermore, many are not configured when manufactured, but are programmed to refuse or ignore further configuration attempts once they have been configured - a "configuration zone", such as a flag that is consulted each time an attempt is made to configure the device. This behavior has been likened to the process of imprinting in a particular animal, where a young animal learns to recognize another individual as its "mother" if it sees another individual at a particular time. Once imprinted, the young animal will refuse to recognize any other individual as its mother. To reconfigure such a device, some kind of reset is required to remove the flag that prevents the device from participating in the configuration process. Such a flag may simply be a status flag, with a value indicating "configured" or "not configured".

[0045] If the previous configuration was successful and appropriate for the network in question, there are various possibilities depending on how the registrant is programmed to act after configuration. If the Simple Device 5 is programmed not to accept a new configuration without a reset, the configuration process will terminate because the registrant will not send the response required to continue the process.

[0046] Furthermore, the configurator may operate in different ways. In one embodiment, the configurator may be configured to terminate the configuration and proceed directly to S8, on the basis that it may not make sense (and be at risk of failure) to re-do the exercise. This branching of the flow may occur once the configurator determines that the registrant has been successfully configured - for example, if an indication is detected in one of the authentication messages. In the case where the configurator has a UI, it can inform the user that a successful configuration was previously performed for the network in question. Alternatively, the configurator may simply continue the process, if the registrant is in a mode to accept configuration, simply adding the new configuration to the registrant's configuration store or overwriting the previous configuration (where the registrant has only one configuration store - this is often the case for simple devices). In the case where the registrant also provides information about how to configure it (as described below), the configurator can understand what impact the reconfiguration will have on the old configuration (e.g., overwrite) and notify the user through its own remote UI or another device connected to the configurator (e.g., AP 2). The configurator can also be programmed to continue configuration for devices that have new configurations added to their configuration stores, but stop configuration for simple devices that can only overwrite existing configurations.

[0047] On the other hand, if the simple device 5 is successfully configured but for another network, it will need to be reconfigured and the situation becomes the same as the previous configuration failure.

[0048] In the event that reconfiguration is required - where the previous attempt failed or was not for the correct network - the process proceeds to S9, where the configurator can inform the user of the results of the previous attempt through its own UI or through a remote UI. In addition to notifying the user that configuration is required again, this can also indicate whether the device in question needs to be reset in order for it to participate in the new configuration. If necessary, the user can reset the device and retry the configuration. In addition to removing any configuration blocks, resetting the simple device 5 can also change the record of the previous configuration attempt in a way that avoids the configurator terminating the configuration protocol prematurely. For example, this may involve changing a value in the record of the previous attempt so that a configurator programmed accordingly can detect the value and continue with the configuration. Alternatively, the configurator can be programmed to always continue with the configuration in the event that the previous result indicates a connection failure.

[0049] Resetting the simple device 5 may be accomplished by a button 8. The button 8 may be a power button, in which case the reset may be accomplished by a short press compared to the long press required to actually power off the device. Alternatively, the button 8 may be recessed in a hole to avoid accidental resetting.

[0050] Simple devices 5 may have two reset levels - a partial reset, which will erase any configuration blocks but will not delete records of previous configuration attempts, and a complete or full reset to set the device back to so-called factory settings, including configuration blocks / status flags. Various ways of implementing a two-level reset are possible, such as a short and long press or a single press for one level and two presses within a certain length of time for another level.

[0051] In one embodiment, once configured, the simple device 5 searches for and attempts to connect to the network it is configured for. If it is able to connect, it connects and remains on the selected network channel between it and the network. If not, the join attempt times out and the simple device 5 gives up. The simple device 5 then returns to listening on the default channel or the channel it was given as part of the boot process. It also sets the connection state flag to "configured", logs information about the failed connection attempt, and puts this into a new connection state attribute for its next configuration request message.

[0052] In one embodiment, a simple device 5 may have a protocol such as a short press for a partial reset and a long press for a full reset.

[0053] In one embodiment, the indication may be omitted for situations where no previous attempt to configure the registrant has been made. In the event that the configurator notices that there is no indication, it simply continues with the protocol. In another embodiment, the indication is present and contains a value indicating that no previous attempt to configure has been made. Again, upon noticing this situation, the configurator simply continues.

[0054] In the following example using the DPP protocol, the entire process of trying to add a simple device to the network can be seen from the user's perspective.

[0055] A simple device 5 wakes up after manufacturing or after a factory reset and turns on its radio and sets it to the channel indicated in the QR code for DPP configuration and starts listening for DPP authentication request messages. Non-simple devices will be set to this mode by their users.

[0056] The simple device 5 receives the configuration via the DPP protocol and accepts the configuration in the DPP Configuration Response message from the Configurator. The simple device attempts to connect to the network it has just configured.

[0057] In one case, the simple device 5 is able to connect successfully. It sets its configuration block and therefore no longer responds to DPP configuration before returning to the factory reset phase. The flow ends here.

[0058] In another case, a simple device 5 is not able to connect. It abandons the attempt to connect after a while, stores the reason for the failure in memory as a result of a previous configuration, and responds to DPP configuration again after a simple (and therefore not factory) reset or immediately after abandoning the attempt to connect to the network. When it is configured again, it includes the reason for the connection failure in one of the four possible messages of the DPP protocol. The reason for the failure may be deleted from memory during a factory reset.

[0059] During an attempt at a new configuration, ie in the case of a "new" device in the sense that it is not known whether the device has been configured before or connected to the network 1, the following may occur.

[0060] Either there is no previous configuration result (eg after the Simple Device 5 has undergone a factory reset). The Configurator simply sends a DPP Configuration Response to configure the Registrant, as specified by the unmodified DPP protocol.

[0061] Or a previous configuration result is available. There are two possibilities here.

[0062] First, the previous configuration result was a success; the Configurator simply sends a DPP Configuration Response to the Registrant. Simple devices will "forget" the previous configuration and (try to) use the new configuration exclusively. Non-simple devices, and especially mobile devices such as laptops or smartphones, will add the new configuration to their configuration list so that they can still connect to previously configured networks when moving around. The Registrant may have included information indicating whether it will add to or overwrite its existing configuration store.

[0063] Second, the previous configuration result was a failure; the configurator may display this to the user. The user can try to correct the situation based on this. For example, the user may decide to configure the device for a different network where the AP is closer to the registrant, or the user may simply try the same configuration again. Finally, a DPP Configuration Response message is sent, in which the DPP status code is set to STATUS_OK and contains a DPP Configuration object. In practical terms, the user can also try and remedy this situation by, for example, moving the registrant closer to the AP (or vice versa), setting the AP's Wi-Fi channel to a channel supported by the registrant, etc. When performing these operations, the user will abort the DPP configuration and send a DPP Configuration Response message with the DPP status code set to STATUS_CONFIG_REJECTED. The registrant will respond to the DPP configuration again after a simple reset, or keep responding to the DPP configuration (depending on its programming). Typically, the DPP Configuration Response message is sent within a fraction of a second after receiving the DPP Configuration Request, and the timeout period for the registrant to wait for the DPP Configuration Response message may be on the order of one second. When the timeout occurs, the registrant may decide to send its DPP configuration request again, because the DPP configurator may not have received the previous request (e.g. due to noise). For the two cases where the previous configuration result failed (reconfiguration or configuration rejection), the DPP configuration response message will not be sent quickly after receiving the DPP configuration request to allow the user to judge the situation and decide on the action. This may take tens of seconds. Therefore, the registrant should set its timeout for waiting for the DPP configuration response message to a larger value, which may be about one minute or more.

[0064] Another solution is to extend the (DPP) configuration phase by sending the Configuration Result message again after the Registrant successfully connects to AP 2. The problem with this is that it may take a long time for the Registrant to search for AP 2 on many channels, during which time the Configurator must stay on the configuration channel and listen for the Registrant - a process that may time out. If the Registrant is actually already connected to AP 2, the Registrant must leave the AP channel again in order to send the DPP Configuration Result message, which is inefficient and increases the risk of the entire process failing later.

[0065] As explained elsewhere herein, headless devices like the simple device 5 are often implemented so that they enter configuration mode or become responsive to (DPP) configuration after a factory reset. As previously described, a device may have network access issues after being configured. A headless device may give up trying to connect to its configured network after a period of time and, for example, return to a simple reset state (in which it still has configuration and network access issues that can be reported to the configurator), or it may enter a mode that responds to (DPP) configuration again. If the user wants to configure the device again, the user must reset the device for the device according to the first example, but if the device is of a type that automatically returns to being ready to be configured, this is not required. In order to help the user how to reconfigure the device, the device can include another attribute in any message sent to the configurator, where the device can also include a PrevCon attribute in which the device provides information about how to reconfigure it. This attribute can be called a ReconfigureInfo attribute. This may be anything from a simple 1-bit value of yes / no to reset the reconfiguration required, to a text description of how to reconfigure it or a URL pointing to a document describing how to reconfigure it. This attribute may indicate how long the device will attempt to connect to the network before responding again to reconfiguration. This is particularly useful for headless devices. During the first configuration attempt, the device should already include this ReconfigureInfo attribute in any messages sent to the configurator, so that the configurator can display this information to the user if the user suspects that the device just configured is having problems accessing the network. This may be in the form of a button saying "If there are connection problems, press position X". The ReconfigureInfo attribute may also contain an indication of whether the new configuration will overwrite the existing configuration or will be added to it.

[0066] An advantage of the proposed embodiment is that the user may be informed of the reason why a device (particularly a simple or headless device) will not join or associate with a desired network. Furthermore, the user may be aware of the problem without having to check the UI of the AP 2. Because the detection of the problem is based on a determination that there has been a previous attempt and the determination is made while the configuration process is being performed rather than after the process, the need to interrupt communications in order to check whether the configuration was successful is avoided. Furthermore, the user may be informed of the actions they may need to take to remedy the situation.

[0067] Figure 3a and Figure 3b An example of a medium access control (MAC) frame is shown. The example discussed is that of the IEEE 802.11 standard. However, it should be understood that other formats are possible as long as there is a frame body or payload portion. For the time being, the other parts, the frame header and error checking (here FCS) are not important.

[0068] During the DPP Configuration protocol phase of DPP, the general MAC frame format is the GAS frame format according to the IEEE 802.11 standard. During the DPP Authentication protocol phase of DPP, the general MAC frame format is the Public Action frame format according to the IEEE 802.11 standard. Attributes can be added to authentication request, authentication response, authentication confirmation, and configuration request messages. For convenience, the new attributes are named "PrevCon" and "ReconfigurationInfo" here, but other names can also be used. Between them, they contain information about previous configuration attempts, information required for reconfiguration, and whether the reconfiguration is an overwrite or append. In one embodiment, these are constructed as separate attributes, and in another embodiment, the information is presented in a single attribute structure.

[0069] According to one embodiment, the format of the information portion DPP authentication request message for the registrant device is:

[0070] SHA256(B R ),SHA256(B I ),PI,[Channel,]{I-nonce,I-capabilities,PrevCon} k1

[0071] in,

[0072] B R is the responder public bootstrap key

[0073] B I is the initiator public bootstrap key

[0074] PI is the initiator protocol key

[0075] [channel] is an optional indication of the initiator's preferred channel

[0076] I-nonce is reported by the initiator

[0077] I-capabilities are the capabilities of the initiator

[0078] PrevCon is the result of the previous attempt

[0079] {} k1Indicates that the information within the curly brackets has been encrypted using AES-SIV (RFC5297) with key k1. In addition to encryption (and therefore confidentiality protection), AES-SIV also provides integrity protection for the encrypted information. In addition, the AES-SIV encryption process protects the integrity of additional, plaintext data (Authentication Association Data). During the AES-SIV decryption process, any bit changes in AAD and the encrypted information will be detected and the decryption of the encrypted data will be declared invalid.

[0080] In DPP, the attributes before the attributes between curly braces are part of the authentication context data.

[0081] In another embodiment, the format is:

[0082] SHA256(B R ),SHA256(B I ),PI,PrevCon,[Channel,]{I-nonce,I-capabilities} k1

[0083] In this embodiment, the attributes about the previous configuration attempt (PrevCon) are sent in the clear, i.e., not encrypted. The PrevCon attribute should be used for {I-nonce, I-capabilities} k1 The AES-SIV encrypted portion of the Authentication Association Data (AAD) protects the integrity of the PrevCon attribute.

[0084] In another embodiment, the encrypted part (indicated between {}) or the unencrypted part may further include the attribute ReconfigurationInfo.

[0085] In the DPP authentication portion of the configuration protocol, where the responder device is the registrant, the format of the DPP authentication response according to one embodiment is:

[0086] DPP Status,SHA256(B R ),SHA256(B I ),{R-nonce,I-nonce,R-capabilities,PrevCon,{R-auth} ke} k1

[0087] Where PrevCon is the property associated with the previous configuration attempt, just like before.

[0088] In another embodiment, the format is:

[0089] DPP Status,SHA256(B R ),SHA256(B I ),PrevCon,{R-nonce,I-nonce,R-capabilities,{R-auth} ke} k1

[0090] In this embodiment, the attributes about the previous configuration attempt (PrevCon) are sent in the clear, i.e., not encrypted. The PrevCon attribute should be used for {R-nonce, I-nonce, R-capabilities, {R-auth} ke} k1 The AES-SIV encrypted authentication association data (AAD) is part of the authentication association data to protect the PrevCon attribute.

[0091] In another embodiment, the encrypted part (indicated between {}) or the unencrypted part may further include the attribute ReconfigurationInfo.

[0092] In the DPP authentication portion of the configuration protocol, where the responder device is the configurator, according to one embodiment, the format of the DPP authentication confirmation is:

[0093] DPP Status,SHA256(B R ),SHA256(B I ),{PrevCon,I-auth} ke

[0094] Where PrevCon is the property associated with the previous configuration attempt, just like before.

[0095] In another embodiment, the format is:

[0096] DPP Status,SHA256(B R ),SHA256(B I ),PrevCon,{I-auth} ke

[0097] In this embodiment, the attribute about the previous configuration attempt (PrevCon) is sent in the clear, i.e., not encrypted. The PrevCon attribute should be used for {I-auth} ke The AES-SIV encrypted portion of the Authentication Association Data (AAD) protects the integrity of the PrevCon attribute.

[0098] In another embodiment, the encrypted part (indicated between {}) or the unencrypted part may further include the attribute ReconfigurationInfo.

[0099] According to one embodiment, the format of the DPP configuration request is:

[0100] {E-nonce,configAttrib,PrevCon} ke

[0101] Among them, E-nonce is the registrant's nonce, and configAttriB is the DPP configuration attribute defined in the DPP specification.

[0102] In another embodiment, the format is:

[0103] PrevCon,{E-nonce,configAttrib} ke

[0104] In this embodiment, the attributes about the previous configuration attempt (PrevCon) are sent in the clear, i.e., not encrypted. The PrevCon attribute should be used for {E-nonce, configAttrib} ke The AES-SIV encrypted portion of the Authentication Association Data (AAD) protects the integrity of the PrevCon attribute.

[0105] In another embodiment, the encrypted part (indicated between {}) or the unencrypted part may further include the attribute ReconfigurationInfo.

[0106] The format of the DPP configuration response is:

[0107] DPP Status,{E-nonce,configurationObject} ke

[0108] Figure 3b The general format of the attribute PrevCon 31 is shown. The attribute ID identifies the attribute as a record of a previous configuration attempt. The length describes the length of the subsequent part, i.e., the variable. The variable may contain some or all of the following information:

[0109] - the result, i.e. success or failure, where success may mean that the registrant was able to contact an AP using the configured SSID in the registrant and was able to use the DPP connector, the Wi-Fi password or Wi-Fi PSK that the registrant received during the configuration process such that it has gained network access to the configured SSID,

[0110] - Reasons for failure,

[0111] -The SSID of the network or networks where a previous attempt was made,

[0112] - the transmit power to use when trying to connect to the network,

[0113] -Search the Wi-Fi channel list for your network,

[0114] - A list of SSIDs found while scanning Wi-Fi channels, but the SSID found is different from the one you want to connect to,

[0115] The "reason for failure" could be:

[0116] - The registrant was able to contact an AP that uses the configured SSID in the registrant and sent its DPP Connector to this AP in a DPP Peer Discovery Request message, but the DPP Peer Discovery Response message received from the AP returned a DPP status of "STATUS_INVALID_CONNECTOR"

[0117] or "STATUS_NO_MATCH". The reasons for these error codes are described in section 6.4.1 of [DPP]

[0118] Listed in

[0119] - The registrant is able to contact an AP using the SSID configured in the registrant, but when the registrant attempts to associate with the AP, it turns out that the Wi-Fi password or Wi-Fi PSK (pre-shared key) configured in the registrant is incorrect.

[0120] - The registrant scanned the channel list (list included) but could not find an AP with the configured SSID.

[0121] -Configuration failed.

[0122] The general format of the attribute ReconfigurationInfo has the same general structure.

[0123] Since the configurator must detect this, it must be programmed accordingly to parse the message correctly. It should be appreciated that this increases the complexity of the configurator and prolongs the execution time. It also increases the complexity on the registrant side, as more complex firmware and larger non-volatile memories are required. It should be remembered that there is huge price reduction pressure on such devices, and even seemingly small additions need to be justified. Furthermore, many of these devices are battery powered, and any additional energy consumption such as retrieving information, composing more complex messages, and sending those more complex and longer messages is discouraged, especially when the battery is small and intended to last a long time.

[0124] Aspects of the embodiments may be implemented in a computer program product, which may be a collection of computer program instructions stored on a computer-readable storage device that may be executed by a computer. Instructions may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), or Java classes. Instructions may be provided as complete executable programs, partial executable programs, as modifications (e.g., updates) to existing programs, or as extensions (e.g., plug-ins) to existing programs. Furthermore, portions of the processing of the present invention may be distributed across multiple computers or processors.

[0125] Storage media suitable for storing computer program instructions include all forms of non-volatile memory, including but not limited to EPROM, EEPROM and flash memory devices, magnetic disks such as internal and external hard drives, removable magnetic disks and CD-ROM disks. The computer program product may be distributed on such storage media or may be provided for download via HTTP, FTP, email or through a server connected to a network such as the Internet.

[0126] The following documents can be used as reference:

[0127] [802.11] IEEE Computer Society, “IEEE Standard for Information Technology–Telecommunications and Information Exchange Between Systems–Localand Metropolitan Area Networks–Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer(PHY)Specifications," (IEEEStd.802.11-2016), December 2016 [DH] Diffie, W.; Hellman, M. (1976), "New directions incryptography", IEEE Transactions on Information Theory, 22(6): 644–654

[0128] [DPP]Device Provisioning Protocol-Technical Specification-Version1.0,Wi-Fi Alliance,2018,https: / / www.wi-fi.org / file-member / device-provisioning-protocol-specification.[RD]The Resurrecting Duckling:SecurityIssues for Ad-Hoc Wireless Networks,University of Cambridge ComputerLaboratory,https: / / www.cl.cam.ac.uk / ~fms27 / papers / 1999-StajanoAnd-duckling.pdf[RFC5297]Synthetic Initialization Vector(SIV)AuthenticatedEncryptionUsing the Advanced Encryption Standard(AES),October 2008,(https: / / datatracker.ietf.org / doc / rfc5297 / )

Claims

1. A method of configuring a simple registrant device for communications in a wireless network, comprising: execute the configuration protocol, and A message is sent by the simple registrant device to a configurator device during execution of the configuration protocol, the message containing an indication of a status of a previous configuration attempt and a reason for a failure to connect to the wireless network if the previous configuration attempt failed.

2. The method according to claim 1, wherein: The message is one of the following: an identity authentication request message, an identity authentication response message, an identity authentication confirmation message or a configuration request message.

3. The method according to claim 1 or 2, wherein: Configuration is the part that establishes communications between the Simple Registrant device and another device in the wireless network.

4. The method according to claim 1 or 2, wherein: The indication includes information regarding at least one of: a result of the previous configuration attempt, an action performed as part of the previous configuration attempt, a network ID, and an indication of whether reconfiguration without reset was possible for the previous configuration attempt.

5. The method according to claim 1 or 2, wherein: Receipt of a message containing an indication that a previous configuration attempt was successful causes termination of the configuration protocol.

6. The method according to claim 1 or 2, wherein: Receipt of a message containing an indication of a previous configuration attempt causes the receiving device to display corresponding information on a user interface.

7. The method according to claim 1, wherein: The indication is contained in a segment of the message which is not encrypted.

8. The method according to claim 1, wherein: The indication is contained in a segment of the message that is encrypted.

9. A simple registrant device arranged to communicate in a wireless network, comprising a storage device and configured to participate in a configuration protocol, the configuration protocol being arranged to configure the simple registrant device for communication in the wireless network and to store in the storage device an indication of a previous configuration attempt to configure the simple registrant device and a reason why a connection to the wireless network failed if the previous configuration attempt failed, and to transmit the indication of a previous configuration attempt to configure the simple registrant device and the reason why a connection to the wireless network failed as part of a message of the configuration protocol to a configurator device.

10. The simple registrant device of claim 9, further configured to transmit instructions on how to reconfigure the simple registrant device.

11. The simple registrant device of claim 9 or 10, further configured to transmit an indication of whether a reconfiguration overwrites a previous configuration or is added to the previous configuration.

12. The simple registrant device according to claim 10, wherein: The indication of how to reconfigure includes at least one of: an indication that a reset is required, a text description containing instructions, and a URL pointing to a document describing how to reconfigure.

13. The simple registrant device of claim 9 or 10, further configured to erase said storage of said indication only after receiving a full reset.

14. A configurator device arranged to configure a device for communicating in a wireless network, the configurator device being configured to participate in a configuration protocol with a simple registrant device and, as part of the configuration protocol, detect in a message from the simple registrant device an indication of a previous configuration attempt to configure the simple registrant device and, if the previous configuration attempt failed, a reason for a connection failure to the wireless network.

15. The configurator device of claim 14, further configured to terminate the configuration protocol if the indication of a previous configuration attempt to configure the simple registrant device indicates a successful configuration.

16. The configurator device of claim 14, further configured to: if the configurator device determines from the message that a previous configuration attempt to configure the simple registrant device has occurred, display corresponding information on a user interface indicating that a previous configuration attempt to configure the simple registrant device has occurred.

Images