Obtaining a configurator public key for authentication

CN122846112APending Publication Date: 2026-09-29HEWLETT PACKARD ENTERPRISE DEV LP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511008991.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2025-03-28
Filing Date
2025-07-22
Publication Date
2026-09-29

Smart Images

  • Figure CN122846112A_ABST
    Figure CN122846112A_ABST
Patent Text Reader

Abstract

Embodiments of this disclosure relate to obtaining a configurator public key for authentication. In some examples, an electronic device includes a wireless interface. The electronic device sends a first message, including a device identifier of the electronic device, to an access point (AP) via the wireless interface to discover a wireless network. The electronic device receives a second message from the AP in response to the first message, the second message including an encrypted configurator public key. The electronic device decrypts the encrypted configurator public key to generate a decrypted configurator public key. The electronic device uses the decrypted configurator public key during the authentication process between the electronic device and the configurator of the wireless network.
Need to check novelty before this filing date? Find Prior Art

Description

Background Technology

[0001] Wireless electronic devices can establish wireless connections with access points (APs) in a wireless network to communicate with other endpoint devices. To establish a wireless connection, an authentication process is performed between the wireless electronic device and the AP. Attached Figure Description

[0002] Some implementations of this disclosure are described with reference to the following figures.

[0003] Figure 1 It is a block diagram based on some examples of the layout of registrant devices, configurators, management systems, and registrant device management repositories;

[0004] Figure 2 This is a flowchart, based on some examples, of the process for obtaining the configurator public boot key used in the mutual authentication process;

[0005] Figure 3 These are block diagrams of some example electronic devices;

[0006] Figure 4 It is based on the block diagram of some example configurators; and

[0007] Figure 5 It is a block diagram of a storage medium with machine-readable instructions based on some examples of storage.

[0008] Throughout the accompanying drawings, the same reference numerals denote similar but not necessarily identical elements. These figures are not necessarily drawn to scale, and the sizes of some parts may be exaggerated for clarity of the examples shown. Furthermore, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. Detailed Implementation

[0009] An example of a wireless network is a Wi-Fi network. To efficiently onboard a large number of wireless electronic devices into a Wi-Fi network, a process following the Wi-Fi Easy Connectivity Specification (also known as the Device Configuration Protocol, DPP) can be used. The DPP onboarding process includes a mutual authentication process where two devices authenticate each other. These two devices can include wireless electronic devices on the Wi-Fi network and access points (APs). An AP is an access device with which wireless electronic devices can establish a wireless connection so that they can communicate over the Wi-Fi network. The devices participating in the mutual authentication process include an initiator (the first device, which sends an authentication request to initiate the authentication process) and a responder (the second device, which responds to the authentication request from the initiator). The mutual authentication process allows the two devices to verify each other's identities to ensure secure communication.

[0010] A wireless electronic device (UAV) joining a Wi-Fi network to use DPP can be referred to as a "registrant device" (or more simply a "registrant"), and the access point (AP) (or another network device) joining the UAV's Wi-Fi network is referred to as a "configurer device" (or more simply a "configurer"). Note that during the mutual authentication process, either the registrant or the configurator can act as the initiator, while the other acts as the responder. To perform the mutual authentication process, the initiator and responder use each other's public boot keys. The initiator has a public boot key and a private boot key, which together form the initiator boot key pair. Similarly, the responder has a public boot key and a private boot key, which together form the responder boot key pair. The UAV (as the initiator or responder in the mutual authentication process) can use any of several technologies to obtain the configurator's public boot key (the configurator's public boot key). Some of these technologies involve using the UAV's secondary (or out-of-band) communication interface, such as Bluetooth Low Energy (BLE) or Near Field Communication (NFC). In some cases, wireless electronic devices (such as headless devices) have a Wi-Fi communication interface but lack a secondary communication interface (such as a BLE or NFC communication interface). Therefore, such wireless electronic devices cannot use the secondary communication interface to obtain the configurator public boot key. Other technologies used to obtain the configurator public boot key involve using the user interface of the wireless electronic device, such as a display and input device (e.g., a touchscreen, keyboard, pointing device, etc.). Headless devices may also lack a user interface, meaning that headless devices cannot use technologies involving user interfaces to obtain the configurator public boot key.

[0011] If a wireless electronic device cannot obtain the configurator's public boot key, the mutual authentication process between the wireless electronic device (registrant) and the configurator cannot be performed. If the wireless electronic device cannot successfully perform the mutual authentication process, it cannot join the wireless network. According to some implementations of this disclosure, systems and techniques are provided for securely obtaining the configurator boot key via a wireless electronic device (such as a headless device or other types of electronic equipment). A headless device can refer to an electronic device lacking certain capabilities (such as a secondary communication interface and / or a user interface).

[0012] A "secondary communication interface," also known as an "out-of-band communication interface," is an interface outside the main wireless interface of an electronic device, used for communication with the access point (AP) of the wireless network. A "user interface" refers to an interface that a user of an electronic device can use to input and / or output information related to the electronic device. A user interface may include any one or a combination of the following: a display screen, an input device such as a touchscreen, a keyboard or pointing device, or any other component through which the user can input or receive information from the electronic device.

[0013] In some examples of this disclosure, the electronic device sends a first message, including the device identifier of the electronic device, to the access point (AP) via its wireless interface. This first message is sent by the electronic device to discover the wireless network. The electronic device receives a second message from the AP in response to the first message, the second message including an encrypted configurator public boot key. The electronic device decrypts the encrypted configurator public boot key to generate a decrypted configurator public boot key, and uses the decrypted configurator public boot key during DPP authentication between the electronic device and the configurator of the wireless network.

[0014] A "boot key" can refer to a cryptographic key used for secure operations, including device authentication. For example, a boot key can be used to perform a mutual authentication process between a registrant and a configurator. A boot key can also be used to derive other secrets, such as a symmetric encryption key, which is used to encrypt and decrypt information during the mutual authentication process.

[0015] The first device's "public" boot key can be shared with the second device. For example, the registrant's public boot key can be shared with the configurator, and the configurator's public boot key can be shared with the registrant. The public boot key can be part of a boot key pair that also includes a private boot key. The device's "private" boot key is stored on the device and is not shared with other devices.

[0016] A "configurator" refers to a device (or set of devices) that can join another device ("registrant") to use network resources, including those of wireless networks such as Wi-Fi. In other examples, a configurator can join devices used for other types of wireless networks. Joining a wireless network involves setting up (configuring) the registrant so that it can use the network's resources. Joining includes an authentication process in which the first device can verify the identity of the second device. A mutual authentication process enables both the first and second devices to verify each other's identities.

[0017] In some examples of this disclosure, the system and techniques improve computer functionality or related technologies for wireless communication by enabling registrant devices with limited functionality to securely obtain the configurator public boot key used in the authentication process. The configurator public boot key can be obtained without using the registrant device's secondary communication interface and / or user interface. The configurator public boot key can be protected from exposure or tampering by sending an encrypted configurator public boot key from the configurator to the registrant device. When sending the configurator public boot key to different registrant devices, the configurator public boot key is encrypted using different encryption keys for each registrant device, thereby protecting it from tampering even when multiple registrant devices are connected to the same configurator. In some examples, the transmission of the encrypted configurator public boot key can be performed without modifying the relevant protocols, such as DPP or other similar protocols associated with the joining device.

[0018] Figure 1 This is a block diagram of an example layout, which includes registrant devices 101 and 102, a configurator 104, a registrant device management repository 106, and a management system 108 associated with the manufacturer or another provider (e.g., distributor, retailer, service provider, etc.) of registrant devices 101 and 102. Although Figure 1 Two registrant devices are shown in the example, but in other examples, there may be a different number of registrant devices.

[0019] In some examples, if the management system 108 is associated with the manufacturer of registrant devices 101 and 102, the management system 108 may be located at the manufacturer's factory or other facility. During the manufacturing of the registrant devices, the management system 108 may connect to the registrant devices to receive specific information from them (including keys, discussed further below). More generally, the management system 108 is responsible for obtaining specific information about the registrant devices in a secure environment. The management system 108 may be implemented using one or more computers.

[0020] The registrant device management repository 106 can be implemented using one or more storage devices. The registrant device management repository 106 can be part of a backend environment 107 (e.g., a cloud environment, a data center, or any other remotely accessible computing environment), which the configurator 104 can access via a network such as a local area network (LAN), wide area network (WAN), public network, or another type of network. Although shown separately from the management system 108, in other examples, the registrant device management repository 106 may also be part of the management system 108.

[0021] The configurator 104 includes an access point 120 for a wireless network. In some examples, the wireless network is a Wi-Fi network. In other examples, the wireless network can be a different type of wireless network.

[0022] In some examples, configurator 104 also includes configurator server 110, which can be part of a cloud environment, data center, server computing environment, or any other type of computing environment accessible to AP 120. Although Figure 1 Only one AP is shown in the example, but in other examples, there may be multiple APs in a wireless network.

[0023] In a further example, the functionality of configurator server 110 can be integrated into AP 120. More generally, configurator 104 can include one or more devices, which may include only AP 120, or AP 120 in combination with configurator server 110.

[0024] Each registrant device 101 or 102 can create a cryptographic key. Specifically, registrant device 101 includes a key generator 171 for creating a cryptographic key; and registrant device 102 includes a key generator 172 for creating a cryptographic key. In some examples, the cryptographic key that each registrant device 101 or 102 can generate includes a bootstrap key and a mutual authentication key. As mentioned above, the bootstrap key is used in the mutual authentication process between the registrant and the configurator 104. The mutual authentication key is used to encrypt or decrypt the bootstrap key.

[0025] The key generator 171 in registrant device 101 can create a registrant bootstrap key pair 121 and a registrant mutual authentication key pair 131 for registrant device 101. The registrant bootstrap key pair 121 includes a registrant private bootstrap key represented as registrant 1bk (E1bk) and a registrant public bootstrap key represented as registrant 1BK (E1 BK). The registrant mutual authentication key pair 131 includes a registrant private mutual authentication key represented as E1 mak and a registrant public mutual authentication key represented as E1 MAK.

[0026] The key generator 172 in registrant device 102 can create a registrant bootstrap key pair 122 and a registrant mutual authentication key pair 132 for registrant device 102. The registrant bootstrap key pair 122 includes a registrant private bootstrap key represented as E2 bk and a registrant public bootstrap key represented as E2 BK. The registrant mutual authentication key pair 132 includes a registrant private mutual authentication key represented as E2 mak and a registrant public mutual authentication key represented as E2 MAK.

[0027] The registrant bootstrap key pair 121 and the mutual authentication key pair 131 are stored by the key generator 171 in a secure storage device of the registrant device 101. The secure storage device may include memory within the secure processor of the registrant device. An example of a secure processor is a Trusted Platform Module (TPM). Therefore, key pairs 121 and 131 can be stored in the TPM 141 of the registrant device 101.

[0028] Similarly, the registrant bootstrap key pair 122 and the mutual authentication key pair 132 are stored by the key generator 172 in a secure storage device of the registrant device 102, such as in the TPM 142 of the registrant device 102.

[0029] A security processor is used by the registrant device to perform security operations within the registrant device. A security processor (sometimes called a secure cryptographic processor) can perform various hardware-based security functions on a physical platform. The security functions of a security processor can include the management and generation of keys and certificates. For example, the security processor can use and securely store the cryptographic keys used in secure operations.

[0030] When registrant device 101 is securely connected to management system 108, registrant device 101 can send E1 BK and E1 MAK to management system 108. Similarly, when registrant device 102 is securely connected to management system 108, registrant device 102 can send E2 BK and E2 MAK to management system 108. Upon request from key manager 124 in management system 108, or based on a public key being pushed to management system 108 by the registrant device, the registrant device can send its public key to management system 108. The secure connection between management system 108 and the registrant device can be a wired or wireless connection. A connection is secure if it is protected against unauthorized access or tampering.

[0031] In some examples, key manager 124 may send (at 126) the registrant public key obtained by key manager 124 to registrant device management repository 106. When stored in registrant device management repository 106, the registrant public key can be used by other entities, including configurator 104. Specifically, key manager 124 sends (at 126) the registrant public key (e.g., E1 BK, E1 MAK, E2 BK, and E2 MAK) to registrant device management repository 106 for storage. Furthermore, key manager 124 sends (at 126) registrant identifiers (IDs) to registrant device management repository 106, including an E1 ID (which identifies registrant device 101) and an E2 ID (which identifies registrant device 102). The E1 ID can be calculated by key generator 171 in registrant device 101 and provided to key manager 124, and the E2 ID can be calculated by key generator 172 in registrant device 102 and provided to key manager 124. Alternatively or additionally, the key manager 124 can also calculate the E1ID and E2ID, as discussed further below.

[0032] The registrant ID and registrant public key can be stored in data structure 127, which can be in the form of a table, list, or another data structure. Data structure 127 can have multiple entries, including a first entry and a second entry. The first entry includes E1 ID, E1 BK, and E1 MAK, and the second entry includes E2 ID, E2 BK, and E2 MAK. Data structure 127 may include other entries from other registrant devices.

[0033] The configurator server 110 can retrieve registrant device information from data structure 127 (at 128) based on either a pull or push transfer. via a pull transfer, the configuration server 110 sends a request for the registrant public key to the registrant device management repository 106, which responds by sending the registrant public key (and corresponding registrant ID) to the configuration server 110. Alternatively, via a push transfer, when the registrant device management repository 106 receives the registrant public key, it can push the registrant public key (and corresponding registrant ID) to the configurator server 110.

[0034] The registrant device information obtained from the registrant device management repository 106 can be stored in a data structure 111 that is formatted similarly to data structure 127.

[0035] Using some examples Figure 1In this configuration, the registrant device (e.g., registrant device 101 or 102) can obtain the configurator public boot key (denoted as CBK) for use in the mutual authentication process between the registrant and configurator 104. The configurator public boot key can be obtained through the registrant device's main interface (e.g., a Wi-Fi interface). As a result, the registrant device does not need to rely on using secondary communication interfaces or user interfaces that may not be available at the registrant device to obtain the configurator public boot key.

[0036] The configurator public boot key CBK is a part of the configurator boot key pair 114 stored in the memory 116 of the configurator server 110. The configurator boot key (configurator BK) is a part of the configurator boot key pair 114, which also includes the configurator private boot key (represented as CBK).

[0037] like Figure 1 As further shown, the registrant device includes a key requester and an authenticator. The key requester is used to send a request for the configurator's public boot key CBK, and the authenticator is used to perform authentication processes, such as the mutual authentication process between the registrant and the configurator 104. Registrant device 101 includes a key requester 151 and an authenticator 161, and registrant device 102 includes a key requester 152 and an authenticator 162.

[0038] AP 120 includes a key provider 130, which provides a configurator public boot key C BK in response to a request from a registrant device. For example, in Figure 1 In this process, the registrant device (101 or 102) can send a probe request (at 144) to AP 120 in configurator 104.

[0039] In response to a probe request from a registrant device, key provider 130 may send a key request 134 to configurator server 110, which retrieves the configurator public boot key CBK from memory 116. Key encryptor 136 in configurator server 110 encrypts the CBK to produce an encrypted CBK 138. Configurator server 110 sends the encrypted CBK 138 to AP 120 for transmission to the registrant device that sent the request for the configurator public boot key. For example, AP 120 may send (at 146) a probe response including the encrypted CBK.

[0040] In a further example, in addition to probe requests and probe responses, other messages may be exchanged between the registrant device and the configurator 104. These other messages may include other types of management messages used to perform control activities between the registrant device and the configurator 104. Furthermore, alternatively, in an example where AP 120 and configurator server 110 are integrated into the system, key requests 134 and encrypted CBKs 138 may include internal information exchange within the system.

[0041] During mutual authentication, the bootstrap key is used by the registrant and configurator to establish a trust and secure channel. Private bootstrap keys (e.g., registrant private bootstrap key E1 bk or E2 bk, and configurator private bootstrap key C bk) are used to generate session keys and protect authentication information.

[0042] The following discussion involves Figure 1 and Figure 2 . Figure 2 This is a flowchart of the process involving the management system 108, the registrant device management repository 106, the registrant device 101, and the configurator 104. A similar process can be performed in conjunction with registrant device 102 (or any other registrant device). Figure 2 This example illustrates tasks executed in a specific order. In other examples, these tasks can be executed in a different order, some tasks can be omitted, and additional tasks can be added.

[0043] Figure 2 The process includes a setup phase 202 and a deployment phase 204. Setup phase 202 can be performed during manufacturing or another initial phase associated with registrant device 101. Deployment phase 204 is performed after registrant device 101 is deployed to the site where it will be put into operation. Setup phase 202 includes tasks 210 to 222. Deployment phase 204 includes tasks 230 to 242.

[0044] The key generator 171 in registrant device 101 generates (at 210) a registrant key pair for registrant device 101, which includes a registrant bootstrap key pair 121 and a registrant mutual authentication key pair 131. Registrant device 101 sends (at 212) the registrant public keys (E1 BK and E1 MAK) to management system 108 via a secure connection. Registrant device 101 stores the registrant key pair (at 214) in TPM 141.

[0045] The key manager 124 in the management system 108 sends (at 216) the registrant device information of registrant device 101 to the registrant device management repository 106, which stores (at 218) the received registrant device information in a data structure such as 127. The registrant device information includes the registrant public key (E1 BK and E1 MAK). Furthermore, the registrant device information includes a registrant device identifier (ID) created for registrant device 101. This registrant device ID for registrant device 101 is called the E1 ID. The E1 ID uniquely identifies registrant device 101 and is different from the device ID of any other registrant device. For example, the device ID of registrant device 102 is an E2 ID, which is different from the E1 ID. In some examples, the E1 ID may be created by the key generator 171 in registrant device 101 and provided to the key manager 124. Similarly, the E2 ID may be created by the key generator 172 in registrant device 102 and provided to the key manager 124. Alternatively or additionally, the key manager 124 can also calculate the E1 ID and E2 ID.

[0046] In some examples, the E1 ID is based on a function applied to the registrant's public bootstrap key E1 BK. This function can include a cryptographic hash function, such as a Secure Hash Algorithm (SHA) hash function, a Message Digest (MD5) algorithm, or another cryptographic hash function. In further examples, the E1 ID can be derived by applying this function to the registrant's public bootstrap key E1 BK and other information, such as a random number.

[0047] The configurator server 110 of configurator 104 retrieves (at 220) the registrant device information of registrant device 101 from the registrant device management repository 106. The configurator server 110 stores (at 222) the retrieved registrant device information (including E1 ID, E1 BK, and E1 MAK) in the memory 116 of the configurator server 110. For example, the E1 ID, E1 BK, and E1 MAK can be added as entries to data structure 111.

[0048] In deployment phase 204, registrant device 101 may send (at 230) a request to configurator 104 to obtain the configurator public boot key CBK. In some examples, this request includes a management message sent to AP 120 of configurator 104. For example, the management message may be a management message conforming to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. More specifically, the request may include a probe request including an E1 ID. IEEE 802.11 probe requests are sent by electronic devices to discover wireless networks within the range of the electronic device. The probe request may also announce the capabilities of the electronic device, including supported data rates and other capabilities. APs within range of the electronic device that received the probe request may issue a probe response, which is then sent to the electronic device.

[0049] As mentioned above, the E1 ID can be a hash value obtained by applying a hash function to the registrant's public bootstrap key E1 BK. By using the hash value as the E1 ID, instead of including the E1 BK directly in the probe request, device privacy can be protected while maintaining the uniqueness of the registrant identifier and improving security. Furthermore, the hashed registrant identifier has a fixed length, making storing and transmitting the hashed registrant identifier more efficient.

[0050] In some examples, the probe request includes a vendor-specific element that includes various fields, including a field for the registrant's device ID. For instance, according to Section 9.4.2.25 of the IEEE 802.11-2020 specification, vendor-specific elements are used to carry information not defined in the IEEE 802.11 standard. Vendor-specific elements can have the following formats:

[0051]

[0052] The Element ID field has a specified value defined by the IEEE 802.11 standard to indicate a supplier-specific element. The Length field indicates the length of the supplier-specific element and does not include the Element ID and Length fields. The Organization Identifier field identifies the entity that defines the content for the supplier-specific element (e.g., a business organization or another type of organization).

[0053] According to some examples of this disclosure, supplier-specific content fields include the registrant device ID (e.g., E1 ID) of the registrant device, and encryption algorithm information specifying the encryption algorithm to be used by the configurator 104 when encrypting data, including the configurator public bootstrap key CBK. The encryption algorithm can be selected based on the mutual capabilities and preferences of the registrant and the configurator 104. Some examples of encryption algorithms include any one or some combination thereof: Elliptic Curve Integration Cryptography (ECIES) algorithm, asymmetric encryption algorithm (RSA) algorithm, or another encryption algorithm.

[0054] In other examples, the supplier-specific elements in the message may have other formats defined by other standards, open-source licenses, or proprietary licenses. More generally, a request for the configurator public boot key CBK sent by the registrant device may be a management frame, such as a probe request according to IEEE 802.11, which includes a supplier-specific element including the registrant device ID.

[0055] Key provider 130 in AP 120 parses (at 232) the probe request and extracts the E1 ID and encryption algorithm information from the provider-specific elements in the probe request. Key provider 130 may send key request 134 to configurator server 110, wherein key request 134 includes the extracted E1 ID and encryption algorithm information.

[0056] Based on the E1 ID, the configurator server 110 obtains (at 234) the registrant public mutual authentication key E1 MAK of the registrant device 101 identified by the E1 ID. Note that the memory 116 stores multiple registrant public mutual authentication keys for different registrant devices. These multiple registrant public mutual authentication keys can be stored in a data structure 111 with multiple entries that associate different registrant IDs with their corresponding registrant public keys. The E1 ID can be used to perform a lookup of the data structure 111 to retrieve an entry that includes the registrant public mutual authentication key E1 MAK associated with the E1 ID in the data structure 111.

[0057] The key encryptor 136 in configurator server 110 encrypts the CBK with E1 MAK using the encryption algorithm specified in the encryption algorithm information in key request 134 (at 236). Configurator server 110 sends the encrypted CBK to AP 120. Key provider 130 in AP 120 sends a probe response to registrant device 101 (at 238), wherein the probe response includes the encrypted CBK.

[0058] The probe response may include supplier-specific elements, such as those conforming to IEEE 802.11-2020. The format of the supplier-specific elements in the probe response is similar to that in the probe request, except that the supplier-specific content in the probe response includes an encrypted configurator public boot key (encrypted CBK).

[0059] By using supplier-specific elements in the message to transmit the registrant device ID and the encrypted configurator public bootstrap key, different suppliers (e.g., manufacturers or other entities) can customize data fields to carry information in different ways. This enhances flexibility and makes it easy to support protocols (e.g., DPP) that define communication exchanges for joining registrant devices.

[0060] The key requester 151 in registrant device 101 decrypts the encrypted CBK (at 240) using the registrant private mutual authentication key E1 mak retrieved from TPM 141 in registrant device 101. This decryption uses the encryption algorithm specified in the encryption algorithm information of the probe request sent by registrant device 101. This decryption produces a decrypted version of the encrypted CBK, referred to as the decrypted CBK.

[0061] The decrypted CBK is the configurator public boot key, which is used by registrant device 101 during the mutual authentication process with configurator 104. The authenticator 161 in registrant device 101 can perform the mutual authentication process by sending a message to configurator 104 (at 242). In an example where the mutual authentication process is part of a DPP exchange, the message sent may include a DPP presence announcement instructing registrant device 101 to be ready to participate in the mutual authentication process.

[0062] Figure 3 This is a block diagram of an electronic device 300 according to some examples of this disclosure. Electronic device 300 is... Figure 1 Examples of registrant devices 101 or 102.

[0063] Electronic device 300 includes a wireless interface 302, such as a Wi-Fi interface for communicating via a Wi-Fi network or another type of wireless interface for communicating via another type of wireless network. The wireless interface may include a transceiver for transmitting and receiving wireless signals, and one or more protocol layers for managing communication according to one or more corresponding communication protocols.

[0064] Electronic device 300 includes hardware processor 304 (or multiple hardware processors). The hardware processor may include a microprocessor, the core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.

[0065] Hardware processor 304 can perform various tasks. The hardware processor used to perform a task can refer to a single hardware processor or multiple hardware processors used to perform a task.

[0066] The tasks of the hardware processor 304 can be performed by machine-readable instructions that execute on the hardware processor 304. Alternatively or additionally, the tasks of the hardware processor 304 can be performed by the hardware circuitry within the hardware processor 304.

[0067] The hardware processor 304 includes a device identifier message transmission task 306, which sends a first message containing the device identifier of an electronic device to the access point (AP) via the wireless interface 302. This first message is sent by the electronic device to discover the wireless network. In some examples, the first message includes an IEEE 802.11 probe request. In other examples, the first message may include different management messages.

[0068] The hardware processor 304 includes a task 308 for receiving an encrypted configurator key message, which is used at the electronic device to receive a second message from the AP in response to the first message, the second message including an encrypted configurator public key. For example, the encrypted configurator public key can be generated by encrypting the configurator public key using a registrant public mutual authentication key. In some examples, the second message includes an IEEE 802.11 probe response. In other examples, the second message may include different management messages.

[0069] The hardware processor 304 includes a configurator public key decryption task 310, which decrypts the encrypted configurator public key to generate a decrypted configurator public key. For example, decryption can use a registrant's private mutual authentication key.

[0070] The hardware processor 304 includes an authentication task 312, which uses a decrypted configurator public key in an authentication process (e.g., a DPP authentication process) between an electronic device and a configurator of a wireless network. For example, the authentication process may include a mutual authentication process.

[0071] In some examples, the device identifier is based on the registrant's public key for the electronic device. The registrant's public key can be the registrant's public bootstrap key.

[0072] In some examples, the device identifier is based on a hash value derived from a hash function of the registrant's public key applied to the electronic device.

[0073] In some examples, the encrypted configurator public key is generated by encrypting the configurator public key using the electronic device's registrant's public mutual authentication key.

[0074] In some examples, electronic device 300 uses the registrant's private mutual authentication key to decrypt the encrypted configurator public key.

[0075] In some examples, the device identifier is included in the provider-specific element of the management message, such as the IEEE 802.11 probe request.

[0076] In some examples, the supplier-specific elements for managing messages also include information specifying the type of encryption algorithm used at the configurator to encrypt the configurator's public bootstrap key.

[0077] In some examples, the device identifier in the first message distinguishes an electronic device from another electronic device associated with a different device identifier.

[0078] In some examples, the electronic device has neither a secondary communication interface nor a user interface.

[0079] Figure 4 This is a block diagram of a configurator 400 based on some examples of this disclosure. Figure 1 Configurator 104 is an example of Configurator 400. Configurator 400 can be implemented using one or more devices, such as... Figure 1 The AP 120 and configurator server 110 are examples. In other examples, the configurator 400 is implemented using a single device that combines the functionality of the AP 120 and the configurator server 110.

[0080] The configurator 400 includes a wireless interface 402 for wireless communication with electronic devices. The configurator 400 also includes a hardware processor 404 (or multiple hardware processors) for performing various tasks. The tasks of the hardware processor 404 can be performed by machine-readable instructions executed on the hardware processor 404. Alternatively or additionally, the tasks of the hardware processor 404 can be performed by a hardware circuitry system within the hardware processor 404.

[0081] The hardware processor 404 includes a device identifier message receiving task 406, which receives a first message containing the device identifier of an electronic device via the wireless interface 402. The first message is sent by the electronic device to discover the wireless network.

[0082] The hardware processor 404 includes a device key acquisition task 408, which retrieves a first key associated with the device identifier in response to a first message. For example, the first key could be a public mutual authentication key for the registrant of an electronic device.

[0083] The hardware processor 404 includes a configurator public key encryption task 410, which encrypts the configurator public key using a first key to obtain an encrypted configurator public key. For example, the encrypted configurator public key could be a configurator public boot key.

[0084] The hardware processor 404 has tasks including an encrypted configurator key message sending task 412, which is used to send a second message including an encrypted configurator public key to an electronic device via the wireless interface 402.

[0085] The hardware processor 404 includes an authentication task 414, which performs an authentication process with the electronic device based on a decrypted version of the encrypted configurator public key.

[0086] In some examples, the configurator 400 includes memory for storing data structures (e.g., Figure 1 (111 in the first message), the data structure includes entries that associate different device identifiers with corresponding keys (e.g., registrant public boot key and registrant public mutual authentication key). The hardware processor 404 accesses the data structure using the device identifier in the first message to look up the first key.

[0087] In some examples, the data structure comes from a data repository (e.g., Figure 1 106 in the figure is filled in, wherein the management system (e.g., 108 in the figure) sends the registrant device information of the corresponding electronic device to the data repository, wherein the registrant device information of the electronic device includes the device identifier and the first key of the electronic device.

[0088] In some examples, the first key is a public key for the electronic device, and the decrypted version of the encrypted configurator public key is based on the decryption of the encrypted configurator public key at the electronic device using the private key corresponding to the public key.

[0089] Figure 5 This is a block diagram of a non-transitory machine-readable or computer-readable storage medium 500 that stores machine-readable instructions, which, when executed, enable a configurator (e.g., Figure 1 104) performs various tasks.

[0090] The machine-readable instructions include a device identifier message receiving instruction 502, which is used to receive a first message sent by an electronic device to discover a wireless network. The first message includes the device identifier of the electronic device and encryption algorithm information specifying the encryption algorithm to be used by the configurator.

[0091] Machine-readable instructions include Registrant Key Acquisition Instruction 504, which is used to acquire a registrant key associated with a device identifier in response to a first message. The registrant key may be a registrant public mutual authentication key. The registrant key can be used to execute data structures (e.g., using the device identifier) Figure 1 The lookup in 111) is used to retrieve the entry that includes the registrant's key.

[0092] The machine-readable instructions include configurator public key encryption instruction 506, which is used to encrypt the configurator public key using the registrant key with the encryption algorithm specified by the encryption algorithm information to obtain the encrypted configurator public key.

[0093] The machine-readable instructions include an encrypted configurator public key message sending instruction 508, which is used to send a second message including an encrypted configurator public key to an electronic device via a wireless interface.

[0094] The machine-readable instructions include authentication instruction 510, which is used to perform an authentication process with an electronic device based on a decrypted version of the encrypted configurator public key. The authentication process can be a mutual authentication process.

[0095] In some examples, the registrant key is a mutual authentication key between the registrants of the electronic device, and the device identifier is based on the registrant bootstrap key for the electronic device.

[0096] As used herein, an electronic device can mean any one or a combination of the following: Internet of Things (IoT) devices, handheld devices, or any other electronic device that has a primary wireless interface (e.g., a Wi-Fi interface) but no secondary communication interface and / or user interface.

[0097] Memory can be implemented using one or more memory devices, such as dynamic random access memory (DRAM) devices, static random access memory (SRAM) devices, flash memory devices, erasable programmable read-only memory (EPROM) devices, electrically erasable programmable read-only memory (EEPROM) devices, or other types of memory devices.

[0098] Figure 1 The key manager 124, key provider 130, key encryptor 136, key generator 171 or 172, key requester 151 or 152, and authenticator 161 or 162 can be implemented using machine-readable instructions executable by the processing resources of the respective devices. Alternatively, any of the above components can be implemented in hardware. The processing resources may include one or more hardware processors.

[0099] Storage media (e.g., Figure 5The 500 in the instruction set may include any one or a combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory; disks, such as fixed disks, floppy disks, and removable disks; another magnetic medium, including magnetic tape; optical media, such as compact discs (CDs) or digital video discs (DVDs); or another type of storage device. Note that the above instructions may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system that may have multiple nodes. Such computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture may refer to any single or multiple manufactured components. One or more storage media may be located in a machine that executes the machine-readable instructions or at a remote site from which the machine-readable instructions can be downloaded via a network for execution.

[0100] In this disclosure, unless the context clearly indicates otherwise, the use of the terms “a,” “an,” or “the” is also intended to include the plural form. Furthermore, when used in this disclosure, the terms “includes,” “including,” “comprises,” “comprising,” “have,” or “having” specify the presence of the stated element but do not exclude the presence or addition of other elements.

[0101] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations to the foregoing details. The appended claims are intended to cover such modifications and variations.

Claims

1. An electronic device, comprising: Wireless interface; as well as Hardware processor, used for: The first message, which includes the device identifier of the electronic device, is sent to the access point (AP) via the wireless interface to discover the wireless network. At the electronic device, a second message in response to the first message is received from the AP, the second message including an encrypted configurator public key; The encrypted configurator public key is decrypted to generate a decrypted configurator public key; as well as The decrypted configurator public key is used during the authentication process between the electronic device and the configurator of the wireless network.

2. The electronic device of claim 1, wherein the device identifier is based on the registrant public key of the electronic device.

3. The electronic device of claim 2, wherein the device identifier is based on a hash value derived from a hash function applied to the registrant's public key of the electronic device.

4. The electronic device of claim 1, wherein the encrypted configurator public key is generated by encrypting the configurator public key using the public mutual authentication key of the electronic device.

5. The electronic device according to claim 4, wherein the hardware processor is used for: The encrypted configurator public key is decrypted using the private mutual authentication key of the electronic device.

6. The electronic device of claim 1, wherein the first message comprises a management message in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard.

7. The electronic device of claim 6, wherein the device identifier is included in a supplier-specific element of the management message.

8. The electronic device of claim 7, wherein the supplier-specific element of the management message further comprises: Information specifying the type of encryption algorithm used to encrypt the configurator public key at the configurator.

9. The electronic device of claim 1, wherein the device identifier in the first message distinguishes the electronic device from another electronic device associated with a different device identifier.

10. The electronic device of claim 1, wherein the first message includes a probe request and the second message includes a probe response.

11. The electronic device of claim 1, wherein the second message comprises a management message in accordance with the IEEE 802.11 standard, and wherein the encrypted configurator public key is included in a supplier-specific element of the management message.

12. The electronic device of claim 1, wherein the electronic device has no auxiliary communication interface and no user interface.

13. The electronic device of claim 1, wherein the AP is part of the configurator.

14. A configurator, comprising: Wireless interface, used for wireless communication with electronic devices; as well as Hardware processor, used for: Through the wireless interface, a first message including the device identifier of the electronic device is received, the first message being sent by the electronic device to discover the wireless network; In response to the first message, a first key associated with the device identifier is obtained; The configurator public key is encrypted using the first key to obtain the encrypted configurator public key; A second message, including the encrypted configurator public key, is sent to the electronic device via the wireless interface. as well as The authentication process with the electronic device is performed based on the decrypted version of the encrypted configurator public key.

15. The configurator of claim 14, comprising: A memory for storing data structures, said data structures including entries that associate different device identifiers with corresponding keys. The hardware processor is used to locate the first key by accessing the data structure using the device identifier in the first message.

16. The configurator of claim 15, wherein the data structure is populated from a data repository, wherein the management system sends registrant device information of a corresponding electronic device to the data repository, wherein the registrant device information of the electronic device includes the device identifier of the electronic device and the first key.

17. The configurator of claim 16, wherein the first key is a registrant mutual authentication key, and the registrant device information of the electronic device further includes a registrant bootstrap key used by the configurator in the authentication process.

18. The configurator of claim 14, wherein the first key is a public key for the electronic device, and the decrypted version of the encrypted configurator public key is based on the decryption of the encrypted configurator public key at the electronic device using a private key corresponding to the public key.

19. A non-transitory machine-readable storage medium, the non-transitory machine-readable storage medium comprising instructions that, when executed, cause an configurator to: Receive a first message sent by an electronic device for discovering a wireless network, the first message including the device identifier of the electronic device and encryption algorithm information specifying an encryption algorithm; In response to the first message, obtain the registrant key associated with the device identifier; Using the encryption algorithm specified by the encryption algorithm information, the configurator public key is encrypted with the registrant key to obtain the encrypted configurator public key; A second message, including the encrypted configurator public key, is sent to the electronic device via a wireless interface. as well as The process performed with the electronic device is executed based on the decrypted version of the encrypted configurator public key.

20. The non-transitory machine-readable storage medium of claim 19, wherein the registrant key is a registrant mutual authentication key for the electronic device, and the device identifier is based on a registrant bootstrapping key for the electronic device.