Secure Change of Encryption Strength during Reconfiguration

Abstract

A method, a configurator, an enrollee device, and systems thereof are provided. The method is one of configuring an enrollee device for communication in a wireless network, the method being configured for execution by a configurator device and an enrollee device. The configurator device and the enrollee device may be 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 comprising transmitting, by the configurator device, a message including an indication of a selection of an open key type, the public key type being selected from a plurality of types of public keys obtained from the enrollee device, the selected public key type being for use for a specific purpose, the selected public key type being different from a previous public key type used by the enrollee device for the same specific purpose as part of a previous configuration of the enrollee device to communicate in a wireless network.

Description

Technical Field

[0001] The present invention relates to an apparatus and method for use in a wireless network, particularly a wireless network compliant with the IEEE 802.11 standard family.

Background Art

[0002] FIG. 1 shows 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), a hub, or a gateway device. The first device 2 is hereinafter referred to as an AP for simplicity, but other types of devices are also actually possible. A user (not shown) wishes to add two more devices to the network 1, namely a complex device 4 (represented here as a computer) and a simple device 5 (represented here as a toothbrush). Devices such as the simple device 5 often do not have 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, and 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 that based on IEEE 802.11, but other technologies may also be suitable.

[0003] In some wireless network standards, one device can configure another device in order to establish a connection and communicate. This eases the burden of the task of adding or registering new devices to the network in that the user no longer needs to perform manual input. A device that requires configuration to participate in the network may sometimes be called an "Enrollee", and a device that performs the configuration may sometimes be called a "Configurator".

[0004] It is desirable to establish trust between a configurator, an enrollee, and ultimately the network to which the enrollee will be connected. "Trust" in this context can be understood to mean that the configured device is the intended device and that no other malicious device can interfere with the connection. For this purpose, communication is often encrypted.

[0005] Diffie-Hellman (see Reference [DH]) is a well-known technique for establishing a secret key between two parties such that the communication between the parties for establishing the secret key does not disclose any information about the established secret key to a third party. Each of the two parties uses its own public / secret key pair and exchanges the public keys with each other. Each party can calculate the secret key using its own secret key, the other party's public key, and optionally other information such as a nonce (random number) from each party. Each party can generate a new key pair each time it executes Diffie-Hellman or reuse an old key pair.

[0006] The Wi-Fi Alliance's Device Provisioning Protocol (DPP) (see Reference [DPP]) uses Diffie-Hellman to establish a secret key between two devices, a DPP enrollee that is desired to be configured and a DPP configurator that can configure the DPP enrollee, and these devices can access a DPP-compliant network or configure a DPP-compliant network as an access point (AP) (see Reference [802.11]).

[0007] When performing Diffie-Hellman over a network, a device that receives a public key for performing Diffie-Hellman does not know from which device this public key is. This can be exploited by an attacker in a so-called man-in-the-middle attack. The attacker E may impersonate the actual device B that device A wants to connect to. The attacker E performs Diffie-Hellman with device A and establishes a secret key Kae with device A. Similarly, the attacker impersonates device A to device B and establishes a secret key Kbe with device B. When a message arrives from one of device A or B, the attacker decrypts the message with one secret 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 when checking the communication by transmitting the same information in another communication method and comparing the results, those devices do not notice any tampering of their communication. However, the attacker has complete knowledge of what is being communicated. ` One way to prevent man-in-the-middle attacks and ensure reliability is to use an additional protocol, so-called out-of-band (OOB) communication, to exchange the public key or a hash of the public key. 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], near-field communication [NFC]. Alternatively, the OOB communication may involve obtaining the public key by a technique such as a configurator scanning a QR device associated with an enrollee device, and then decrypting the public key.

[0008] In this way, the user of the device can verify the association between the QR code and the enrollee, or since the enrollee is within the operating range of the OOB communication protocol, it can be known that the public key received via OOB is from the intended device. When the hash of the public key is exchanged via OOB, the device can check whether the public key received via the communication protocol that requires encryption results in the same hash as the hash received via OOB. Note that the use of the term communication protocol in this specification 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 DPP (Device Provisioning Protocol) (https: / / www.wi-fi.org / downloads-public / wi-fi_Easy_Connect_Specification_v2.0.pdf / 35330)). This protocol is also known by the name Wi-Fi Easy Connect.

[0010] In DPP, elliptic curve cryptography [RFC 6090] is used for all asymmetric cryptography, particularly for the network access key (NAK) and the configurator signature key. The essential condition for supporting the ECC curve is P-256.

[0011] Suppose the enrollee (AP or a Wi-Fi device that can be associated with the AP) is configured by the Wi-Fi Easy Connect Release 2 configurator using the ECC curve P-256 for the network access key (netAccessKey or NAK). This means that the enrollee has used the P-256 bootstrap key. This is because these two curves need to be the same in DPP R2. The configurator may have used a curve different from P-256 for its signature key.

[0012] The user wishes to upgrade the security of the network such that P-256 is no longer used and instead a stronger curve is used. That is, the AP and all devices permitted on its network need to be newly configured. Or the user wishes to create a DPP network using another curve that is preferably stronger than necessary to implement P-256, such as P-384.

[0013] The requirement to manage security upgrades means that in addition to how simple devices handle new requirements, a way to handle new keys / key types is needed. In particular, the DPP protocol does not provide for a "security upgrade" scenario.

Summary of the Invention

Problems 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, including executing a configuration protocol.

Means for Solving the Problems

[0015] A method for configuring an enrollee device for communication in a wireless network is provided. The method is configured to be executed by a configurator device and an enrollee device, the configurator device and the enrollee device communicate using a wireless communication protocol and are configured to participate in a configuration protocol, the configuration protocol is configured to configure the enrollee device to communicate in the wireless network, and the enrollee device is previously configured to communicate in the wireless network. The method includes executing a configuration protocol, the configuration protocol including transmitting, by the configurator device, a message using the wireless communication protocol, the message including an indicator of a selection of a type of public key, the type of public key being selected, by the configurator device, from a plurality of types of public keys obtained from the enrollee device, the selected type of public key being used for a particular purpose, and the selected type of public key 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 for communication in the wireless network.

[0016] This allows the configurator and the enrollee device to agree on a new type of key, preferably a more powerful key in cryptographic terms, and complete the bootstrap and authentication protocols. In many situations, the enrollee device is configured to "lock out" further configuration when successfully set. Such means provide some security from the network in that it prevents malicious devices from using the reconfiguration of devices within the network as a way to gain access. Thus, a user who wishes to reconfigure the network to use stronger encryption must reset these enrollee devices. This is itself cumbersome, but can be made even more problematic by the fact that some devices are installed in remote or hard-to-access locations (e.g., lighting fixtures). The method also allows for the reconfiguration to be performed using improved strength encryption from the start, as opposed to starting the reconfiguration using existing, less strong settings.

[0017] In one embodiment, a message causes a restart of the authentication protocol between the configurator device and the enrollee device.

[0018] By a new execution of the authentication protocol, the authentication of the enrollee and the configurator can then be performed using improved strength encryption.

[0019] In one embodiment, the public key of the public key type 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 indicator of the public key type stored during the previous configuration of the enrollee device.

[0021] In one embodiment, the configurator device selects an enrollee bootstrap key for use with the resumed authentication protocol, and the enrollee bootstrap key is obtained during previous settings of the enrollee device for communicating over a wireless network.

[0022] Thereby, the configurator can select a new type of public key without the potentially burdensome reacquisition of the type of public key that the enrollee device can use. 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 indicator of the selection of the type of public key, and the response message includes the enrollee ID used during previous settings of the enrollee device, and the configurator uses the enrollee ID to select the enrollee key.

[0024] Thereby, the configurator device can automatically select the enrollee key when there are keys and key types for multiple enrollees. This feature can also provide additional security in that a warning can be provided to the user if the ID is not recognized as having been previously set. This can occur as a result of a malicious device attempting to join the network or simply as a result of a user-side error (e.g., the enrollee device was not actually set up). The user can then check the problem and, if applicable, initiate a completely new setup by using an appropriate out-of-band method.

[0025] In addition, for information already present in the DPP reconfiguration authentication response defined by DPP R2[DPP], the enrollee can also include the enrollee bootstrap key of the newly desired curve type by the configurator. This enrollee bootstrap key should preferably be placed in the encrypted part of the DPP reconfiguration authentication response message. The advantage is that the user of the configurator does not need to scan a QR code or touch NFC, which is very user-friendly.

[0026] In one embodiment, the enrollee device transmits a message including an encrypted hash of the information including the enrollee key. Authentication proceeds in this way.

[0027] In one embodiment, the enrollee device is a simple device. This method enables the automatic reconfiguration of simple or 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 enables this message to be processed by both the enrollee device according to one embodiment and the legacy enrollee. In such a case, the enrollee device according to one embodiment is reconfigured with a new type of public key, while the legacy device can continue with the key of the type it was using. This can be useful in networks where lower security devices have a limited role since they can be tolerated.

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

[0031] An enrollee device configured to participate in a configuration protocol, the configuration protocol providing a plurality of types of public keys configured to participate in the configuration protocol and configured to be used in the configuration protocol, providing at least one public key for each type of public key provided, configured to connect to a network, as a result, being able to connect to the network, as a result, being set to a state where it cannot receive messages, configured to use, in the configuration protocol, the type of public key selected by a configurator device from the plurality of types of public keys, and the receipt of a message causing a restart of an authentication protocol between the configurator device and the enrollee device, is also provided.

[0032] Thereby, the enrollee device can participate in the reconfiguration without performing a manual reset and without performing a private key exchange via a connection using low-security encryption.

[0033] In one embodiment, the enrollee device is configured to respond to a message with a response message including the ID of the enrollee device used during the previous configuration of the enrollee device in an indication of the ID of the enrollee device.

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

[0035] Also provided is a device configured to operate as a configurator device and configured to reset 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 being arranged to participate in a configuration protocol to perform the following: obtain from the enrollee device a plurality of types of public key indicators to be used as part of the configuration protocol; select a public key type from the indicators, where the selected public key type is to be used for a specific purpose and is different from the public key type previously 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; and transmit a message to the enrollee device using the transceiver, the message having an indicator of the public key type selected from the plurality of types of public keys by the configurator.

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

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

[0038] In one embodiment, the configurator device is configured to obtain and store a plurality of types of public keys and at least one public key according to the public key type obtained during the previous configuration of the enrollee device for communication 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 store the key type for future use is that the user does not need to find information related to the enroll 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 enroll device, the response message including an indicator of enroll device identification information for selecting a public key type from a plurality of stored public key types.

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

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

[0044] Also provided is a computer program product that, when operating on a processor within the enroll device, causes the enroll device to execute a method according to one embodiment.

[0045] Also provided is a computer program product that, when operating on a processor within the configurator device, causes the configurator device to execute a method according to one embodiment.

Brief Description of the Drawings

[0046] The above and additional objects, features, and advantages of the disclosed devices, systems, and methods will be better understood through the following illustrative and non-limiting detailed description of embodiments of the devices and methods with reference to the accompanying drawings.

Figure 1

Figure 2

Figure 3

Figure 4a

Figure 4b

Best Mode for Carrying Out the Invention

[0047] In the following description, the same reference signs refer to the same elements.

[0048] As an example, the case of a simple device 5 will be described. Although much of this description provides examples including networks with devices such as AP 2, it should be understood that this process may function in a peer-to-peer situation. This configuration flow can be used to configure a device that is in an unconfigured state or that cannot yet be connected.

[0049] As an example of a configuration method controlled by a device, there is a Device Provisioning Protocol (DPP) used in a network using Wi-Fi or IEEE 802.11. In the Device Provisioning Protocol (DPP), a device functioning 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 starts with the two devices 9 and 5 not connected and the device 5 not configured. For the sake of discussion, device 9 is used to configure device 5 to participate in the wireless network 1. Thus, device 9 is sometimes called the Configurator, and device 5 may be called the Enrollee (as it is "enrolled" in the wireless network 1).

[0051] In S2 (Bootstrapping), often called "bootstrapping", one device, the Initiator, obtains the bootstrapping public key (BR) of the other device, the Responder. If the Responder device desires mutual authentication, it also obtains the Initiator's bootstrapping public key (BI). This is achieved by a method separate from the wireless communication technology and is called so-called "out-of-band" (OOB) communication. Examples of this can be the user having a certain device read the QR code on the Responder, NFC communication between two devices, or other wireless technologies (such as Bluetooth). The bootstrapping process is initiated by the user's intervention. If the bootstrapping is successful, the process reaches S3 (Bootstrapped), and devices 10, 5 are "bootstrapped". Otherwise, it returns to the "start" state at S1. In either case, the enrollee device (in this case, simply device 5) can record the result of the bootstrapping process in a suitable storage device, for example, as a flag in a register within the memory. Often, simple devices are programmed to turn on the wireless on the channel indicated by the QR code for configuration after manufacturing or reset and start listening for authentication request messages.

[0052] In S4 (Authentication), devices 9, 5 execute an authentication procedure, whereby the devices establish "trust", i.e., the user can be confident that they are devices that can be trusted and are not "posing as" one or the other of these devices, other unknown (and potentially malicious) devices. A message requesting the start of authentication is sent from one device. This message can be sent by either the device that performs the configuration (configurator) or the device to be configured (enrollee). In this example, the third device 9 functions as the configurator and the simple device 5 functions as the enrollee. Although the third device 9 is shown as being connected to the network 1, it should be noted that this is not necessarily required for the embodiment to function. The device that initiates wireless communication is called the initiator, and the device that responds is called the responder. In particular, the DPP protocol enables both the configurator and enrollee devices to act as initiators of the DPP protocol, whereby other devices automatically become responders. Simple or headless devices usually play the role of the responder.

[0053] Another device responds to this message. If the authentication request message is correctly decoded and contains information indicating that the initiator is a device that the responder device trusts and has the necessary functions, the response message indicates that the message has been "accepted" and contains the information necessary for the initiator to verify the responder's qualification information and also indicates that it has the necessary functions. If the two devices do not receive the necessary information from the other device, the process is interrupted and the devices return to the bootstrapped state of S3. If the initiator is the enrollee, the authentication request message may also include an additional part indicating the result of previous attempts to configure the enrollee. If the responder is the enrollee, the authentication response message may include an additional part indicating the result of the previous attempt. It should be understood that the indicator also shows whether there were previous attempts.

[0054] In the case of the DPP protocol, the first message is an authentication request message, and the response message is a DPP authentication response. The responder checks whether the DPP authentication request message contains the encrypted hash of the correctly generated responder public bootstrap key or has a copy of the initiator's public bootstrap key. The responder sends a DPP authentication response message indicating whether authentication can continue. For example, if the process cannot continue because the attempt to decrypt the encrypted nonce in the DPP authentication request message fails, the process is aborted. The DPP authentication response may include the encrypted hash of the responder public bootstrap key and may include the hash of the initiator public bootstrap key. Similarly, for the initiator, the enroller may obtain this public key by OOB communication. Thereafter, the initiator's public bootstrap key can be used for mutual authentication. Without the initiator's public bootstrap key, only the initiator can authenticate the enroller, but not vice versa.

[0055] If the authentication response message indicates that the responder has 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 relevant device, this part of the protocol, the authentication part, is successful, and the process reaches S5 (Authenticated) and the setup can begin. The confirmation message may also include an indicator of the result of previous setup attempts where the enroller 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 having information regarding which type of settings the enrollee desires. If the configurator can permit the request, it sends a message including information required by the enrollee, such as a network key. In a variant, the configuration request may also include an indicator of the result of a previous configuration attempt.

[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 connects and may include a DPP connector. The DPP connector is digitally signed by the configurator using a key (C-sign key) and includes, among other things, the enrollee's public network access key. The configurator may obtain the enrollee's public network access key from a DPP authentication response message previously sent by the enrollee, and in this message, this key is called the responder's public protocol key. When DPP authentication is successful, the responder's public protocol key is renamed to the enrollee's public network access key, indicating the new purpose of the protocol. The DPP Configuration Response message also includes the public signature key of the configuration. Other devices configured by the same configurator can thereby confirm whether they can trust the public network access keys of other devices. The DPP Configuration Response message may also include the Wi-Fi passphrase or Pre-Shared Key (PSK) of the network. The enrollee sends a DPP configuration result message (depending on the version of DPP) to the configurator to indicate whether it accepts the configuration. The configurator not receiving this message can indicate to the configurator that there is a Wi-Fi problem between the configurator and the enrollee. Next, the enrollee, which "thinks it is configured", can send its connector to DPP Configuration AP 2. If the connector signature is detected as correct and there is a matching connector at AP 2 (a connector of the same network signed by the same configurator), AP 2 sends its connector to the enrollee. The enrollee and AP 2 can calculate a symmetric key based on the mutual network access keys in the connector and their own private network access keys using the Diffie-Hellman method.

[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 way through the 4-way handshake as specified in [802.11]. If the connection attempt is successful, the flow proceeds to S8 (Complete) where it completes.

[0059] In the case of DPP, the actual public keys, for example, specific P-256 keys, usually include the type of public key within a structure that contains the public key when they are transferred within a message. An example of an elliptic curve public key represented as an ASN.1 structure called SubjectPublicKeyInfo as defined 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 the type of public key, while the BITSTRING contains the value of this specific public key.

[0061] Currently, especially 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 in the following format: "K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;", Here, the characters between ":" and ";" are an ASN.1 SEQUENCE SubjectPublicKeyInfo encoded in base64 from [RFC 5280]. Decoding and prettifying the bootstrap key representation in the above example gives: 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 executed using the apparatus according to an embodiment, the bootstrap URI is extended so that additional bootstrap keys can be added in a backward-compatible manner, where all additional bootstrap keys use different ECC curves. This can be done in a series of one or more attributes that appear anywhere previously, similar to the existing attribute indicated by "K" in the DPP bootstrap URI, but for the P-384 bootstrap key, for example, as follows, instead indicated by, for example, "A": "A:MEYwEAYHKoZIzj0CAQYFK4EEACIDMgADBJL3omc4bW2UHu7FaOs8Tgy0pXL / J6NXgcD9YYxfkWlSjXvesPGekHMI04f7+Pe9;" If we decrypt the bootstrap key representation of the above example and display it neatly, it will be 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, especially for network access keys (NAKs) and the configurator signature keys. However, other forms of asymmetric cryptography are also possible, such as the multiplicative group of integers modulo q as described in [DH], where q is a prime number (referred to in [DH] as the "finite field GF(q)" with prime element q), and α is a primitive root modulo q (referred to in [DH] as the "fixed primitive element of GF(q)"). All public keys generated with the same values of q and α are considered the same type of public key for the purposes of this specification. Similarly, all public keys that are points on the same elliptic curve are also considered the same type. Public keys using different encryption algorithms, such as ECC and the multiplicative group of integers modulo q, are considered different types of public keys. Public keys that use the same encryption algorithm but have at least one of the defining parameters with a different value are considered different types of public keys for the purposes of this specification. For example, the defining parameters are q and α for the multiplicative group of integers modulo q, and the elliptic curve is the defining parameter for the ECC algorithm. In addition to using the OBJECTIDENTIFIER shown in the above example, the representation of the elliptic curve can be given or obtained using the element group containing the Finite Cyclic group attribute as defined 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 type of the public key of the network access key at the connector of the enrollee.

[0064] For the purposes of the present disclosure, it should be noted that selecting, comparing, providing, obtaining, receiving, etc. the type of public key is also achieved when selecting, comparing, providing, obtaining, receiving, etc. a structure including the public key and the type of the public key, or a blob of data. Examples of such a structure or blob of data are presented herein.

[0065] For some reason, the enrollee may fail to connect. In the case of the complex device 4, the enrollee can display a message to the user, make the user aware of the status, and instruct the user on how to solve the problem. However, the simple device 5 does not have a UI. If the connection is not successful, it will give up the attempt after the timeout period in which it is programmed, unless it is further programmed.

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

[0067] When receiving the status message, if it is indicated that the status is other than Status_OK in the DPP Connection status, the configurator responds with a response message including the updated (or new) settings, and the enrollee retries the connection to the network. For DPP, in this S11, there may be an execution of the DPP configuration protocol and the DPP introduction protocol. If this connection is successful, the flow ends at S8 (Complete).

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

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

[0070] The user can always intervene manually and reset the simple devices, but this can be very inconvenient in that many of these devices will be installed in hard-to-reach locations (e.g., a light bulb in a ceiling socket). Therefore, it is not desirable to require the user to manually reset all of these simple devices, and a configurator-based solution is highly desirable.

[0071] In the case of DPP, there are also other problems. The DPP Bootstrapping URI can currently contain only one public key in accordance with the DPP R2 specification [DPP]. Devices that support two or more ECC curves need to present two or more bootstrap keys in some form in two or more QR codes. To transfer multiple DPP bootstrap keys, multiple Alternative Carrier Records each containing one DPP bootstrap URI are put into the NFC handover request message or the NFC handover selection message (see section 5.4 "NFC" of [DPP]).

[0072] It is actually possible to have two or more QR codes for two or more ECC curves, but using this solution is cumbersome for the user. The user must somehow keep track of which QR code to scan so as to actually scan the QR code corresponding to a more secure key / key type.

[0073] A possible solution for DPP could be to modify the DPP configuration protocol such that the configurator performs bootstrapping using P-256 and executes the DPP authentication protocol using P-256, while the configurator requests the enrollee to first create a new Network Access Key (NAK) using another, preferably stronger curve, such as P-384 or P-521. The enrollee that supports this new curve does so and supplies that new NAK in the adapted DPP configuration protocol, proving to the configurator that it owns the private key belonging to that new NAK. If successful, the configurator puts that new enrollee NAK into the DPP connector, and in some cases signs this connector using a new, for example stronger curve, signature key, and sends the new connector, possibly together with a new configurator public signature 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 being sent over a connection that was bootstrapped using the very encryption that was just determined to be insufficient.

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

[0076] Before the configuration protocol is initiated, devices 4, 5 should be in a state where they can participate in the protocol. Simple devices, such as device 5, are often not programmed to respond to a reset request if they “think” they are properly configured and connected. Many devices, such as simple device 5, are configured to hold only one configuration at a time. Further, many are manufactured without a configuration but are programmed to reject or ignore subsequent configuration attempts once they have been configured. For example, a “configuration block” is a flag that is referenced each time a configuration attempt for the device occurs. This behavior is similar to the process of imprinting on a particular animal, whereby a young animal learns to recognize another individual as its “mother” if it sees that individual at a particular point in time. Once imprinted, the young animal rejects other individuals as its mother. To reset such a device, some sort of reset is required to remove the flag that prevents the device from participating in the configuration process. Such a flag can be a status flag that simply has a value indicating either “configured” or “not configured”. Also, simple devices may be preconfigured for communication by some means other than the configuration protocol, such as being configured at the factory. In this example, devices 9 and 4, 5 are according to an embodiment.

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

[0078] Another possible way is to simply change the security settings on the network on the side of AP 2 (or in the case of a peer-to-peer network, another complex device). If the security settings are changed in AP 2, for example, 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. Next, devices 4 and 5 are ready to bootstrap with the new key / key type. In the case of DPP, it can send a DPP reset notification in the following format: Enrollee -> Configurator: SHA256(C-sign-key), group, A-NONCE, E'-id Here, ?A-NONCE and E'-id are points on the curve of the configurator signature key (C-sign-key). ?group indicates the elliptic curve of the enrollee network access key that previously received the connector.

[0079] The configurator signature key for this step is the key with which the configurator provisioned the enrollee during a previous initial setup or previous reset, thereby signing the connector. 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 bootstrap via Near Field Communication (NFC), devices 4, 5 turn on their NFC radios.

[0081] In the case of bootstrap via BluetoothTM (BT), e.g., BT Low Energy i.e., BLE, devices 4, 5 start transmitting BT (or BLE) advertisements.

[0082] As described above, currently, especially 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 in the following form: "K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;", Here, the symbols between ":" and ";" are the base64-encoded ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC 5280]. Decoding and prettifying the bootstrap key representation in the above example gives the following: 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 backward-compatible manner, and all the additional bootstrap keys use different ECC curves. This can be done in a series of one or more attributes that appear anywhere previously, all similar to the existing attributes indicated by "K" in the DPP bootstrap URI. For the P-384 bootstrap key, for example, it can be indicated by, say, "A" instead, as follows: "A:MEYwEAYHKoZIzj0CAQYFK4EEACIDMgADBJL3omc4bW2UHu7FaOs8Tgy0pXL / J6NXgcD9YYxfkWlSjXvesPGekHMI04f7+Pe9;" For the P-384 bootstrap key. Decoding and prettifying the bootstrap key representation in the above example gives the following: 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 user of the configurator wants to use a curve for a different enrollee NAK than that indicated by the 'group' attribute of the received DPP reset announce. Therefore, the configurator sends the following response, called a DPP reset authentication request message: Configurator -> Enrollee: TransId, Protocol Version, C-Connector, C-nonce Here, the C-Connector includes a configurator NAK on the newly desired curve rather than on the curve indicated by the enrollee with the "group" attribute. Since the C-Connector is still signed by the signature key owned by the enrollee, it needs to be on the same curve as the attribute A-NONCE and E'-id. This is in contrast to the current DPP R2 standard. It may be advantageous to configure the configurator to maintain a record of the keys / key types used in the previous settings as described above in steps S1 to S8. In this embodiment, this is the previously used curve. The configurator then checks that the new curve is actually stronger, and if this new selection is not stronger than the existing settings, or warns the user, it can perform actions such as aborting the protocol. 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 that is stronger than the one currently in use. As can be easily understood, this curve / key / key type must be used for other elements within the network.

[0085] Legacy enrollees, i.e., enrollees not according to one embodiment, may not be able to continue the DPP reconfiguration authentication protocol at this point. This may be desirable if only devices that support better or other security for the new group are permitted on the network, but may not be desirable if the user still wishes to be able to use legacy devices. In the latter case, the legacy device can be configured to use a network that does not permit access to confidential information.

[0086] Another way to indicate a newly desired curve in the DPP reconfiguration authentication request message's Configurator Connector (C-Connector) is by adding a new JSON attribute-value pair to the DPP Connector that indicates this (e.g., "newGroup" = "P-384"), and by using a Configurator NAK on the curve indicated by the group attribute of the DPP reconfiguration announcement. The advantage of the latter is that legacy enrollments can still be configured since they continue DPP reconfiguration authentication with a NAK on the curve of the group attribute, and perhaps in the latter case, can only be configured for networks that do not provide access to sensitive information. An example of a 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 newly desired curve in the connector in these ways or other ways, the DPP reconfiguration authentication request message is, at this point, protected from forgery by an attacker.

[0088] ​However, an attacker can copy a previously sent C-Connector and use it in a forged message. This can be prevented by adding, as new JSON attribute value pairs within the C-Connector, either or both of two random attributes from a preceding DPP reconfiguration announcement, namely A-NONCE and E'-id. Not all of these bits are required, but it is sufficient to make it highly unlikely that the same combination of bits has been used previously by a configurator using the same signing key. An exemplary DPP Connector Body Object containing the first 16 bits of A-NONCE is as follows. { "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. This can be done because the C-Connector owns the correct public signature key of the configurator. The enrollee confirms that the NAK in the C-Connector is on a different curve from its own NAK. If the enrollee supports that curve, the enrollee cannot continue the DPP reconfiguration authentication protocol by sending a DPP reconfiguration authentication response message. Instead, it resumes the DPP authentication protocol (not shown in Figure 3). The enrollee can do this by selecting that bootstrap key which is on this curve and exists in its bootstrap URI, and starting to send a DPP Presence Announcement message using this bootstrap key, which is in the following format: Enrollee → Configurator: SHA256("chirp" | BR2) Here, BR2 is the enrollee bootstrap key on the new curve. While sending the DPP Presence Announcement message, the enrollee is ready to receive a DPP authentication request message from the configurator as defined in the DPP standard [DPP]. Optionally, the enrollee can simply listen for a DPP authentication request message from the configurator without sending a DPP Presence Announcement message.

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

[0091] A legacy enrollment (i.e., an enrollment not according to an embodiment) aborts the reconfiguration or continues with its "old" NAK, depending on how a new desired curve is shown in the C-Connector. The protocol then ends at this step (Terminate).

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

[0093] Another advantage of adding the new "newGroup" attribute to the C-Connector is that an enrollee implemented according to the present invention can respond in a secure manner using a (possibly adapted) DPP reconfiguration authentication response before restarting the DPP authentication protocol. This response is possible because the Configurator NAK of the connector for the DPP reconfiguration authentication request is on the same curve as the enrollee NAK of the enrollee connector, and the key ke of the encrypted part of the DPP reconfiguration authentication response can be calculated on both devices. This secure response can include the enrollee NAK of the enrollee connector, and using this key, the bootstrap URI of this device used during initialization can be found. This is because this particular enrollee NAK was used as the public protocol key of the enrollee during its initialization. Thus, the enrollee NAK can function as the ID of the enrollee, because the enrollee uses this key from authentication until (and including) the execution of the DPP network introduction protocol to obtain access to the network. The stored bootstrap URI may include a bootstrap key on the curve that the configurator wishes to use. In that case, the user of the configurator 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 proceeds to be set with a new curve and / or a bootstrap key on a new curve with respect to the information already present in the DPP reconfiguration authentication response specified by DPP R2 [DPP]. The additional information may be described anywhere in the DPP reconfiguration authentication response message. This is because the entire content thereof is integrity-protected by AES-SIV (Synthetic Initialization Vector (SIV) Authenticated Encryption Using Advanced Encryption Standard (AES), see [RFC 5297]).When the additional information is put into the encrypted part of the DPP reconfiguration authentication response message, the information also becomes non-public. In addition, for the information already existing in the DPP reconfiguration authentication response defined by DPP R2 [DPP], the enrollee can also include the enrollee bootstrap key of the newly desired curve type by the configurator. This enrollee bootstrap key should preferably be put into the encrypted part of the DPP reconfiguration authentication response message. This advantage is that the user of the configurator no longer needs to scan the QR code, touch the NFC, etc. in step RS4, which is very user-friendly.

[0094] In step RS4 (Implement New Key Type), the configurator uses either "NFC touch" for bootstrapping, scanning a QR code that includes the enrollee's bootstrap URI that is placed or presented on the device itself, printed on the package, or printed in the manual, or the configurator may have saved the enrollee's bootstrap URI when previously setting up the enrollee or BLE bootstrap. Touching an NFC tag or scanning a code on the manual or casing can be a burden for the user, so it would be preferable for the user for the configurator to remember the bootstrap URI when bootstrapping with this enrollee for its initial setup. If the configurator stores the bootstrap URI from the enrollee since it first set up the enrollee, it is desirable for the configurator to know 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 indicating 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 the bootstrap URIs or bootstrap keys for a particular enrollee, the configurator should also store the identification information of that enrollee along with these URIs or keys. Thus, when a bootstrap URI or key for a particular enrollee is required, for example, in step RS4, the configurator can select the bootstrap URI or key from what is stored for this particular enrollee. Which key to input as the DPP protocol key received by the configurator from the enrollee after bootstrap in the DPP authentication protocol and as the enrollee network access key in the connector that the enrollee is trying to set up with it can serve a role such as the ID of the enrollee.

[0095] In step RS5 (Bootstrapped), the configurator selects the enrollee's bootstrap key from the key indicated by "K" or "A" on the desired ECC curve and proceeds to the DPP authentication protocol. Then the device is bootstrapped.

[0096] In step RS6 (Authentication), the configurator and the enrollee execute the authentication protocol. In the case of DPP, this is the DPP authentication protocol defined in [DPP], which was explained in relation to step S4 above. Here, the configurator operates as the initiator regarding the DPP authentication request message and, in some cases, in response to these DPP presence announcement messages of the enrollee in step RS3 when a DPP presence announcement message was sent, uses the new bootstrap key of the enrollee on the new curve.

[0097] In step RS7 (Configuration), the configurator and the enrollee execute the DPP configuration protocol, and the configurator uses, for the configurator signature key, something different from what it had to use to sign the C-Connector in step RS2 and which may have been used for the previous configuration of the enrollee in step S7, for example, when it is desired to use a stronger curve. For security reasons, the new configurator signature key needs to be on a curve that is as strong as or stronger than the bootstrap key and the newly required curve for NAK.

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

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

[0100] In another embodiment, in step RS3, the enrollee does not start sending a DPP presence announcement message but immediately starts the DPP authentication protocol as a responder and waits for the DPP authentication request message from the configurator in step RS6.

[0101] In yet another embodiment, in step RS3, the enrollee does not start sending a DPP presence announcement message but starts the DPP authentication protocol in step RS7 as an initiator. Although possible, this has the drawback that the enrollee needs to know the configurator's DPP bootstrap URI. An enrollee with a rich UI and sensors for obtaining the configurator's DPP bootstrap URI can do this. However, a headless / simple enrollee has difficulty obtaining the configurator's DPP bootstrap URI and requires features to enable this. In both cases of this embodiment, ensuring that the enrollee can capture the configurator's DPP bootstrap URI is a burden on the user.

[0102] The above 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 communicate using a wireless communication protocol, and are configured to participate in a configuration protocol that is configured to configure the enrollee device to communicate in the wireless network, and the enrollee device is pre-configured to communicate in the wireless network. The method includes executing a configuration protocol, the configuration protocol including the configurator device transmitting, using the wireless communication protocol, a message including an indicator of a selection of a type of public key, the type of public key being selected by the configurator device from a plurality of types of public keys obtained from the enrollee device, the selected type of public key being for use for a particular purpose, and the selected type of public key being different from a previous type of public key that was used for the same particular purpose as part of a previous configuration of the enrollee device for communicating in the wireless network by the enrollee device.

[0103] As a result, the configurator and the enrollee device can agree on a new type of key, preferably a more powerful key in cryptographic terms, and complete the bootstrap and authentication protocols. In many situations, the enrollee device, when properly configured, is configured to "lock out" further configuration. Such means provide some security from the network in that it prevents malicious devices from using the reconfiguration of devices within the network as a way to gain access. Thus, a user who wishes to reconfigure the network to use stronger cryptography needs to reset these enrollee devices. This is cumbersome in itself, but can be made even more problematic by the fact that some devices are installed in remote or hard-to-access locations (e.g., lighting fixtures). The method also allows for reconfiguration to be done using improved strength cryptography from the start, as opposed to starting reconfiguration using existing, less strong configurations.

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

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

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

[0107] In one embodiment, the configurator device selects an enrollment bootstrap key for use with a resumed authentication protocol, and this enrollment bootstrap key is obtained during a previous configuration of an enrollment device for communicating in a wireless network. Thereby, the configurator can select a new type of key without the potentially burdensome reacquisition of the type of public key that the enrollment device might use. For example, this can avoid having to scan multiple QR codes.

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

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

[0110] In one embodiment, the enrollment device transmits a message that includes an encrypted hash of information that includes the enrollment key. Authentication proceeds in this way.

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

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

[0113] The enrollee devices 4, 5 according to one embodiment are configured to be reset by a configurator device 9 for communication in a wireless network. The enrollee devices 4, 5 may be configured to participate in a configuration protocol, which is configured to configure unconfigured enrollee devices. The enrollee devices 4, 5 provide multiple types of public keys configured to be used in the configuration protocol, provide at least one public key for each type of the provided public keys, connect to the network as a result of being configured, set themselves to a state where they can be configured as a result of not being able to connect to the network, receive a message, and use the type of public key selected by the configurator device from the multiple types of public keys in the configuration protocol. The reception of this message restarts the authentication protocol between the configurator device and the enrollee device. Thereby, the enrollee device can participate in the reset without performing a manual reset and without performing a private key exchange via a connection using low-security encryption.

[0114] In one embodiment, the enrollee devices 4, 5 can be set to respond to a message from the configurator device 9 with a response message that includes an indication of the enrollee device ID used during the previous configuration of the enrollee device.

[0115] The configurator device 9 according to the embodiment is configured to reconfigure the enrollee devices 4, 5 for communication in a wireless network. The device has a transceiver configured to transmit and receive according to a communication protocol. The device participates in a setting protocol and obtains, from an enrollee device, indicators of a plurality of types of public keys used as part of the setting protocol, and is configured to select a type of public key from the indicators. Here, the selected type of public key is used for a specific purpose, and the selected type of public key is different from the type of public key used by the enrollee device for the same specific purpose as part of a previous setting of the enrollee device for communication in the wireless network. The device is configured to transmit, using the transceiver, a message including an indicator of the type of public key selected from the plurality of types of public keys by the configurator device to the enrollee device.

[0116] The configurator device 9 configured as such may be able to automatically detect that the enrollee device is ready to participate in reconfiguration with an enrollee device according to an embodiment. The configurator device 9 can select a new type of key, such as a new curve, without the need for manual intervention, such as when a user scans a plurality of QR codes. In particular, this avoids the user having to engage in a trial-and-error process of finding a new curve for a bootstrap that the enrollee device can accept.

[0117] In one embodiment, the configurator device is configured to obtain and store a plurality of types of public keys and at least one public key according to the type of public key obtained during a previous setting of the enrollee device for communication in a 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. The advantage of having the configurator store the key type for future use is that the user does not need to find information related to the enrollee device (such as a QR code), 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 indicator of enrollee device identification information for selecting a public key type from a plurality of stored public key types.

[0120] The advantage of a system composed of a configurator device and an enrollee device according to one embodiment is that, particularly when the enrollee is a simple device, the network including the enrollee device can upgrade its security, that is, strengthen encryption, in a convenient manner. "Convenient" can be understood to mean that the enrollee can be reset to connect to the network without cumbersome manual intervention on the user side on the enrollee device.

[0121] Figure 4a shows a computer-readable medium 1000 having a writable portion 1010 that includes a computer program 1020. The computer program 1020 includes instructions for causing a processor system to execute one 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 conceivable. Further, although the computer-readable medium 1000 is shown 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 execute the above method.

[0122] Figure 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 can include a circuit 1110, for example, one or more integrated circuits. The architecture of the circuit 1110 is schematically shown in the figure. The circuit 1110 includes a processing unit 1120, for example a CPU, for executing computer program components for executing a method according to an embodiment and / or implementing its modules or units. The circuit 1110 includes a memory 1122 for storing program code, data, etc. A part of the memory 1122 may be read-only. The circuit 1110 may include a communication element 1126, for example, an antenna, a transceiver, a connector, or both. The circuit 1110 may include an application specific integrated circuit 1124 for executing part or all of the processing defined by the method. The processor 1120, the memory 1122, the application specific IC 1124, and the communication element 1126 can be connected to each other via an interconnection 1130, for example a bus. The processor system 1110 can be configured for wired and / or wireless communication using connectors and / or antennas, respectively.

[0123] Since both the configurator and the enrollery devices need to process compliant messages, they need to be programmed to correctly parse the messages. It should be understood that this increases the complexity of the configurator and lengthens the execution time. Also, in terms of requiring more complex firmware and larger non-volatile memory, the complexity on the enrollery side increases. It should be noted that there is significant downward price pressure on such devices, and clearly even minor additions require justification. Furthermore, many such devices are battery-powered, and any additional energy consumption, such as acquiring information, constructing more complex messages, and transmitting their more complex and longer messages, is not actively recommended, especially when the battery is small and intended to last for a long time. Finally, changing the protocol often involves other modifications to enable the processing of legacy devices.

[0124] Aspects of this embodiment may be a set of computer program instructions stored on a computer-readable storage device executable by a computer, and may be implemented in a computer program product. The instructions may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), or Java classes. The instructions may be provided as a complete executable program, a partial executable program, a modification (e.g., update) to an existing program, or an extension (e.g., plugin) to an existing program. Further, a portion of the processing of the present invention can be distributed among multiple computers or processors.

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

[0126] The following can be used as references: [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. A method for configuring an enrollee device for communication in a wireless network, the method being configured to be executed by a configurator device and an enrollee device, the configurator device and the enrollee device communicating using a wireless communication protocol and being configured 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 comprising: executing a configuration protocol, the configuration protocol including transmitting, by the configurator device using the wireless communication protocol, a message having an indicator of a selection of a type of public key, the type of public key being selected from a plurality of types of public keys acquired by the configurator device from the enrollee device; wherein the selected type of public key is for use for a particular purpose and is 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 for communication in the wireless network.

2. The method according to claim 1, wherein the message resumes an authentication protocol between the configurator device and the enrollee device.

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

4. The method according to claim 1 or 2, wherein the configurator device compares the selected type of public key with an indicator of the type of public key stored during a previous configuration of the enrollee device.

5. The configurator device selects an enrollee bootstrap key for use in the resumed authentication protocol, wherein the enrollee bootstrap key is acquired during a previous configuration of the enrollee device for communication in the wireless network. The method according to any one of claims 1 to 4.

6. The enroll device transmits a response message to a message from the configurator device having an indicator for selection of a public key type, the response message includes the ID of the enroll device used during previous settings of the enroll device, the configurator device uses the ID of the enroll device to select an enrollment key, The method according to claim 4.

7. The enroll device transmits a response message to a message from the configurator device having an indicator for selection of a public key type, the response message includes an enrollment key of a type that exists in the indicator for selection of the public key type, The method according to claim 4, wherein the configurator device and the enroll device use the enrollment key during a resumed authentication protocol between the configurator device and the enroll device.

8. The method according to any one of claims 1 to 7, wherein the enroll device transmits a message having an encrypted hash of information having an enrollment key.

9. The method according to any one of claims 1 to 8, wherein the enroll device is a device having no user interface other than light.

10. The method according to any one of claims 1 to 9, wherein the message from the configurator device has an indicator that the selection of the public key type is a new selection.

11. The method according to any one of claims 1 to 10, wherein the setting protocol conforms to DPP (Device Provisioning Protocol).

12. An enroll device configured to be reset by a configurator device for communication in a wireless network, participates in a setting protocol configured to set an unconfigured enroll device, provides a plurality of types of public keys configured to be used in the setting protocol, and provides at least one public key for each type of public key provided, connects to the network as a result of being set, sets itself to a state in which it can be set as a result of not being able to connect to the network, receives a message from the configurator device, configured to use the type of public key selected by the configurator device from the plurality of types of public keys in the setting protocol; An enrollee device that causes the resumption of an authentication protocol between the configurator device and the enrollee device upon receipt of the message.

13. The enrollee device according to claim 12, wherein the enrollee device is set to respond to the message with a response message having an indicator of the ID of the enrollee device, and the ID of the enrollee device is the one used during a previous setting of the enrollee device.

14. configured to transmit a response message to a message from the configurator device having an indicator of a selection of a type of public key, the response message including an enrollee key of a type that exists in the indicator of the selection of the 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. The enrollee device according to claim 12 or 13.

15. The enrollee device according to any one of claims 12 to 14, which is a device having no user interface other than a light.

16. 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, and the device: participates in a setting protocol; acquires, from the enrollee device, indicators of a plurality of types of public keys to be used as part of the setting protocol; configured to select a type of public key from the indicators; The selected type of public key is to be used for a specific purpose and is different from the type of public key used by the enrollee device for the same specific purpose as part of a previous setting of the enrollee device for communication in the wireless network. The apparatus is further configured to transmit, to the enrollee device using the transceiver, a message having an indication of the type of public key selected by the configurator device from the plurality of types of public keys.

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

18. The apparatus according to claim 16 or 17, configured to obtain and store the plurality of types of public keys and at least one public key according to the type of public key obtained between previous settings of the enrollee device for communicating in a wireless network.

19. The apparatus according to claim 18, configured to select a public key from the plurality of stored public keys.

20. The enrollee device is configured to transmit 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 that exists in the indication of the selection of the type of public key, The apparatus according to any one of claims 16 to 19, wherein the enrollee device is configured to use the enrollee key during the resumed authentication protocol between the configurator device and the enrollee device.

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

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

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

24. A computer program, executed by a processor of an enrollee device, causing the enrollee device to execute the method according to any one of claims 1 to 11.

25. A computer program, executed by a processor of a configurator device, for causing the configurator device to execute the method according to any one of claims 1 to 11.

Images