Loop prevention when reconfiguring a device

Abstract

There is provided a method of configuring an enrollee device for communication in a wireless network, comprising a configurator device, the configurator and the enrollee device performing at least part of a configuration protocol, the enrollee device encrypting enrollee identification information using public key information of the configurator and random information to produce a first encrypted message, the enrollee device transmitting the first encrypted message to the configurator device; the configurator device receiving the first encrypted message, the configurator device decrypting the first encrypted message using private key information associated with the public key, the configurator device using the enrollee identification information to identify the enrollee device, and deciding, based on the enrollee identification information, whether the configuration should continue. There is also provided a configurator and enrollee device arranged to perform the method.

Description

Technical Field

[0001] This invention relates to devices and methods for use in wireless networks, particularly those conforming to the IEEE 802.11 series of standards. Background Technology

[0002] Figure 1 This refers to wireless network 1, which includes a first device 2 and another device 3. The first device 2 may have a central function and resemble an access point (AP), hub, or gateway device. For simplicity, the first device 2 will hereafter be referred to as the AP, but other types of devices are indeed possible. A user (not shown) wishes to add more than two devices to network 1: a complex device 4 (represented here as a computer) and a simple device 5 (represented here as a toothbrush). Devices like the simple device 5 typically lack any real user interface (UI) except perhaps a light, and are therefore often referred to as "headless" devices. The AP2 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 to establish a connection and communication. This makes adding or registering new devices in a network less cumbersome, as users no longer need to manually enter information. The device that requires configuration to join a network can be called an "Enrolle," and the device that performs the configuration can be called an "Configurer."

[0004] It's possible that, although the configuration process may have completed successfully, the configured device may still be unable to connect to network 1 (or may be already connected but unable to reconnect for some reason). There are many possible reasons for this, some of which are:

[0005] The registrant can contact a node using the network ID configured in the registrant's settings and send its information and related keys in a message to request joining, but receives a response indicating that the request is invalid or does not match the expected values. This is in accordance with the IEEE 802.11 Device Provisioning Protocol (DPP) (also known as "Wi-Fi EasyConnect"). TMIn the case of ""), the node can be an AP, and the request message is sent to that AP in a DPP Peer Discovery Request message containing the DPP connector. The response is a DPP Peer Discovery Response message, and the DPP status in it is either "STATUS_INVALID_CONNECTOR" or "STATUS_NO_MATCH". The reasons for these error codes are listed in section 6.6.1 of [DPP]. One of the reasons for the DPP status "STATUS_INVALID_CONNECTOR" listed here is that the registrant's NAK has expired and is no longer accepted by the AP.

[0006] The registrant is able to contact the s node in the network using the ID configured in the registrant, but when the registrant attempts to associate with the node, it proves that the password or PSK (pre-shared key) configured in the registrant is incorrect.

[0007] The registrant scanned the channel list (including the list of channels) but could not find a node with the configured ID. This could be due to, for example, the node moving to a channel not supported by the registrant, the registrant and / or the node physically moving out of range, or an object blocking the signal being placed between the registrant and the node.

[0008] In DPP, a connector is a data structure that contains information that allows a receiving device to establish a trust relationship with another device in the network under discussion. A connector may contain information such as a network access key (NAK), which is used to establish a shared secret or encryption key for use between the receiver and other devices in the network.

[0009] Devices with user interfaces, such as the complex device 4, can display the connection status to the AP (or an equivalent node in the network under discussion) and whether problems have occurred after configuration, for example, if the device cannot "find" the AP (or other devices it expects to connect to). Furthermore, in the case of a complex device, the UI may display instructions to the user on how to resolve connection problems.

[0010] However, for simple (headless) devices, the only way for users to observe a successful connection is to test the functionality of the connection or check the UI of the access point (AP), hub, or gateway. If these devices encounter problems when trying to connect to the network they are configured to connect to after configuration, the user will not know what is wrong and may not realize it until later when they find the connection is missing, or unless they want to check the AP's UI. Summary of the Invention

[0011] Therefore, there is a need to provide a method for configuring a registrant device for communication in a wireless network. The method is arranged to be used with a configurator device, which includes a configurator and a registrant device that execute at least a portion of a configuration protocol. The registrant device encrypts registrant identification information using the configurator's public key information and random information to generate a first encrypted message. The registrant device transmits the first encrypted message to the configurator device, which receives the first encrypted message. The configurator device decrypts the encrypted portion of the first encrypted message using private key information associated with the public key. The configurator device uses the registrant identification information to identify itself and determines whether the configuration should continue based on the registrant identification information.

[0012] When the configurator can identify the actual device, it may be able to determine that there is a situation that means (re)configuration should not continue—or at least without user intervention. The configurator may be able to determine this by recognizing relevant messages it receives from the registrant regarding the connection status. For example, when the registrant fails to find the AP, user intervention could be something like moving the registrant closer to the relevant access point or fixing the access point's problem. However, the current trend of using different random MAC addresses for different protocol exchanges is problematic. The result of devices using random MAC addresses for DPP reconfiguration is that the configurator no longer knows the registrant's actual identity until multiple messages have been exchanged, which is a waste of resources. By allowing the registrant to be identified from its initial request for reconfiguration, the configurator can then identify the registrant's connection status from its history and terminate the reconfiguration when it identifies a problem requiring user intervention.

[0013] In one aspect, if the configurator decides it should not continue configuring, it does not reply to the first encrypted message. This allows for the simple termination of this reconfiguration cycle.

[0014] In one aspect, the registrant device transmits a first-part encrypted message as a result of failing to connect to the wireless network.

[0015] In one aspect, if the configurator decides it should not continue configuring, it sends a rejection message to the registrant. This allows registrants with more advanced interfaces to signal to the user that a connection / configuration problem has occurred.

[0016] In one aspect, the configuration protocol is based on the Wi-Fi DPP protocol, and the first encrypted message is a DPP reconfiguration message.

[0017] In one aspect, the identification information is used by the configurator device to identify a stored record of the registrant connection status previously sent by the registrant device during the operation of a portion of the configuration protocol.

[0018] According to the method of any of the foregoing aspects, a portion of the configuration protocol includes the registrant device sending registrant identification information.

[0019] This allows the configurator to identify the registrant and look up its connection status history.

[0020] In one aspect, the configurator is configured to display status and / or instructions to the user if a decision is made not to continue. This helps the user resolve the issue.

[0021] A registrant device is also provided, configured by a configurator device using a configuration protocol for communication in a wireless network. The registrant device includes: a receiver configured to receive a configurator device public key from the configurator device; a security module configured to encrypt a first portion of an encrypted message using the configurator device public key, the first encrypted message including registrant identification information and random information; and a transmitter configured to transmit the first portion of the encrypted message to the configurator device.

[0022] In one aspect, as a result of failing to connect to the wireless network, the registrant device sends a first part of an encrypted message.

[0023] A configurator device is provided, configured to configure a registrant device using a configuration protocol. The configurator device includes: a transmitter configured to send a configurator device public key to the registrant; a receiver configured to receive a first portion of encrypted message from the registrant device; a security module configured to decrypt the encrypted portion of the first portion of encrypted message using a configurator device private key and derive registrant identification information based on the first encrypted message; and a processor configured to determine whether to continue the configuration protocol based on the registrant identification information.

[0024] In one aspect, the configurator device is arranged to display status and / or instructions to the user if it is decided not to continue the protocol.

[0025] Also provided is a computer program product on a machine-readable medium, which is configured to implement the configurator and registrar portions described herein when the configurator processor and registrar processor are running. Attached Figure Description

[0026] Referring to the accompanying drawings, the above and additional objects, features, and advantages of the disclosed apparatus, systems, and methods will be better understood through the following illustrative and non-limiting detailed description of embodiments of the apparatus and methods, in which:

[0027] Figure 1 This indicates a wireless network, for which we expect to configure devices to add them.

[0028] Figure 2 This describes the flow of the configuration process according to the embodiment.

[0029] Figure 3a This refers to the registrant device according to the embodiment.

[0030] Figure 3b This refers to the configurator device according to the embodiment.

[0031] Figure 4a This refers to an exemplary 802.11 MAC frame that can be used in an embodiment.

[0032] Figure 4b This indicates the attributes according to an embodiment of the 802.11 MAC frame. Detailed Implementation

[0033] In the following description, the same reference numerals designate similar elements.

[0034] Figure 2 This describes the flow of a configuration method for device control according to an embodiment, wherein a device (e.g., Figure 1 The third device 9) can be configured and connected to another device (e.g. Figure 1 The third device 9 and devices 4 and 5 are according to the embodiments. As an example, the case of simple device 5 will be discussed. It should be understood that although most of this description provides an example involving a network with devices similar to AP2, the process can work in peer-to-peer situations.

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

[0036] At S1, the process begins with both devices 9 and 5 in an unconnected state, and device 5 is not configured. For the purposes of discussion, device 9 will be used to configure device 5 to join wireless network 1, so device 9 can be referred to as the configurator, and device 5 is referred to as the registrant (because it is being "registered" in wireless network 1).

[0037] At point S2, commonly referred to as "bootstrapping," one device (responder) obtains the bootstrap public key (B) of another device (initiator). R When a responder device requests mutual authentication, it also obtains the initiator's bootstrap public key (B). I This is achieved through a means other than wireless communication technology, and is therefore often referred to as “out-of-band” (OOB) communication. Examples of this include a user enabling a device to read another device's QR code, NFC communication between two devices, or another wireless technology such as Bluetooth. The bootstrapping process is initiated by user intervention. If bootstrapping is successful, the process reaches S3, and devices 9 and 5 are “bootstrapping”; otherwise, they return to the “start” state at S1. In either case, the registrant device (in this case, simple device 5) may record the result of the bootstrapping process in an appropriate storage device, such as as a flag in a register in memory. Often, simple devices are programmed to wake up after manufacturing or reset, turn on their radio on the channel indicated in their QR code for configuration, and begin listening for authentication request messages.

[0038] At S4, devices 9 and 5 perform the authentication process, where the devices establish "trust," meaning the user can be certain that the device is the one they believe to be, and not some unknown (and potentially malicious) device "pretending" to be one of the devices in question. A message requesting the start of authentication is sent from one device. This message can be sent by the device performing the configuration (configurer) or the device to be configured (registerer). In this example, the third device 9 acts as the configurator, and the simple device 5 acts as the registerer. It should be noted that the third device 9 is shown connected to network 1, but this is not necessary for the operation of this embodiment. The device that initiates wireless communication is called the initiator, and the device that responds is called the responder. Specifically, the DPP protocol allows both the configurator and registerer devices to act as initiators of the DPP protocol, thereby automatically making the other device a responder. Simple devices or headless devices typically assume the responder role.

[0039] Another device responds to the message. If the authentication request message is correctly decoded and contains information indicating that the initiator is the device the responder believes it to be and has the required capabilities, the response message indicates that the message has been "accepted" and contains the information the initiator needs to verify the responder's certificate and that it also has the required capabilities. If neither device receives the required information from the other, the process aborts, and the device returns to the bootstrap state at S3. If the initiator is a registrant, the authentication request message may also contain an additional part indicating the result of a previous attempt to configure the registrant. If the responder is a registrant, the authentication response message may contain an additional part indicating the result of a previous attempt. It should be understood that this indication also indicates whether a previous attempt has been made.

[0040] 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 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 authentication can continue. If not, for example, because an attempt to decrypt the encrypted random number in the DPP authentication request message fails, the process is aborted. The DPP authentication response contains a cryptographic hash of the responder's public bootstrap key, and may also contain a hash of the initiator's public bootstrap key. Similarly, for the initiator, the registrant may have already 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, and vice versa.

[0041] If the authentication response message indicates that the responder has accepted the authentication request message and that 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, this part of the protocol, i.e., the authentication part, is successful, the process has reached S6, and configuration can begin. The confirmation message may also contain an indication of the result of a previous configuration attempt by the registrant, who is also the initiator.

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

[0043] At S7, the registrant device sends a configuration request message containing information about the type of configuration the registrant desires. If the configurator approves 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 successful configuration by the registrant. According to an embodiment, the configuration request may include an indication of the result of a previous configuration attempt.

[0044] In the case of DPP, the request message is a DPP configuration request, and the configurator's response is a DPP configuration response message. The DPP configuration response may contain the Service Set Identifier (SSID) of the network the registrant should connect to, and may also contain a DPP connector. The DPP connector is digitally signed by the configurator using a key (C-sign key) and contains the registrant's public network access key, etc. The DPP configuration response message also contains the public signature key for the configuration. Other devices already configured by the same configurator can thus check whether they can trust the public network access key of other devices. The DPP configuration response message may also contain the network's Wi-Fi password or pre-shared key (PSK). The registrant sends a DPP configuration result message (depending on the DPP version) to the configurator to let it know whether it accepts the configuration. The configurator's failure to receive this message may indicate a Wi-Fi problem between the configurator and the registrant. The "presumably configured" registrant can then send its connector to the DPP-configured AP2. If the connector signature is found to be correct, and if AP2 has a matching connector—that is, a connector signed by the same configurator for the same network—then AP2 sends its own connector to the registrant. The registrant and AP2 can compute a symmetric key in the Diffie-Hellman [DH] manner based on each other's network access keys in the connector and their own private network access keys. This symmetric key can be used by the registrant as the PSK associated with AP2.

[0045] At S8, registrant 4 or 5 attempts to connect to the network. In the case of Wi-Fi, the registrant will have received the Wi-Fi password or Wi-Fi pre-shared key (PSK), and the registrant attempts to associate with AP2 in a normal manner using the Wi-Fi password or Wi-Fi pre-shared key through a 4-way handshake as specified in [802.11]. If the connection attempt is successful, the process proceeds to S9, where the process is complete.

[0046] On the other hand, if the registrant is unable to connect, different results may occur.

[0047] For the complex device 4, the registrant can display messages to the user to inform them of the status and guide them on how to resolve the issue. However, the simple device 5 has no UI. If it fails to connect, it will give up trying after its programmed timeout period unless it undergoes further programming as outlined in this article.

[0048] This protocol may require, and indeed DPP does require, that the registrant return a connection status message to the configurator. In the case of DPP, the message is called the DPP connection status result and is formatted as follows:

[0049] Registrant → Configurator: {E-nonce, DPP connection status}ke

[0050] DPP connection status E-Nonce uses the encryption key calculated during the initial authentication period. ke Encrypt it. DPP connection state The values ​​are given in the table below.

[0051]

[0052] When the DPP connection status is STAUS_NO_AP, the DPP connection status attribute also includes a channel list, which indicates the channels that the registrant scans when attempting to discover the AP to which it is configured to connect.

[0053] If the status message indicates that the registrant has successfully connected to the network it just configured, the process is passed to S9.

[0054] If the status message indicates that the registrant failed, there are alternatives.

[0055] In an alternative solution, the process can directly return to S7, where the registrant device sends a configuration request message with information about the type of configuration the registrant wants. In this case, a DPP reconfiguration notification message will not be needed. Note that, potentially helpfully, both devices will then use the key established during the earlier authentication phase. Furthermore, since this will be part of a single protocol operation, the MAC addresses will not be changed, and there will be no issues associated with them.

[0056] While configuration usually succeeds and the registrant will be able to connect to the network the device was just configured for, connectivity issues can arise at any time, even years later. It's possible that the AP or registrant was moved to another location at some point and thus became out of Wi-Fi (RF) range. It's also possible that the NAK in the registrant's connector has expired and is no longer accepted by the AP. Furthermore, it's possible that the old AP was replaced by a new one and the registrant was ignored during the reconfiguration of the new network.

[0057] In another alternative, the process could proceed to S10 (which may involve a series of message exchanges), where attempts are made to implement the new configuration. For DPP, this process consists of a series of messages:

[0058] Registrant -> Configurator: Reconfigure notification messages

[0059] Configurator -> Registrant Reconfigure Authentication Message

[0060] Registrant -> Configurator: Reconfigure authentication response

[0061] Configurator -> Registrant: Reconfigure Authentication Confirmation

[0062] Registrant -> Configurator: Reconfiguration Request

[0063] Configurator -> Registrant: Reconfigure Authentication Response

[0064] In the case of DPP, the format of the DPP reconfiguration notification is as follows:

[0065] Registrant -> Configurator: SHA256 (C-sign key)

[0066] As can be seen, this is a simple message containing the SHA-256 hash of the configurator's public signature key (see [FIPS180-4]). The configurator receiving this message can calculate the SHA-256 hash of all public signature keys it has previously used to check if it has previously configured a registrant to send DPP reconfiguration notification messages. If the configurator has previously configured a registrant, it will act as the initiator in the reconfiguration and continue sending DPP reconfiguration authentication request messages to the registrant. The format of the DPP reconfiguration authentication request is as follows:

[0067] Configurator -> Registrant: TransId, Protocol Version, I-Connector, I-nonce.

[0068] The DPP connector contains a so-called Public Network Access Key (NAK) and other information. The DPP connector is digitally signed by the configurator signing key. I-Connector It is the connector for the initiator, i.e., the connector for the configurator.

[0069] The registrant and the AP's DPP connectors may or may not match. When they match, both devices can calculate the PMK (Pairwise Master Key) required for the registrant to associate with the AP, see Section 6.6 of [DPP]. This calculation is based on the Diffie-Hellman procedure [DH]. One of the requirements for two DPP connectors to match is that they use the same type of public key. By "same type of public key," we mean the same type of encryption and that the specific parameters related to the encryption are identical.

[0070] For example, the implementation of the protocol in [DH] uses a multiplicative group of integers modulo q, where q is a prime number (referred to in [DH] as "a finite field GF(q) with q prime elements"), and α is a primitive root modulo q (referred to in [DH] as "a fixed primitive element of GF(q)"). When using the Diffie-Hellman implementation as described in [DH], the parties must agree on q and α. For the purposes of this document, all public keys generated with the same values ​​of q and α are considered to be of the same type.

[0071] Elliptic curves can also be used with Diffie-Hellman, see [NIST 800-56A-3]. When using elliptic curves, both parties must agree on all elements defining the elliptic curve, i.e., the domain parameters of the scheme. Table 24 in [NIST 800-56A-3] lists many named sets of domain parameters, such as P-256, P-384, and P-521. The larger the number in the name, the better or stronger the security that Diffie-Hellman provides against attacks. For the purposes of this study, all public keys generated using the same set of domain parameters of an elliptic curve (e.g., P-256) are considered to be of the same type.

[0072] It is important to note that DPP specifies the use of Diffie-Hellman's DPP versions P-256, P-384, P-521, brain bank P-256r1, brain bank P-384r1, and brain bank P-512r1 in the DPP certification agreement. The brain bank curves are specified in [RFC5639].

[0073] It should be understood that actual public keys, such as specific P-256 keys, are typically included in the public key type within a structure containing the public key when they are transmitted in a message. An example of an elliptic curve public key represented as an ASN.1 structure called SubjectPublicKeyInfo, as specified in Section 4.1 of [RFC5280], is the following ASN.1 notation:

[0074] SEQUENCE {

[0075] SEQUENCE {

[0076] OBJECTIDENTIFIER 1.2.840.10045.2.1 (ecPublicKey)

[0077] OBJECTIDENTIFIER 1.2.840.10045.3.1.7 (P-256)

[0078] }

[0079] BITSTRING 0x0343A6A094A9BC6C9B92CBA3164849F0DB0B91350270ABE80DC554 B1E6B3897F30:0 unused bit(s)

[0080] }

[0081] The two OBJECTIDENTIFIER together define the type of the public key, while BITSTRING contains the value of that specific public key.

[0082] In DPP, elliptic curve cryptography [RFC6090] is used for all asymmetric cryptography, especially network access keys (NAK) and configurator signature keys, but other forms of asymmetric cryptography, such as multiplicative groups of integers modulo q as described in [DH], are also possible.

[0083] The I-Connector sent in the DPP reconfiguration authentication request does not serve its normal purpose as a configuration registrant. Instead, it provides the registrant with the public key provided by the configurator, namely the configurator NAK, which is signed by the configurator, allowing the registrant to verify the signature, and thus enabling them to believe that the configurator NAK indeed comes from their configurator. In this case, the configurator NAK is used as one of several components of the shared key created by the registrant and the configurator for the cryptographic parts of the DPP Reconfig Authentication protocol and subsequent DPP configuration protocols. In this context, the configurator NAK is also referred to as C in the DPP specification [DPP]. I。

[0084] Now, the registrant receiving the DPP reconfiguration authentication request message from its configurator uses NAK from its own connector (the R-Connector it received from its configuration during the previous DPP configuration), and I-Nonce and C from the I-Connector it received in the DPP reconfiguration authentication request. I The key ke is calculated as specified in Section 6.5.4 "DPP Reconfigure Authentication Response" of [DPP].

[0085] The format of the DPP reconfiguration authentication request is as follows:

[0086] Responder -> Initiator: TransId, Protocol Version, R-Connector, Pr, {I-nonce, R-nonce, connection status ke

[0087] The "Connectivity Status" attribute is the same as the DPP connectivity status explained above. Using this attribute, the registrant notifies the configurator of any connectivity issues it knows about, allowing the configurator to determine if it can perform automatic reconfiguration, for example, when the registrant's NAK has expired. When the connectivity status indicates that the AP could not be found, this can be understood as a problem with the wireless link itself (the registrant and the AP are not in range) or a problem with the AP. In turn, this might mean that the configurator's user must do something before being able to reconfigure the registrant again, such as reconfiguring the AP or bringing the devices closer together. In cases where user intervention is required first, the configurator can use its UI to alert the user to this fact, for example, in the form of an alert, an Android notification, and / or as part of its stored configuration "to-do list."

[0088] When the DPP configurator receives a DPP reconfiguration notification from the registrant, it may be able to identify the MAC address of the registrant who sent the original reconfiguration notification message. This allows the configurator to identify the registrant's device and its history of previously running configuration or reconfiguration protocols, including the reasons given in the DPP status previously provided by the registrant. As can be seen, several messages have been exchanged before the DPP configurator can assess the reasons for the apparent failure of previous configuration and connection attempts.

[0089] It should be understood that the initial reconfiguration request (or DPP reconfiguration notification for DPP) can be repeated until the registrant receives a response from the configurator. In the case of complex registrant devices, the user may be notified of the problem and given information on how to resolve it via the device UI. However, in the case of simple registrant devices, the registrant may simply continue repeating its reconfiguration request instead of remaining disconnected and therefore unavailable. This is likely to happen without the user's knowledge.

[0090] When the configurator is able to identify the actual device, it may be able to determine that there is a situation that means (re)configuration should not continue—or at least without user intervention. The configurator may be able to determine this by recognizing relevant messages it receives from the registrant regarding the status of the connection. For example, when the registrant fails to locate the AP, user intervention might be something like moving the registrant closer to the relevant access point or fixing a problem with the access point.

[0091] The inventors have recognized a more serious problem. The current trend is for devices to increasingly use random (Wi-Fi) MAC addresses to protect privacy. Wi-Fi devices transmit so-called probe requests (see [802.11]) multiple times to find out which access points (APs) are within their Wi-Fi range. If the same MAC address is always used, the device's location can be tracked, which can be considered undesirable and a privacy violation. To protect their privacy, devices may use random MAC addresses in every complete protocol exchange, thus making it impossible to track their location using their MAC address.

[0092] The consequence of a device using a random MAC address for DPP reconfiguration is that the configurator no longer knows the actual identity of the registrant, as multiple (re)configuration requests may arrive with different MAC addresses. This means that, in turn, the configurator will have to wait for a DPP reconfiguration authentication response message to know which actual registrant it is processing and whether it can reconfigure the current sender of the DPP reconfiguration notification message it just received. The DPP specification allows the configurator to signal to the registrant whether it will (re)configure the registrant only with a DPP configuration response message, which is the fifth Wi-Fi message following the DPP reconfiguration notification message. If there are reasons beyond the control of the configurator and the registrant (e.g., a poor connection to the AP or a malfunction in the AP), the reconfiguration attempt will (again) fail.

[0093] For simple registrant devices, the danger lies in the fact that the configurator and registrant eventually enter a reconfiguration loop, where the registrant simply restarts the reconfiguration process automatically without giving any external signal that it is doing so. This can result in another series of six reconfiguration message exchanges (including the DPP reconfiguration notification), causing yet another failure. This wastes resources and bandwidth.

[0094] The reconfiguration process, especially when the registrant device uses a random MAC address, can be implemented more efficiently and robustly by having the registrant send a reconfiguration request (DPP Reconfiguration Notification) that includes not only a cryptographic hash of the configurator's public signature key but also an indication of the registrant's identity. However, the inventors have realized that simply sending the registrant's identity explicitly or in simple encryption using the target device's public key is insufficient, as the registrant's encrypted identity remains unique and can be tracked, despite the use of a random MAC address. To have a solution to this problem, it is necessary to break the one-to-one mapping between the registrant's identity and the corresponding plaintext data. This can be achieved by using additional random information during encryption, such that multiple encrypted datasets correspond to the same registrant identity. The configurator will then perform decryption, extracting the registrant's identity and ignoring the random information. According to an embodiment, the improved message could therefore be:

[0095] Registrant -> Configurator: SHA256 (C-sign key), {A-nonce, E-id} E公共签名密钥

[0096] Upon receiving this, the configurator is then able to link that identity to the results of previously configured attempts stored in the database. According to an embodiment, the improved configurator can then decide whether to continue reconfiguration based on the results of the previous configuration. If the configurator decides not to continue, the process proceeds to S11, whereby it terminates, at least for the current protocol operation. By "terminating," it should be understood that the (re)configuration can be restarted later.

[0097] The registrant's identity E-id can be a random number, or a portion of the coordinates of one or more public ECC keys, such as the protocol key or the registrant's NAK, or a random point on a curve of a signature key specifically generated for this purpose. The registrant should create and maintain the E-id before sending its first DPP reconfiguration notification message until it receives a DPP configuration message containing a new configuration object, see Section 4.5, “DPP Configuration Objects,” of [DPP]. The registrant may generate the E-id earlier, such as after a reset or factory reset, and may maintain it for a longer period, such as until the next (factory) reset, as long as it remains constant from the first DPP reconfiguration notification message until successful reconfiguration.

[0098] Therefore, a method for configuring a registrant device for communication in a wireless network includes providing a configurator device, the configurator and the registrant device performing at least a portion of a configuration protocol, the registrant device encrypting registrant identification information using the configurator's public key information and random information to generate a first encrypted message, the registrant device sending the first encrypted message to the configurator device, the configurator device receiving the first encrypted message, the configurator device decrypting the first encrypted message using private key information associated with the public key, the configurator device using the registrant identification information to identify the registrant device, and determining whether the configuration should continue based on the registrant identification information.

[0099] When the configurator decides not to continue the reconfiguration protocol, it may simply not reply to the reconfiguration request message (or, in the case of DPP, a DPP reconfiguration notification). The registrant may continue sending requests until a timeout occurs and it stops. Alternatively, the configurator may also send a message to the registrant rejecting the reconfiguration request, optionally including one or more reasons.

[0100] The registrant may change its MAC address for any of these reconfiguration request messages in order to protect its privacy. The registrant should maintain its MAC address throughout the entire series of message exchanges of the running protocol, from the moment it receives the DPP reconfiguration authentication request message until, and including, all DPP configuration messages.

[0101] Encryption using the configurator's public signature key can be based on elliptic curve cryptography (see [SEC1702]). Let... s c This is the configurator's private signing key. S C = s c G For his public key, where,G It is known that the curve generator or base point is the configurator. Registrant E wants to send an encrypted message to configurator C. Registrant E knows the configurator's public signature key from a previous configuration. S C The configurator's public signature key is sent to it in the configuration object within the configuration response message. The registrant E performs the following operations:

[0102] 1. E selects random numbers r ,1≤ r ≤ n -1, and calculate rG ,in ，n yes G The order of, i.e. nG Equivalent to the so-called infinity point or identification point O Regarding it, P = O + P For all points on the curve P All established 。 The random number here r It is the value of A-nonce above.

[0103] 2. E, then calculate. M + rS C This message M Yes < G> The point in the equation represents the identity of E, E-id, as explained later.

[0104] 3. E will pair values ​​< rG , M + rS C This is sent as part of the DPP reconfiguration notification message to configurator C. It is a tuple of two elliptic points that together represent the {A-nonce, E-id} mentioned above. 公共签名密钥 .

[0105] Upon receiving the encrypted text, configurator C decrypts {A-nonce, E-id} in the following manner. 公共签名密钥

[0106] 1. C extraction rG and utilize S C = s c G calculate s c ⋅( rG )= r ⋅( s cG )= rS C ,

[0107] 2. C Extraction Pair M + rS C The second part and subtract rS C To obtain M + rS C - rS C = M

[0108] In the above scheme, the generator G will correspond to the base point of the curve used. S C = s c G This will correspond to the public key used in algorithms such as ECC encryption, and s c This corresponds to the private key, as it is the secret used for decryption. It should be noted that ECC has already incorporated randomization during encryption using a random number r. Therefore, other mechanisms for linking identification information and random information are possible, provided the receiving device has access to the identification information.

[0109] When a registrant uses their public network access key as the identifier E-id, the elliptic point M above is taken as the registrant's public network access key. Similarly, when the registrant uses another elliptic point on the same curve as their identity, such as a public bootstrap key. Note that a public network access key can only be used as the identifier E-id or another public key if the curve type of these keys is the same as the curve type of the configurator's signing key.

[0110] When the registrant does not use an elliptic point as their identity, or when the curve type of the elliptic point used for identity differs from the curve type of the configurator's signing key, the identity E-id should first be transformed into an elliptic point M. The background is that not all x values ​​1 ≤ x ≤ n-1 are x-coordinates of points on the curve. [SEC1702] lists several methods for converting plaintext blocks into elliptic points and returning them. In the case where the identity is an elliptic point on a curve different from the curve of the configurator's signing key, the x-coordinate of the identity point can be considered as the value to be converted to a point on the curve of the configurator's signing key. If the curve used to represent the registrant's identity contains more points than the curve of the configurator's signing key, the x-coordinates representing the identity points must be divided into octet strings, each of which can be represented by a point on the curve of the configurator's signing key, and each of these octet strings is encrypted as a value pair < rG , M+ rS C >, where random number r Each octet of the string is different, or the same random number is used. The first possibility is that < r 1 G , M 1 + r 1 S C >< r 2 G , M 2 + r 2 S C >…< r n G , M n + r n S C And the second possibility arises. rG , M 1 + rS C ,>< M 2 + rS C , … M n + rS C >

[0111] An elliptic point can be represented in several ways. One way is to use both its x and y coordinates for us. Another way is to use the x-coordinate value and only the sign of the y-coordinate. This is because an ECC curve always has the form y 2 =f(x), where f(x) is a third-order polynomial. If the x-coordinate of an elliptic point is known, for example, x1, then sqrt(f(x1)) is calculated and the y-coordinate of the point is known except for its sign. These techniques for representing ECC points and interpreting the octet strings representing ECC points, known as element-to-octet string conversion and octet string-to-element conversion, can be found in [802.11].

[0112] Each of the two methods described above can be used to represent the above tuple < rG , M + rS CECC points in > rG and < M + rS C >

[0113] tuple< rG , M + rS C It can be sent as a TLV (Label, Length, Value) information element used in the DPP specification, for example...

[0114]

[0115] If the registrant knows the configurator's RSA public key, the public key encryption of the E-id can be based on the RSA algorithm [RSA]. The bit string representing the E-id is combined with a second string (a random number or other random information) before encryption, for example, by concatenation. The configurator will use its private key to decrypt the received encrypted information, and it will discard the second string to extract the E-id.

[0116] Optionally, the message may also include elements. Group This is the finite cycle group attribute specified in Section 8.1.1.12 "Finite Cyclic Group Attributes" of [DPP], which uses the registry maintained by IANA as the attribute for the "Group Description" against IETF RFC 2409 [RFC 2409] and [IKE], and Group The public key type of NAK in the connector that indicates the registrant. Other ways of indicating the public key type are of course possible, such as by using a set of appropriate OBJECTIDENTIFIERs, as done in the ASN.1 example of the public key mentioned above, or by an ASN.1 structure called AlgorithmIdentifier, as specified in section 4.1.1.2 of [RFC5280].

[0117] Optionally, the improved message can include the registrant's previous connection state attribute. The advantage of this is that it allows the configurator to check it without having to identify the registrant and then look back at the previously received connection state, but the message will be longer than an E-id. Since connection state itself does not allow for easy identification of the registrant, it should not raise privacy concerns. One form of this message could be...

[0118] Registrant -> Configurator: SHA256 (C-sign key), DPP connection status

[0119] Or, optional Registrant -> Configurator: SHA256 (C-sign key), {A-nonce, DPP concatenation state} state} E公共签名密钥

[0120] Or, optional

[0121] Registrant -> Configurator: SHA256 (C-sign key), DPP connection status, group

[0122] Or, optional

[0123] Registrant -> Configurator: SHA256 (C-sign key), {A-nonce, DPP connection state, group} E公共签名密钥

[0124] Nevertheless, having both connection status and E-id in the improved message could be useful.

[0125] Figure 3a The registrant devices 5 and 4 are represented according to the embodiments. Registrants 5 and 4 include: a receiver 51, which is arranged to receive a configurator device public key from the configurator.

[0126] Security module 52 is configured to encrypt a first encrypted message using the configurator device public key, the first encrypted message including registrant identification information and random information, and transmitter 53 is configured to transmit the first encrypted message to the configurator device.

[0127] Figure 3b The configurator device 9, according to an embodiment, is configured to configure a registrant device using a configuration protocol. The configurator device 9 includes a transmitter 91 configured to send a configurator device public key to the registrant. The configurator device 9 includes: a receiver 92 configured to receive a first encrypted message from the registrant device; a security module 93 configured to decrypt the first encrypted message using the configurator device public key and derive registrant identification information based on the first encrypted message; and a processor 94 configured to determine whether to continue the configuration protocol based on the registrant identification information.

[0128] The receiver, transmitter, security module, and processor of the configurator and registrant can be implemented in hardware, software, or different combinations thereof.

[0129] When the configurator receives this message (in one embodiment, a DPP reconfiguration notification message enhanced with registrant identification information), it is then able to identify the registrant's previous connection results and detect situations where it should not continue using the reconfiguration protocol. The configurator then no longer needs to undertake a reconfiguration process with a high probability of failure, thus significantly saving resources, namely time and bandwidth.

[0130] Furthermore, this is particularly useful when the registrant is a simple device, as the process can be automated, thus avoiding the user being unaware that the connection failed and that the configurator and registrant are trapped in a potentially infinite loop, unlike when the registrant device is connected to the network. Additionally, when the reconfiguration process stops early, the user is more likely to detect that the connection has failed because they may be able to determine that the device is idle, whereas a reconfiguration loop could prevent the user from correctly identifying the status.

[0131] Optionally, the configurator device may provide the user with an indication that it has unilaterally terminated (re)configuration of the protocol, alerting the user to an issue related to the registrant. This indication may also include information about the registrant's identity, and optionally, instructions based on the aforementioned "to-do list." Once the user has resolved part of their issue, they may instruct the configurator that they can now reconfigure the registrant, causing the configurator to respond to the registrant's next DPP reconfiguration notification and reconfigure the registrant by sending it the sixth message of the new connector protocol, the DPP configuration response.

[0132] Optionally, if the registrant has a user interface capable of displaying the configuration status (e.g., LEDs flashing at different rates depending on whether the registrant is configuring, whether the connection has been successful, etc.), it can display the results of (re)configuration, including reconfiguration rejection.

[0133] Optionally, in another embodiment, the encrypted E-id may have already been generated and sent in any message of the "normal" DPP protocol sent by the registrant to the configurator, i.e., in any of the following: DPP authentication request, DPP authentication response, DPP verification confirmation, DPP configuration request, DPP configuration result, and DPP connection state result message. In particular, it is advantageous for the registrant to have already sent its encrypted E-id in the DPP connection state result message, because the DPP connection state attribute of that message also contains information about potential problems the registrant might encounter when connecting to the network it was just configured for with the DPP configuration response message. If the registrant fails to connect to the network and requires the user to do something before the registrant can be successfully configured again, and the registrant does include its encrypted E-id, the configurator can now discard the registrant's first DPP reconfiguration notification, thus saving five Wi-Fi message exchanges. The DPP connection state result now takes the form of...

[0134] Registrant → Configurator:

[0135] {E-nonce, DPP connection state}ke, {A-nonce, E-id} E公共签名密钥

[0136] Any other DPP message can be authorized in the same way. The registrant should retain its E-id from the time it sends the message containing the encrypted E-id until at least the time it receives the DPP configuration message containing the new configuration object.

[0137] Figure 4aThis section presents an example of a Media Access Control (MAC) frame. The example discussed is from the IEEE 802.11 standard. However, it should be understood that other formats are possible as long as a frame body or payload portion is present. For the purposes of this discussion, the other portions, frame header, and error checking (FCS in this case) are not important.

[0138] In the DPP configuration protocol phase of DPP, the general MAC frame format is the GAS frame format according to the IEEE 802.11 standard. In the DPP authentication protocol phase of DPP, the general MAC frame format is the common action frame format according to the IEEE 802.11 standard. Attributes can be added to various messages, including reconfiguration announcement messages.

[0139] Figure 4b The general form representing an attribute, which will form Figure 4a It is part of the frame's payload and will contain the contents of a reconfiguration notification and a reconfiguration request message according to the embodiment, namely, respectively SHA256 (C-sign) Key), E-id and TransId, Protocol versionVersion, I-Connector, I-nonce .

[0140] Since the configurator must detect this, it must be programmed accordingly to correctly parse the message. This adds complexity and prolongs the configurator's execution time. Complexity also increases on the registrant side due to the need for more sophisticated firmware and larger non-volatile memory. It should be remembered that there is significant downward pressure on the price of such devices, and even a seemingly small increase requires justification. Furthermore, many such 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 given the small battery size and the intended long battery life. Finally, changing the protocol often involves other modifications to allow for the handling of legacy devices.

[0141] Various aspects of the embodiments can be implemented in a computer program product, which may be a collection of computer program instructions executable by a computer and stored on a computer-readable storage device. The instructions can be any interpretable or executable code mechanism, including but not limited to scripts, interpreters, 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., an update) of an existing program, or an extension (e.g., a plugin) of an existing program. Furthermore, some processing of the invention may be distributed across multiple computers or processors.

[0142] 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, such as internal and external hard disks, removable disks, and CD-ROMs. Computer program products can be distributed on such storage media or made available for download via HTTP, FTP, email, or through a server connected to a network such as the Internet.

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

[0144] [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

[0145] [DH]Diffie, W.; Hellman, M. (1976), "New directions in cryptography", IEEE Transactions on Information Theory, 22 (6): 644 (~-654)

[0146] [DPP]Device Provisioning Protocol - Technical Specification - Version1.0, Wi-Fi Alliance, 2018, https: / / www.wi-fi.org / file-member / device-provisioning-protocol-specification.

[0147] [FIPS180-4]FIPS180-4, "Secure Hash Standard", United States of America, National Institute of Standards and Technology, Federal Information Processing Standard(FIPS) 180-4

[0148] [IKE]Internet Key Exchange(IKE) Attributes, Group Description(Value 4), https: / / www.iana.org / assignments / ipsec-registry / ipsec-registry.xhtml#ipsec- registry-10

[0149] [NIST 800-56A-3]NIST Special Publication 800-56A, Revision 3, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", Elaine Barker, Lily Chen, Allen Roginsky, Apostol Vassilev, Richard Davis, https: / / doi.org / 10.6028 / NIST.SP.800-56Ar3

[0150] [RFC 2409]RFC 2409, The Internet Key Exchange, November 1998, https: / / datatracker.ietf.org / doc / rfc2409 / .

[0151] [RFC 5280]RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List(CRL) Profile, https: / / datatracker.ietf.org / doc / rfc5280 /

[0152] [RFC 5639]RFC 5639, Elliptic Curve Cryptography(ECC) Brainpool Standard Curves and Curve Generation, March 2010, https: / / datatracker.ietf.org / doc / rfc5639 / .

[0153] [RFC 6090]RFC 6090, Fundamental Elliptic Curve Cryptography Algorithms, February 2011 https: / / datatracker.ietf.org / doc / rfc6090 /

[0154] [RSA]Rivest, R.; Shamir, A.; Adleman, L. (February 1978). "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems"

Claims

1. A method for configuring a registrant device for communication in a wireless network, the method being arranged for use with a registrant device, and the method comprising: The configurator device and the registrant device perform at least a portion of the configuration protocol; The registrant device generates registrant identification information and encrypts the registrant identification information using the public key information and random information of the configurator device to generate a first part of encrypted message; The registrant device transmits the first part of the encrypted message to the configurator device; The configurator device receives the first part of the encrypted message; The configurator device uses the private key information associated with the public key to decrypt the encrypted portion of the first encrypted message; The configurator device uses the registrant identification information to identify the registrant device and determines whether the configuration should continue based on the registrant identification information, wherein the registrant identification information remains unchanged between the time the first part of the encrypted message is sent and the time the registrant device next receives configuration information.

2. The method according to claim 1, wherein, If the configurator device decides that it should not continue configuring, the configurator device does not respond to the first part of the encrypted message.

3. The method according to claim 1 or 2, wherein, As a result of failing to connect to the wireless network, the registrant device transmits the first part of the encrypted message.

4. The method according to claim 1 or 2, wherein, If the configurator device decides that it should not continue the configuration, the configurator device sends a rejection message to the registrant device.

5. The method according to claim 1 or 2, wherein, The configuration protocol is based on the Wi-Fi DPP protocol, and the first part of the encrypted message is a DPP reconfiguration notification message.

6. The method according to claim 1 or 2, wherein, The identification information is used by the configurator device to identify a stored record of the registrant connection status previously sent by the registrant device during the execution of a portion of the configuration protocol.

7. The method according to claim 1 or 2, wherein, The configuration protocol includes a portion of the registrant identification information being sent by the registrant device.

8. The method according to claim 1 or 2, comprising the configurator device displaying status and / or instructions to the user if it decides not to continue.

9. A registration device arranged to be configured by a configurator device using a configuration protocol for communication in a wireless network, the registration device comprising: A receiver is configured to receive the configurator device public key from the configurator device. A security module is configured to encrypt a first portion of an encrypted message using the configurator device's public key. The encrypted portion of the first portion of the encrypted message includes registrant identification information and random information. A transmitter is configured to transmit the first portion of the encrypted message to the configurator device. The registrant device is configured to generate the registrant identification information before transmitting the first part of the encrypted message, and to keep the registrant identification information unchanged until it receives configuration information from the configurator device.

10. The registrant device according to claim 9, wherein, As a result of failing to connect to the wireless network, the registrant device sends the first part of the encrypted message.

11. A configurator device configured to configure a registrant device using a configuration protocol, the configurator device comprising: A transmitter is configured to send the configurator device public key to the registrant device; A receiver is configured to receive a first portion of an encrypted message from the registrant's device; A security module is configured to decrypt the encrypted portion of the first encrypted message using the configurator device's private key, derive registrant identification information from the first encrypted message, and, if the registrant device has been previously configured, compare the registrant identification information with previously received registrant identification information. A processor is configured to determine whether to continue the configuration protocol based on the registrant identification information.

12. The configurator device of claim 11, configured to display status and / or instructions to a user if it is decided not to continue the protocol.

13. A computer program product on a machine-readable medium, the computer program product being configured to implement the configurator portion of the method according to any one of claims 1-8 when run on a configurator processor.

14. A computer program product on a machine-readable medium, the computer program product being configured to implement the registrant portion of the method according to any one of claims 1-8 when run on a registrant processor.

Images