Random MAC Settings

Abstract

A method of configuring an enrollee device for communication in a wireless network is provided, the method including, at the enrollee side, providing a configurator device, executing a configuration protocol, and, if an attempt by the enrollee device to connect to the network fails following a previous execution of a portion of the configuration protocol, sending by the enrollee device, during execution of the configuration protocol, an announce message including an indication of the type of public key previously used by the enrollee as part of the protocol. Also provided are enrollee and configurator devices configured to perform the method.

Description

[Technical Field]

[0001] The present invention relates to an apparatus and method for use in wireless networks, particularly wireless networks conforming to the IEEE 802.11 family of standards. [Background technology]

[0002] FIG. 1 illustrates a wireless network 1 including a first device 2 and another device 3. The first device 2 has a central function and may be something like an access point (AP), hub, or gateway device. The first device 2 is referred to below as an AP for simplicity, although other types of devices are indeed possible. A user (not shown) wishes to add two more 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 often have no actual user interface (UI) other than perhaps a light and are therefore often referred to as "headless" devices. The AP 2 has a processor 6, while the simple device 5 has a microcontroller, a small non-volatile memory 7, and a button 8 that can be used to reset the simple device 5. A third device 9 is also present.

[0003] Some wireless network standards allow one device to configure another device to establish a connection and communicate. This eases the task of adding or registering a new device to the network in that the user no longer needs to provide manual input. A device that requires configuration to join the network is sometimes called an "enrollee," and the device that performs the configuration is sometimes called a "configurator."

[0004] It may happen that, despite the apparently successful completion of the configuration process, the configured device still cannot connect to network 1. There are several possible causes for this situation: some of them are: - The enrollee connects to a node using the network ID configured in the enrollee and sends that information and associated keys to this node in a message requesting to join, but receives a response indicating that the request is invalid or does not match the expected values. In the case of the IEEE 802.11 Device Provisioning Protocol (DPP) (also known as "Wi-Fi Easy Connect™"), the node may be an AP, and the request message is to this AP in a DPP Peer Discovery Request message containing a DPP Connector. The response is a DPP Peer Discovery Response message with a DPP status of "status_INVALID_CONNECTOR" or "status_NO_MATCH". The reasons for these error codes are described in Section 6.6.1 of [DPP]. One reason for the DPP status "Status_INVALID_CONNECTOR" is that the Enrollee NAK has expired and is no longer accepted by the AP. - The enrollee was able to connect to a node in the network using the ID configured in the enrollee, but the passphrase or PSK (Pre Shared Key) configured in the enrollee proved incorrect when the enrollee attempted to associate with the node. - The enrollee scanned the list of channels (including the list) and did not find a node with the configured ID. This could be the result of, for example, the node moving to a channel that the enrollee does not support, the enrollee and / or node physically moving out of range, or a signal-blocking object being placed between the enrollee and the node.

[0005] 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 in question. A connector may contain information such as a network access key (NAK) that is used to establish a shared secret or encryption key for use between the receiving device and other devices in the network.

[0006] A device with a user interface, such as complex device 5, can indicate the status of the connection with the AP (or equivalent node in the network) after configuration and when a problem occurs, such as when the device cannot find the AP (or other device to which a connection is desired). Also, in the case of complex devices, the UI can display instructions for the user on how to resolve the connection problem. Summary of the Invention [Problem to be solved by the invention]

[0007] However, on simple (headless) devices, the only way a user can observe a successful connection is by verifying that the connection is working or by inspecting the UI of the Access Point (AP), hub, or gateway. After configuration, these devices face problems when attempting to connect to the network they are configured to connect to, and the user has no idea or realizes what went wrong until some time later when they discover that there is no connection or try to check the AP's UI. [Means for solving the problem]

[0008] Therefore, there is a need to provide a method for configuring an enrollee device for communication in a wireless network that includes executing a configuration protocol, particularly a method configured for use with a configurator device as part of configuring an enrollee device for communication in a wireless network, the method comprising: executing a configuration protocol; and sending, during execution of the configuration protocol, by the enrollee device to the configurator device an announcement message that includes an indication of a type of public key previously used by the enrollee device as part of the protocol if an attempt by the enrollee device to connect to the network fails after a previous execution of a portion of the configuration protocol.

[0009] There is nothing that forces the configurator signing key and the NAK curve to be the same for connectors signed with this configurator signing key.

[0010] A first approach to address this issue is for the configurator to store the combination of MAC address and curve type for all enrollee NAKs configured by the configurator so that the configurator can select a right curve for the key in the I-Connector to use in the DPP Reconfig Authentication Request message and select a right length for the I-Nonce depending on the curve type. This is undesirable in itself because it imposes additional complexity on 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 repeatedly send so-called probe requests (see [802.11]) to find out which APs are within their Wi-Fi range. If they always use the same MAC address, the device's location could be tracked, which is considered undesirable and could violate privacy. To preserve its privacy, a device can use a random MAC address for each complete protocol exchange, so that its location can no longer be tracked using its MAC address.

[0011] A consequence of the device's use of a random MAC address for DPP reconfiguration is that the configurator now has no way to determine the curve the enrollee used for its NAK when initially configured. The configurator could try the curve of the signing key used, but the process would fail because the enrollee's NAK might be on a different curve. A simple approach that does not require modification of existing protocols would be for the configurator to try several curves, but that would mean running the DPP reconfiguration protocol several times, significantly increasing time and Wi-Fi bandwidth consumption. It also increases the risk that this will fail for some reason.

[0012] The reconfiguration process, particularly in situations where the enrollee device uses random MAC addresses, can be rendered more efficient and robust by having the enrollee send a request for reconfiguration (DPP Reconfig Announcement) with a cryptographic hash of the configurator public signing key as well as an indication of the type of public key held by the configurator. According to one aspect, the enrollee device is a simple device.

[0013] In one aspect, the method comprises the enrollee device receiving, from the configurator device in response to the announce message, a response message having a public key of a type indicated by the public key type indicator, calculating a new key based on the received key, and sending further messages using the new key.

[0014] Furthermore, this is particularly useful where the enrollee is a simple device in that the process can proceed automatically, i.e., avoiding the user being forced to engage in time-consuming investigation to understand why the enrollee device is not connecting to the network.

[0015] According to one aspect, the announce message further includes a hash of a public key previously used by the configurator.

[0016] According to one aspect, the index comprises a finite cyclic group attribute.

[0017] Also provided is an enrollee device configured to be configured by a configurator device for communication in a wireless network, the enrollee device configured to participate in a configuration protocol and configured to send an announce message to the configurator if an attempt to connect to the network fails following a previous execution of a portion of the configuration protocol, the announce message including an indication of the type of public key previously used by the enrollee as part of the protocol.

[0018] According to one aspect, the enrollee device is configured to receive, in response to the announce message, a response message from the configurator device including a public key of a type indicated by the public key type indicator, calculate a new key based on the received key, and send further messages using the new key.

[0019] According to one aspect, the enrollee device is a simple device.

[0020] According to one aspect, the enrollee device is further configured to include in the announcement message a hash of a public key previously used by the configurator.

[0021] According to one aspect, the enrollee device is configured to include a finite cyclic group attribute in the index.

[0022] A configurator device configured to configure an enrollee device for communication in a wireless network is also provided, the configurator device being configured to participate in a configuration protocol, receive from the enrollee device an announcement message having an indication of a type of public key previously used by the enrollee as part of the configuration protocol, retrieve the indication, and transmit to the enrollee device a configuration message having a key of the same type as the indication.

[0023] A system is also provided that includes an enrollee device according to an aspect and a configurator device according to an aspect.

[0024] Also provided is a computer program which, when running on a processor within an enrollee device, causes the enrollee device to carry out the method.

[0025] 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, taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0026] [Figure 1] 1 is a diagram illustrating a wireless network to which a device may be configured for addition. [Figure 2] FIG. 4 is a diagram showing the flow of a setting process according to the embodiment. [Figure 3a] 2 illustrates an exemplary 802.11 MAC frame according to one embodiment. [Figure 3b] 10 is a diagram illustrating attributes according to an embodiment for an 802.11 MAC frame. DETAILED DESCRIPTION OF THE INVENTION

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

[0028] 2 illustrates a flow diagram of a device-controlled configuration method according to an embodiment in which one device, such as the third device 9 of FIG. 1, may configure and connect to another device, such as the complex or simple devices 4 and 5 of FIG. 1. The third device 9 and the devices 4 and 5 are according to an embodiment. The case of the simple device 5 will be described as an example. While much of this description provides examples involving a network with a device such as AP 2, it should be understood that this process may also work in a peer-to-peer context.

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

[0030] At S1, the process begins with two devices 9 and 5 disconnected and device 5 unconfigured. For the purposes of discussion, device 9 is used to configure device 5 to join wireless network 1, and thus device 9 may be referred to as the Configurator, and device 5 may be referred to as the Enrollee (because it has been "registered" with wireless network 1).

[0031] In S2, often called "bootstrap," one device, the responder, obtains the bootstrap public key (BR) of the other device, the initiator. If the responder device desires mutual authentication, it also obtains the initiator's bootstrap public key (BI). This can be achieved through a method other than wireless communication, known as "out-of-band" communication (OOB). For example, a user can have one device scan a QR code on the responder, NFC communication between the two devices, or another wireless technology such as Bluetooth. The bootstrap process is initiated by user intervention. If bootstrapping is successful, the process reaches S3, and the device 10, 5 is "bootstrapped." Otherwise, it returns to the "start" state in S1. In either case, the registering device (in this case, the simple device 5) can record the results of the bootstrap process in an appropriate storage device, for example, as a flag in a register in memory. Often, a simple device will boot up after manufacture or reset, be programmed to turn on its radio on the channel indicated in the QR code for configuration, and begin listening for authentication request messages.

[0032] In S4, devices 9 and 5 perform an authentication procedure, thereby establishing "trust" with the device. That is, the user can be confident that the device is who they believe it is and not some other unknown (and potentially malicious) device "pretending" to be one or more of the devices in question. A message requesting authentication to begin is sent from one device. This message can be sent by either the device performing the configuration (configurator) or the device being configured (enrollee). In this example, a third device 9 acts as the configurator, and a simple device 5 acts as the enrollee. Note that while the third device 9 is shown connected to network 1, this is not necessary for the embodiment to function. A device that initiates wireless communication is called an initiator, and a device that responds is called a responder. In particular, the DPP protocol allows both configurator and enrollee devices to act as initiators in the DPP protocol, thereby automatically making other devices responders. Simple or headless devices typically assume the role of responder.

[0033] The other device responds to this message. If the authentication request message is decoded correctly and contains information indicating that the initiator is a device the responder device trusts and has the required capabilities, the response message indicates that the message is "accepted" and indicates that the initiator contains the information necessary to verify the responder's credentials and also has the required capabilities. If the two devices do not receive the required information from the other device, the process aborts and the device returns to its bootstrapped state at S3. If the initiator is an enrollee, the authentication request message may also include an additional portion indicating the result of a previous attempt to set up the enrollee. If the responder is an enrollee, the authentication response message may include an additional portion indicating the result of a previous attempt. It should be understood that the indication also indicates whether there was a previous attempt.

[0034] In the DPP protocol, the first message is an Authentication Request message, and the response message is a DPP Authentication Response. The responder checks whether the DPP Authentication Request message contains a correctly generated cryptographic hash of the responder's public bootstrap key and a copy of the initiator's public bootstrap key. The responder sends a DPP Authentication Response message indicating whether authentication can proceed. If not, the process is aborted, for example, because an attempt to decrypt the encrypted nonce in the DPP Authentication Request message failed. The DPP Authentication Response contains a cryptographic hash of the responder's public bootstrap key and may contain a hash of the initiator's public bootstrap key. Similarly, for the initiator, the enrollee may have obtained this public key through 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 enrollee, but not vice versa.

[0035] If the Authentication Response message indicates that the responder accepted the Authentication Request message, and the response meets the criteria imposed by the initiator's setup, the initiator issues an Authentication Confirmation message. If the authentication values in the Authentication Response and Confirmation message are found to be correct by the associated devices, this part of the protocol, the authentication part, is successful and the process reaches S6, where configuration can begin. The Confirmation message may also contain an indication of the results of a previous configuration attempt in which the enrollee was also the initiator. In the case of the DPP protocol, the authentication confirmation message is a DPP Authentication Confirm message.

[0036] At S7, the enrollee device sends a configuration request message containing information about the type of configuration the enrollee requires. If the configurator can grant the request, it sends a message containing the information the enrollee requires, such as a network key. The process then ends at S8, with successful enrollee configuration. According to one embodiment, the configuration request may include an indication of the results of previous configuration attempts.

[0037] For DPP, the request message is a DPP Configuration Request, and the configurator response is a DPP Configuration Response message. The DPP Configuration Response may contain the Service Set Identifier (SSID) of the network to which the enrollee will connect and may contain a DPP Connector. The DPP Connector is digitally signed by the configurator using a key (C-sign key) and contains, among other things, the enrollee's public network access key. The DPP Configuration Response message also contains the configuration's public signing key. Other devices configured by the same configurator can thereby verify whether they can trust the other device's public network access key. The DPP Configuration Response message may also contain the network's Wi-Fi passphrase or pre-shared key (PSK). The enrollee sends a DPP Configuration Result message (depending on the DPP version) to the configurator to inform it whether it will accept the configuration. Failure of the configurator to receive this message can indicate to the configurator that there was a Wi-Fi problem between the configurator and the enrollee. The "supposedly configured" enrollee can then send its to the DPP Configuration AP 2. If the connector signature is found to be correct and AP 2 has a matching connector (a connector on the same network, signed by the same configurator), AP 2 sends its connector to the enrollee. The enrollee and AP 2 can then calculate a symmetric key based on each other's network access keys in the connector and their own private network access keys using the Diffie-Hellman method.

[0038] At S8, Enrollee 4 or 5 attempts to connect to the network. In the case of Wi-Fi, the enrollee has received the Wi-Fi password or Wi-Fi Pre-Shared key (PSK), which causes the enrollee to attempt to associate with AP 2 in the normal manner through a four-way handshake as specified in [802.11]. If the connection attempt is successful, the flow proceeds to and completes at S9.

[0039] On the other hand, if the enrollee fails to connect, a different outcome may occur.

[0040] In the case of a complex device 4, the enrollee may display a message to the user to make them aware of the condition and instruct them on how to resolve the issue. However, a simple device 5 does not have a UI. If it is not successful in connecting, it will give up trying after a timeout period for which it is programmed, unless it has further programming as outlined herein.

[0041] The protocol can require the enrollee to return a status message to the configurator, which is what the DPP does. In the case of the DPP, the message is of the form Enrollee → Configurator: {DPP Status, E-nonce}ke The DPP status and E-Nonce are encrypted using the encryption key ke calculated during initial authentication. The values of DPP status are shown in the table below. [Table 1]

[0042] If the status message indicates that the enrollee has successfully connected to the network that was just configured, flow proceeds to S9.

[0043] If the status message indicates that the enrollee was not successful, you have a choice.

[0044] In one option, flow proceeds to S10 where the enrollee issues a request to be reconfigured (or for a new configuration) to the configurator.

[0045] In another alternative solution, the flow can return directly to S7, where the enrollee device sends a Configuration Request message with information about what type of configuration the enrollee desires. In such a case, a DPP Reconfiguration Announce message is not required. It is useful to note that both devices use keys established during the previous authentication phase. Also, because this forms part of a single protocol execution, there is no change in MAC address, which would pose a problem.

[0046] In most cases, the configuration is successful and the enrollee is able to connect to the network that was just configured, but connectivity issues can occur even years later. The AP or enrollee may have been moved to a different location at some moment and is now out of Wi-Fi (RF?) range. The Enrollee Connector's NAK may have expired and is no longer accepted by the AP. The old AP may have been replaced with a new AP and the enrollee may have been overlooked in reconfiguring the new network. In all connectivity cases, the flow continues to S10, where the enrollee issues a request to the Configurator to be reconfigured.

[0047] In S11, the configurator responds with a response message containing the updated (or new) settings, and the enrollee retries connecting to the network. For DPP, in this S11, there may be execution of the DPP configuration protocol and the DPP installation protocol. If this connection is successful, the flow ends at S9.

[0048] In the case of a DPP, the reconfiguration request in S10 is a DPP reconfiguration announcement of the following form: Enrollee -> Configurator: SHA256(C-sign key)

[0049] As can be seen, this is a simple message consisting of the SHA-256 hash (see [FIPS180-4]) of the configurator's public signing key. A configurator receiving this message can calculate the SHA-256 hash of all previously used public signing keys to see if it has previously configured the enrollee, which sent it a DPP Reconfiguration Announce message. If the configurator has previously configured the enrollee, it assumes the role of initiator in the reconfiguration and proceeds to send a DPP Reconfiguration Authentication Request message back to the enrollee. The format of the DPP Reconfiguration Authentication Request is as follows: Configurator -> Enrollee: TransId, Protocol versionVersion, I-Connector, I-nonce.

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

[0051] The DPP Connectors of the enrollee and AP may or may not match. If they match, both devices can calculate the Pairwise Master Key (PMK) required by the enrollee 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. "The same type of public key" means the same type of encryption, and certain parameters related to the encryption are the same.

[0052] For example, the implementation of the protocol in [DH] uses a multiplicative set of integers where q is prime (referred to in [DH] as a "finite field GF(q)" with prime q elements), and α is a primitive root modulo q (referred to in [DH] as a "fixed primitive element of GF(q)"). Both parties should agree on q and α when using an implementation of Diffie-Hellman as described in [DH]. All public keys generated with the same values of q and α are considered to be the same type of public key for the purposes of this specification.

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

[0054] It is instructive to note that DPP specifies the use of P-256, P-384, P-521, Brainpool P-256r1, Brainpool P-384r1, and Brainpool P-512r1 curves for the DPP version of Diffie-Hellman in the DPP authentication protocol. The Brainpool curves are specified in [RFC 5639].

[0055] It should be understood that actual public keys, e.g., certain P-256 keys, when they are transmitted in messages, typically include the public key type within the structure that contains them. An example of an elliptic curve public key, represented as an ASN.1 structure called SubjectPublicKeyInfo, as specified in Section 4.1 of [RFC 5280], is as follows in ASN.1 notation: SEQUENCE { SEQUENCE { OBJECTIDENTIFIER 1.2.840.10045.2.1 (ecPublicKey) OBJECTIDENTIFIER 1.2.840.10045.3.1.7 (P-256) } BITSTRING 0x0343A6A094A9BC6C9B92CBA3164849F0DB0B91350270ABE80DC554B1E6B3897F30 : 0 unused bit(s) }

[0056] Both OBJECTIDENTIFIERs define a public key type, while the BITSTRING contains the value of this particular public key.

[0057] In DPP, elliptic curve cryptography [RFC 6090] is used for all asymmetric cryptography, particularly for the Network Access Key (NAK) and configurator signing keys, although other forms of asymmetric cryptography are possible, such as the multiplicative group of the integers modulo q as described in [DH].

[0058] The I-Connector sent in a DPP Reconfiguration Authentication Request does not serve its usual purpose for configuring the enrollee. Instead, by providing the enrollee with a Configurator NAK signed by the Configurator, a public key provided by the Configurator, the enrollee can check the signature and in this way trust that the Configurator NAK is indeed from that Configurator. In this case, the Configurator NAK is used as one of several components by which the enrollee and Configurator create a shared key for the encrypted portions of the DPP Reconfiguration Authentication Protocol and the subsequent DPP Configuration Protocol. In this case, the Configurator NAK is also referred to as a CI in the DPP standard [DPP].

[0059] Here, the enrollee receiving the DPP Reconfiguration Authentication Request message from the Configurator performs key calculations using the NAK from its own Connector (the R-Connector received from the Configuration during the previous DPP configuration) and the I-Nonce and CI from the I-Connector received in the DPP Reconfiguration Authentication Request, as specified in Section 6.5.4 "DPP Reconfig Authentication response" of [DPP]. As mentioned above, this calculation can only be performed if both NAKs use the same type of public key, and therefore, in the case of DPP, both ECC points lie on the same curve.

[0060] When the DPP Configurator receives a DPP Reconfiguration Announcement, the enrollee only knows the Wi-Fi MAC address that the enrollee sent. The DPP Configurator can find the Configurator signing key from which the enrollee sent its SHA-256 hash by comparing the SHA-256 hashes of all previously used public signing keys and comparing these hashes with the received hash. This also allows the DPP Configurator to know the curve that was used to sign the DPP Connector sent to this enrollee when it was first configured.

[0061] However, the inventors have recognized that the curve for the configurator signing key and the curve for the NAK in a connector signed with this configurator signing key do not have to be the same.

[0062] A first approach to this problem is for the configurator to store the NAK curve type and MAC address combinations of all enrollees it has configured so that it can select the correct curve for the key in the I-Connector to use in the DPP Reconfiguration Authentication Request message, and in the case of the I-Nonce, the correct length, which depends on the curve type. This is undesirable in itself, as it imposes more complexity on the configurator and the operations it must perform.

[0063] However, the inventors have also recognized that a more serious problem arises. The current trend is for devices to increasingly use random (Wi-Fi) MAC addresses to protect privacy. A Wi-Fi device repeatedly sends so-called probe requests (see [802.11]) to find out which APs are within its Wi-Fi range. If it always uses the same MAC address, the device's location could be tracked, which is considered undesirable and could violate privacy. To preserve its privacy, a device can use a random MAC address for each complete protocol exchange, and thus its location can no longer be tracked using its MAC address.

[0064] The consequence of the configurator's use of random MAC addresses for DPP reconfiguration is that the configurator now has no way to determine the curve the enrollee used for its NAK when it was initially configured. The configurator could try the curve of the signing key used, but the process would fail because the enrollee's NAK could be on a different curve. A simple approach that does not require adapting existing protocols would be for the configurator to try several curves, but this would mean running the DPP reconfiguration protocol multiple times, significantly increasing time and Wi-Fi bandwidth consumption. It also increases the risk of failure for several reasons.

[0065] The reconfiguration process, especially in situations where the enrollee device is using random MAC addresses, can be rendered more efficient and robust by having the enrollee send a reconfiguration request (DPP Reconfiguration Announcement) with an indication of the type of public key held by its connector as well as a cryptographic hash of the configurator public signing key. Thus, the improved message is as follows: Enrollee -> Configurator: SHA256(C-sign key), group "group" is a finite cyclic group attribute specified in Section 8.1.1.12 "Finite Cyclic Group attribute" of [DPP], using the registry maintained by IANA for the "Group Description" attribute in IETF RFC 2409 [RFC 2409] and [IKE], and indicates the type of public key in the enrollee's connector's NAK. Of course, other ways of indicating the public key type are possible, for example, using the appropriate OBJECTIDENTIFIER set as done in the public key ASN.1 example above, or by the ASN.1 construct called AlgorithmIdentifier specified in Section 4.1.1.2 of [RFC 5280].

[0066] Thus, a method of configuring an enrollee device for communication in a wireless network may include providing a configurator device, executing a configuration protocol, and, if an attempt by the enrollee device to connect to the network fails following a previous execution of a portion of the configuration protocol, sending, by the enrollee device during execution of the configuration protocol, an announce message including an indication of the type of public key previously used by the enrollee as part of the protocol.

[0067] In practice, an enrollee device may be configured by a configurator device for communication in a wireless network, and if an attempt to connect to the network fails after a previous execution of a configuration protocol, the enrollee device may be configured to send an announce message to the configurator, the announce message having an indication of the type of public key previously used by the enrollee as part of the protocol.

[0068] When the configurator receives this message (in the case of DPP, a DPP Reconfiguration Announcement message extended with an indicator of the public key type, according to an embodiment), it knows, and therefore selects, the correct type of key to include in the connector (in the case of DPP, a DPP Reconfiguration Authentication Request) that it sends back. Thus, the configurator device may be configured to configure the enrollee device for communication in a wireless network. The configurator device may receive an announcement message from the enrollee device, which announcement message includes an indicator of the type of public key previously used by the enrollee as part of the configuration protocol. The configurator device obtains this indicator and transmits a configuration message including a key of the same type as the indicator.

[0069] The configurator then does not have to embark on the process of searching that record and the trial and error process of finding the correct type of key to use. Identifying and selecting the correct type of key can be accomplished without a significant increase in resource usage, i.e., time and bandwidth.

[0070] Furthermore, this is particularly useful where the enrollee is a simple device in that the process can proceed automatically, i.e., avoiding the user being forced to engage in time-consuming investigation to understand why the enrollee device is not connecting to the network.

[0071] 3 shows an example of a MAC (Media Access Control) frame. The example in question is that of the IEEE 802.11 standard. However, it should be understood that other formats are possible as long as there is a frame body or payload portion. For the purposes of the present invention, the other portions, the frame header and the error check (here FCS), are not important.

[0072] During the DPP Configuration Protocol phase of DPP, the generic MAC frame format is the GAS frame format conforming to the IEEE 802.11 standard. During the DPP Authentication Protocol phase of DPP, the generic MAC frame format is the Public Action frame format conforming to the IEEE 802.11 standard. Attributes can be added to various messages, including Reconfiguration Announcement messages.

[0073] Figure 3b represents the general format of the attributes that would form part of the payload of the frame of Figure 3a and would include the content of the Reconfigure Announce and Reconfigure Request messages according to an embodiment, namely SHA256 (C-sign key), Group and TransId, Protocol Version, I-Connector, and I-Nonce, respectively.

[0074] The configurator must detect this and be programmed accordingly to parse the message correctly. It should be understood that this increases the complexity of the configurator and its execution time. It also increases the complexity on the enrollee side in that more complex firmware and larger non-volatile memory are required. It should be noted that there is significant downward price pressure on such devices, and even small additions obviously require justification. Furthermore, many such devices are battery-powered, and any extra energy consumption, such as retrieving information, composing more complex messages, and transmitting those more complex and longer messages, is actively avoided, especially when the battery is small and intended to last a long time. Finally, changing the protocol often involves other modifications to enable handling of legacy devices.

[0075] Aspects of the present embodiments may be a collection of computer program instructions stored on a computer-readable storage device that can be executed by a computer, or may be embodied in a computer program product. The instructions may be any interpretable or executable code mechanism, including, but not limited to, a script, an interpretable program, a dynamic link library (DLL), or a Java class. The instructions may be provided as a complete executable program, a partial executable program, a modification (e.g., an update) to an existing program, or an extension (e.g., a plug-in) to an existing program. Furthermore, portions of the processing of the present invention may be distributed across multiple computers or processors.

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

[0077] The following references can be used: [802.11] IEEE Computer Society, "IEEE Standard for Information Technology- Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," (IEEE Std. 802.11-2016), December 2016 [DH] Diffie, W.; Hellman, M. (1976), "New directions in cryptography", IEEE Transactions on Information Theory, 22 (6): 644-654 [DPP] Device Provisioning Protocol - Technical Specification - Version 1.0, Wi-Fi Alliance, 2018, https: / / www.wi-fi.org / file-member / device-provisioning-protocol-specification. [FIPS180-4] FIPS180-4, "Secure Hash Standard", United States of America, National Institute of Standards and Technology, Federal Information Processing Standard (FIPS) 180-4 [IKE] Internet Key Exchange (IKE) Attributes, Group Description (Value 4), https: / / www.iana.org / assignments / ipsec-registry / ipsec-registry.xhtml#ipsec-registry-10 [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 [RFC 2409] RFC 2409, The Internet Key Exchange, November 1998, https: / / datatracker.ietf.org / doc / rfc2409 / . [RFC 5280] RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, https: / / datatracker.ietf.org / doc / rfc5280 / [RFC 5639]RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, March 2010, https: / / datatracker.ietf.org / doc / rfc5639 / . [RFC 6090] RFC 6090, Fundamental Elliptic Curve Cryptography Algorithms, February 2011 https: / / datatracker.ietf.org / doc / rfc6090 /

Claims

1. 1. A method for configuring an enrollee device for communication in a wireless network by a configurator device, comprising: The method comprises: the configurator device executing a configuration procedure for configuring the enrollee device; After the setting procedure, the enrollee device attempts to connect to the wireless network based on the settings set in the setting procedure; sending, by the enrollee device to the configurator device, if the enrollee device fails to connect to the wireless network, an announce message having an indication of the type of public key previously used by the enrollee device during the configuration procedure; sending, by the configurator device to the enrollee device, a reset message including a key of the same type as indicated by the indicator.

2. 2. The method of claim 1, further comprising receiving, by the enrollee device, the reconfiguration message; and calculating, based on the received key, a new key required for the enrollee device to connect to the wireless network.

3. 3. The method of claim 1 or 2, wherein the enrollee device is a simple device.

4. The method of claim 1 , wherein the announcement message further comprises a hash of a public key previously used by the configurator device.

5. The method of claim 1 , wherein the index has a finite cyclic group property.

6. 1. An enrollee device configured to be configured by a configurator device for communication in a wireless network, the enrollee device comprising: Execute a configuration procedure with the configurator device; After the setting procedure, attempting to connect to the wireless network based on the settings set in the setting procedure; sending an announce message to the configurator device if the enrollee device fails to connect to the wireless network, the announce message having an indication of the type of public key previously used by the enrollee device during the configuration procedure; receiving a reconfiguration message from the configurator device that includes a key of the same type as indicated by the indicator; The enrollee device is configured to:

7. An enrollee device as described in claim 6, configured to calculate a new key required for the enrollee device to connect to the wireless network based on the received key.

8. 8. An enrollee device according to claim 6 or 7, which is a simple device.

9. 9. The enrollee device of claim 6, further configured to include in the announce message a hash of a public key previously used by the configurator device.

10. 10. The enrollee device of claim 6, further configured to include a finite cyclic group in the index.

11. 1. A configurator device configured to configure an enrollee device for communication in a wireless network, comprising: performing a setup procedure with the enrollee device; receiving an announce message from the enrollee device having an indication of the type of public key previously used by the enrollee device during the setup procedure; obtaining the indicator from the announcement message; sending a reset message to the enrollee device having a key of the same type as the indicator to enable the enrollee device to calculate a new key for connecting to the wireless network; The configurator device is configured as follows.

12. A system comprising an enrollee device according to any one of claims 6 to 10 and a configurator device according to claim 11.

13. A computer program product which, when executed by a processor of an enrollee device, causes the enrollee device to perform the method of any one of claims 1 to 5.

Images