Secure modification of cryptographic strength during reconfiguration

Abstract

To provide a method for reconfiguring an enrollee apparatus for communication in a wireless network, including executing a configuration protocol.SOLUTION: In a method for configuring an enrollee for communication in a wireless network, a configurator and the enrollee participate in a configuration protocol according to a wireless communication protocol, with the configuration protocol configuring the enrollee to communicate in the wireless network. The configurator executes the configuration protocol and transmits a message including an indicator of selection of a public key type. The public key type is selected from a plurality of types of public keys obtained from the enrollee, with the selected public key type being used for a specific purpose. The selected public key type is different from a previous public key type that the enrollee used for the same specific purpose as a part of a previous configuration of the enrollee for communication in the wireless network.SELECTED DRAWING: None

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 central functions 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) wants 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 lack an 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. The simple device 5 may not have a specific reset button. The wireless network uses a wireless communication technology such as one based on IEEE 802.11, although other technologies may also be suitable.

[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 is desirable to establish trust between the configurator, the enrollee, and ultimately the network to which the enrollee will be connected. "Trust" in this context can be understood to mean that the device being configured is the intended device and that other, malicious devices cannot intervene in the connection. To this end, communications are often encrypted.

[0005] Diffie-Hellman (reference [DH]) is a well-known technique for establishing a private key between two parties in which the communication between the parties to establish the private key does not disclose any information about the established private key to third parties. The two parties each use their own public / private key pair and exchange their public keys with each other. Each party can calculate the private key using its own private key and the other party's public key, and possibly other information such as a nonce (random number) from each party. Each party can generate a new key pair each time it runs Diffie-Hellman, or it can reuse an old key pair.

[0006] The Wi-Fi Alliance's Device Provisioning Protocol (DPP) (see References [DPP]) uses Diffie-Hellman to establish a secret key between two devices: a DPP enrollee that wishes to be configured, and a DPP configurator that can configure the DPP enrollee so that these devices can access a DPP-enabled network or configure the DPP-enabled network as an Access Point (AP) (see References [802.11]).

[0007] When Diffie-Hellman is executed on a network, the device receiving the public key for executing Diffie-Hellman does not know which device this public key comes from. This can be exploited by an attacker in a so-called man-in-the-middle attack. Attacker E can pose as the actual device B that device A wants to connect to. Attacker E executes Diffie-Hellman with device A and establishes a private key, Kae, with device A. Similarly, the attacker masquerades as device A to device B and establishes a private key, Kbe, with device B. When a message comes in from either device A or B, the attacker decrypts the message with one private key, encrypts it with the other, and forwards it to the other device. In this way, devices A and B do not notice anything strange in their communication, except for some extra delay. Even if they check the communication by sending the same information via another communication method and comparing the results, the devices will not notice any tampering in their communication. However, the attacker has complete knowledge of what is being communicated. One way to prevent man-in-the-middle attacks and ensure authenticity is to use an additional protocol, so-called out-of-band (OOB) communication, to exchange public keys or hashes of public keys. The OOB communication may be a short-range wireless communication protocol, such as Wi-Fi [802.11], Bluetooth [BT], 802.15.4 [802.15.4], ZigBee [ZIGBEE], or Near Field Communication [NFC]. Alternatively, the OOB communication may involve the configurator obtaining the public key by a technique such as scanning a QR code associated with the enrollee device, and then decrypting the public key.

[0008] In this way, a device user knows that a public key received over the OOB is from the intended device because they can verify the association between the QR code and the enrollee, or because the enrollee is within the operating range of the OOB communication protocol. Once hashes of public keys are exchanged over the OOB, a device can verify whether a public key received over a communication protocol that requires encryption results in the same hash as the one received over the OOB. Note that the use of the term communication protocol herein encompasses multiple layers of the ISO-OSI model, including the physical layer for transmission and reception.

[0009] Specifically, consider the case of an enrollee configured using the Device Provisioning Protocol (DPP) (https: / / www.wi-fi.org / downloads-public / wi-fi_Easy_Connect_Specification_v2.0.pdf / 35330), also known as Wi-Fi Easy Connect.

[0010] In DPP, elliptic curve cryptography [RFC 6090] is used for all asymmetric cryptography, especially for Network Access Keys (NAKs) and Configurator Signing Keys. The requirement for ECC curve support is P-256.

[0011] Suppose an enrollee (an AP or a Wi-Fi device that can associate with an AP) was configured by a Wi-Fi Easy Connect Release 2 configurator using ECC curve P-256 for the network access key (netAccessKey or NAK). This means that the enrollee used a P-256 bootstrap key, because these two curves are required to be the same in DPP R2. The configurator could have used a curve other than P-256 for its signing key.

[0012] The user wants to upgrade the security of their network so that P-256 is no longer used and a stronger curve is used instead, which requires new configuration of the AP and all devices allowed on the network, or the user wants to create a DPP network using another curve, such as P-384, which is preferably stronger than the curve required to implement P-256.

[0013] The requirement to manage security upgrades means that simple devices need a way to handle new keys / key types in addition to a way to handle new requests. In particular, the DPP protocol does not provide a "security upgrade" context. Summary of the Invention [Problem to be solved by the invention]

[0014] Therefore, there is a need to provide a method for reconfiguring an enrollee device for communication in a wireless network that involves performing a configuration protocol. [Means for solving the problem]

[0015] A method for configuring an enrollee device for communication in a wireless network is provided, the method being configured to be executed by a configurator device and an enrollee device, the configurator device and the enrollee device being configured to communicate using a wireless communication protocol and to participate in a configuration protocol, the configuration protocol being configured to configure the enrollee device to communicate in the wireless network, the enrollee device having been previously configured to communicate in the wireless network. The method includes executing the configuration protocol, the configuration protocol including transmitting, by the configurator device, a message using the wireless communication protocol, the message including an indication of a selection of a public key type, the public key type being selected by the configurator device from a plurality of types of public keys obtained from the enrollee device, the selected public key type being used for a specific purpose, the selected public key type being different from a previous type of public key used by the enrollee device for the same specific purpose as part of a previous configuration of the enrollee device for communication in the wireless network.

[0016] This allows the configurator and enrollee devices to agree on a new type of key, preferably a stronger key in cryptographic terms, and complete the bootstrap and authentication protocol. In many situations, the enrollee device is configured to "lock out" further configuration once it has been successfully configured. Such a measure provides some security from the network in that malicious devices are prevented from using reconfiguration of devices in the network as a method to gain access. Thus, a user wishing to reconfigure the network to use stronger encryption must reset these enrollee devices. While this is an annoyance in itself, it can become even more problematic if some devices are installed in remote or difficult-to-access locations (e.g., lighting fixtures). This method also allows the reconfiguration to occur using improved strength encryption from the beginning, as opposed to initiating the reconfiguration using an existing, less strong configuration.

[0017] In one embodiment, the message triggers a re-initiation of the authentication protocol between the configurator device and the enrollee device.

[0018] With the new implementation of the authentication protocol, authentication of the enrollee and configurator can then be performed using improved strength cryptography.

[0019] In one embodiment, the public key of the type of public key is a Device Provisioning Protocol (DPP) bootstrap, network access or protocol key.

[0020] In one embodiment, the configurator device compares the public key type to an indication of the public key type stored during a previous configuration of the enrollee device.

[0021] In one embodiment, the configurator device selects an enrollee bootstrap key for use in the resumed authentication protocol, the enrollee bootstrap key being obtained during a previous configuration of the enrollee device to communicate in a wireless network.

[0022] This allows the configurator to select a new type of public key without the potentially burdensome reacquisition of the types of public keys available to the enrollee device, for example, this can avoid having to scan multiple QR codes.

[0023] In one embodiment, the enrollee device responds to a message from the configurator device that includes an indication of the selection of the public key type, and the response message includes the enrollee's ID used during a previous configuration of the enrollee device, and the configurator uses the enrollee's ID to select the enrollee key.

[0024] This allows the configurator device to automatically select an enrollee key when there are multiple keys and key types for the enrollee. This feature may also provide additional security in that a warning may be provided to the user if the ID is not recognized as one previously configured. This may occur as a result of a malicious device attempting to join the network or simply as a result of user error (e.g., the enrollee device is not actually configured). The user can then check for the problem and, if applicable, initiate an entirely new configuration by using appropriate out-of-band methods.

[0025] In addition to the information already present in the DPP Reconfiguration Authentication Response defined by DPP R2 [DPP], the enrollee may also include an enrollee bootstrap key for the newly desired curve type by the configurator. This enrollee bootstrap key should preferably be included in the encrypted portion of the DPP Reconfiguration Authentication Response message. The advantage of this is that the configurator user does not need to scan a QR code or touch an NFC, which is very user-friendly.

[0026] In one embodiment, the enrollee device sends a message containing a cryptographic hash of information including the enrollee key, and thus authentication proceeds.

[0027] In one embodiment, the enrollee device is a simple device. This method allows for automatic reconfiguration of simple or even headless devices without the cumbersome requirement of manually resetting such devices.

[0028] In one embodiment, the message from the configurator device includes an indication that the selection of the public key type is a new selection.

[0029] This allows this message to be processed by both enrollee devices according to one embodiment and legacy enrollees. In such a case, an enrollee device according to one embodiment is reconfigured with a public key of the new type, while the legacy device can continue with the key type it was using. This can be useful in networks where lower security devices are tolerated because they have a limited role.

[0030] In one embodiment, the configuration protocol follows the Device Provisioning Protocol (DPP).

[0031] Also provided is an enrollee device configured to participate in a configuration protocol, the enrollee device being configured to participate in the configuration protocol, providing a plurality of types of public keys configured to be used in the configuration protocol, providing at least one public key for each type of public key provided, being configured to connect to a network such that it is able to connect to the network and is set to a state in which it is unable to receive messages, and being configured to use a type of public key selected by the configurator device from the plurality of types of public keys in the configuration protocol, wherein receipt of the message triggers re-initiation of the authentication protocol between the configurator device and the enrollee device.

[0032] This allows enrollee devices to participate in reconfiguration without manual resets and without exchanging secret keys over connections using less secure encryption.

[0033] In one embodiment, the enrollee device is configured to respond to the message with a response message that includes, in the indication of the enrollee device's identity, the enrollee device's identity that was used during the enrollee device's previous configuration.

[0034] In one embodiment, the enrollee device is a simple device.

[0035] There is also provided a device configured to operate as a configurator device and configured to reconfigure an enrollee device for communication in a wireless network, the device having a transceiver configured to transmit and receive according to a communications protocol, the device being arranged to: participate in a configuration protocol, obtaining from the enrollee device an indication of a plurality of types of public keys to be used as part of the configuration protocol; selecting a public key type from the indication, wherein the selected public key type is to be used for a particular purpose, the selected public key type being different from a public key type used by the enrollee device for the same particular purpose as part of a previous configuration of the enrollee device to communicate in the wireless network; and using the transceiver to send a message to the enrollee device, the message having an indication of the public key type selected by the configurator from the plurality of types of public keys.

[0036] A configurator device so configured can automatically detect when an enrollee device is ready to participate in a reconfiguration for the enrollee device according to one embodiment. The configurator device can select a new type of key, such as a new curve, without the need for manual user intervention, such as scanning multiple QR codes. Notably, this avoids the user having to engage in a trial-and-error process of finding a new curve for bootstrap that the enrollee device can accept.

[0037] In one embodiment, the message triggers a resumption of the authentication protocol between the configurator device and the enrollee device.

[0038] In one embodiment, the configurator device is configured to obtain and store multiple types of public keys and at least one public key according to the type of public key obtained during a previous configuration of the enrollee device to communicate in the wireless network.

[0039] In one embodiment, the configurator device is configured to select a public key from a plurality of stored public keys.

[0040] The advantage of having the configurator remember the key type for future use is that the user does not need to find information associated with the enrollee device (such as a QR code), which may be difficult to find after the initial installation.

[0041] In one embodiment, the configurator device is configured to receive and process a response message from the enrollee device, the response message including an indication of the enrollee device identification information for selecting a public key type from a plurality of stored types of public keys.

[0042] In one embodiment, the configurator device is configured to include an indication that the selection of the public key type is a new selection.

[0043] Also provided is a system comprising an enrollee device according to an embodiment and a configurator device according to an embodiment.

[0044] Also provided is a computer program product that, when running on a processor in an enrollee device, causes the enrollee device to perform a method according to one embodiment.

[0045] A computer program product is also provided which, when running on a processor in a configurator device, causes the configurator device to perform a method according to an embodiment. [Brief explanation of the drawings]

[0046] 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] Setup process flow. [Figure 3] 10 is a flow chart of a reset process according to an embodiment. [Figure 4a] 1 illustrates a computer-readable medium. [Figure 4b] 1 is a schematic diagram of a processor system. The drawings are schematic and not drawn to scale. In the drawings, elements corresponding to elements already described may have the same reference numerals. DETAILED DESCRIPTION OF THE INVENTION

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

[0048] As an example, we will consider the case of a simple device 5. While much of this discussion provides examples involving networks with devices such as AP 2, it should be understood that this process may also work in a peer-to-peer context. This configuration flow may be used to configure devices that are in an unconfigured state or that are not yet connectable.

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

[0050] At S1 (Start), 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 as the Enrollee (as it is "enrolled" in wireless network 1).

[0051] In S2 (Bootstrapping), often called "bootstrap," one device, the initiator, obtains the bootstrap public key (BR) of the other device, the responder. If the responder device desires mutual authentication, it also obtains the initiator's bootstrap public key (BI). This can be achieved by a method other than wireless communication, known as "out-of-band" communication (OOB). Examples of this could be a user having one device scan a QR code on the responder, NFC communication between two devices, or other wireless technologies (such as Bluetooth). The bootstrap process is initiated by user intervention. If the bootstrap is successful, the process reaches S3 (Bootstrapped), and the device 10, 5 is "bootstrapped." If not, it returns to the "start" state in S1. In either case, the enrollee 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 configuration QR code, and begin listening for authentication request messages.

[0052] In S4 (Authentication), the devices 9 and 5 perform an authentication procedure, thereby establishing "trust" between the devices, i.e., the user can be confident that the devices are who they believe they are and not some other unknown (and potentially malicious) device "pretending" to be one of the devices in question or another. 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, the third device 9 acts as the configurator, and the simple device 5 acts as the enrollee. Note that while the third device 9 is shown connected to the network 1, this is not necessary for the embodiment to function. The device that initiates the wireless communication is called the initiator, and the device that responds is called the responder. In particular, the DPP protocol allows both the configurator and the enrollee device to act as initiators in the DPP protocol, thereby automatically making the other device the responder. Simple or headless devices typically assume the role of responder.

[0053] 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 the bootstrapped state of 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.

[0054] 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 continue authentication. If it cannot continue because, for example, an attempt to decrypt the encrypted nonce in the DPP Authentication Request message fails, the process is aborted. The DPP Authentication Response contains a cryptographic hash of the responder's public bootstrap key and may also contain a hash of the initiator's public bootstrap key. Similarly, for the initiator, the 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.

[0055] 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 messages are found to be correct by the associated devices, this part of the protocol, the authentication part, is successful, the process reaches S5 (Authenticated), and configuration can begin. The Confirmation message may also include 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.

[0056] In S6 (Configuration), the enrollee device sends a configuration request message with information about what type of configuration the enrollee desires. If the configurator can grant the request, it sends a message containing the information the enrollee needs, such as a network key. In a variant, the configuration request can also include an indication of the results of previous configuration attempts.

[0057] In the case of DPP, the request message is a DPP Configuration Request, and the configurator response is a DPP Configuration Response message. The DPP Configuration Response may include the Service Set Identifier (SSID) of the network to which the enrollee will connect and may include a DPP Connector. The DPP Connector is digitally signed by the configurator using a key (a C-sign key) and includes, among other things, the enrollee's public network access key. The configurator may have obtained the enrollee's public network access key from a DPP Authentication Response message previously sent by the enrollee; in this message, this key is referred to as the responder's public protocol key. If DPP authentication is successful, the responder's public protocol key is renamed the enrollee's public network access key, indicating the new purpose of the protocol. The DPP Configuration Response message also includes the configuration's public signing key. Other devices configured by the same configurator can thereby verify whether they can trust the other devices' public network access keys. The DPP Configure Response message may also contain the network's Wi-Fi passphrase or pre-shared key (PSK). The enrollee sends a DPP Configure 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 for 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 Diffie-Hellman network access keys.

[0058] In S7 (Connection), Enrollee 4 or Enrollee 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 in S8 (Complete).

[0059] In the case of DPP, the 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)}

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

[0061] Currently, specifically in DPP, the bootstrap URI contains only one bootstrap key in DPP R2. This bootstrap key is the last attribute of the bootstrap URI. It is of the following format: "K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;", where the characters between the ":" and ";" are the base64 encoded ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC 5280]. The decoded and pretty printed version of the above example bootstrap key representation looks like this: SEQUENCE { SEQUENCE { OBJECTIDENTIFIER 1.2.840.10045.2.1 (ecPublicKey) OBJECTIDENTIFIER 1.2.840.10045.3.1.7 (P-256)} } BITSTRING 0x03336db4e9abf11c96875e02cc92aff6e1ed2bb2b7cc3fd2b54e6f20c7ea2f3f42 : 0 unused bit(s)}

[0062] When this procedure is performed using a device according to one embodiment, the bootstrap URI is extended to allow additional bootstrap keys to be added in a backwards compatible manner, where the additional bootstrap keys all use different ECC curves. This can be done with a series of one or more attributes similar to the existing attributes denoted with "K" in the DPP bootstrap URI, appearing anywhere before, but denoted with, for example, "A" instead, for P-384 bootstrap keys, for example as follows: "A:MEYwEAYHKoZIzj0CAQYFK4EEACIDMgADBJL3omc4bW2UHu7FaOs8Tgy0pXL / J6NXgcD9YYxfkWlSjXvesPGekHMI04f7+Pe9;" The above example bootstrap key representation can be decrypted and pretty printed as follows: SEQUENCE { SEQUENCE { OBJECTIDENTIFIER 1.2.840.10045.2.1 (ecPublicKey) OBJECTIDENTIFIER 1.3.132.0.34 (P-384)} } BITSTRING 0x030492f7a267386d6d941eeec568eb3c4e0cb4a572ff27a35781c0fd618c5f9169528d7bdeb0f19e907308d387fbf8f7bd : 0 unused bit(s)} }

[0063] In DPP, elliptic curve cryptography [RFC 6090] is used for all asymmetric cryptography, particularly for network access keys (NAKs) and configurator signing keys; however, other forms of asymmetric cryptography are possible, such as the multiplicative group of the integers modulo q, as described in [DH], where q is a prime number (called a "finite field GF(q)" in [DH] with element prime q), and α is a primitive root modulo q (called a "fixed primitive element of GF(q)" in [DH]). All public keys generated with the same values ​​of q and α are considered to be the same type of public key for purposes of this specification. Similarly, all public keys that are points on the same elliptic curve are considered to be the same type. Public keys that use different encryption algorithms, such as ECC and the multiplicative group of the integers modulo q, are considered to be different types of public keys. Public keys that use the same encryption algorithm but have different values ​​for at least one of their defining parameters are considered to be different types of public keys for purposes of this specification. For example, the defining parameters are q and α for the multiplicative group of the integers modulo q, and the elliptic curve is the defining parameter for the ECC algorithm. In addition to using the OBJECTIDENTIFIER shown in the example above, the representation of the elliptic curve can also be given or obtained using an element group containing the Finite Cyclic group attribute specified in Section 8.1.1.12 "Finite Cyclic group attribute" of [DPP], using the registry maintained by IANA as the "group Description" attribute in IETF RFC 2409 [RFC 2409] and [IKE]. For example, in a DPP Reconfiguration Announcement message, the element group indicates the public key type of the enrollee's connector's Network Access Key.

[0064] It is noted that for purposes of this disclosure, selecting, comparing, providing, obtaining, receiving, etc., a type of public key is also accomplished when selecting, comparing, providing, obtaining, receiving, etc., a structure, or blob of data, that contains the public key and that public key type. Examples of such structures or blobs of data are provided herein.

[0065] For some reason, the enrollee may fail to connect. In the case of a complex device 4, the enrollee may display a message to the user to make the user 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 that it is programmed to, unless further programmed.

[0066] The protocol requires (and in fact DPP does require) the enrollee to return a status message to the configurator. In the case of DPP, the message is of the form: Enrollee → Configurator: { E-nonce, DPP Connection Status}ke

[0067] Upon receiving the status message, if the DPP Connection status indicates anything other than Status_OK, the configurator responds with a response message containing the updated (or new) configuration, and the enrollee retries connecting to the network. For DPP, this S11 may involve the execution of the DPP configuration protocol and the DPP installation protocol. If this connection is successful, the flow ends with S8 (Complete).

[0068] In S9 (Reconfiguration request), in the case of a DPP, in the case of an already configured enrollee experiencing problems connecting to the network in which it is configured, the enrollee can send a reconfiguration request, called a DPP reconfiguration announcement, which is of the following form: Enrollee -> Configurator: SHA256(C-sign key), group, A-NONCE, E'-id

[0069] For a simple re-execution of a configuration, the flow goes through S10 (Reconfiguration response). However, this protocol does not address the situation where a request to change the key or key type comes from the configurator. In a normally operating network, a (previously) configured enrollee is not configured to receive and process such a request; it either ignores it or reacts with an error.

[0070] While the user could always manually intervene and reset simple devices, this could be very inconvenient in that many of these devices will be installed in hard-to-reach locations (e.g., light bulbs in ceiling sockets). Therefore, requiring the user to manually reset all of those simple devices is undesirable, and a configurator-based solution is highly desirable.

[0071] For DPP, other issues exist: the DPP Bootstrapping URI can currently only contain one public key according to the DPP R2 standard [DPP]. Devices that support more than one ECC curve must somehow present more than one QR code with more than one bootstrap key. To transfer multiple DPP Bootstrap Keys, the NFC Handover Request or NFC Handover Selection message must contain multiple Alternative Carrier Records, each containing one DPP Bootstrap URI (see Section 5.4 "NFC" of [DPP]).

[0072] While it is indeed possible to have more than one QR code for more than one ECC curve, using this solution is cumbersome for the user: the user must somehow keep track of which QR code they scan, so that they actually scan the QR code that corresponds to the more secure key / key type.

[0073] A possible solution for DPP might be to modify the DPP configuration protocol so that the configurator performs bootstrap using P-256 and runs the DPP authentication protocol using P-256, while the configurator asks the enrollee to first create a new network access key (NAK) using another, preferably stronger, curve, e.g., P-384 or P-521. An enrollee that supports this new curve does so, supplies its new NAK in the adapted DPP configuration protocol, and proves to the configurator that it possesses the private key belonging to the new NAK. If successful, the configurator places the new enrollee NAK in a DPP connector, possibly signing this connector with a signing key on a new, e.g., stronger, curve, and sends the new connector, possibly along with the new configurator public signing key, to the enrollee in a DPP Configuration Response message.

[0074] However, this solution has a fundamental flaw in that the new key / key type is sent over the bootstrapped connection using exactly the encryption that was determined to be insufficient.

[0075] 3 illustrates a protocol flow for upgrading the encryption of a connection, according to one embodiment. This is described with particular reference to DPP. However, this flow may be applicable to other protocols.

[0076] Before the configuration protocol begins, devices 4 and 5 must be in a state where they can participate in the protocol. Simple devices, such as device 5, are often not programmed to respond to requests for reconfiguration if they "think" they are successfully configured and connected. Many devices, such as simple device 5, are configured to retain only one configuration at a time. Furthermore, many are manufactured without a configuration, but are programmed to reject or ignore subsequent attempts to configure the device once configured. For example, a "configuration block" is a flag that is referenced whenever an attempt to configure the device occurs. This behavior is similar to the process of imprinting a particular animal, whereby a young animal learns to recognize another individual as its "mother" if it sees that individual at a particular time. Once imprinted, the young animal refuses to consider another individual as its mother. Reconfiguring such a device requires some kind of reset to remove the flag that prevents the device from participating in the configuration process. Such a flag can simply be a status flag with a value indicating either "configured" or "not configured." Simple devices may also be preconfigured for communication by some means other than the configuration protocol, such as being configured at the factory. In this example, the device 9 and the devices 4 and 5 are according to the embodiment.

[0077] In step RS1 (Start), the protocol to upgrade the encryption is initiated. This requires the enrollee to be in a state where it can be configured (or to configure itself). One possible way for this could be to have a dedicated command issued by another device in the network (such as AP 2) that forces device 5 to accept a reconfiguration.

[0078] Another possible method is to simply change the security settings on the network at AP 2 (or other complex device in case of a peer-to-peer network). If the security settings are changed at AP 2, for example by changing from using P-256 to P-384, AP 2 will reject further connections from devices 4 and 5 because their connectors are no longer valid. According to one embodiment, devices 4 and 5 register that they can no longer connect and reset the "configured" flag. Devices 4 and 5 are then ready to bootstrap with the new key / key type. In the case of DPP, it can send a DPP reconfiguration notification of the following form: Enrollee -> Configurator: SHA256(C-sign-key), group, A-NONCE, E'-id where: A-NONCE and E'-id are points on the curve of the configurator signing key (C-sign-key). The group indicates the elliptic curve of the enrollee network access key that was previously received by the connector.

[0079] The configurator signing key in this step is the key with which the configurator provisioned the enrollee during a previous initial configuration or a previous reconfiguration, and with which the connector was signed. This key may be on the same curve as the curve indicated by the group attribute, or on a different curve.

[0080] In the case of bootstrapping via near field communication (NFC), the device 4, 5 turns on its NFC radio.

[0081] In the case of bootstrapping via Bluetooth (BT), for example BT Low Energy or BLE, the device 4, 5 starts transmitting BT (or BLE) advertisements.

[0082] As mentioned above, currently, specifically in DPP, the bootstrap URI contains only one bootstrap key in DPP R2. This bootstrap key is the last attribute of the bootstrap URI. It is of the following form: "K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;", where the symbols between ":" and ";" are the base64 encoded ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC 5280]. The decoded and pretty printed version of the example bootstrap key representation above looks like this: SEQUENCE { SEQUENCE { OBJECTIDENTIFIER 1.2.840.10045.2.1 (ecPublicKey) OBJECTIDENTIFIER 1.2.840.10045.3.1.7 (P-256)} } BITSTRING 0x03336db4e9abf11c96875e02cc92aff6e1ed2bb2b7cc3fd2b54e6f20c7ea2f3f42 : 0 unused bit(s)}

[0083] According to one embodiment, the bootstrap URI is extended so that additional bootstrap keys can be added in a backwards compatible manner, all using different ECC curves. This can be done with a series of one or more attributes that are all similar to the existing attributes denoted with "K" in the DPP bootstrap URI and appear anywhere before, but in the case of a P-384 bootstrap key, are instead denoted with, for example, "A", e.g., as follows: "A:MEYwEAYHKoZIzj0CAQYFK4EEACIDMgADBJL3omc4bW2UHu7FaOs8Tgy0pXL / J6NXgcD9YYxfkWlSjXvesPGekHMI04f7+Pe9;" For a P-384 bootstrap key, the example bootstrap key representation above can be decrypted and pretty printed as follows: SEQUENCE { SEQUENCE { OBJECTIDENTIFIER 1.2.840.10045.2.1 (ecPublicKey) OBJECTIDENTIFIER 1.3.132.0.34 (P-384) } BITSTRING 0x030492f7a267386d6d941eeec568eb3c4e0cb4a572ff27a35781c0fd618c5f9169528d7bdeb0f19e907308d387fbf8f7bd : 0 unused bit(s) }

[0084] In RS2 (Propose New Key Type), in this example, the configurator user wants to use a different curve for the enrollee NAK than the one indicated in the 'group' attribute of the received DPP Reconfiguration Announcement. Therefore, the configurator sends the following response, called a DPP Reconfiguration Authentication Request message: Configurator -> Enrollee: TransId, Protocol Version, C-Connector, C-nonce The C-Connector now includes a Coconfigurator NAK on the new desired curve, not the curve indicated by the enrollee in the "group" attribute. Because the C-Connector is still signed by a signing key owned by the enrollee, it must be on the same curve as attributes A-NONCE and E'-id. This contrasts with the current DPP R2 standard. It may be advantageous to configure the configurator to maintain a record of the key / key type used in the previous configuration, as described above in steps S1 through S8. In this example, this is the previously used curve. The configurator then checks that the new curve is indeed stronger and can take action, such as aborting the protocol, if this new choice is not stronger than the existing configuration or if it warns the user. Another advantage is obtained when the enrollee provides an extended bootstrap URI, according to one embodiment. In this case, the configurator can remember the curve / key / key type and automatically select one stronger than the one currently in use. As can be easily seen, this curve / key / key type must be used for other elements in the network.

[0085] Legacy enrollees, i.e., enrollees not according to one embodiment, may not be able to continue with the DPP reconfiguration authentication protocol at this point. This may be desirable if only devices supporting the new group's better or other security are allowed on the network, but may be undesirable if users still want to be able to use legacy devices. In the latter case, the legacy devices may be configured to use a network that does not allow them access to sensitive information.

[0086] An alternative way to indicate the new desired curve in the Configurator Connector (C-Connector) of the DPP Reconfigure Authentication Request message is to add a new JSON attribute-value pair to the DPP Connector to indicate this (e.g., "newGroup"="P-384") and use a Configurator NAK on the curve indicated in the Group attribute of the DPP Reconfigure Announcement. The advantage of the latter is that legacy enrollees will continue to perform DPP Reconfiguration Authentication with a NAK on the curve in the Group attribute, so they can still be configured, perhaps only for networks that do not provide access to sensitive information. An example DPP Connector Body Object is shown below. { "groups": [ {"groupId":"home","netRole":"sta"}, {"groupId":"cottage","netRole":"sta"} ], "netAccessKey": { "kty":"EC", "crv":"P-256", "x":"Xj-zV2iEiH8XwyA9ijpsL6xyLvDiIBthrHO8ZVxwmpA", "y":"LUsDBmn7nv-LCnn6fBoXKsKpLGJiVpY_knTckGgsgeU" }, "newGroup"="P-384", "expiry":"2022-01-31T22:00:00+02:00" }

[0087] By indicating the new desired curve in the connector in these ways, or in other ways, the DPP Reconfiguration Authentication Request message is now protected from forgery by an attacker.

[0088] However, an attacker could copy a previously sent C-Connector and use it in a fake message. This can be prevented by adding one or both of the two random attributes in the preceding DPP reconfiguration announcement, namely A-NONCE and E'-id, as new JSON attribute-value pairs in the C-Connector. Not all of these bits are required, but enough are needed to make it highly unlikely that the same bit combination has been used previously by a configurator using the same signing key. An example DPP Connector Body Object with the first 16 bits of A-NONCE included is below: { "groups": [ {"groupId":"home","netRole":"sta"}, {"groupId":"cottage","netRole":"sta"} ], "netAccessKey": { "kty":"EC", "crv":"P-256", "x":"Xj-zV2iEiH8XwyA9ijpsL6xyLvDiIBthrHO8ZVxwmpA", "y":"LUsDBmn7nv-LCnn6fBoXKsKpLGJiVpY_knTckGgsgeU" }, "newGroup"="P-384", "aNonceBits"="3FC5" "expiry":"2022-01-31T22:00:00+02:00" }

[0089] In RS3 (Accept New Key Type), the enrollee checks the C-Connector. It is able to do this because the C-Connector possesses the Configurator's correct public signing key. If the enrollee sees that the NAK in the C-Connector is on a different curve than its own NAK, and if the enrollee supports that curve, it cannot continue the DPP Reconfiguration Authentication Protocol by sending a DPP Reconfiguration Authentication Response message. Instead, it restarts the DPP Authentication Protocol (not shown in Figure 3). The enrollee can do so by selecting its bootstrap key that is on this curve and present in its bootstrap URI, and using this bootstrap key to begin sending DPP Presence Announcement messages, which have the following format: Enrollee → Configurator: SHA256("chirp" | BR2) where BR2 is the enrollee bootstrap key on the new curve. While sending the DPP Presence Announce message, the enrollee is ready to receive DPP Authentication Request messages from the configurator, as specified in the DPP standard [DPP]. Optionally, the enrollee can simply listen for DPP Authentication Request messages from the configurator without sending a DPP Presence Announce message.

[0090] If the enrollee bootstrap URI is fixed, for example, fixed on an NFC tag, printed in the enrollee's manual, on its housing, or made available on the manufacturer's website, the new enrollee bootstrap key is a pre-configured key. If the enrollee has a display or uses peer-to-peer NFC or BLE for (DPP) bootstrap, the enrollee may generate a new enrollee bootstrap key and corresponding (DPP) bootstrap URI at this time and display it or send it to the configurator via NFC or BLE.

[0091] Legacy enrollees (i.e., enrollees not according to the embodiment) will either abort the reconfiguration or continue with their "old" NAK, depending on how the new desired curve is indicated in the C-Connector. The protocol then ends with this step (Terminate).

[0092] In one embodiment, an already configured enrollee may check the key / type of the proposed public key against the key / type of the public key used in the previous configuration.

[0093] Yet another advantage of adding the new "newGroup" attribute to the C-Connector is that an enrollee implemented in accordance with the present invention can respond securely with a (possibly adapted) DPP Reconfiguration Authentication Response before resuming the DPP authentication protocol. This response is possible because the Connector's Configurator NAK in the DPP Reconfiguration Authentication Request is on the same curve as the Enrollee Connector's Enrollee NAK, and both devices can compute the key ke for the encrypted portion of the DPP Reconfiguration Authentication Response. This secure response can include the Enrollee Connector's Enrollee NAK, and this key can be used to find the device's Bootstrap URI used during initialization. This is because this particular Enrollee NAK was used as the enrollee's public protocol key during its initialization. The Enrollee NAK can therefore serve as the enrollee's identity, because the enrollee uses this key from authentication through (and including) execution of the DPP network introduction protocol to gain access to the network. The stored Bootstrap URI may contain the bootstrap key on the curve the Configurator wants to use. In that case, the configurator user does not need to scan a QR code, touch NFC, etc. in step RS4, which has the advantage of being more user-friendly. Additionally, there may be a status field indicating that the enrollee will proceed to be configured for a new curve and / or a bootstrap key on a new curve, relative to the information already present in the DPP Reconfiguration Authentication Response specified by DPP R2 [DPP]. The added information may appear anywhere in the DPP Reconfiguration Authentication Response message, since its entire contents are integrity protected by AES-SIV (Synthetic Initialization Vector (SIV) Authenticated Encryption Using Advanced Encryption Standard (AES), see [RFC 5297]).Placing the added information in the encrypted portion of the DPP Reconfiguration Authentication Response message also keeps the information private. In addition, the enrollee may include an enrollee bootstrap key of a new curve type desired by the configurator in addition to the information already present in the DPP Reconfiguration Authentication Response specified by DPP R2 [DPP]. This enrollee bootstrap key should preferably be placed in the encrypted portion of the DPP Reconfiguration Authentication Response message. The advantage of this is that the configurator user no longer needs to scan a QR code, touch NFC, etc. in step RS4, making it very user-friendly.

[0094] In step RS4 (Implement New Key Type), the configurator uses either an "NFC touch" to bootstrap, scanning a QR code containing the enrollee's bootstrap URI located or presented on the device itself, printed on the packaging, or printed in the manual, or the configurator may have saved the enrollee's bootstrap URI from a previous configuration of the enrollee or BLE bootstrap. Because touching an NFC tag or scanning a code on the manual or casing can be burdensome for the user, it may be preferable for the user to remember the bootstrap URI when the configurator bootstraps with this enrollee for its initial configuration. If the configurator stored the bootstrap URI from the enrollee from when it first configured it, the configurator preferably knows whether the enrollee bootstrap key is static or not. Only static bootstrap keys can be reused. The DPP bootstrap URI can include a special attribute that indicates whether the bootstrap key is static or not; for example, "D:0;" indicates a static bootstrap key and "D:1;" indicates a dynamic bootstrap key. If the configurator stores all bootstrap URIs or bootstrap keys for a particular enrollee, the configurator should also store the enrollee's identity along with these URIs or keys, so that when a bootstrap URI or key for a particular enrollee is needed, for example in step RS4, the configurator can select a bootstrap URI or key from those stored for this particular enrollee. The DPP protocol key that the configurator receives from the enrollee after bootstrapping in the DPP authentication protocol, and which key it enters as the enrollee network access key in the connector with which it is configuring the enrollee, can serve as a kind of enrollee identity.

[0095] In step RS5 (Bootstrapped), the configurator selects a bootstrap key for the enrollee from the keys denoted "K" or "A" on the desired ECC curve and proceeds with the DPP authentication protocol. The device is then bootstrapped.

[0096] In step RS6 (Authentication), the configurator and enrollee perform an authentication protocol. In the case of DPP, this is the DPP authentication protocol specified in [DPP] and described in connection with step S4 above. Here, the configurator acts as the initiator with respect to DPP authentication request messages and, optionally, if DPP presence announce messages were sent, responds to the enrollee's DPP presence announce messages of step RS3 using the enrollee's new bootstrap key on the new curve.

[0097] In step RS7 (Configuration), the Configurator and Enrollee run the DPP configuration protocol, and the Configurator may wish to use a different, e.g., stronger, curve for the Configurator Signing Key than the one it had to use to sign the C-Connector in step RS2 and that it may have used for the previous configuration of the Enrollee in step RS7. For security reasons, the new Configurator Signing Key needs to be on a curve that is as strong as or stronger than the newly required curve for the Bootstrap Key and NAK.

[0098] In step RS8 (Connection), the enrollee is configured. If it is an AP, it initiates beacons about the new configuration. If it is not an AP, it initiates the DPP network introduction protocol and network access protocol to connect to the newly configured network based on a network access key on a new, possibly stronger curve. The security strength of the resulting Wi-Fi link encryption is based on the strength of the NAK curve used.

[0099] In step RS9 (Complete), the process is completed.

[0100] In another embodiment, the enrollee does not initiate sending DPP Presence Announcement messages in step RS3, but immediately initiates the DPP Authentication protocol as a Responder and waits for the Configurator's DPP Authentication Request message in step RS6.

[0101] In yet another embodiment, the enrollee does not initiate the sending of a DPP Presence Announcement message in step RS3, but rather initiates the DPP authentication protocol in step RS7 as the initiator. While possible, this has the drawback of requiring the enrollee to know the configurator's DPP Bootstrap URI. An enrollee with a rich UI and sensors to obtain the configurator's DPP Bootstrap URI can do this. However, a headless / simple enrollee will have difficulty obtaining the configurator's DPP Bootstrap URI and will need a feature to enable this. In both cases of this embodiment, it is the user's responsibility to ensure that the enrollee can capture the configurator's DPP Bootstrap URI.

[0102] The method is suitable for configuring an enrollee device for communication in a wireless network. The method is configured to be executed by a configurator device and an enrollee device, the configurator device and the enrollee device being configured to communicate using a wireless communication protocol and to participate in a configuration protocol, the configuration protocol being configured to configure the enrollee device to communicate in the wireless network, the enrollee device being pre-configured to communicate in the wireless network. The method includes executing the configuration protocol, the configuration protocol including transmitting, by the configurator device using the wireless communication protocol, a message including an indication of a selection of a public key type, the public key type being selected by the configurator device from multiple types of public keys obtained from the enrollee device, the selected public key type being to be used for a particular purpose, the selected public key type being different from a previous type of public key used by the enrollee device for the same particular purpose as part of a previous configuration of the enrollee device to communicate in the wireless network.

[0103] This allows the configurator and enrollee devices to agree on a new type of key, preferably a stronger key in cryptographic terms, and complete the bootstrap and authentication protocol. In many situations, the enrollee device is configured to "lock out" further configuration once it has been successfully configured. Such measures provide some security from the network in that they prevent malicious devices from using reconfiguration of devices in the network as a method to gain access. Thus, a user who wants to reconfigure the network to use stronger encryption must reset these enrollee devices. This is cumbersome in itself, but can become even more problematic due to the fact that some devices are installed in remote or difficult-to-access locations (e.g., lighting fixtures). This method also allows the reconfiguration to occur using improved strength encryption from the beginning, as opposed to initiating the reconfiguration using an existing, less strong configuration.

[0104] In one embodiment, the message triggers the resumption of the authentication protocol between the configurator device and the enrollee device. By executing a new authentication protocol, the enrollee and configurator private keys may then be exchanged using improved strength cryptography.

[0105] In one embodiment, the public key of the type of public key is a Device Provisioning Protocol (DPP) bootstrap, network access or protocol key.

[0106] In one embodiment, the configurator device compares the public key type to an indication of the public key type stored during a previous configuration of the enrollee device.

[0107] In one embodiment, the configurator device selects an enrollee bootstrap key for use in the resumed authentication protocol, the enrollee bootstrap key being obtained during a previous configuration of the enrollee device to communicate in a wireless network. This allows the configurator to select a new type of key without the potentially burdensome reacquisition of the types of public keys the enrollee device may use. For example, this can avoid having to scan multiple QR codes.

[0108] In one embodiment, the enrollee device responds to a message from the configurator device that includes an indication of the selection of the public key type, and the response message includes the enrollee's ID used during a previous configuration of the enrollee device, and the configurator uses this ID of the enrollee to select the enrollee key.

[0109] This allows the configurator device to automatically select an enrollee key when there are multiple enrollee keys and key types. This feature may also provide additional security in that a warning may be provided to the user if the ID is not recognized as one previously configured. This may occur as a result of a malicious device attempting to join the network or as a result of user error (e.g., the enrollee device is not actually configured). The user can then check for the problem and, if applicable, initiate an entirely new configuration by using appropriate out-of-band methods.

[0110] In one embodiment, the enrollee device sends a message containing a cryptographic hash of information including the enrollee key, and thus authentication proceeds.

[0111] In one embodiment, the enrollee device is a simple device. This method allows for automatic reconfiguration of simple or even headless devices without the cumbersome requirement of manually resetting such devices.

[0112] In one embodiment, the message from the configurator device includes an indication that the selection of the public key type is a new selection. This allows the message to be processed by both enrollee devices according to one embodiment and legacy enrollees. In such a case, an enrollee device according to one embodiment is reconfigured with a public key of the new type, while legacy devices can continue with the public key type they are using. This may be useful in networks where lower security devices may be tolerated because they have limited roles.

[0113] In one embodiment, an enrollee device 4, 5 is configured to be reconfigured by a configurator device 9 for communication in a wireless network. The enrollee device 4, 5 may be configured to participate in a configuration protocol configured to configure an unconfigured enrollee device. The enrollee device 4, 5 provides multiple types of public keys configured for use in the configuration protocol, provides at least one public key for each type of public key provided, connects to the network as a result of being configured, and sets itself to a configurable state as a result of being unable to connect to the network. The enrollee device 4, 5 receives a message using a public key of a type selected by the configurator device from the multiple types of public keys in the configuration protocol, and receipt of the message restarts the authentication protocol between the configurator device and the enrollee device. This allows the enrollee device to participate in the reconfiguration without manual reset and without exchanging secret keys over a connection using less secure encryption.

[0114] In one embodiment, the enrollee device 4, 5 may be configured to respond to a message from the configurator device 9 with a response message comprising an indication of the enrollee device's ID used during a previous configuration of the enrollee device.

[0115] A configurator device 9 according to an embodiment is configured to reconfigure an enrollee device 4, 5 for communication in a wireless network, the device having a transceiver configured to transmit and receive according to a communication protocol, the device being configured to participate in the configuration protocol, obtain from the enrollee device an indication of multiple types of public keys to be used as part of the configuration protocol, and select a public key type from the indication, wherein the selected public key type is to be used for a particular purpose, and the selected public key type is different from a public key type used by the enrollee device for the same particular purpose as part of a previous configuration of the enrollee device to communicate in the wireless network, and the device is configured to use the transceiver to send to the enrollee device a message including an indication of the public key type selected by the configurator device from the multiple types of public keys.

[0116] A configurator device 9 so configured may be capable of automatically detecting when an enrollee device is ready to engage in reconfiguration with the enrollee device according to one embodiment. The configurator device 9 may select a new type of key, such as a new curve, without the need for manual user intervention, such as scanning multiple QR codes. Notably, this avoids the user having to engage in a trial-and-error process of finding a new curve for bootstrap that the enrollee device can accept.

[0117] In one embodiment, the configurator device is configured to obtain and store multiple types of public keys and at least one public key according to the type of public key obtained during a previous configuration of the enrollee device to communicate in the wireless network.

[0118] In one embodiment, the configurator device 9 may be configured to select a public key from a plurality of stored public keys. An advantage of having the configurator store the key type for future use is that it avoids the user having to find information (such as a QR code) associated with the enrollee device, which may be difficult to find after the initial installation.

[0119] In one embodiment, the configurator device is configured to receive and process a response message from the enrollee device, the response message including an indication of the enrollee device identification information for selecting a public key type from a plurality of stored types of public keys.

[0120] An advantage of a system consisting of a configurator device and an enrollee device according to one embodiment is that it allows a network including an enrollee device to upgrade its security, i.e., strengthen encryption, in a convenient manner, especially when the enrollee is a simple device. "Convenient" may be understood as the enrollee being able to be reconfigured to connect to a network without cumbersome manual intervention on the part of a user on the enrollee device.

[0121] FIG. 4a illustrates a computer-readable medium 1000 having a writable portion 1010 containing a computer program 1020, the computer program 1020 including instructions for causing a processor system to perform one to three or more of the above-described methods and processes, as described with reference to FIG. 1. The computer program 1020 may be embodied on the computer-readable medium 1000 as a physical mark or by magnetization of the computer-readable medium 1000. However, any other suitable embodiment is also contemplated. Furthermore, while the computer-readable medium 1000 is illustrated here as an optical disk, it will be understood that the computer-readable medium 1000 may be any suitable computer-readable medium, such as a hard disk, solid-state memory, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 includes instructions for causing a processor system to perform the above-described methods.

[0122] FIG. 4b shows a schematic diagram of a processor system 1100 according to an embodiment of the apparatus or method described with reference to FIGS. 1 to 3. The processor system may include a circuit 1110, e.g., one or more integrated circuits. The architecture of the circuit 1110 is shown schematically in the figure. The circuit 1110 includes a processing unit 1120, e.g., a CPU, for executing computer program components to perform a method according to an embodiment and / or to implement its modules or units. The circuit 1110 includes a memory 1122 for storing program code, data, etc. Part of the memory 1122 may be read-only. The circuit 1110 may also include a communication element 1126, e.g., an antenna, a transceiver, a connector, or both. The circuit 1110 may also include a dedicated integrated circuit 1124 for performing some or all of the processing defined in the method. The processor 1120, the memory 1122, the dedicated IC 1124, and the communication element 1126 may be connected to each other via an interconnect 1130, e.g., a bus. The processor system 1110 may be configured for wired and / or wireless communication using connectors and / or antennas, respectively.

[0123] Both the configurator and enrollee devices must process the adapted messages and therefore be programmed to parse the messages 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 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 discouraged, especially when the battery is small and intended to last a long time. Finally, changing the protocol often involves other modifications to enable processing of legacy devices.

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

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

[0126] 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 [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 5297]Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES), October 2008, https: / / datatracker.ietf.org / doc / rfc5297 / . [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, comprising: The method is configured to be performed by a configurator device and an enrollee device, the configurator device and the enrollee device being configured to communicate using a wireless communication protocol and to participate in a configuration protocol, the configuration protocol being configured to configure the enrollee device to communicate in the wireless network, the enrollee device having previously been configured to communicate in the wireless network, the method comprising: executing a configuration protocol, the configuration protocol including transmitting, by the configurator device using the wireless communication protocol, a message having an indication of a selection of a public key type, the public key type being selected from a plurality of public key types obtained by the configurator device from the enrollee device; The method, wherein the type of selected public key is for use for a specific purpose, and the type of selected public key is different from a previous type of public key used by the enrollee device for the same specific purpose as part of a previous configuration of the enrollee device to communicate in the wireless network.

2. The method of claim 1 , wherein the message restarts an authentication protocol between the configurator device and the enrollee device.

3. 3. The method of claim 1, wherein the public key of said type of public key is a Device Provisioning Protocol (DPP) bootstrap key, a network access key or a protocol key.

4. 3. The method of claim 1, wherein the configurator device compares the type of public key with an indication of the type of public key stored during a previous configuration of the enrollee device.

5. the configurator device selecting an enrollee bootstrap key for use in the resumed authentication protocol; The method of claim 1 , wherein the enrollee bootstrap key is obtained during a previous configuration of the enrollee device to communicate in the wireless network.

6. the enrollee device responding to a message from the configurator device with an indication of a selection of a public key type; the response message includes the enrollee device's ID used during a previous configuration of the enrollee device; the configurator device uses the ID of the enrollee device to select the enrollee key; The method of claim 4.

7. the enrollee device sending a response message to the message from the configurator device that includes an indication of a selection of a public key type; the response message includes an enrollee key of a type present in the indication of a public key type selection; 5. The method of claim 4, wherein the configurator device and the enrollee device use the enrollee key during a resumed authentication protocol between the configurator device and the enrollee device.

8. The method of claim 1 , wherein the enrollee device sends a message comprising a cryptographic hash of information comprising an enrollee key.

9. 9. The method of claim 1, wherein the enrollee device is a simple device.

10. 10. The method of claim 1, wherein the message from the configurator device includes an indication that the selection of the type of public key is a new selection.

11. The method according to any one of claims 1 to 10, wherein the configuration protocol is in accordance with the Device Provisioning Protocol (DPP).

12. an enrollee device configured to be reconfigured by a configurator device to communicate in a wireless network, participate in a configuration protocol configured to configure an unconfigured enrollee device; providing a plurality of types of public keys configured to be used in the establishment protocol, providing at least one public key for each type of public key provided; As a result of the configuration, you will connect to the network. setting itself to a state that can be set as a result of being unable to connect to said network; receiving a message from the configurator device; configured to use a public key type selected by the configurator device from the plurality of types of public keys in the configuration protocol; An enrollee device, wherein receipt of the message causes resumption of an authentication protocol between the configurator device and the enrollee device.

13. 13. The enrollee device of claim 12, configured to respond to said message with a response message having an indication of an identity of said enrollee device, said identity of said enrollee device being used during a previous configuration of said enrollee device.

14. configured to send a response message to a message from the configurator device having an indication of a selection of a type of public key, the response message including an enrollee key of a type present in the indication of a selection of a type of public key; the enrollee device is configured to use the enrollee key during the resumed authentication protocol between the configurator device and the enrollee device.

14. An enrollee device according to claim 12 or 13.

15. 15. An enrollee device according to any one of claims 12 to 14, which is a simple device.

16. 1. A device configured to operate as a configurator device and configured to reconfigure an enrollee device for communication in a wireless network, the device having a transceiver configured to transmit and receive according to a communication protocol, the device comprising: Participate in the configuration protocol, obtaining from the enrollee device an indication of a plurality of types of public keys to be used as part of the establishment protocol; configured to select a type of public key from the indicator; the type of public key selected is to be used for a specific purpose, and the type of public key selected is different from the type of public key used by the enrollee device for the same specific purpose as part of a previous configuration of the enrollee device to communicate in the wireless network; The apparatus is further configured to send, using the transceiver, a message to the enrollee device having an indication of a public key type selected by the configurator device from the plurality of types of public keys.

17. 17. The device of claim 16, wherein the message causes a resumption of an authentication protocol between the configurator device and the enrollee device.

18. 18. The device of claim 16 or 17, configured to acquire and store the plurality of types of public keys and at least one public key of a type acquired during previous configuration of the enrollee device to communicate in a wireless network.

19. 19. An apparatus according to any one of claims 16 to 18, configured to select a public key from the stored plurality of public keys.

20. the enrollee device is configured to send a response message to a message from the configurator device having an indication of a selection of a type of public key, the response message including an enrollee key of a type present in the indication of a selection of a type of public key; 20. The apparatus of claim 16, wherein the enrollee device is configured to use the enrollee key during a resumed authentication protocol between the configurator device and the enrollee device.

21. 21. The apparatus of claim 16, wherein the configurator device is configured to receive and process a response message from the enrollee device, the response message having an indication of an enrollee device ID for selecting a public key type from the stored plurality of types of public keys.

22. 22. Apparatus according to any one of claims 16 to 21, wherein the configurator device is configured to include an indication that the selection of a public key type is a new selection.

23. A system comprising an enrollee device according to any one of claims 12 to 15 and an apparatus according to any one of claims 16 to 22.

24. A computer program product which, when executed by a processor of an enrollee device, causes the enrollee device to carry out the method of any one of claims 1 to 11.

25. A computer program product which, when executed by a processor of a configurator device, causes the configurator device to carry out the method of any one of claims 1 to 11.

Images