Random mac configuration

Abstract

A method of configuring an enrollee device for communication in a wireless network is provided. The method comprises, at the enrollee side, providing a configurator device, running a configuration protocol, and sending, by the enrollee device, a notification message in case the enrollee device has failed to connect to the network after a previous run of a part of the configuration protocol during the running of the configuration protocol, the notification message comprising an indication of a public key type previously used by the enrollee as part of the protocol. Enrollee and configurator devices arranged to perform the method are also provided.

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 (e.g., device 4, represented here as a computer) and a simple device (e.g., device 5, represented here as a toothbrush). Devices like the simple device (e.g., device 5) typically lack any real user interface (UI) except perhaps a light, and are therefore often referred to as "headless" devices. AP2 has a processor 6, and the simple device (e.g., 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 (e.g., 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. There are several 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 that node 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 that includes 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 having moved to a channel not supported by the registrant, the registrant and / or the node having physically moved out of range, or an object blocking the signal having been 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 complex devices (e.g., device 5), 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 complex devices, the UI may display instructions to the user on how to resolve connection problems.

[0010] However, for simple (headless) devices, the only way for a user 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 after configuration when trying to connect to the network they are configured to connect to, 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, a method for configuring a communication registrant device in a wireless network is needed, including running a configuration protocol. Specifically, as part of configuring a communication registrant device in a wireless network, the method is arranged to be used with a configurator device. The method includes: running a configuration protocol, and during the running of the configuration protocol, if the registrant device fails to connect to the network after attempting to do so previously in part of the configuration protocol, the registrant device sends a notification message to the configurator device, the notification message including an indication of the type of public key previously used by the registrant as part of the protocol.

[0012] There is no forced configurator signing key that is identical to the NAK curve in a connector signed with this configurator signing key.

[0013] One approach to addressing this issue would be for the configurator to store a combination of MAC addresses and NAK curve types for all registrants it has configured. This would allow the configurator to still select the correct curve for the key it will use in the I-Connector in the DPP reconfiguration authentication request message, and to select the correct I-Nonce length, which depends on the curve type. This is undesirable in itself, as it adds more complexity to the configurator and the operations it must perform. More importantly, 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 multiple times (see [802.11]) to find out which APs are within their Wi-Fi range. If the same MAC address is always used, the device's location can be tracked, which could 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 addresses.

[0014] The consequence of the device using a random MAC address for DPP reconfiguration is that the configurator can no longer determine the curve the registrant used for their NAK during their initial configuration. The configurator could try the curve of the signing key it used, but the registrant's NAK might already be on a different curve, causing the process to fail. A straightforward approach that doesn't require tweaking the existing protocol is to have the configurator try several curves, but this means running the DPP reconfiguration protocol multiple times, significantly increasing time and Wi-Fi bandwidth consumption. This also increases the risk of failure for some reason.

[0015] 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) with not only a cryptographic hash of the registrant's public signature key but also an indication of the type of public key it stores in its connector. In one respect, the registrant device is a simple device.

[0016] In one aspect, the method includes a registrant device receiving a response message from a configurator device in response to a notification message, the response message including a public key of a type indicated by an indication of a public key type, calculating a new key based on the received key, and sending further messages using the new key.

[0017] Furthermore, this is particularly useful when the registrant is a simple device, as the process can be automated, thus avoiding the need for users to conduct time-consuming investigations to find out why the registrant's device is not connected to the network.

[0018] According to one aspect, the notification message also includes a hash of the public key previously used by the configurator.

[0019] According to one aspect, the indication includes finite cyclic group properties.

[0020] A registrant device is also provided, which is configured by a configurator device to communicate in a wireless network. The registrant device is configured to participate in a configuration protocol and, in the event of a failed attempt to connect to the network after previously running a portion of the configuration protocol, send a notification message to the configurator, the notification message including an indication of the public key type previously used by the registrant as part of the protocol.

[0021] According to one aspect, the registrant device is configured to receive a response message from the configurator device in response to a notification message, the response message including a public key of a type indicated by an indication of the public key type and calculating a new key based on the received key and using the new key to send further messages.

[0022] According to one aspect, the registrant device is a simple device.

[0023] According to one aspect, the registrant device is also configured to include a hash of the public key previously used by the registrant in the notification message.

[0024] According to one aspect, the registrant device is configured to include a finite cyclic group attribute in the indication.

[0025] A configurator device is also provided, which is configured to configure a registrant device for communication in a wireless network. The configurator device is configured to participate in a configuration protocol, receive a notification message from the registrant device, the message including an indication of the type of public key previously used by the registrant as part of the configuration protocol, retrieve the indication, and send a configuration message to the registrant device including a key of the same type as the indication.

[0026] A system is also provided, comprising a registrant device according to one aspect and an configurator device according to one aspect.

[0027] A computer program product is also provided, which, when operated on a processor in a registrant device, causes the registrant device to execute the method. Attached Figure Description

[0028] 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:

[0029] Figure 1 This indicates a wireless network, and we expect to configure devices to be added to it.

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

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

[0032] Figure 3b 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 a simple device (e.g., 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 a peer-to-peer situation.

[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 a disconnected 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 such communication include a user instructing a device to read the responder’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 proceeds to 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, a simple device (e.g., device 5)) may record the result of the bootstrapping process in a suitable 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 (e.g., device 5) acts as the registerer. It should be noted that the third device 9 is shown as 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 a Diffie-Hellman manner based on each other's network access keys in the connector and their own private network access keys.

[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 complex devices (e.g., 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, simple devices (e.g., device 5) do not have a UI. If it fails to connect, it will give up trying after its programmed timeout period unless it has further programming as outlined in this document.

[0048] This protocol may be required, and indeed DPP does require, for the registrant to return a status message to the configurator. In the case of DPP, the message format is:

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

[0050] The DPP state and E-Nonce are encrypted using the encryption key ke calculated during initial authentication. The values ​​for the DPP state are shown in the table below.

[0051]

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

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

[0054] In an alternative, the process can proceed to S10, where the registrant requests the configurator to reconfigure (or for a new configuration).

[0055] In another 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] Although configuration usually succeeds and the registrant will be able to connect to the network that 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 possible that the NAK in the registrant's connector has expired and is no longer accepted by the AP. 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. In all cases of connectivity problems, the process can be passed to S10, where the registrant requests reconfiguration from the configurator.

[0057] At S11, the configurator replies with a response message containing the updated (or new) configuration, and the registrant retryes the connection to the network. On the DPP side, at this S11, the DPP configuration protocol and the DPP introduction protocol may be running. If this connection succeeds, the process terminates at S9.

[0058] In the case of DPP, the reconfiguration request in S10 is a DPP reconfiguration notification, which takes the following form:

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

[0060] As can be seen, this is a simple message, including 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:

[0061] Configurator -> Registrant: TransId, Protocol versionVersion, I-Connector, I-nonce.

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

[0063] The registrant and the AP's DPP connectors may or may not match. When they match, both devices can calculate the Pairwise Master Key (PMK) 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.

[0064] 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], both parties should 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.

[0065] 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.

[0066] 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].

[0067] 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:

[0068] SEQUENCE{

[0069] SEQUENCE{

[0070] OBJECTIDENTIFIER 1.2.840.10045.2.1(ecPublicKey)

[0071] OBJECTIDENTIFIER 1.2.840.10045.3.1.7(P-256)

[0072] }

[0073] BITSTRING

[0074] 0x0343A6A094A9BC6C9B92CBA3164849F0DB0B91350270ABE80DC554B1E6B3897F30:0unused bit(s)

[0075] }

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

[0077] 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.

[0078] 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 .

[0079] Now, the registrant receiving the DPP reconfiguration authentication request message from its configurator uses the NAK in its own connector (the R-Connector it received from its configuration during the previous DPP configuration), and the I-Nonce and C from the I-Connector it received in the DPP reconfiguration authentication request. IThe key ke is calculated as specified in Section 6.5.4, “DPP Reconfiguration of Authentication Responses,” of [DPP]. As previously mentioned, this calculation can only be performed when both NAKs use the same type of public key; therefore, in the case of DPP, both ECC points lie on the same curve.

[0080] When the DPP configurator receives a DPP reconfiguration notification, it only knows the Wi-Fi MAC address of the registrant who sent it. The DPP configurator is able to find the configurator signing key for the SHA-256 hash sent by the registrant by comparing the SHA-256 hashes of all previously used public signing keys with the received hash. This also allows the DPP configurator to know the curve used to sign the DPP connector sent to the registrant when initially configuring this registrant.

[0081] However, the inventors have realized that the curve of the configurator signing key and the NAK curve in the connector signed with that configurator signing key do not necessarily have to be the same.

[0082] One approach to this problem is for the configurator to store a combination of MAC addresses and NAK curve types for all registrants it has configured. This allows the configurator to still select the correct curve for the key it will use in the I-Connector in the DPP reconfiguration authentication request message, and, in the case of I-Nonce, the correct length, which depends on the curve type. This is undesirable in itself because it adds more complexity to the configurator and the operations it must perform.

[0083] However, the inventors have also 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 could 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.

[0084] The consequence of the device using a random MAC address for DPP reconfiguration is that the configurator can no longer determine the curve the registrant used for their NAK during their initial configuration. The configurator could try the curve of the signing key it used, but the registrant's NAK might already be on a different curve, causing the process to fail. A straightforward approach that doesn't require tweaking the existing protocol would be to have the configurator try several curves, but this would mean running the DPP reconfiguration protocol multiple times, significantly increasing time and Wi-Fi bandwidth consumption. This also increases the risk of failure for some reason.

[0085] The reconfiguration process, especially when the registrant's device uses a random MAC address, can be implemented more efficiently and robustly by having the registrant send a reconfiguration request (DPP reconfiguration notification) containing not only a cryptographic hash of the configurator's public signature key but also an indication of the type of public key it stores in its connector. Therefore, the improved message might be:

[0086] Registrant -> Configurator: SHA256 (C-sign key), Group

[0087] Here, the group is a finite cyclic group attribute as specified in Section 8.1.1.12 “Finite Cyclic Group Attributes” of [DPP], using a registry maintained by IANA as an attribute for the “Group Description” of IETF RFC 2409 [RFC 2409] and [IKE], and the group indicates the public key type of NAK in the registrant’s connector. Other ways of indicating the public key type are of course possible, for example, 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].

[0088] Therefore, a method for configuring a registrant device for communication in a wireless network may include: providing a registrant device, running a configuration protocol, and during the operation of the configuration protocol, the registrant device sending a notification message, the notification message including, as part of the protocol, an indication of the public key type previously used by the registrant in the event that the registrant device has failed to connect to the network after previously running a portion of the configuration protocol.

[0089] In practice, the registrant device can be configured by the configurator device to communicate in a wireless network, and if an attempt to connect to the network fails after previously running a configuration protocol, it sends a notification message to the configurator, the notification message including an indication of the public key type previously used by the registrant as part of the protocol.

[0090] When the configurator receives this message (a DPP reconfiguration notification message, which, according to an embodiment, is enhanced with a public key type indication in the case of DPP), the configurator is then able to know and therefore select the correct type of key to include in the connector it will send back (a DPP reconfiguration authentication request in the case of DPP). Thus, the configurator device can be configured to configure the registrant device for communication in a wireless network. The configurator device can receive a notification message from the registrant device that includes an indication of the public key type previously used by the registrant as part of the configuration protocol. The configurator device can retrieve this indication and send a configuration message including a key of the same type as indicated.

[0091] The configurator no longer needs to begin the process of searching its records, or worse, by trial and error, to find the correct type of key to use. Identifying and selecting the correct type of key can be achieved without significantly increasing resource usage (i.e., time and bandwidth).

[0092] Furthermore, this is particularly useful when the registrant is a simple device, as the process can be automated, thus avoiding the need for users to conduct time-consuming investigations to find out why the registrant's device is not connected to the network.

[0093] Figure 3a This 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.

[0094] 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 notification messages.

[0095] Figure 3b The general form representing an attribute, which will form Figure 3a 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 SHA256 (C-signkey), group and TransId, Protocol versionVersion, I-Connector, and I-nonce, respectively.

[0096] 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.

[0097] 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.

[0098] 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.

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

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

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

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

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

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

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

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

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

[0108] [RFC 5639]RFC 5639,Elliptic Curve Cryptography(ECC)Brainpool StandardCurves and CurveGeneration,March 2010, https: / / datatracker.ietf.org / doc / rfc5639 / .

[0109] [RFC 6090]RFC 6090,Fundamental Elliptic Curve CryptographyAlgorithms,February 2011 https: / / datatracker.ietf.org / doc / rfc6090 /

Claims

1. A method for configuring a registrant device for communication in a wireless network, the method being configured for use with a registrant device, the method comprising: Run the configuration protocol, and During the operation of the configuration protocol, if the registrant device fails to connect to the wireless network after previously running a portion of the configuration protocol, the registrant device sends a notification message to the configurator device, the notification message including an indication of the public key type previously used by the registrant device as part of the configuration protocol.

2. The method according to claim 1, comprising: The registrant device receives a response message from the configurator device in response to sending the notification message, the response message including a public key of the type indicated by the indication of the public key type; and calculates a new key based on the received public key and uses the new key to send further messages.

3. The method according to any of the preceding claims, wherein, The registrant device is a simple device.

4. The method according to claim 1, wherein, The notification message also includes a hash of the public key previously used by the configurator device.

5. The method according to claim 1, wherein, The indication includes finite cyclic group properties.

6. A registration device arranged to be configured by a configurator device for communication in a wireless network, the registration device comprising: One or more processors; as well as One or more memories storing computer program instructions that, when executed by the one or more processors, are configured to: Participate in the configuration protocol, and If an attempt to connect to the wireless network has failed after previously running the configuration protocol described in part, a notification message is sent to the configurator device, the notification message including an indication of the type of public key previously used by the registrant device as part of the configuration protocol.

7. The registrant device according to claim 6, wherein, When executed by the one or more processors, the computer program instructions are configured to: receive a response message from the configurator device in response to sending the notification message, the response message including a public key of the type indicated by the indication of the public key type; and calculate a new key based on the received public key and use the new key to send further messages.

8. The registrant device according to any one of claims 6 or 7, wherein, The registrant device is a simple device.

9. The registrant device of claim 6, wherein when run by the one or more processors, the computer program instructions are further configured to include a hash of a public key previously used by the registrant device in the notification message.

10. The registrant device of claim 6, wherein when run by the one or more processors, the computer program instructions are configured to include a finite cyclic group attribute in the instructions.

11. A configurator device arranged to configure a registrant device for communication in a wireless network, the configurator device comprising: One or more processors; as well as One or more memories storing computer program instructions that, when executed by the one or more processors, perform the following operations: Participate in the configuration protocol; A notification message is received from the registrant device, the notification message including an indication of the public key type previously used by the registrant device as part of the configuration protocol. Retrieve the instruction, and Send a configuration message to the registrant device, including a public key of the same type as the indication.

12. A wireless communication system comprising a registrant device according to any one of claims 6-9 and an configurator device according to claim 11.

13. A computer program product comprising computer program instructions that, when executed on a processor in a registrant device, cause the registrant device to perform the method according to any one of claims 1-5.

Images