Status Report of Previous Connection

Abstract

To a method and device for performing a configuration protocol and configuring an enrollee device for communication in a wireless network.SOLUTION: In an enrollee device having a memory unit and a processor configured to participate in a configuration protocol, the configuration protocol is configured to configure the enrollee device for communication in a wireless network, store, in the memory, an indication of a previous configuration attempt to configure the device and, when the previous configuration attempt fails, an indication of the reason why, and during a subsequent configuration attempt to configure the enrollee device, transmit the indication stored in the memory unit of a previous configuration attempt performed prior to the subsequent configuration attempt.SELECTED DRAWING: None

Description

Technical Field

[0001] The present invention relates to an apparatus and method for use in a wireless network, particularly a wireless network compliant with the IEEE 802.11 standard family.

Background Art

[0002] FIG. 1 shows a wireless network 1 including a first device 2 and another device 3. The first device 2 has a central function and may be something like an access point (AP), a hub, or a gateway device. The first device 2 is hereinafter referred to as an AP for simplicity, but other types of devices are also actually possible. A user (not shown) desires to add two more devices to the network 1, namely a complex device 4 (represented here as a computer) and a simple device 5 (represented here as a toothbrush). Devices such as the simple device 5 often do not have an actual user interface (UI) other than perhaps a light, and are thus often referred to as "headless" devices. The AP 2 has a processor 6, and the simple device 5 has a microcontroller, a small non-volatile memory 7, and a button 8 that can be used to reset the simple device 5. There is also a third device 9.

[0003] In some wireless network standards, one device can configure another device in order to establish a connection and communicate. This eases the burden of the task of adding or registering a new device to the network in that the user no longer needs to perform manual input.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Devices with a user interface, such as a complex device 5, can display the connection status with an AP when a problem occurs after setting, for example, when the device cannot "find" the AP (or other device for which a connection is desired). However, for simple (headless) devices, the only way for the user to confirm a normal connection is to check the UI of the access point (AP), hub, or gateway. This does not apply to headless devices, i.e., devices without a user interface. When a problem occurs when these devices attempt to connect to the network they are set as a connection destination after setting, the user may not be able to recognize that a problem has occurred unless they know what the problem is and do not think to check the UI of the AP.

[0005] Document US2017 / 257819 discusses the provisioning of headless devices but does not consider previous connection attempts.

Means for Solving the Problem

[0006] Therefore, a method for setting a registered device for communication in a wireless network is provided, which includes executing a setting protocol and, during the execution of the setting protocol, transmitting, by the registered device, a message including an indicator of the status of previous setting attempts.

[0007] The provisioning device that receives the status of previous provisioning attempts becomes operational based thereon. For example, it can end the provisioning if unnecessary, or notify the user that a previous attempt has failed. The information provided to the user enables the user to understand why the device cannot connect to the target network and, perhaps, warns the user of the fact that it is not connected. This is particularly valuable in the case of simple or headless devices that do not have a means to directly inform the user of the device to be connected to the network. Such a device may appear to be provisioned, but may have failed to participate. The user may notice that the device has failed to participate, but not know why, and even worse, may not notice for some time. By obtaining such timely metrics, the user can save a lot 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 provisioning request message. These messages are exchanged between the provisioning device and the device registered during the provisioning process. By including a metric in one or more of these messages, a headless device according to one embodiment can automatically notify a provisioning device according to one embodiment of the result of a previous attempt without a specific user survey.

[0009] According to one embodiment, this provisioning is part of establishing communication between an enroll device and another device within a wireless network.

[0010] According to one embodiment, the indicator includes information regarding at least one of the results of previous setup trials, actions performed as part of previous setup trials, network IDs, and an indicator as to whether a reconfiguration for a previous setup trial performed is possible without reset. Based on the results of previous trials, the setup device can determine which flow to follow during setup and can show the results to the user. With a network ID, the setup device can determine the reason for a connection failure for a device for which setup was completed despite the connection failure.

[0011] According to one embodiment, upon receiving a message including an indicator of a successful previous setup trial, the setup protocol ends, thus avoiding potential problems that would not serve to trigger a reconfiguration trial.

[0012] According to one embodiment, upon receiving a message including an indicator of a previous setup trial, the receiving device displays corresponding information on the user interface, thus informing the user of the reason for the connection problem.

[0013] According to one embodiment, the indicator is included 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 indicator is included in a segment of an encrypted message. This has the advantage that it is more difficult for another malicious device to obtain information regarding the network (i.e., that a particular device tried to participate and failed for a particular reason), which can be used as part of an attempt to penetrate the network.

[0015] According to another aspect, a registration device is provided that is arranged for communication within a wireless network and configured to participate in a configuration protocol with a configuration device, the configuration protocol being configured to configure a device for communication within the wireless network and to store an indicator regarding a previous attempt to configure the device. By storing the result of the previous attempt, the registration device can provide information to inform the user of the result when attempting a new configuration.

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

[0017] According to one embodiment, the registration device is further configured to erase the recording of the indicator only after receiving a full reset. Thus, even if a partial reset is performed to prepare for configuration, the indicator is retained and as a result, the indicator can still be transmitted during configuration.

[0018] According to an embodiment, the registration device is further configured to transmit an indicator of how to reset the registration device. The indicator of how to reset includes at least one of an indicator of the reset it requested, a text description including instructions, and a URL to a document describing how to reset. Thereafter, a configurator (or other device with a UI) can display this information to the user, saving the user the trouble of searching for the information. The indicator can include information regarding whether the reset overwrites the previous configuration or is added to the previous configuration.

[0019] Information regarding the reset of the registration device is displayed by the configurator or by a device connected to the configurator, saving the user time in finding the information. Also, an indicator of whether the reset was added to or overwrote the existing configuration allows a properly programmed configurator to determine whether to abort the reset of a properly configured device.

[0020] According to another aspect, there is provided a setting device that is arranged to set up a device for communication in a wireless network, configured to participate in a setup protocol with a registration device, and as part of the setup protocol, detect an indicator regarding a previous attempt before setting up the registration device in a message from the registration device.

[0021] According to one embodiment, the setting device is further configured to terminate the setup protocol if the indicator indicates a successful setup. This is only useful if the user desires to reset due to a problem. The user may have thought there was a connection problem, but can know that there is no problem with the setup and thus no need to re-execute or change.

[0022] According to an embodiment, the setting device determines from the message that a previous attempt to set up the registration device has occurred, and displays corresponding information indicating that a previous attempt to set up the registration device has occurred on a user interface. Then, the setting device can detect the indicator, inform the user of its content, and respond according to its content by changing the flow of the setup process.

Brief Description of the Drawings

[0023] The above and additional objects, features, and advantages of the disclosed devices, systems, and methods will be better understood through the following illustrative and non-limiting detailed description of embodiments of the devices and methods with reference to the accompanying drawings.

Figure 1

Figure 2

Figure 3a

Figure 3b

Modes for Carrying Out the Invention

[0024] In the following description, the same reference numerals refer to like elements.

[0025] FIG. 2 shows a flow of a device control setting method according to an embodiment in which one device such as the third device 9 in FIG. 1 is set and can be connected to another device such as the complex or simple devices 4 and 5 in FIG. 1. The third device 9 and the devices 4 and 5 are according to the embodiment. As an example, the case of the simple device 5 will be described. Although much of this description provides examples including a network having a device such as the AP 2, it should be understood that this process may function in a peer-to-peer situation.

[0026] As an example of a device control setting method, there is a device provisioning protocol (DPP) used in a network using Wi-Fi or IEEE 802.11. In the device provisioning protocol (DPP), a device functioning as a DPP configurator can securely set any Wi-Fi-compatible device to connect to a Wi-Fi AP.

[0027] In S1, the process starts with the two devices 9 and 5 not being connected and the device 5 being in an unconfigured state. For the sake of discussion, the device 9 is used to configure the device 5 to participate in the wireless network 1, and thus the device 9 is called a configurator, and the device 5 may be called an enrollee (since it is "registered" in the wireless network 1).

[0028] In S2, often called "bootstrap", a certain device publishes the bootstrap public key (B of another device to be configured. R) is obtained. Since this is done by means other than wireless communication technology, it is generally called "out-of-band" (OOB) communication. For example, it may be the case where the user has a device read a QR code on a responder, NFC communication between two devices, or another wireless technology such as Bluetooth. The bootstrap process is initiated by user intervention. If the bootstrapping is successful, the process reaches S3, and devices 10, 5 are "bootstrapped", and if not, it returns to the "start" state of S1. In either case, the registering device (in this case, the simple device 5) can record the result of the bootstrap process in a suitable storage device, for example, as a flag in a register in the memory. A simple device often wakes up after manufacture or reset, turns on the radio of the channel indicated by the QR code for setting, and is programmed to start listening for authentication request messages. (A non-simple device is often set to this mode by its user, for example, by resetting it.)

[0029] In S4, the devices 9 and 5 execute an authentication procedure, by which the devices establish "trust". That is, the user can be confident that the device is something they trust and is not impersonating one or more of the devices in question, which are other unknown (and potentially malicious) devices. A message requesting the start of authentication is sent from one device. This message can be sent by either the device that performs the setting (configurator) or the device to be set (enrollee). In this example, the third device 9 functions as the configurator and the simple device 5 functions as the enrollee. Although the third device 9 is shown as being connected to the network 1, it should be noted that this is not necessarily required for the embodiment to function. The device that starts the wireless communication is called the initiator, and the device that responds is called the responder. In particular, the DPP protocol enables both the configurator and the enrollee device to operate as initiators of the DPP protocol, whereby other devices automatically become responders. Simple or headless devices usually play the role of the responder.

[0030] The counterpart device responds to this message. If the authentication request message is correctly decoded and contains information indicating that the initiator is a device trusted by the user and has the necessary functions, the response message indicates that the message has been "accepted", contains the information necessary for the initiator to verify the responder's qualification information, and indicates that it also has the necessary functions. If the two devices do not receive the necessary information from the other device, the process is interrupted and the devices return to the state where they were bootstrapped in S3. If the initiator is the enrollee, the authentication request message may also include an additional part indicating the result of previous attempts to configure the enrollee. If the responder is the enrollee, the authentication response message may include an additional part indicating the result of the previous attempt. It should be understood that the indicator also shows whether there was a previous attempt.

[0031] In the case of the DPP protocol, the first message is an authentication request message, and the response message is a DPP authentication response. The responder checks whether the DPP authentication request message has the encrypted hash of the correctly generated responder public bootstrap key and a copy of the initiator's public bootstrap key. The responder sends a DPP authentication response message indicating whether authentication can proceed. Otherwise, for example, if an attempt to decrypt the encrypted nonce in the DPP authentication request message fails, the process is aborted. The DPP authentication response includes the encrypted hash of the responder public bootstrap key and may include the hash of the initiator public bootstrap key. Similarly, for the initiator, the enroller may obtain this public key by OOB communication. Subsequently, the initiator's public bootstrap key can be used for mutual authentication. Without the initiator's public bootstrap key, only the initiator can authenticate the enroller, but not vice versa.

[0032] In the case of DPP, the indicator of the result of previous attempts can be in the form of a dedicated additional attribute in the frame body of the DPP authentication request or response message. The message format and content are described with reference to FIG. 3.

[0033] 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 setup, the initiator issues an authentication confirmation message. If it is determined by the relevant device that the authentication values of the authentication response and the confirmation message are correct, this part of the protocol, the authentication part, is successful, and the process reaches S6 and the setup can be started. The confirmation message may also include an indicator of the result of previous setup attempts where the enroller was also the initiator. In the case of the DPP protocol, the authentication confirmation message is a DPP Authentication Confirm message.

[0034] In S7, the enrollee device sends a configuration request message that includes information about the type of configuration required by the enrollee. If the configurator can grant the request, it sends a message that includes the information required by the enrollee, such as the network key. The process then ends at S8 and the enrollee configuration is successful. According to one embodiment, the configuration request can include an indicator of the results of previous configuration attempts.

[0035] 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 include the service set identifier (SSID) of the network to which the enrollee connects, and may include a DPP connector. The DPP connector can be regarded as a certificate digitally signed by the configurator, and particularly includes the enrollee's public network access key. The DPP Configuration Response message also includes the public signature key of the configuration. Other devices configured by the same configurator can thereby confirm whether they can trust the public network access keys of other devices. The DPP configuration response message may also include the Wi-Fi passphrase or pre-shared key (PSK) of the network. The enrollee sends a DPP configuration result message (depending on the version of DPP) to the configurator to indicate whether it accepts the configuration. The configurator not receiving this message can indicate to the configurator that there is a Wi-Fi problem between the configurator and the enrollee. Next, the enrollee that "is thought to be configured" can send its connector to DPP configuration AP 2. If the connector signature is detected to be correct and there is a matching connector on AP 2 (a connector of the same network signed by the same configurator), AP 2 sends its connector to the enrollee. The enrollee and AP 2 can calculate a symmetric key based on the mutual network access keys in the connector and their own private network access keys using the Diffie-Hellman method.

[0036] If the enrollee receives a Wi-Fi password or Wi-Fi Pre Shared key (PSK), the enrollee attempts to associate with AP 2 in the normal way via the 4-way handshake specified in [802.11].

[0037] On the one hand, if the enrollee (in this example, the simple device 5) fails to connect successfully, the enrollee interrupts the attempt after the programmed timeout period, and the enrollee stores information regarding the connection attempt and the connection failure and stops. The timeout may be very long or indefinite. If the user senses that the participation or connection to the network 1 is not functioning, the user can understand the situation, try the setting again, and then cause the simple device 5 to retry participating in the network 1.

[0038] If the configurator detects that the enrollee has experienced previous setting attempts, several possibilities exist, which depend in part on how the enrollee is arranged and what the previous results were.

[0039] Many devices, such as the simple device 5, are configured to hold only one setting at a time. Further, many are manufactured without a setting but are programmed to reject or ignore subsequent setting attempts after being set once. For example, a configuration block is a flag that is referenced each time a setting attempt for the device occurs. This behavior is similar to the process of imprinting on a particular animal, by which a young animal learns to recognize another individual as its "mother" if it sees that individual at a particular point in time. Once imprinted, the young animal rejects seeing other individuals as its mother. To reset such a device, some reset is required to remove the flag that prevents the device from participating in the setting process. Such a flag can be a status flag that has a value indicating either simply "set" or "not set".

[0040] If the previous configuration was successful and for the network in question, once configured, depending on how the enrollee is programmed to operate, there are various possibilities. If the simple device 5 is programmed not to accept a new configuration without a reset, the enrollee does not send the responses necessary to continue the process, and the configuration process ends.

[0041] Also, the configurator may operate in different ways. In one embodiment, the configurator can be configured to end the configuration and proceed directly to S8 because it may not make sense to retry (and risk failure). This branch of the flow can occur immediately when the configurator determines that the enrollee is already configured properly, for example, when an indicator is detected in any authentication message. If the configurator has a UI, it can notify the user that a previous successful configuration of the network in question has been performed. Alternatively, the configurator can simply continue the process and, if the enrollee is in a mode to accept configurations, simply add the new configuration to the enrollee's configuration store or (as often happens in the case of simple devices where the enrollee has only one configuration storage) overwrite the previous configuration. If the enrollee also provides information about the configuration method (described below), the configurator can learn how the reconfiguration affects the old configuration (such as overwriting) and notify the user via its own UI or the remote UI of another device such as AP 2 connected to the configurator. The configurator can also be programmed to stop the configuration of a simple device that can only overwrite existing configurations while continuing the configuration of a device that adds new configurations to the configuration store.

[0042] On the other hand, if the simple device 5 is properly configured but for a different network, it needs to be reconfigured, and the situation is the same as when the previous configuration failed.

[0043] If a reconfiguration is necessary (if the previous attempt failed or if it was not the correct network), the process proceeds to S9, where the configurator can notify the user of the results of the previous attempt via its own UI or a remote UI. This can also indicate to the user that a reconfiguration is needed again and whether the device in question needs to be reset to participate in the new configuration. Optionally, the user can reset the device and retry the configuration. Resetting the simple device 5 can not only delete the configuration block but also modify the record of previous configuration attempts in a manner that avoids the configurator aborting the configuration protocol in the middle. For example, the values in the record of previous attempts can be changed so that the correspondingly programmed configurator can detect the values and continue with the configuration. Alternatively, the configurator can be programmed to always continue with the configuration if the previous result indicates a connection failure.

[0044] The reset of the simple device 5 can be done by button 8. Button 8 can be a power button where the reset can be achieved by a short press as compared to the long press actually required to turn off the device. Alternatively, to avoid accidental reset, button 8 can be recessed into a hole.

[0045] The simple device 5 can have two levels of reset, namely a partial reset that erases any configuration blocks but does not remove the record of previous configuration attempts, and a full reset or factory reset to return the device to its so-called factory settings, including configuration blocks / status flags. Various ways of implementing the two-level reset are possible, for example, a short press and a long press, or one press for one level and two presses over a certain length of time for the other level.

[0046] In one embodiment, once set, the simple device 5 searches for the network it is set to and attempts to connect to the network. If a connection is possible, the connection is made and it stays on the selected network channel with the network. Otherwise, the attempt to participate times out and the simple device 5 gives up. Next, the simple device 5 returns to listening on either the default channel or a channel provided as part of the bootstrap process. Also, the connection status flag is set to "set", information regarding the failed connection attempt is recorded and placed in the new Connection Status attribute of the next set request message.

[0047] In one embodiment, the simple device 5 can have protocols such as a short press for a partial reset and a long press for a full reset.

[0048] In one embodiment, if no previous attempt has been made to set the enrollee, the indicator may be omitted. If the configurator notices the absence of the indicator, it simply continues with the protocol. In another embodiment, the indicator is present and contains a value indicating that no previous attempt to set has been made. And upon noticing this situation, the configurator simply continues.

[0049] The overall flow of attempting to add a simple device to a network can be seen from the user's perspective in the following example using the DPP protocol.

[0050] The simple device 5 wakes up after manufacture or after a reset at the factory, turns on its radio, sets it to the channel indicated by the QR code for DPP settings, and starts listening for DPP authentication request messages. Devices that are not simple devices are set to this mode by the user.

[0051] The simple device 5 receives the settings through the DPP protocol and accepts the settings in the DPP settings response message from the configurator. The simple device attempts to connect to the network that has just been set up.

[0052] In one case, the simple device 5 can successfully connect. It sets its configuration block and thus no longer responds to DPP settings until it returns to the factory reset stage. Here the flow ends.

[0053] In other cases, the simple device 5 cannot connect. After a while, it gives up the connection attempt, saves the reason for the failure in memory as a previous configuration result, and will respond to DPP settings again after a simple (non-factory) reset or immediately after giving up the connection attempt to the network. During reconfiguration, the reason for the connection failure is included in one of the four possible messages of the DPP protocol. The cause of the failure may be erased from memory during reset to the factory shipment settings.

[0054] During an attempt at a new configuration, i.e., in the case of a "new" device in the sense that it is not known whether the device has ever been configured or connected to network 1, the following situations can occur.

[0055] (For example, after the simple device 5 has received a factory shipment reset) None of the previous configuration results exist. The configurator simply sends a DPP configuration response and sets the enrollee as specified by the unchanged DPP protocol.

[0056] Or, the previous configuration results are available. Here there are two possibilities.

[0057] First, the previous configuration result was successful. The configurator simply sends the DPP configuration response to the enrollee. The simple device "forgets" the previous configuration and exclusively uses (attempts to use) the new configuration. Non-simple devices, particularly mobile devices such as laptops or smartphones, add the new configuration to their list of settings so that they can connect to previously configured networks while on the move. The enrollee may include information indicating whether to append to or overwrite the existing configuration storage.

[0058] The second is when the previous configuration result fails. The configurator can display this to the user. The user can then attempt to correct the situation based on this. For example, the user can decide to configure the device for another network where the AP is closer to the enrollee, or simply retry the same configuration. Finally, the DPP configuration response message is sent with the DPP status code set to Status_OK and including the DPP configuration object. In practical conditions, the user can attempt to improve the situation, for example, by moving the enrollee closer to the AP (or vice versa) and setting the AP's Wi-Fi channel to a channel supported by the enrollee. In performing these actions, the user aborts the DPP configuration, and the DPP configuration response message is sent with the DPP status code set to Status_CONFIG_REJECTED. The enrollee will (depending on its program) either respond to the DPP configuration again after a simple reset, or continue to respond to the DPP configuration. Usually, the DPP configuration response message is sent within 1 second after receiving the DPP configuration request, and the timeout for the enrollee to wait for the DPP configuration response message can be on the order of seconds. When timing out, the enrollee may decide to resend the DPP configuration request. In either case where the previous configuration result was a failure (either setting new or rejected), the DPP configuration response message is not sent immediately after receiving the DPP configuration request, so the user needs to judge the situation and decide on an action. This can take dozens of seconds. Therefore, the enrollee should set the timeout for waiting for the DPP configuration response message to a much larger value, probably on the order of 1 minute or more.

[0059] An alternative solution could be to extend the (DPP) configuration phase by having the enrollee resend the configuration result message after successfully connecting to AP 2. The problem with this is that the enrollee may take a long time to discover AP 2 on multiple channels, during which the configurator must stay on the configuration channel and listen for the enrollee, and the process may time out. If the enrollee actually connects to AP 2, the enrollee must then leave the AP channel again to send the DPP configuration result message, which is inefficient and increases the risk of the entire process failing.

[0060] As described elsewhere in this specification, headless devices such as simple device 5 are often implemented to enter a setup mode or respond to (DPP) settings after a factory reset. As previously described, the device may have problems accessing the network after being set up. The headless device can eventually give up trying to connect to the configured network and, for example, return to a simple reset state (still having the settings available for reporting to the configurator and network access problems) or re-enter the mode to respond to (DPP) settings. If the user wants to reconfigure the device, the user needs to reset the device according to the first example, except for types of devices that automatically return to a configurable state. To assist the user on how to reconfigure the device, the device can include another attribute, the PrevCon attribute, which provides information on how to reconfigure the device in any of the messages sent to the configurator. This attribute may be called the ReconfigureInfo attribute. This can be anything from a simple 1-bit value of yes / no reset required for reconfiguration to a text description of the reconfiguration method or a URL pointing to a document explaining the reconfiguration method. This attribute can indicate the time the device tries to connect to the network until it responds to reconfiguration again. This is particularly useful for headless devices. The device needs to already include this ReconfigureInfo attribute in any of the messages sent to the configurator in the initial setup, so that the configurator can display this information to the user when the user suspects that a just-set-up device has problems accessing the network. This can be in the form of a button saying "press location X in case of connection problems". The ReconfigureInfo attribute may include an indicator indicating whether the new settings overwrite or are added to the existing settings.

[0061] The proposed embodiment has the advantage that a device, particularly a simple or headless device, can inform the user of the reasons for not participating or being associated with a desired network. Further, the user can recognize the problem without having to check the UI of AP 2. The detection of the problem is based on the determination that there was a previous attempt, and this determination is made during the execution of the setup procedure rather than after the setup procedure, so there is no need to interrupt communication to check for the success of the setup. Further, the user can be informed of actions that may need to be taken to improve the situation.

[0062] Figure 3 represents an example of a MAC (Media Access Control) frame. Examples of problems are those 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 purposes of the present invention, the other parts, the frame header and the error check (here FCS) are not important.

[0063] In the DPP setting protocol phase of DPP, the general MAC frame format is the format of a GAS frame compliant with the IEEE 802.11 standard. In the DPP authentication protocol phase of DPP, the general MAC frame format is the format of a Public Action frame compliant with the IEEE 802.11 standard. Attributes can be added to the Authentication Request, Authentication Response, Authentication Confirm, and Configuration Request messages. The new attributes are, for convenience, named "PrevCon" and "ReconfigurationInfo" here, but other names can also be used. Between these, information about previous setup attempts, what is needed for reconfiguration, and whether the reconfiguration is overwritten or added is included. In one embodiment, these are configured as separate attributes, and in another embodiment, the information is presented in a single attribute structure.

[0064] For the information part regarding the enrollee according to an embodiment, the format of the DPP authentication request message is as follows: SHA256(B R ), SHA256(B I ), PI, [Channel,] {I-nonce, I-capabilities, PrevCon} k1

[0065] Here,

[0066] B R is the responder's public bootstrap key.

[0067] B I is the initiator public bootstrap key.

[0068] PI is the initiator protocol key.

[0069] [channel] is an indicator of the option of the channel prioritized by the initiator.

[0070] I-nonce is the initiator's nonce.

[0071] I-capabilities is the initiator's capabilities.

[0072] PrevCon is the result of the previous attempt.

[0073] {} k1It means that the information within the square brackets is encrypted by AES-SIV (RFC5297) using key k1. In addition to encryption, and thus confidentiality protection, AES-SIV provides integrity protection for the information being encrypted. Furthermore, the AES-SIV encryption process can protect the integrity of additional, unencrypted data (Authenticated Associated Data). During AES-SIV decryption, any bit change in the AAD and the encrypted information is detected and the decryption of the encrypted data is declared invalid. In DPP, the attribute preceding the attribute within the square brackets is part of the Authenticated Associated Data.

[0074] In another embodiment, the format is as follows: SHA256(B R ), SHA256(B I ), PI, PrevCon, [Channel,] {I-nonce, I-capabilities} k1

[0075] In this embodiment, the attribute regarding the previous configuration attempt (PrevCon) is sent in plain, i.e., unencrypted, state. To protect the integrity of the PrevCon attribute, the PrevCon attribute should be part of the Authenticated Associated Data (AAD) used for AES-SIV encryption of {I-nonce, I-capabilities}. k1

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

[0077] In the DPP authentication part of the configuration protocol, when the responder device is an enroller, the format of the DPP authentication response according to one embodiment is as follows: DPP Status, SHA256(B​R ), SHA256(B I ), {R-nonce, I-nonce, R-capabilities, PrevCon, {R-auth} ke} k1

[0078] Here, PrevCon is an attribute regarding previous configuration attempts.

[0079] In another embodiment, the format is as follows: DPP Status, SHA256(B R ), SHA256(B I ), PrevCon, {R-nonce, I-nonce, R-capabilities, {R-auth} ke} k1

[0080] In this embodiment, the attribute regarding the previous configuration attempt (PrevCon) is sent in plain, i.e., unencrypted, form. To protect the integrity of the PrevCon attribute, the PrevCon attribute should be part of the authenticated associated data (AAD) used for AES-SIV encryption of {R-nonce, I-nonce, R-capabilities, {R-auth} ke} k1

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

[0082] In the DPP authentication part of the configuration protocol, when the responder commissioning device is the configurator, the format of the DPP authentication confirmation according to one embodiment is as follows: DPP Status, SHA256(B R ), SHA256(B I), {PrevCon, I-auth} ke

[0083] Here, PrevCon is an attribute regarding a previous configuration trial.

[0084] In another embodiment, the format is as follows: DPP Status, SHA256(B R ), SHA256(B I ), PrevCon, {I-auth} ke

[0085] In this embodiment, the attribute (PrevCon) regarding the previous configuration trial is sent in plain, i.e., unencrypted, state. To protect the integrity of the PrevCon attribute, the PrevCon attribute needs to be part of the authenticated associated data (AAD) used for AES-SIV encryption of {I-auth} ke .

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

[0087] The format of the DPP configuration request according to one embodiment is as follows: {E-nonce, configAttrib, PrevCon} ke

[0088] Here, the E-nonce is the enrollment nonce, and configAttrib is the DPP configuration attribute defined in the DPP standard.

[0089] In another embodiment, the format is as follows: PrevCon, {E-nonce, configAttrib} ke

[0090] In this embodiment, the attributes (PrevCon) regarding the previous configuration attempt are sent in plain, i.e., unencrypted, form. To protect the integrity of the PrevCon attribute, the PrevCon attribute must be part of the authenticated associated data (AAD) used for AES-SIV encryption of {E-nonce, configAttrib} ke and is required to be part of the authenticated associated data (AAD) used for AES-SIV encryption of {E-nonce, configAttrib}.

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

[0092] The DPP configuration response format is as follows: DPP Status, {E-nonce, configurationObject} ke

[0093] Figure 3b shows the general format of the attribute PrevCon 31. The Attribute ID identifies that the attribute is a record of a previous configuration attempt. The length represents the length of the next part, Variable. The Variable can include some or all of the following information: - The result (i.e., success or failure). Here, success means that the AP configured with the SSID set during enrollment can be contacted, and it can be successfully associated with that AP using the DPP connector, Wi-Fi passphrase, or Wi-Fi PSK received by the enrolllee during configuration, and network access to the configured SSID can be obtained. - The reason for failure - The SSID of the network, or the SSID for which the previous attempt was made - The transmit power used when attempting to connect to the network - - List of Wi-Fi channels searched for the network, - - List of SSIDs found during Wi-Fi channel scan but found to be different from the destination SSID

[0094] The "reason for failure" can be as follows: - The enrollee contacted an AP using the SSID set in the enrollee and was able to send a DPP connector to this AP in the DPP peer discovery request message, but the DPP peer discovery response message received from the AP returned a DPP status of "STATUS_INVALID_CONNECTOR" or "STATUS_NO_MATCH". The reasons for these error codes are described in Section 6.4.1 of [DPP]. - The enrollee was able to contact an AP using the SSID set in the enrollee, but it was found that the Wi-Fi passphrase or Wi-Fi PSK (pre-shared key) set in the enrollee was incorrect. - The enrollee scanned the list of channels (including the list) but was unable to find an AP with the set SSID. - The setting failed.

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

[0096] Since the configurator needs to detect this, it needs to be appropriately programmed to correctly analyze the message. It is necessary to understand that this increases complexity and lengthens the execution time of the configurator. Also, the complexity on the enrollee side increases in that more complex firmware and a larger non-volatile memory are required. Note that there is significant downward price pressure on such devices, and even a slight addition clearly requires justification. Furthermore, many of such devices are battery-powered, and extra energy consumption, such as reading information, constructing more complex messages, and sending more complex and long messages, is actively discouraged, especially when the battery is small and intended to last for a long time.

[0097] Aspects of this embodiment may be a set of computer program instructions stored on a computer-readable storage device that can be executed by a computer, and may be implemented in a computer program product. The instructions may be any interpretable or executable code mechanism, including (but not limited to) scripts, interpretable programs, dynamic link libraries (DLLs), or Java classes. The instructions may be provided as a complete executable program, a partial executable program, a modification (e.g., update) to an existing program, or an extension (e.g., plugin) to an existing program. Furthermore, a part of the processing of the present invention can be distributed among multiple computers or processors.

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

[0099] [References] [802.11]IEEE Computer Society, “IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” (IEEE Std. 802.11-2016), December 2016 [DH]Diffie, W.; Hellman, M. (1976), "New directions in cryptography", IEEE Transactions on Information Theory, 22 (6): 644-654 [DPP]Device Provisioning Protocol - Technical Specification - Version 1.0, Wi-Fi Alliance, 2018, https: / / www.wi-fi.org / file-member / device-provisioning-protocol-specification. [RD]The Resurrecting Duckling: Security Issues for Ad-Hoc Wireless Networks, University of Cambridge Computer Laboratory, https: / / www.cl.cam.ac.uk / ~fms27 / papers / 1999-StajanoAnd-duckling.pdf [RFC5297]Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES), October 2008, (https: / / datatracker.ietf.org / doc / rfc5297 / )

Claims

1. An enrollee device configured for communication in a wireless network, the enrollee device having a memory unit and a processor configured to participate in a configuration protocol configured to configure the enrollee device for communication in the wireless network, the configuration protocol storing in the memory an indication of a previous configuration attempt to configure the device and, if a previous configuration attempt failed, an indication of the reason why the previous configuration attempt failed, and during a subsequent configuration attempt to configure the enrollee device, transmitting the indication stored in the memory unit of the previous configuration attempt performed prior to the subsequent configuration attempt.

2. 2. The enrollee device of claim 1, further configured to transmit said indication as part of a message of said setup protocol.

3. 3. The enrollee device of claim 1 or 2, further configured to transmit an indication as to how to reconfigure the enrollee device.

4. 4. The enrollee device of claim 1, further configured to transmit an indication of whether the reconfiguration will overwrite or be added to a previous configuration.

5. 4. The enrollee device of claim 3, wherein the indication of how to reset includes at least one of an indication of whether a reset is needed, a text description containing instructions, and a URL to a document describing how to reset.

6. 6. The enrollee device of claim 1, further configured to delete said storage of said indicator only after receiving a full reset.

7. a configurator device configured to configure a device for communication in a wireless network, configured to participate in a configuration protocol with an enrollee device, and detecting, during a configuration attempt to configure the enrollee device, an indication in a message from the enrollee device regarding a previous configuration attempt to configure the enrollee device that was performed prior to the configuration attempt.

8. The configurator device of claim 7 , further configured to terminate the configuration protocol if the indication indicates success of the previous configuration attempt.

9. 8. The configurator device of claim 7, further configured to, if it is determined from the message that a previous configuration attempt has been made to configure the enrollee device, display corresponding information on a user interface indicating that a previous configuration attempt has been made to configure the enrollee device.

Images