Early indications for changing cipher strength during configuration

Abstract

A method, a commissioning device and an enrollee device, and systems thereof, are provided for configuring an enrollee device for communication in a wireless network, the method configured for execution by a commissioning device 9 and an enrollee device 4, 5. The commissioning device and the enrollee device are configured to communicate using a wireless communication protocol and to participate in a configuration protocol, the configuration protocol configured to configure the enrollee device to communicate in the wireless network. The method includes executing the configuration protocol, the configuration protocol including transmitting, by the commissioning device, a message including an indication of a selection of a public key type, the public key type being selected from a plurality of public key types obtained from the enrollee device, keys of the selected public key type being to be used for phases after the configuration protocol, the selected public key type being different from the public key type obtained from the enrollee for bootstrapping.

Description

[Technical field]

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

[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 can be something like an access point (AP), a hub or a 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 the network 1: a complex device 4 (here represented as a computer) and a simple device 5 (here represented as a toothbrush). Devices like the simple device 5 often have no real user interface (UI) other than perhaps a light, and are therefore often called "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 wireless communication technologies such as those 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 a device that performs the configuration is sometimes called a "commissioning device" or "commissioner." In the case of the Device Provisioning Protocol (DPP), also known as "Wi-Fi Easy Connect," the commissioning device is called a "configurator" and the registering device is called an "enrollee."

[0004] It is desirable to establish trust between the commissioning device and 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 no other malicious device can intervene in the connection. To this end, communications are often encrypted.

[0005] Diffie-Hellman (Reference [DH]) is a well-known technique for establishing a secret key between two parties where the communication between the parties to establish the secret key does not disclose any information about the established secret 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 secret key using its own private key and the other'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 [DPP]) uses Diffie-Hellman to establish a secret key between two devices, a DPP enrollee that wishes to be configured, and a DPP configurator (i.e., commissioning device) that can configure the DPP enrollee and then gain access to a DPP-enabled network or configure it as an Access Point (AP) (see [802.11]).

[0007] When running Diffie-Hellman on a network, the device that receives the public key to run Diffie-Hellman does not know which device this public key is from. This can be exploited by an attacker in a so-called man-in-the-middle attack. An attacker E can pose as the real device B that device A wants to connect to. Attacker E runs Diffie-Hellman with device A and establishes a private key Kae with device A. Similarly, the attacker poses as device A to device B and establishes a private key Kbe with device B. When a message comes from one of devices A or B, the attacker decrypts the message with the private key of one, encrypts it with the private key of 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. If they check the communication by sending the same information in another communication method and comparing the results, they do not notice any tampering of their communication. But the attacker has perfect knowledge of what to communicate. ` 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 can 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], etc. Alternatively, the OOB communication can involve the commissioning device obtaining the public key by a technique such as scanning a QR code associated with the enrollee device, which decrypts the public key(s) from the QR code.

[0008] In this way, a user of the device knows that a public key received OOB is from the intended device because the association of the QR code with the enrollee can be verified, or the enrollee is within range of operation of the OOB communications protocol. Once hashes of public keys are exchanged OOB, the device can verify that a public key received over a communications protocol that requires encryption results in the same hash as the hash received OOB. Note that the use of the term communications 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 that has been 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, in particular the public protocol keys (also called Network Access Keys (NAKs)) and the commissioning device signing keys. A requirement for supporting ECC curves is P-256. In other configurations or configuration protocols, other forms of cryptography may be used.

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

[0012] A user wants to upgrade the security of their network so that P-256 is no longer used and a stronger curve is used instead, i.e. the APs and all devices allowed on that network need to be newly configured. Or the user wants to create a DPP network using other curves, preferably stronger than is required to implement P-256, such as P-384. The curve (P-256 or other) can be thought of as a "type" of key. Summary of the Invention [Problem to be solved by the invention]

[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. [Means for solving the problem]

[0014] There is therefore provided a method of configuring an enrollee device for communication in a wireless network by execution of a configuration protocol, the method being configured to be performed by a commissioning device and an enrollee device, the commissioning device and the enrollee device being configured to communicate using a wireless communication protocol and to participate in the configuration protocol, the configuration protocol comprising: - providing, by the enrollee device, the first public key and at least one indication of a type of the second public key to the commissioning device using out-of-band (OOB) communications; - selecting, by the commissioning device, if said at least one indication of a second public key type indicates a key type different from the first public key type, at least one key type from said at least one indication, wherein all types in said selection are different from the first public key type; - sending a first message using a wireless communication protocol, the first message requesting a second public key of a type corresponding to any key type in the selection, the second key being used by the commissioning device to enable the enrollee device to connect to a wireless network; - sending, by the enrollee device, a second message including a second public key of the key type requested in the first message; - completing a configuration protocol with the enrollee device and the commissioning device using a key type corresponding to said selection, and attempting, by the enrollee device, to connect to the wireless network.

[0015] There is also provided a method of configuring an enrollee device for communication in a wireless network by execution of a configuration protocol, said method being configured to be performed by a commissioning device (9) and an enrollee device, said commissioning device and enrollee device being configured to communicate using a wireless communication protocol and to participate in said configuration protocol, said configuration protocol comprising: - providing, by the enrollee device, using out-of-band (OOB) communications, the first public key and at least one indication of a type of the second public key to the commissioning device; - making, by the commissioning device, a selection of at least one key type from at least one indication of a second public key type if said indication indicates a key type different from the first public key type, where all types in said selection are different from the first public key type; - signing a data object using a third key of a type corresponding to any key types in the selection, the data object being configured to be transmitted to an enrollee and configured to be used by the enrollee device to attempt to connect to a wireless network; - completing a configuration protocol by the enrollee device and the commissioning device using a key of a type corresponding to the selection and attempting to connect to a wireless network using the data object, wherein the selection is made and the data object is signed by the enrollee device after providing at least an indication of the type of the first public key and the second public key to the commissioning device using OOB communications and before a first attempt is made to connect to the network.

[0016] In one aspect, when the at least one indicator of the second public key type indicates the same key type as the first public key, the at least one indicator uses smaller data elements than data elements used when the at least one indicator of the second public key type indicates a key type different from the first public key type.

[0017] In this way, the amount of data encoded can be reduced. When the overhead of error correction mechanisms is taken into account, the savings become even greater. This is particularly advantageous when OOB communication uses QR codes. With QR codes, space is at a premium and increasing the data encoded increases the area required by the code. This can make it difficult to fit an extended QR code on a product or packaging.

[0018] In one aspect, the method may include terminating execution of the configuration protocol prior to completion by the commissioning device if at least one indication of the type of the second public key indicates only the same type as the type of the first public key.

[0019] In one aspect, the method may include terminating execution of the configuration protocol prior to completion by the commissioning device if the at least one indication of the type of the second public key does not include a type of public key that is available for use by the commissioning device.

[0020] Thus, the commissioning device can determine the highest encryption strength that the enrollee can support. It may turn out that such encryption strength is insufficient for the network in question. By determining this highest encryption strength during the OOB communications phase or when the enrollee responds with a proposed new public key, the commissioning device can save the user trouble by failing early. This can also be reported to the user.

[0021] In one aspect, the enrollee device is a simple device.

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

[0023] In one aspect, at least one indication of the type of the second public key is included in a bitmask portion of the DPP bootstrap URI.

[0024] In one aspect, the selection of the at least one public key type and the transmission of the first message occur after the first public key and at least one indication of the second public key type are provided by the enrollee device to the commissioning device using OOB communications and prior to the enrollee device attempting to connect to the network for the first time.

[0025] An enrollee is provided that is configured to communicate using a wireless communication protocol and configured to be configured by a commissioning device for communication in a wireless network, the enrollee device having a transceiver configured for communication in the wireless network, the enrollee device comprising: - Participate in a configuration protocol configured to configure the enrollee device; - providing, using out-of-band (OOB) communications, a first public key and at least an indication of a type of a second public key for use in a first phase of a configuration protocol; - receiving a first message from the commissioning device via said transceiver and using a wireless communication protocol, the first message including a request indicating one or more types of a second public key, the type of the second public key being different from the type of the first public key; - transmitting a second message to the commissioner device via the transceiver and using a wireless communication protocol, the second message including a second public key of the type requested in the first message; - participating in a commissioning protocol with a commissioning device using the first public key and a key of a type indicated by the at least one indicator, using a wireless communication protocol; - Configured to attempt to connect to the network as a result of the setting.

[0026] An enrollee device configured in this manner can indicate during the OOB communications phase, i.e., near the start of the configuration process, the level or strength of encryption it can support beyond that of its public bootstrap key. This then enables a commissioning device configured to use this facility to a) determine that the enrollee can support sufficient encryption strength, and b) select (in the form of selecting one or more key types) the encryption strength that the enrollee can support.

[0027] Additionally or alternatively, the enrollee device is configured to verify the data object, the data object being signed by the commissioning device using a key of a type corresponding to said at least one indicator.

[0028] Thus, an enrollee may provide and use a key that has a default encryption, ie, a stronger encryption than the enrollee's public bootstrap key.

[0029] In one aspect, the enrollee device is configured to provide a second public key of a type having the greatest cryptographic strength when the request indicates more than one public key type.

[0030] It is advantageous for the commissioning device to make a request that includes an option for the new key type. For example, the commissioning device may have to deal with many types of enrollees, some of which may advertise support for a level of encryption that is more burdensome to the enrollee than strictly required. Leaving some of the choice up to the enrollee can introduce some flexibility into the process. The request allows the enrollee to choose which key type to use for the new (upgraded) public key, allowing the network to benefit from this by the enrollee selecting the option that provides the strongest encryption.

[0031] In one aspect, the enrollee device is a simple device.

[0032] A device is provided that is configured to act as a commissioning device and configured to configure an enrollee device for communication in a wireless network. - the apparatus has a transceiver configured to transmit and receive according to a wireless communication protocol, the apparatus being configured to: - Participate in the configuration protocol, - obtaining, via out-of-band (OOB) communications, from the enrollee device, a first public key and at least one indication of a second type of public key to be used as part of the configuration protocol; - if the at least one indicator indicates a key type different from the type of the first public key, performing a selection of at least one type of key based on the at least one indicator, all types in the selection being different from the type of the first public key; - transmitting a first message to the enrollee device using a transceiver and a wireless communication protocol requesting a second public key of a key type corresponding to one of the key types in said selection; and / or - signing a data object using a third key of a type corresponding to one of the key types in said selection, and transmitting the signed data object to the enrollee via the transceiver and using a wireless communication protocol, wherein the data object is used by the enrollee device to attempt to connect to the wireless network.

[0033] In this way, the commissioning device can determine what types of keys, other than the enrollee bootstrap key type, the enrollee can support. With that information, it can request a new public key from the enrollee. Additionally or alternatively, it can determine what key types (other than the enrollee bootstrap key type) can be used to sign data objects (e.g., DPP connectors) that contain connection information packets. By determining what can be used, the commissioning device can change encryption levels without having to resort to trial and error.

[0034] In one aspect, the device is configured to exit before completing the configuration of the enrollee device if the indicator shows only keys of the same type as the key type of the first public key.

[0035] In one aspect, the device is configured to exit before completing the configuration of the enrollee device if the at least one indicator does not indicate a type of key for which the device is enabled.

[0036] Also provided is a computer program product that, when running on a processor within the enrollee device, causes the enrollee device to perform the methods described herein, and a computer program product that, when running on a processor within the commissioning device, causes the commissioning device to perform the methods described herein. [Brief description of the drawings]

[0037] The above, as well as 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] 1 is a diagram illustrating a wireless network in which one would like to configure a device for addition. [Diagram 2] Setup process flow. [Diagram 3] 6 is a flow chart showing a reconfiguration process according to the embodiment. [Figure 4] A diagram showing a representation of a QR code. [Figure 5a] 1 illustrates a computer-readable medium. [Figure 5b] 1 is a schematic diagram of a processor system.

[0038] The drawings are schematic and not drawn to scale. In the drawings, elements that correspond to elements already described may have the same reference numbers. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0039] In the following description, like reference numbers refer to similar elements.

[0040] FIG. 2 illustrates a device-controlled configuration flow in which one device, such as the third device 9 in FIG. 1, may configure and connect to another device, such as the complex or simple devices 4, 5 in FIG.

[0041] The process of Figure 2 is sometimes referred to as a commissioning protocol or configuration protocol. As an example, the case of a simple device 5 will be described. While much of this description provides examples involving networks with devices such as AP 2, it should be understood that this process may 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.

[0042] One 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.

[0043] At S1 (Start), the process begins with two devices 9 and 5 not connected, and device 5 is not configured. For purposes of explanation, device 9 is used to configure device 5 to join wireless network 1, and thus device 9 may be referred to as the commissioning device (e.g., the DPP configurator), and device 5 as the enrollee (as it is "enrolled" in wireless network 1).

[0044] In S2 (Bootstrapping), often called "bootstrap", one device, the initiator, sends the bootstrap public key (B R If the responder device wants to perform mutual authentication, it obtains the initiator's bootstrap public key (B I) to the responder. This is achieved by a method other than wireless communication technology, the so-called "out of band" communication (OOB). For example, it could be a user having one device read a QR code on the responder, an NFC communication between two devices, or another wireless technology (e.g. Bluetooth). The bootstrap process is started by user intervention. If the bootstrap is successful, the process reaches S3 (Bootstrapped) and the device 9, 5 is "bootstrapped", otherwise it returns to the "start" state in S1. In either case, the enrollee device (simple device 5 in this case) can record the result of the bootstrap process in an appropriate storage device, for example as a flag in a register in memory. Often, the simple device is programmed to start up after manufacture or after a reset, turn on its radio on the channel indicated in the QR code for configuration, and start listening for authentication request messages.

[0045] In S4 (Authentication), the devices 9, 5 perform an authentication procedure, whereby the devices establish "trust", i.e. the user can be sure that they 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 the other. A message is sent from one device requesting the initiation of authentication. This message can be sent either by the device doing the configuration (the commissioning device or configurator (in the case of DPP)) or by the device to be configured (the enrollee). In this example, the third device 9 acts as the commissioning device, and the simple device 5 acts as the enrollee. It should be noted that the third device 9 is shown as being connected to the network 1, but this is not necessary for the embodiment to work. 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 commissioning device and the enrollee device to act as initiators in the DPP protocol, and the other device automatically becomes a responder. A simple or headless device typically assumes the role of a responder.

[0046] The other 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 believes to be and has the necessary capabilities, the response message indicates that the message is "accepted" and contains the necessary information for the initiator to verify the responder's credentials and also indicates that it has the necessary capabilities. If the two devices do not receive the necessary information from the other device, the process aborts and the devices return to the bootstrapped state in S3 or to the start state S1. 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 an enrollee. If the responder is an enrollee, the authentication response message may also include an additional portion indicating the result of a previous attempt. It should be understood that the indication may also indicate whether there has been a previous attempt. In these authentication messages, both devices provide information proving that they possess a private key belonging to their own public key, which has been obtained by the other device. Proving possession of the private key can be performed by successfully deriving the same symmetric key in a Diffie-Hellman procedure, or by both devices computing the same authentication values, such as I-Auth and R-Auth in the DPP.

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

[0048] 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 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 setup can begin. The Confirmation message may also contain an indication of the results of a previous setup attempt in which the enrollee was also the initiator.

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

[0050] In S6 (Configuration), the enrollee sends a configuration request message with information about what type of configuration the enrollee wants. If the commissioning device 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 a previous configuration attempt.

[0051] In the case of DPP, the request message is a DPP Configuration Request, and the commissioning device response is a DPP Configuration Response message. The response from the commissioning device (e.g., DPP Configuration Response) may include the Service Set Identifier (SSID) of the network to which the enrollee should connect, and may include a data object that may function as a "connection information package." In the case of DPP, this is called a DPP Connector. For convenience, this connection information package is called a "connector." It should be understood that this is not intended to limit the systems and methods described herein to DPP, and indeed other commissioning protocols may use connectors. The connector, at least in the case of DPP, is digitally signed by the commissioning device using a key (C-signature key) and includes, among other things, the enrollee's public network access key (NAK). The enrollee can then use the signing key to verify the contents of the connection information package in order to proceed.

[0052] The commissioning device can obtain the enrollee's public network access key from the message sent by the enrollee at the end of the authentication (DPP authentication response message in case of DPP), and this key is called the responder's public protocol key. It should be noted that in this application, the term protocol key is used not only for the protocol key in the DPP protocol, but also for any other enrollee public key used in any commissioning protocol and / or any protocol for connecting to the network based on the success of the enrollee's commissioning. Upon successful DPP authentication, the responder's public protocol key is renamed to the enrollee's public network access key to indicate its new purpose in the protocol. The DPP configuration response message also contains the configuration's public signature key. Other devices configured by the same commissioning device 9 (e.g., DPP configurator) can thereby check whether they can trust the public network access key of the other device. Thus, an enrollee attempting to connect to the network can be authorized by the network or other devices in the network using the signature of its connector, including its NAK. The DPP Configuration Response message may also include the Wi-Fi passphrase or pre-shared key (PSK) for the network. The enrollee sends a message (e.g., DPP Configuration Result, depending on the version of DPP) to the commissioning device (e.g., DPP Configurator) to inform it whether or not to accept the configuration. Failure to receive this message by the commissioning device may indicate to the commissioning device that there was a Wi-Fi problem between the commissioning device and the enrollee. The "supposedly configured" enrollee may then send its connectors to the DPP-configured AP 2. If the connector signature is found to be correct and AP 2 has a matching connector (one for the same network, signed by the same commissioning device), AP 2 sends its connectors to the enrollee (e.g., DPP Enrollee).The enrollee and AP 2 can calculate a symmetric key based on each other's network access key in the connector and their own secret network access key using the Diffie-Hellman method.

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

[0054] 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 in the structure that contains the public key. An example of an elliptic curve public key, represented as an ASN.1 structure called SubjectPublicKeyInfo, as specified in Section 4.1 of [RFC 5280], is as follows in ASN.1 notation: SEQUENCE { SEQUENCE { OBJECTIDENTIFIER 1.2.840.10045.2.1 (ecPublicKey) OBJECTIDENTIFIER 1.2.840.10045.3.1.7 (P-256) } BITSTRING 0x0343A6A094A9BC6C9B92CBA3164849F0DB0B91350270ABE80DC554B1E6B3897F30 : 0 unused bit(s) }

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

[0056] Currently, specifically in the DPP, regarding the information about the enrollee device's public key, the bootstrap URI only contains the bootstrap key in DPP R2. This bootstrap key is the last attribute in the bootstrap URI. It has the following format: "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 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) }

[0057] DPP uses elliptic curve cryptography [RFC 6090] for all asymmetric cryptography, especially for the network access key (NAK) and the commissioning device (configurator) signing key, but 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 "the finite field GF(q) with elements prime q" in [DH]) and α is a primitive root modulo q (called "the fixed primitive element of GF(q)" in [DH]). All public keys generated with the same values ​​of q and α are considered for the purposes of this specification to be the same type of public key. 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, e.g., 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 the defining parameters are considered to be different types of public keys for the 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 as 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, the IANA representation in [IKE] for curve P-256 is 1300. For example, in a DPP Reconfiguration Announcement message, the element group indicates the type of the public key of the enrollee's connector's network access key.

[0058] It should be understood that the above paragraphs describe the situation in the DPP, however, other commissioning protocols may have similar aspects and similar elements (such as network access keys).

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

[0060] Currently, specifically in the current version of the DPP, a bootstrap URI can contain only one bootstrap key. This bootstrap key is the last attribute of the bootstrap URI. It has the following format: "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 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) }

[0061] The inventors have recognised that this has drawbacks for the efficient operation of the configuration protocol.

[0062] Much attention has been paid to the issue of privacy and protection from cyber attacks. A major part of the defense against such attacks is the strength of the encryption, and there is a trend towards increasing the strength of the encryption. Thus, situations may arise where the commissioning device discovers from initial information from the enrollee (e.g., bootstrap URI and initial exchanges) that the enrollee device is configured to use a lower strength encryption than the commissioning device "wants" to use (i.e., is programmed or enabled). In fact, with many older potential enrollee devices having old and weak encryption and left in the supply chain, so to speak, this is likely to occur, and the problem may be more pressing than is realized.

[0063] Moreover, the inventors have realized that there is an additional problem. The configuration protocol allows, and in fact DPP prescribes, the commissioning device to change to a higher strength encryption for later phases of the configuration protocol and for the enrollee's connection to the wireless network. In the case of DPP, in S6a, the DPP configurator (i.e., the commissioning device) can use the DPP Configuration Response message to request a new public protocol key (NEWK REQ) on a particular (possibly) stronger curve. In S6b, if the enrollee can use the proposed curve, it responds with a message (e.g., in the case of DPP, DPP Configuration Request) containing the new public protocol key. The flow then continues to S7 as described above. However, if the enrollee cannot comply, it fails to respond and finally the configuration process ends after a timeout, resulting in a configuration failure in S6c (FAIL). The commissioning device remains hung up, so to speak, and eventually informs the user that it cannot complete the configuration. The only option left for the user is to restart the procedure. This sequence of events is time consuming. Even worse, the commissioning device must be restarted "blind" and it is not known in advance whether a new key request, requesting a different type of key than the one previously requested, will be successful. In short, the only option is trial and error, i.e. running the configuration procedure repeatedly until it works.

[0064] A similar situation may arise when the commissioning device wishes to use a private key of a type other than the key type of the bootstrap key provided by the enrollee, e.g. a more secure type. The commissioning device can send a configuration response, (part of) its information, e.g. the DPP connector, is signed with a private key of a type different from the key type of the bootstrap key provided by the enrollee. However, if the enrollee is not capable, it will fail to respond and finally the configuration process will end at step 6 and the commissioning device will remain hung up as before.

[0065] According to an embodiment, the bootstrap URI can be extended so that additional elliptic curves can be added in a backwards compatible manner. This can be done by a series of one or more attributes appearing somewhere before the existing one, all similar to the existing attribute denoted by "K" in the DPP bootstrap URI, but now denoted by another unused character.

[0066] Several variations are possible.

[0067] In one variant, a list contains indications of all types of keys supported by the device to which the bootstrap URI belongs (i.e. elliptic curves in the case of DPP) for use by the commissioning device as signing keys and as protocol keys (network access keys), other than the type of bootstrap key in the bootstrap URI.

[0068] In another variation, an indication of all key types (e.g., elliptic curve) that the device to which the bootstrap URI belongs supports for use as commissioning device (configurator) signatures and network access keys, other than the type of bootstrap key in the bootstrap URI, are in two separate lists.

[0069] Using ASN.1, the encoding is SEQUENCE { OBJECTIDENTIFIER 1.2.840.10045.2.1 (ecPublicKey) OBJECTIDENTIFIER 1.3.132.0.34 (P-384) } } which in BASE64 encoding is MBAGByqGSM49AgEGBSuBBAAi.

[0070] P-384 support for both signing keys and protocol keys / network access keys can be indicated as follows, where "B" can mean "both": B: MBAGByqGSM49AgEGBSuBBAAi; And for DPP, the bootstrap URI would be: DPP:B:MBAGByqGSM49AgEGBSuBBAAi;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;;

[0071] Other information may also be added to the bootstrap URI, such as the channel on which the enrollee listens.

[0072] The above ASN.1 notation is very long. This has the drawback that it may increase the size of the QR code, including the bootstrap URI, to the point where there is not enough space left to print the QR code on the product. An advantageous way could be to use the encoding in the IANA maintained registry mentioned above. And indicating support for P-384 signing keys independently from indicating support for P-521 NAK can be done as follows, where "S" can indicate the signing key type and "N" can indicate the NAK key type: DPP:S:1400;N:1500;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;; Support for two curves for both signature and NAK use can be done as follows: DPP:B:14001500;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;; or DPP:B:1400;B:1500;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;;

[0073] Figure 3 illustrates a protocol flow for upgrading encryption (i.e., increasing encryption strength) according to one embodiment. The processes at S1, S2, S3, S4, S5, S7, S7a and S8 have been described with reference to Figure 2 and therefore will not be described further. The process of Figure 3 may also be referred to as a commissioning or configuration protocol.

[0074] In S20, the commissioning device checks the information received from the enrollee in S2, for example in the bootstrap URI. If the commissioning device "wants" to use the bootstrap type key (e.g., curve) also for connector signing and NAK for network access, it proceeds with the process to S3.

[0075] However, if the commissioning device wants to use a different type of key (e.g., curve) than the bootstrap key in the bootstrap URI for later-stage protocols (e.g., protocol keys such as signing DPP connectors, or NAK), it will attempt to find information about which curves the enrollee supports for signing. In the above example, this would be the information after "B:", "N:", or "S:" and before the next semicolon. If the commissioning device finds a type of key (e.g., curve) that it can accept, the process proceeds to S3. The commissioning device can then keep a record of the bootstrap URI for later use, e.g., if a reconfiguration is required.

[0076] However, if the enrollee does not support a curve (i.e., a key type) that the commissioning device is willing to accept for use, the commissioning device will stop the process of configuring this enrollee, the process will be aborted in S20a, and the commissioning device may notify the user of the fact that the enrollee does not appear to support an acceptable key type.

[0077] In S61, the commissioning device can select one or more key types (e.g., curves) from the information in the bootstrap URI and request the enrollee to provide a public protocol key of any of the selected types. The enrollee can then respond in S62 with a new protocol key (e.g., NAK) of the requested type(s). When presented with a request that allows more than one type of public key, it may be advantageous for the enrollee to be configured to use the strongest type of key. The commissioning device then knows that the enrollee is using an acceptable level of encryption when connecting to the network. Since the commissioning device has, in theory, selected from a list that the enrollee supports, the risk that the enrollee will not be able to use a signing key to verify the connection information package and will fail to respond (causing the process to hang and then abort) is greatly reduced. This provides a significant improvement in the efficiency of the commissioning process by eliminating the commissioning device's wasteful trial and error attempts to "guess" the appropriate key types for the signing and public protocol keys and by early weeding out enrollees that cannot connect.

[0078] It may be advantageous for the commissioning device to make a request that includes an option for the new key type. For example, the commissioning device may have to deal with many types of enrollees, some of which may advertise support for a level of encryption that is more burdensome to the enrollee than strictly necessary in a given situation. Leaving some of the choice up to the enrollee can introduce some flexibility into the process. The request allows the enrollee to choose which key type to use for the new (upgraded) public protocol key, allowing the network to benefit from this by the enrollee selecting the option that provides the strongest encryption.

[0079] In addition to or instead of requesting in S60 the enrollee to provide a public protocol key of a key type (e.g. curve) from the information in the bootstrap URI, the commissioning device can select a key type (e.g. curve) from the information in the bootstrap URI other than the key type in the bootstrap URI to sign the connection information packet (e.g. DPP Connector). The commissioning device knows that it can sign the connection information packet (e.g. DPP Connector) with a supported key type. The enrollee can then use the signature of the connection information package to gain acceptance from the network when attempting to connect to the network. If the commissioning device also requested a new public protocol key, the key type for signing the connection information packet may be the same as one of the requested public protocol keys or it may be different. In theory, the risk of the enrollee not responding (the process hanging and aborting) is greatly reduced because the commissioning device is making the selection from a list that the enrollee supports. This provides a significant improvement in the efficiency of the commissioning process by eliminating wasteful trial and error where the commissioning device attempts to "guess" appropriate key types for signature and public protocol keys, and by early elimination of enrollees that cannot connect.

[0080] An enrollee may require reconfiguration even when connected to a network. For example, this action may be performed to upgrade the cryptographic security of the network, thus requiring a change in key type. Another situation is when an enrollee attempts to connect to a network and fails, as represented by S7a. The inventors have recognized that such reconfiguration may suffer from the same problem when the commissioning device does not know which key types (e.g., curves) are supported by the enrollee.

[0081] According to one embodiment, reconfiguration of the enrollee can be performed. In an advantageous implementation, the commissioning device stores the bootstrap URI of all enrollees that it has configured, in combination with the NAK with which it configured each enrollee. At S9, the enrollee requires reconfiguration and starts sending a request message, such as a DPP Reconfiguration Announcement message. The commissioning device, such as a DPP Configurator, recognizing the hash of its signing key in the DPP Reconfiguration Announcement message responds to the enrollee with a DPP Reconfiguration Authentication Request message. In the case of DPP, the commissioning device can learn the enrollee's identity during the DPP Reconfiguration Authentication Protocol when it receives a DPP Reconfiguration Authentication Response message from the enrollee, which message includes the enrollee connector and the enrollee NAK. This establishment of the enrollee's identity can be done as follows:

[0082] In S10, the enrollee replies with a response (such as a DPP Reconfiguration Authentication Response message) and includes its (enrollee) connector. The commissioning device finds a NAK in the enrollee connector in the received (DPP Reconfiguration Authentication Response) message. The commissioning device can then try to find this NAK in a list of NAKs that it used in the connector to previously configure the enrollee. If it finds a NAK in that list, it can find the bootstrap URI that the enrollee used when it was configured in the connector using that NAK. In S63, the commissioning device can then evaluate the key types (e.g., curves) supported by this enrollee, as described above. The commissioning device can decide either to abort the reconfiguration procedure in S63a, or to proceed in S63b to reconfigure this enrollee since it supports the curve that the commissioning device wants to use. In some commissioning protocols, S63b can be shown as including S60, S61, S62, and S7. After the reconfiguration is successful, the process ends at S8 as described above.

[0083] Thus, the method of configuring an enrollee device for communication in a wireless network by execution of a configuration protocol may be described as follows: The method is configured to be executed by a commissioning device and an enrollee device, the commissioning device and the enrollee device configured to communicate using a wireless communication protocol and participate in the configuration protocol. The configuration protocol includes the following elements: The enrollee device provides the first public key and at least one indication of a type of the second public key to the commissioning device using out-of-band (OOB) communication. If the commissioning device determines that the at least one indication of the type of the second public key indicates a key type different from the type of the first public key, it does the following:

[0084] The commissioning device makes a selection of at least one key type from the at least one indication, all types in the selection being different from a type of the first public key, and transmits a first message using the wireless communication protocol, the first message requesting a second public key of a type corresponding to any key type in the selection, the second key being used by the commissioning device to enable the enrollee device to connect to the wireless network.

[0085] Additionally or alternatively, the commissioning device signs the data object using a third key of a type corresponding to any key type in the selection, and the data object is configured to be sent to the enrollee and used by the enrollee device to attempt connection to the wireless network.

[0086] The enrollee device sends a second message, if requested, including a second public key of the key type requested in the first message, and the enrollee and commissioning devices complete the configuration protocol using one or more keys of the type corresponding to the selection by using one or more of the enrollee's public key and the commissioning device's signing key.

[0087] If the second public key type indicator indicates the same key type as the first public key type, then this indicator may use a smaller data element than the data element used if the second public key type indicator indicates a different key type than the first public key type.

[0088] In this way, the amount of data to be encoded can be reduced. When the overhead of error correction mechanisms is taken into account, the savings become even greater. This is particularly advantageous when OOB communication uses QR codes. Space is limited in QR codes, and as the data to be encoded increases, the area required by the code will also increase. This can make it difficult to fit larger QR codes on products or packaging.

[0089] The method may thus include terminating, by the commissioning device, execution of the configuration protocol prior to completion of the configuration protocol only if the at least one indication of the second public key type indicates the same type as the first public key type.The method may include terminating, by the commissioning device, execution of the configuration protocol prior to completion of the configuration protocol if the at least one indication of the second public key type does not include a public key type that the commissioning device can use.

[0090] Thus, the commissioning device can determine the highest encryption strength that the enrollee can support. It may turn out that such encryption strength is insufficient for the network in question. By determining this highest encryption strength during the OOB communications phase or when the enrollee responds with a proposed new public key, the commissioning device can save effort (on the user's part) by failing early. This can also be reported to the user.

[0091] An enrollee according to one embodiment is configured to communicate using a wireless communication protocol and is configured to be configured by a commissioning device for communication in a wireless network. The enrollee device is configured to: - Participate in a configuration protocol configured to configure the enrollee device; - providing, using out-of-band (OOB) communications, a first public key and at least an indication of a type of a second public key for use in a first phase of a configuration protocol; - participating in a commissioning protocol with the commissioning device using the first public key and a key of a type indicated by the at least one indicator, using a wireless communication protocol; - Attempt to connect to the network as the configured outcome.

[0092] An enrollee device configured in this manner can indicate during the OOB communications phase, i.e., near the beginning of the configuration process, the level or strength of encryption that it can support beyond that of its public bootstrap key. This then enables a commissioning device configured to use this facility to a) determine that the enrollee can support a sufficient encryption strength, and b) select (in the form of selecting one or more types of keys) the encryption strength that the enrollee can support.

[0093] According to one embodiment, the enrollee device is configured to verify a data object that has been signed by the commissioning device using a key of a type that corresponds to the at least one indicator.

[0094] The enrollee may have a transceiver configured to receive, via the transceiver, a first message from the commissioning device using a wireless communication protocol, the first message including a request indicating one or more types of a second public key, the type of the second public key being different from the type of the first public key, and to transmit, via the transceiver, a second message to the commissioner device using the wireless communication protocol, the second message including the second public key of the type requested in the message.

[0095] Thus, an enrollee may provide and use a default key, ie, a key that has a stronger encryption strength than the enrollee's public bootstrap key.

[0096] In one embodiment, the enrollee device is configured to provide a second public key of the type having the greatest encryption strength if the request indicates more than one type of public key. It is advantageous for the commissioning device to make a request that includes a selection of new key types. For example, the commissioning device may have to deal with many types of enrollees, some of which may advertise support for a level of encryption that is more burdensome to the enrollee than strictly required. Leaving some of the selection to the enrollee can introduce some flexibility into the process. The request allows the enrollee to choose which key type to use for the new (upgraded) public key, allowing the network to benefit from this by the enrollee choosing the option that provides the strongest encryption.

[0097] A commissioning device according to one embodiment is configured to configure an enrollee device for communication in a wireless network. - the apparatus has a transceiver configured to transmit and receive according to a wireless communication protocol, the apparatus being configured to: - Participate in configuration protocols; - obtaining, via out-of-band (OOB) communications, from the enrollee device, a first public key and at least one indication of a second type of public key to be used as part of the configuration protocol; - if the at least one indication indicates a key type different from the first public key type, selecting at least one type of key based on said at least one indicator, where all types in said selection are different from the type of the first public key; - sending a first message to an enrollee device using a transceiver and a wireless communication protocol, the enrollee device requesting a second public key of a key type corresponding to any key types in said selection; and / or - Signing a data object using a third key of a type corresponding to any key type in said selection, and transmitting the signed data object via the transceiver to the enrollee using a wireless communication protocol (the data object is configured to be used by the enrollee device to attempt a connection to a wireless network).

[0098] Thus, the commissioning device can determine what types of keys the enrollee can support, other than the type of the enrollee bootstrap key. With that information, it can request a new public key from the enrollee. Additionally or alternatively, it can determine what key types (different from the type of the enrollee bootstrap key) can be used to sign data objects (e.g., DPP connectors) that contain connection information packets. By determining what can be used, the commissioning device can change encryption levels without having to resort to trial and error.

[0099] The device can be configured to exit before completing configuration of the enrollee device if the indicators indicate only key types that are the same as the key type of the first public key. Additionally or alternatively, the device can be configured to exit before completing configuration of the enrollee device if the at least one indicator does not indicate a key type for which the device is enabled.

[0100] Also provided is a computer program which, when running on a processor within the enrollee device, causes the enrollee device to perform the methods described herein, and a computer program which, when running on a processor within the commissioning device, causes the commissioning device to perform the methods described herein.

[0101] FIG. 4 represents a QR code that may be used in the bootstrap stage of S2 described above. The International Organization for Standardization (ISO) established a standard for QR codes, ISO / IEC 18004:2015, entitled "Information technology - Automatic identification and data capture techniques - QR code bar code symbology specification," which defines a standardized symbol structure. There are 40 versions with different information capacities. The QR code 100 has various component areas, such as a finder pattern 101, data and error correction areas 102. Data is encoded as a bit stream that is divided into 8-bit code words. An error correction mechanism is used that further increases the actual amount of encoded data stored in the printed code. Increasing the amount of information in the QR code can significantly increase the size of the printed QR code, which can create problems in actually fitting the QR code into the available space on the device or package. Thus, there is an advantage to saving space. In one embodiment, if the enrollee only supports the key type (e.g., curve) of its public bootstrap key, the indication of the supported key types for the signature and / or public protocol key (i.e., NAK) is removed. therefore DPP:B:1300;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;; teeth, DPP:B:;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;; And then, DPP:S:1400;N:1500;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;; teeth DPP:S:;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;; It becomes.

[0102] This saves four or eight octets (depending on whether an index to the signing key and / or protocol key is involved) and thus a potential area reduction in the QR code or allows those octets to be used for another purpose. The commissioning device according to this embodiment reads the "missing" index as a flag that the signing key and / or NAK must be of the same type as the public bootstrap key in the URI.

[0103] Another way to save octets is to use a special index for one or more sets of curves, where the set is specified, for example, in an Internet Draft, RFC, or standard published by a standards body such as IEEE, Wi-Fi Alliance, NIST, ETSI, IEC, etc. As an example, the letter A can be defined to denote all NIST curves P-256, P-384, and P-521, along with Brainpool curves BP-256, BP-384, and BP-512. Using this example, the URI would look like this: DPP:S:A;K:MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgADM2206avxHJaHXgLMkq / 24e0rsrfMP9K1Tm8gx+ovP0I=;; This indicates that the device supports all NIST curves P-256, P-38, and P-521, along with the Brainpool curves BP-256, BP-384, and BP-512 for signing and NAKing.

[0104] FIG. 5a shows a computer readable medium 1000 having a writable portion 1010 including a computer program 1020, which includes instructions for causing a processor system to execute one to three or more of the above methods and processes, as described with reference to FIG. 1. The computer program 1020 may be realized 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, 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. Alternatively, the computer readable medium may be located on a remote server storage 1200, such as a cloud storage. The computer program 1020 includes instructions for causing a processor system to execute the above methods.

[0105] FIG. 5b shows a schematic diagram of a processor system 1100 according to an embodiment of the apparatus or method described with reference to FIGS. 1-3. The processor system may comprise a circuit 1110, e.g., one or more integrated circuits. The architecture of the circuit 1110 is shown diagrammatically in the figure. The circuit 1110 comprises a processing unit 1120, e.g., a CPU, for executing computer program components to perform the method according to an embodiment and / or to implement the modules or units thereof. The circuit 1110 comprises a memory 1122 for storing program code, data, etc. Parts of the memory 1122 may be read-only. The circuit 1110 may include a communication element 1126, e.g., an antenna, a transceiver, a connector, or both. The circuit 1110 may 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.

[0106] Since both the commissioning device and the enrollee device must be able to process the adapted messages, they must be programmed accordingly to parse the messages correctly. It should be appreciated that this increases the complexity of the configuration device and increases execution time. It also increases the complexity on the enrollee side in that more complex firmware and larger non-volatile memory will be required. It should be noted that there is significant downward price pressure on such devices, and apparently even small additions require justification. Furthermore, many such devices are battery powered, and any extra energy consumption, such as retrieving information, composing more complex messages, and transmitting those more complex and longer messages, is actively discouraged, especially when the battery is small and intended to last for long periods of time. Finally, changing the protocol often involves other modifications to allow for the handling of legacy devices.

[0107] 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 and 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. Additionally, parts of the processing of the present invention may be distributed across multiple computers or processors.

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

[0109] 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 of configuring an enrollee device for communication in a wireless network by executing a configuration protocol, the method being configured to be performed by a commissioning device and an enrollee device, the commissioning device and the enrollee device being configured to communicate using a wireless communication protocol and to participate in the configuration protocol, the configuration protocol comprising: providing, by the enrollee device to the commissioning device using out-of-band (OOB) communications, a first public key and at least one indication of a type of a second public key, the indication indicating a type other than the type of the first public key; and if the at least one indication of a second public key type indicates a key type different from the first public key type, selecting at least one type of key from the at least one index, all types in the selection being different from the type of the first public key; sending a first message using the wireless communication protocol, the first message requesting a second public key of a type corresponding to one of the key types in the selection, the second public key being used by the commissioning device to enable the enrollee device to connect to the wireless network; sending, by the enrollee device, a second message including a second public key of the key type requested in the first message; The enrollee device and the commissioning device complete the setup protocol using a key type corresponding to the selection, and the enrollee device attempts to connect to the wireless network.

2. 1. A method of configuring an enrollee device for communication in a wireless network by executing a configuration protocol, the method being configured to be performed by a commissioning device and an enrollee device, the commissioning device and the enrollee device being configured to communicate using a wireless communication protocol and to participate in the configuration protocol, the configuration protocol comprising: providing, by the enrollee device to the commissioning device using out-of-band (OOB) communications, the first public key and at least one indication of a type of the second public key; and if the at least one indication of a second public key type indicates a key type different from the first public key type, selecting at least one type of key from the at least one index, all types in the selection being different from the type of the first public key; using a third key of a type corresponding to the type of any of the keys in the selection to sign a data object, the data object being configured to be transmitted to the enrollee device and used by the enrollee device to attempt a connection to the wireless network; completing the configuration protocol with the enrollee device and the commissioning device using a key of a type corresponding to the selection and attempting to connect to the wireless network using the data object; wherein the selection and signing of the data object occurs after the enrollee device provides the first public key and the at least one indication of the type of the second public key to the commissioning device using the OOB communication and before a first attempt to connect to the wireless network is made.

3. 3. The method of claim 1, wherein if the at least one indicator of a second public key type indicates a key type that is the same as the first public key type, the at least one indicator uses smaller data elements than data elements used if the at least one indicator of a second public key type indicates a key type that is different from the first public key type.

4. 3. The method of claim 1, wherein the commissioning device terminates execution of the configuration protocol before completion if the at least one indication of a second public key type indicates only the same type of the first public key type.

5. 3. The method of claim 1, wherein the commissioning device terminates execution of the configuration protocol before completion if the at least one indication of a second public key type does not include a public key type that can be used by the commissioning device.

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

7. The method of claim 1 or 2, wherein the configuration protocol is the Device Provisioning Protocol (DPP).

8. The method of claim 7 , wherein the at least one indication of the type of the second public key is included in a bitmask portion of a DPP bootstrap URL.

9. 2. The method of claim 1, wherein the selection of the at least one type of key and the transmission of the first message occur after the enrollee device provides the first public key and the at least one indication of a second public key type to the commissioning device using the OOB communication and before the enrollee device first attempts to connect to the wireless network.

10. an enrollee device configured to communicate using a wireless communication protocol and configured to be configured by a commissioning device for communication in a wireless network, the enrollee device having a transceiver configured for communication in the wireless network; The enrollee device is participating in a configuration protocol configured to configure the enrollee device; providing, using out-of-band (OOB) communications, a first public key and at least one indication of a type of a second public key for use in a first phase of the configuration protocol, the indication indicating a type other than the type of the first public key; configured to receive a first message from a commissioning device via the transceiver using the wireless communication protocol; the first message includes a request indicating one or more types of second public keys, the types of the second public keys being different from the types of the first public keys; The enrollee device further comprises: sending a second message to the commissioning device via the transceiver using the wireless communication protocol, the second message including a second public key of the type requested in the first message; attempting to connect to the wireless network as a result of the setting; The enrollee device is configured to:

11. an enrollee device configured to communicate using a wireless communication protocol and configured to be configured by a commissioning device for communication in a wireless network, the enrollee device having a transceiver configured for communication in the wireless network; The enrollee device is participating in a configuration protocol configured to configure the enrollee device; providing, using out-of-band (OOB) communications, a first public key and at least one indication of a type of a second public key for use in a first phase of the configuration protocol, the indication indicating a type other than the type of the first public key; decrypting the data object signed by the commissioning device using a third key selected by the commissioning device from the at least one indicator, the third key being of a different type than the first public key; configured to attempt to connect to the wireless network as a result of the setting; The enrollee device, wherein the decryption of the data object occurs after the enrollee device provides the first public key and the at least one indication of the type of the second public key to the commissioning device using the OOB communication and before a first attempt to connect to the wireless network is made.

12. 12. An enrollee device according to claim 10 or 11, configured to provide a second public key of a type having the greatest cryptographic strength if the request indicates multiple types of public keys.

13. 12. An enrollee device according to claim 10 or 11, which is a simple device.

14. 12. The enrollee device of claim 10 or 11, wherein the at least one indication of the type of the second public key is included in a bitmask portion of a DPP bootstrap URL.

15. 11. The enrollee device of claim 10, wherein receiving the first message and transmitting the second message occurs after providing the at least one indication of the type of the first public key and the second public key by the enrollee device to the commissioning device using OOB communications and before the enrollee device first attempts to connect to the wireless network.

16. 1. A device configured to operate as a commissioning device and configured to configure an enrollee device for communication in a wireless network, comprising: the device has a transceiver configured to transmit and receive according to a wireless communication protocol; The device comprises: Participate in the configuration protocol, obtaining from the enrollee device via out-of-band (OOB) communications a first public key and at least one indication of a second type of public key to be used as part of the configuration protocol; configured to select at least one type of key based on the at least one indicator if the at least one indicator indicates a key type different from the type of the first public key, all types in the selection being different from the type of the first public key; The apparatus further comprises: A device configured to transmit, using the transceiver and the wireless communication protocol, a first message to the enrollee device requesting a second public key of a key type corresponding to one of the key types in the selection.

17. 1. A device configured to operate as a commissioning device and configured to configure an enrollee device for communication in a wireless network, comprising: the device has a transceiver configured to transmit and receive according to a wireless communication protocol; The device comprises: Participate in the configuration protocol, obtaining from the enrollee device via out-of-band (OOB) communications a first public key and at least an indication of a type of second public key to be used as part of the configuration protocol; configured to select at least one type of key based on the at least one indicator if the at least one indicator indicates a key type different from the type of the first public key, all types in the selection being different from the type of the first public key; The apparatus further comprises: configured to use a third key of a type corresponding to the type of key in the selection to sign a data object and transmit the signed data object to the enrollee device via the transceiver using the wireless communication protocol, the data object being configured to be used by the enrollee device to attempt a connection to the wireless network; The selection and use of the third key occurs after obtaining the first public key and the at least one indication of the type of the second public key from the enrollee device via the OBB communication and before the enrollee device first attempts to connect to the wireless network.

18. 18. The apparatus of claim 16 or 17, configured to terminate before completing configuration of the enrollee device if the indicator shows only key types that are the same as the type of the first public key.

19. 18. The apparatus of claim 16 or 17, configured to terminate before completion of configuration of the enrollee device if the at least one indicator does not indicate a type of key that the device can use.

20. 17. The device of claim 16, wherein the selecting of the at least one type of key and the sending of the first message occurs after the enrollee device provides the first public key and the at least one indication of a type of second public key to the commissioning device using the OOB communication and before the enrollee device first attempts to connect to the wireless network.

21. A computer program product which, when executed by a processor of an enrollee device, causes the enrollee device to perform the method according to claim 1 or 2.

22. A computer program product, when executed by a processor of a commissioning device, causing the commissioning device to carry out the method according to claim 1 or 2.

Images