Loop prevention when reconfiguring devices

Abstract

A method for configuring an enrollee device for communication in a wireless network with a configurator device includes the configurator and enrollee device performing at least a portion of a configuration protocol, the enrollee device encrypting an enrollee identification information using the configurator's public key information and random information to generate a first encrypted message, the enrollee 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 related to the public key, and the configurator device identifying the enrollee device using the enrollee identification information and determining whether configuration should continue based on the enrollee identification information. Also provided are configurators and enrollee devices configured to perform this 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. There is also a third device 9.

[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 apparent success of the configuration process, the configured device still cannot connect to network 1 (or has connected but for some reason is unable to (re)connect). - There are several possible causes for this situation, some of which are that the enrollee contacted a node using a network ID configured in the enrollee and was able to send that information and associated keys to this node in a message requesting to join, but received a response indicating that the request was invalid or did 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 listed 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 when the enrollee attempted to associate with the node, the passphrase or PSK (Pre Shared Key) configured in the enrollee was found to be incorrect. - 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 moving physically 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. Summary of the Invention [Problem to be solved by the invention]

[0006] A device with a user interface, such as complex device 4, can display the status of the connection with the AP (or equivalent node in the network) after configuration and if a problem occurs, for example if the device cannot find the AP (or other device to which a connection is desired). In the case of complex devices, the UI can also display instructions for the user on how to resolve connection issues.

[0007] However, on simple (headless) devices, the only way a user can observe a successful connection is by testing the functionality of the connection or by inspecting the UI of the access point (AP), hub, or gateway. If, after configuration, these devices encounter problems when attempting to connect to the network they are configured to connect to, the user may not know what is wrong and may not realize until some time later when they discover that there is no connection or until they try to check the UI of the AP. [Means for solving the problem]

[0008] Therefore, there is a need for a method for configuring an enrollee device for communication in a wireless network, the method being configured to be used with a configurator device and comprising the steps of: the configurator device and the enrollee device executing at least a portion of a configuration protocol; the enrollee device encrypting enrollee identification information using configurator public key information and random information to generate a first partially encrypted message; the enrollee device sending the first partially encrypted message to the configurator device; the configurator device receiving the first partially encrypted message; the configurator device decrypting the encrypted portion of the first encrypted message using private key information associated with the public key; and the configurator device identifying the enrollee device using the enrollee identification information and determining whether to continue configuration based on the enrollee identification information.

[0009] When the configurator can identify the actual device, it may be able to determine that a condition exists that means the (re)configuration will not proceed, or at least will not proceed without user intervention. The configurator can determine this is the case by identifying the relevant messages received from the enrollee regarding the status of the connection. For example, when the enrollee fails to find an AP, user intervention may be to move the enrollee closer to the relevant access point or to correct a problem with the access point. However, the current trend of using different random MAC addresses for different protocol exchanges poses a problem. The result of the device using a random MAC address for DPP reconfiguration is that the configurator does not know the enrollee's actual identity until multiple messages have been exchanged, which is a waste of resources. By enabling the enrollee to be identified from its initial request for reconfiguration, the configurator can identify the enrollee's connection status from its history and terminate the reconfiguration if it identifies a problem requiring user intervention.

[0010] In one aspect, if the configurator determines that configuration should not continue, the configurator does not respond to the first encrypted message, which allows for a simple end to this cycle of reconfiguration.

[0011] In one aspect, the enrollee device transmits the first partially encrypted message as a result of a failed connection to the wireless network.

[0012] In one aspect, if the configurator determines that configuration should not continue, it sends a denial message to the enrollee, allowing enrollees with more advanced interfaces to notify the user of connection / configuration problems.

[0013] In one aspect, the configuration protocol follows the Wi-Fi DPP protocol and the first encrypted message is a DPP reconfiguration notification message.

[0014] In one aspect, the identification information is used by the configurator device to identify a stored record of an enrollee connection status previously transmitted by the enrollee device during execution of a portion of the configuration protocol.

[0015] In the method, the portion of the setup protocol includes transmitting, by the enrollee device, the enrollee identification information. This allows the configurator to identify the enrollee and find its connection status history.

[0016] In one aspect, the configurator is configured to display status and / or instructions to the user in the event of a decision not to continue, which may assist the user in resolving the issue.

[0017] Also provided is an enrollee device configured to be configured for communication in a wireless network by a configurator device using a configuration protocol, the enrollee device having a receiver configured to receive a configurator device public key from the configurator device, a security module configured to encrypt a first partially encrypted message including the enrollee identification information and random information using the configurator device public key, and a transmitter to transmit the first partially encrypted message to the configurator device.

[0018] In one aspect, the enrollee device transmits the first partially encrypted message as a result of a failed connection to the wireless network.

[0019] A configurator device is provided that is configured to configure the enrollee device using the configuration protocol.

[0020] The configurator device has a transmitter configured to transmit a configurator device public key to the enrollee; a receiver configured to receive a first partially encrypted message from the enrollee device; a security module configured to decrypt the encrypted portion of the first partially encrypted message using the configurator device private key and derive enrollee identification information from the first encrypted message; and a processor configured to determine whether to continue the configuration protocol based on the enrollee identification information.

[0021] In one aspect, the configurator device is configured to display status and / or instructions to the user in the event of a decision not to continue with the protocol.

[0022] Also provided is a computer program product on a machine-readable medium configured to, when executed on a configurator processor and an enrollee processor, implement the configurator and enrollee portions described herein. [Brief explanation of the drawings]

[0023] 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. [Figure 1] 1 is a diagram illustrating a wireless network to which a device may be configured for addition. [Figure 2] FIG. 10 is a diagram showing the flow of a setting process according to the embodiment. [Figure 3a] FIG. 1 illustrates an enrollee device according to one embodiment. [Figure 3b] FIG. 1 illustrates a configurator device according to one embodiment. [Figure 4a] 2 illustrates an exemplary 802.11 MAC frame according to one embodiment. [Figure 4b] 10 is a diagram illustrating attributes according to an embodiment for an 802.11 MAC frame. DETAILED DESCRIPTION OF THE INVENTION

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

[0025] 2 illustrates a flow diagram of an apparatus-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.

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

[0027] 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 "enrolled" in wireless network 1).

[0028] In S2, often called "bootstrap," one device, the responder, obtains the bootstrap public key (B RIf the responder device wants to perform mutual authentication, it obtains the initiator's bootstrap public key (B I ) is also obtained. This is achieved by a method other than wireless communication technology, so-called "out-of-band" communication (OOB). Examples of this could be a user having one device read a QR code on the other device, 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 9, 5 is "bootstrapped"; otherwise, it returns to the "start" state of S1. In either case, the enrollee device (in this case, the simple device 5) can record the result of the bootstrap process in an appropriate storage device, for example, as a flag in a register in memory. Often, the simple device is programmed to start up after manufacture or reset, turn on its radio on the channel indicated in the QR code for configuration, and begin listening for authentication request messages.

[0029] In S4, devices 9 and 5 perform an authentication procedure, thereby establishing "trust." 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 is sent from one device requesting that authentication begin. 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.

[0030] 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 believes has the required capabilities, the response message indicates that the message is "accepted" and that the initiator contains the information necessary to verify the responder's credentials and also indicates that it 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 contain an additional portion indicating the results of a previous attempt to set up the enrollee. If the responder is an enrollee, the authentication response message may contain an additional portion indicating the results of a previous attempt. It should be understood that the indication also indicates whether there has been a previous attempt.

[0031] 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 whether it has a copy of the initiator's public bootstrap key. The responder sends a DPP Authentication Response message indicating whether it can proceed with authentication. 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 communications. 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.

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

[0033] In the case of the DPP protocol, the authentication confirmation message is a DPP Authentication Confirm message.

[0034] 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 the enrollee being successfully configured. According to one embodiment, the configuration request may include an indication of the results of previous configuration attempts.

[0035] In the case of DPP, the request message is a DPP Configuration Request, and the configurator response is a DPP Configuration Response message. The DPP Configuration Response may 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. This allows other devices configured by the same configurator to 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 indicate whether it accepts 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 connector to the DPP-configured 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 compute a symmetric key based on each other's network access keys in the Connector and their own private network access keys in Diffie-Hellman [DH]. This symmetric key can be used by the enrollee as a PSK to associate with AP 2.

[0036] 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), and the enrollee attempts to associate with AP 2 in the normal manner via a four-way handshake as specified in [802.11]. If the connection attempt is successful, the flow proceeds to and completes at S9.

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

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

[0039] The protocol may require (and in practice is done by DPP) that the enrollee return a connection status message to the configurator. In the case of DPP, this message is called the DPP Connection Status Result and has the following format: Enrollee → Configurator: { E-nonce, DPP Connection Status}ke

[0040] "DPP Connection Status" and "E-Nonce" are encrypted using the encryption key ke calculated during initial authentication. The values ​​of "DPP Connection Status" are shown in the table below: [Table 1]

[0041] If "DPP Connection Status" is STAUS_NO_AP, the DPP Connection Status attribute also contains a channel list indicating the channels the enrollee scanned in an attempt to find an AP to connect to.

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

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

[0044] In one 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, no DPP Reconfig Announcement message is needed. It may be useful to note that both devices use keys established during the previous authentication phase. Also, since this forms part of a single protocol execution, there is no change in MAC address, which would pose a problem.

[0045] In most cases, the configuration is successful and the enrollee can connect to the configured network, but connectivity issues can occur even years later. The AP or enrollee may be moved to a different location at some moment and therefore 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 the reconfiguration of the new network.

[0046] In another alternative, the flow can proceed to S10 (which may include a series of message exchanges) where a new configuration attempt is made. In the case of DPP, this process consists of the following series of messages:

[0047] Enrollee -> Configurator: Reconfig Announcement message

[0048] Configurator -> Enrollee Reconfig Authentication message

[0049] Enrollee -> Configurator: Reconfig Authentication Response

[0050] Configurator -> Enrollee: Reconfig Authentication Confirm

[0051] Enrollee -> Configurator: Configuration Request

[0052] Configurator -> Enrollee: Configuration Response

[0053] For DPP, the DPP Reconfiguration Announcement is of the form: Enrollee -> Configurator: SHA256(C-sign key)

[0054] 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 Announcement message. If the configurator has previously configured the enrollee, it assumes the initiator role in the reconfiguration and continues by sending a DPP Reconfig(uration)Authentication request message back to the enrollee. The format of the DPP Reconfiguration Authentication Request is as follows: Configurator -> Enrollee: TransId, Protocol Version, I-Connector, I-nonce.

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

[0056] The DPP Connectors of the enrollee and AP may or may not match. When 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, where certain parameters related to the encryption are the same.

[0057] For example, an implementation of the protocol in [DH] uses the multiplicative group of the integers modulo q, a prime number (denoted in [DH] as "the finite field GF(q) with elements prime q"), and α is a primitive root modulo q (denoted in [DH] as "a fixed primitive element of GF(q)"). Two parties must 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.

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

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

[0060] It should be understood that actual public keys, e.g., certain P-256 keys, when transmitted in messages will typically include the public key type within the structure that contains the public key. 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) }

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

[0062] 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 also possible, such as multiplicative groups of the integers modulo q as described in [DH].

[0063] The I-Connector sent in a DPP Reconfig(uration) Authentication Request does not serve its usual purpose of configuring the enrollee. Instead, it provides the enrollee with a Configurator NAK, a Configurator-supplied public key, which is signed by the Configurator. This allows the enrollee to check the signature and in this way trust that the Configurator NAK actually came from the 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].

[0064] Here, the enrollee that receives the DPP Reconfiguration Authentication Request message from the Configurator calculates the key ke using the NAK of its own connector (the R-Connector received from 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].

[0065] The DPP Reconfig Authentication Response has the following format: Responder -> Initiator: TransId, Protocol Version, R-Connector, Pr , {I-nonce, R-nonce, Connection Status}ke

[0066] The attribute "Connection Status" is the same as the DPP connection status described above. This attribute allows the enrollee to inform the configurator that it knows about a connection problem, allowing the configurator to determine whether it can perform an automatic reconfiguration, for example, when the Enrollee NAK expires. If the connection status indicates an AP discovery failure, this can be understood as a problem with the wireless link itself (the enrollee and AP are not in range) or a problem with the AP. This would then mean that the configurator's user must first do something before reconfiguring the enrollee, such as reconfiguring the AP or moving the devices closer together. If the user must intervene first, the configurator can alert the user of this fact using its UI, for example, in the form of an alert, an Android notification, and / or as part of a "to-do list" it remembers.

[0067] When the DPP Configurator receives a DPP Reconfiguration Announcement from an enrollee, it can identify the MAC address of the enrollee sending the original Reconfiguration Announcement message. The Configurator can then identify the enrollee device and the history of previous executions of the configuration or reconfiguration protocol, including the reason given in the DPP Status previously provided by the enrollee. As can be seen, several messages may be exchanged before the DPP Configurator can assess why previous configuration and connection attempts apparently failed.

[0068] It should be understood that the initial request for reconfiguration (in the case of DPP, the DPP reconfiguration announcement) can be repeated until the enrollee gets a response from the configurator. For complex enrollee devices, the user may be notified of the problem by the device UI and given information to resolve the problem. However, for simple enrollee devices, the enrollee may simply repeat its request for reconfiguration rather than remain disconnected and unavailable. This can often happen without the user's knowledge.

[0069] When the configurator can identify the actual device, it may be able to determine that a condition exists that means the (re)configuration should not proceed, or at least not without user intervention. The configurator can determine this is the case by identifying relevant messages received from the enrollee regarding the status of the connection. For example, when the enrollee fails to find an AP, user intervention may be to move the enrollee closer to the relevant access point or to correct a problem with the access point.

[0070] The inventors have realized that a 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 cannot be tracked anymore using its MAC address.

[0071] A consequence of the device's use of random MAC addresses for DPP reconfiguration is that the configurator currently does not know the enrollee's actual identity, since multiple requests for (re)configuration may arrive with different MAC addresses. This means that the configurator must wait for the DPP Reconfigure Authentication Response message to know which actual enrollee it is dealing with and therefore whether it can reconfigure the current sender of the DPP Reconfiguration Announce message it just received. The DPP standard only allows the configurator to signal to the enrollee that it will (re)configure or will not (re)configure the enrollee using the DPP Configuration Response message, the fifth Wi-Fi message after the DPP Reconfiguration Announce message. For reasons outside the control of the configurator and the enrollee (such as poor connectivity to the AP or a malfunctioning AP), the reconfiguration attempt will (again) fail.

[0072] In simple enrollee devices, there is a risk that the configurator and enrollee may get into a reconfiguration loop, where the enrollee automatically restarts the reconfiguration process without providing any external signal that it is doing so. This results in another series of six reconfiguration messages (including the DPP reconfiguration announcement) being exchanged, resulting in another failure. This wastes resources and bandwidth.

[0073] The reconfiguration process, especially in situations where the enrollee device uses a random MAC address, can be performed more efficiently and robustly by having the enrollee send a reconfiguration request (DPP Reconfiguration Announcement) with an indication of the enrollee's identity as well as a cryptographic hash of the configurator's public signing key. However, the inventors have realized that sending the enrollee's identity in plaintext or by simple encryption of the enrollee's identity with the target device's public key is not sufficient, since the enrollee's encrypted identity remains unique and can be tracked despite the use of a random MAC address. To achieve a solution to this problem, it is necessary to break the one-to-one mapping between the enrollee's identity and the corresponding data sent in plaintext. This can be achieved by using additional random information in the encryption process so that multiple encrypted data sets correspond to the same enrollee's identity. The configurator performs the decryption, extracts the enrollee's identity, and ignores the random information. The improved message, according to one embodiment, is as follows: Enrollee -> Configurator: SHA256(C-sign key), {A-nonce, E-id} Epublic signing key

[0074] Upon receiving this, the configurator can link this ID to the stored results of a previous configuration attempt. According to one embodiment, the improved configurator can then decide whether or not to continue with the reconfiguration based on the results of the previous configuration. If the configurator decides not to continue, the process proceeds to S11, where the process terminates, at least for the current protocol run. By "terminate," it is understood that the (re)configuration can be restarted at a later time.

[0075] The enrollee's ID, E-id, can be a random number, or a portion(s) of the coordinates of the enrollee's protocol key or public ECC key, such as a NAK, or a random point on the curve of a signing key generated specifically for this purpose. The enrollee MUST create the E-id before sending the first DPP Reconfiguration Announce message and keep this E-id constant until it receives a DPP Configuration message containing a new Configuration object (see Section 4.5, "DPP Configuration object" of [DPP]). The enrollee MAY generate the E-id previously, e.g., after a reset or factory reset, and MAY keep it for longer, e.g., until the next (factory) reset, as long as it is kept constant from the first DPP Reconfiguration Announce message until the reconfiguration is successful.

[0076] Thus, a method of configuring an enrollee device for communication in a wireless network includes providing a configurator device; the configurator device and the enrollee device executing at least a portion of a configuration protocol; the enrollee device encrypting an enrollee device identification information using the configurator's public key information and random information to generate a first encrypted message; the enrollee 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; and the configurator device identifying the enrollee device using the enrollee device identification information and determining whether to continue configuration based on the enrollee device identification information.

[0077] If the configurator decides not to continue with the reconfiguration protocol, it simply does not respond with a Reconfiguration Request message (or, in the case of DPP, a DPP Reconfiguration Announcement). The enrollee continues to send requests until a timeout occurs, at which point it stops. Alternatively, the configurator can send a message to the enrollee denying the reconfiguration request, optionally including a reason for doing so.

[0078] The enrollee MAY change its MAC address for any of these Reconfigure-Request messages to maintain its privacy. The enrollee SHOULD keep its MAC address constant throughout the complete series of protocol message exchanges, e.g., from when it receives the DPP Reconfigure Authentication-Request message through all DPP Configure messages.

[0079] Encryption using the configurator's public signing key can be based on elliptic curve cryptography (see [SEC1702]). c Let s be the configurator's private signing key, and s C =S c Let G be a public key, where G is the generator or base point of the curve, which is publicly known. An enrollee E wishes to send an encrypted message to a configurator, C. The enrollee E knows the configurator public signing key S from a previous configuration. C where the configurator's public signing key is sent in the Configuration Object of the Configuration Response message. The enrollee E does the following: 1. E chooses a random number r (1≦r≦n-1) and calculates rG, where n is the degree of G. That is, nG is equal to the so-called point at infinity or identity point O, and P = O + P holds for every point P on the curve. The random number r here is the value of A-nonce above. 2. And E is M+rS CHere, message M is a point in 〈G〉 and represents E's ID, E-id, as will be described later. 3. E is a pair of values ​​〈rG, M+rS C 〉 to Configurator C as part of the DPP Reconfiguration Announce message. This is a pair of two elliptic points, which together form the {A-nonce, E-id} public signing key Represents. When configurator C receives this ciphertext, it converts it into {A-nonce, E-id} public signing key is decoded as follows: 1. C Extract rG and S C =s c Using G, s c ·(rG)=r·(s c G)=rS C Calculate. 2. C is a pair M+rS C Extract the second part of rS C Subtract M+rS C -rS C =Get M

[0080] In the above scheme, the generator G corresponds to the base point of the curve used, and S C =s c G corresponds to the public key used in the ECC encryption algorithm, and s c corresponds to the secret key, which is the secret key used for decryption. Note that ECC already has inherent randomization during encryption with the random number r. Therefore, other mechanisms for concatenating the identification information and random information are possible, as long as the receiving device can obtain the identification information.

[0081] When an enrollee uses its public network access key as an identifier E-id, the above elliptic point M is considered to be the enrollee's public network access key. Similarly, if the enrollee uses another elliptic point on the same curve as an identifier, e.g., as a public bootstrapping key. Note that using a public network access key as an identifier E-id or another public key is only possible if the curve type of these keys is the same as the curve type of the configurator's signing key.

[0082] If the enrollee does not use elliptic points as IDs, or if the curve type of the elliptic point used as ID differs from the curve type of the configurator signing key, the ID, E-id, should first be converted to an elliptic point M. The reason for this is that not all values ​​of x (1 ≤ x ≤ n-1) are the x-coordinate of a point on the curve. [SEC1702] lists several ways to convert a block of plaintext to an elliptic point and back. If the ID is an elliptic point on a curve different from that of the configurator signing key, the x-coordinate of the ID point can be used as a value to convert to a point on the configurator signing key's curve. If the curve used for the elliptic point representing the enrollee's ID contains more points than the configurator signing key's curve, the x-coordinate of the point representing the ID must be split into octet strings that can each be represented by a point on the configurator signing key's curve, and each of these octet strings is represented by a value pair〈rG, M + rS〉. C 〉, where the random number r is different for each octet string, or the same random number is used. The first possibility is 〈r1G, M1+r1S C 〉 〈r2G, M2+r2S C 〉 ... 〈r n G, M n +r n S C 〉, and the second possibility is 〈rG, M1+rS C , M2+rS C , ... M n +rS C〉results.

[0083] An ellipse point can be represented in several ways. One way is to use both its x and y coordinates. Another way is to use only the value of the x coordinate and the sign of the y coordinate. This is because the ECC curve 2 = f(x), where f(x) is a third-order polynomial. If you know the x-coordinate of an elliptic point, say x1, you can calculate sqrt(f(x1)) to find the y-coordinate of the point without its sign. These so-called element-to-octet-string and octet-string-to-element conversion techniques for representing ECC points and for interpreting octet strings that represent ECC points can be found in [802.11].

[0084] Using each of the above two methods, we can find the above tuple 〈rG, M+rS C ECC points rG and M+rS in C can be expressed as:

[0085] Tuple 〈rG, M+rS C 〉 can be transmitted as a TLV (Tag, Length, Value) information element as used in the DPP standard, for example: [Table 2]

[0086] If the enrollee 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, e.g., concatenated, with a second string (a nonce or other random information) before being encrypted. The configurator uses its private key to decrypt the received encrypted information and discards the second string to extract the E-id.

[0087] Optionally, the message may also include the element Group, which 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], where the group indicates the type of the enrollee's connector's public key for the NAK. Of course, other ways of indicating the public key type are possible, for example, using an 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].

[0088] Optionally, the improved message can include the enrollee's previous connection status attribute. This has the advantage of allowing the configurator to inspect the configurator and find the previously received connection status without having to identify the enrollee, but the message will be longer than with E-id. The connection status itself does not easily identify the enrollee, so it does not raise privacy concerns. The format of this message is as follows: Enrollee -> Configurator: SHA256(C-sign key), DPP Connection Status Or, optionally, Enrollee -> Configurator: SHA256(C-sign key), {A-nonce, DPP Connection Status} Epublic signing key Or, optionally Enrollee -> Configurator: SHA256(C-sign key), DPP Connection Status, Group Or, optionally Enrollee -> Configurator: SHA256(C-sign key), {A-nonce, DPP Connection Status, Group} Epublic signing key

[0089] Nevertheless, it may be useful to have both the connection status and the E-id in the improved message.

[0090] 3a depicts an enrollee device 5, 4 according to one embodiment. The enrollee 5, 4 comprises a receiver 51 configured to receive a configurator device public key from a configurator, a security module 52 configured to encrypt a first encrypted message including enrollee identification information and random information using the configurator device public key, and a transmitter 53 configured to transmit the first encrypted message to the configurator device.

[0091] 3b illustrates a configurator device 9, according to one embodiment. The configurator device 9 is configured to configure an enrollee device using a configuration protocol and includes a transmitter 91 configured to transmit a configurator device public key to the enrollee. The configurator device 9 includes a receiver 92 configured to receive a first encrypted message from the enrollee device, a security module 93 configured to decrypt the first encrypted message using the configurator device public key and derive an enrollee identity from the first encrypted message, and a processor 94 configured to determine whether to continue the configuration protocol based on the enrollee identity.

[0092] The receiver, transmitter, security module, and processor of the configurator and enrollee may be implemented in hardware, software, or various combinations thereof.

[0093] When the configurator receives this message (DPP Reconfiguration Announce Message) enriched with enrollee identification information, according to one embodiment, it can determine the enrollee's previous connection results and detect situations in which the reconfiguration protocol should not continue, thereby eliminating the need for the configurator to embark on another likely unsuccessful reconfiguration attempt, resulting in significant savings in resource usage, i.e., time and bandwidth.

[0094] Furthermore, this is particularly useful when the enrollee is a simple device in that the process may proceed automatically, i.e., to avoid the user remaining unaware of the fact that the connection has not been successful and the configurator and enrollee are caught in a potentially endless loop, as opposed to the enrollee device being connected to the network. Furthermore, the user is likely to detect that the connection has failed when the reconfiguration process stops prematurely, because while the user may determine that the device is idle, the reconfiguration loop may prevent the status from being correctly identified to the user.

[0095] Optionally, the configurator device can provide the user with an indication that it has unilaterally terminated the (re)configuration protocol to alert the user to the existence of a problem with the enrollee. This indication can also include an indication of the enrollee's ID and, optionally, instructions based on the "to-do list" described above. When the user has resolved part of the problem, the user can instruct the configurator to allow the configurator to reconfigure this enrollee, so that the configurator will respond to the enrollee's next DPP Reconfiguration Announcement, reconfigure this enrollee, and send a new connector in the sixth message of the protocol, i.e., the DPP Configure Response.

[0096] Optionally, if the enrollee has a user interface that can display configuration status (e.g., an LED that flashes at different rates depending on whether the enrollee is configured, whether it is successfully connected, etc.), the enrollee can display the results of the (re)configuration, including rejection of the reconfiguration.

[0097] Optionally, in another embodiment, the encrypted E-id may already be generated and sent in any of the "normal" DPP protocol messages that the enrollee sends to the configurator: DPP Authentication Request, DPP Authentication Response, DPP Authentication Confirm, DPP Configuration Request, DPP Configuration Result, and DPP Connection Status Result. It is particularly advantageous for the enrollee to send the encrypted E-id in the DPP Connection Status Result message, since the DPP Connection Status attribute of this message also contains information about any problems the enrollee had connecting to the network that was just configured in the DPP Configuration Response message. If an enrollee fails to connect to a network and the user needs to do something first before the enrollee can be successfully configured again, and the enrollee includes an encrypted E-id, the configurator can discard the enrollee's very first DPP reconfiguration announcement, thereby saving the exchange of five Wi-Fi messages. The DPP Connection Status Result has the following format: Enrollee → Configurator: {E-nonce, DPP Connection Status}ke, {A-nonce, E-id} Epublic signing key

[0098] Any of the other DPP messages can be argumented in the same manner. The enrollee MUST keep the E-id constant from the time it sends a message containing the encrypted E-id until it receives a DPP configuration message containing a new configuration object.

[0099] 4 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.

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

[0101] Figure 4b represents the general format of the attributes that would form part of the payload of the frame of Figure 4a and store the contents of the Reconfigure Announce and Reconfigure Request messages according to an embodiment, namely SHA256 (C-sign key), E-id and TransId, protocol version, I-Connector, and I-nonce, respectively.

[0102] 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 it requires more complex firmware and larger non-volatile memory. It should be noted that there is significant downward price pressure on such devices, and obviously even small additions 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 discouraged, especially when the battery is small and intended to last a long time. Finally, changing the protocol often involves other modifications to enable compatibility with legacy devices.

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

[0104] 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. A 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.

[0105] 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 / [RSA] Rivest, R.; Shamir, A.; Adleman, L. (February 1978). "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems"

Claims

1. 1. A method for a configurator device to configure an enrollee device for communication in a wireless network, comprising: the configurator device and the enrollee device executing at least a portion of a configuration protocol; the enrollee device encrypting the enrollee identity information with the configurator device's public key information and random information to generate a first partially encrypted message; the enrollee device sending the first partially encrypted message to the configurator device; receiving the first partially encrypted message by the configurator device; the configurator device decrypting the encrypted portion of the first partially encrypted message using private key information associated with the public key information; the configurator device identifying the enrollee device using the enrollee identification information and determining whether to continue the configuration based on the enrollee identification information; A method having the following.

2. 2. The method of claim 1, wherein the configurator device does not respond to the first partially encrypted message if the configurator device determines that the configuration should not continue.

3. 3. The method of claim 1, wherein the enrollee device transmits the first partially encrypted message as a result of a failure to connect to the wireless network.

4. 4. The method of claim 1, wherein if the configurator device determines that the configuration should not continue, it sends a rejection message to the enrollee device.

5. 5. The method of claim 1, wherein the configuration protocol is in accordance with the Wi-Fi DPP protocol and the first partially encrypted message is a DPP Reconfiguration Announcement message.

6. 6. The method of claim 1, wherein the enrollee identification information is used by the configurator device to identify a saved record of enrollee connection status previously transmitted by the enrollee device during execution of a portion of the configuration protocol.

7. 7. The method of claim 1, wherein the portion of the setup protocol comprises transmitting, by the enrollee device, the enrollee identification information.

8. 8. The method of claim 1, wherein in the event of a decision not to continue, the configurator device displays a status and / or instructions to the user.

9. an enrollee device configured to be configured for communication in a wireless network by a configurator device using a configuration protocol, a receiver configured to receive a configurator device public key from the configurator device; a security module configured to encrypt a first partially encrypted message including enrollee identification information using the configurator device public key and random information; a transmitter configured to transmit the first partially encrypted message to the configurator device.

10. 10. The enrollee device of claim 9, wherein the enrollee device transmits the first partially encrypted message as a result of a failure to connect to the wireless network.

11. a configurator device configured to configure an enrollee device using a configuration protocol, a transmitter configured to transmit a configurator device public key to the enrollee device; a receiver configured to receive a first partially encrypted message from the enrollee device; a security module configured to decrypt an encrypted portion of the first partially encrypted message using a configurator device private key and derive enrollee identification information from the first partially encrypted message; a processor configured to determine whether to continue the setup protocol based on the enrollee identity; A configurator device having:

12. 12. The configurator device of claim 11, which displays status and / or instructions to the user in the event of a decision not to continue with the configuration protocol.

13. A computer program configured to be executed by a configurator device and to cause the configurator device to perform a configurator device part of the method of any one of claims 1 to 8.

14. A computer program configured to be executed by an enrollee device and to cause the enrollee device to perform the enrollee device part of the method of any one of claims 1 to 8.

Images