Protection of Return Communication via Application Uniform Resource Locator

Abstract

Techniques and devices for protecting return communication via an application uniform resource locator are described with respect to commissioning a participant device to a home area network by an initiator device. In the home area network, the initiator device obtains a responder access uniform resource locator (URL), and uses the obtained responder access URL to generate an extended responder access URL. The initiator device accesses the extended responder access URL at the responder, whereby the responder generates a responder payload. The initiator device accesses an extended initiator response URL including the generated responder payload, recovers the responder payload, and by recovering the responder payload, the initiator device commissions the participant device to the home area network.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 364,017, filed May 2, 2022, the entire disclosure of which is incorporated herein by reference.

Background Art

[0002] Using wireless networking to connect devices to each other and to cloud - based services is becoming increasingly common for sensing environmental conditions, controlling devices, and providing information and alerts to users. Many devices on wireless networks are designed to operate on battery power for extended periods, which limits the computing, user interface, and wireless resources available on the device.

[0003] To ensure the security of these networks, the identities of devices participating in and operating on wireless networks and / or wired networks are authenticated, and communications within the network are encrypted based on credentials commissioned to the device. As these networks become more prevalent and grow in scale, commissioning techniques limit the quality of the user experience for commissioning, the accuracy of getting devices to join the correct network, securely injecting credentials into the device, and provisioning device - specific and application - specific information to the device during commissioning. As cross - vendor networking solutions evolve, there is an opportunity to improve secure commissioning communications across multi - vendor networks.

Summary of the Invention

[0004] The summary of the present invention is provided to introduce a simplified concept of protecting return communication via an application uniform resource locator, which generally relates to commissioning a device to a home area network. The simplified concept will be further described in the form of implementing the following invention. This summary of the invention is not intended to identify the essential features of the claimed invention, nor is it intended to be used in determining the scope of the claimed invention.

[0005] In an aspect, a method, device, system, and means for protecting return communication via an application uniform resource locator are described for an initiator device to commission a participant device to a home area network. In the home area network, the initiator device obtains a responder access uniform resource locator (URL), and uses the obtained responder access URL to generate an extended responder access URL. The initiator device accesses the extended responder access URL at the responder, thereby causing the responder to generate a responder payload. The initiator device accesses an extended initiator response URL including the generated responder payload, recovers the responder payload, and by recovering the responder payload, the initiator device commissions the participant device to the home area network.

[0006] In one aspect, a method, device, system, and means for protecting return communication via an application uniform resource locator are described for commissioning a responder to a participant device in a home area network, where the responder issues a responder access uniform resource locator (URL) and receives an extended responder access URL from an initiator device. The responder extracts an initiator-payload-ciphertext-and-tag tuple and decrypts the initiator-payload-ciphertext-tag tuple. The responder derives a shared secret using the responder's public key and a secret key associated with the initiator device's ephemeral public key, and uses an authenticated encryption with associated data (AEAD) algorithm to decrypt and authenticate the initiator payload. When the initiator payload is authenticated, the responder recovers the initiator payload and generates a responder payload for transmission to the initiator device.

[0007] Details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims. The summary of the invention is provided to introduce a further subject matter which is further described in the embodiments and drawings for carrying out the invention. Therefore, the summary of the invention should not be considered as defining the essential features, nor should it be used for limiting the scope of the claimed subject matter.

[0008] Aspects for protecting return communication via an application uniform resource locator are described with reference to the following drawings. The same numbers are used throughout the drawings to refer to like features and components.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

DETAILED DESCRIPTION OF THE INVENTION

[0010] This specification describes techniques and devices for providing secure communication for commissioning devices in a home area network (smart home network) such as a Matter (registered trademark) network, a Thread (registered trademark) network, a Weave (registered trademark) network, etc. For example, setting up a device using the Matter protocol requires an on-board payload that includes a passcode. Any entity capable of communicating with the device via a setup interface (e.g., Wi-Fi (registered trademark), Thread, BLE) can use this passcode to become the administrator (commissioner) of its participating devices.

[0011] Most of the setup flows for Matter are the standard flows of the Matter protocol and use the initial passcode scanned from the QR code (registered trademark) of the device participating in the network. However, some Matter setup flows are custom commissioning flows. In these custom commissioning flows, the device to be setup is not ready to allow the Matter setup (commissioning) protocol to proceed. Instead, the commissioning application has the requirement to obtain the custom flow Uniform Resource Locator (URL) from a trusted ledger (e.g., a blockchain-based database of trusted data from Matter vendors and / or participants) and usually has to guide the user to that URL which becomes a web page containing additional instructions for the commissioning process. Completing the manual custom steps described in the custom flow URL with the assistance of the instructions or additional installed applications, the device enters a state where the commissioner can proceed with the setup of the device.

[0012] An important problem with this scheme is that there is no way to return to the application from the initial URL using the commissioning passcode that would be required to continue the commissioning process without manual intervention by the user across several applications. There is no way to ascertain when the callback URL will be accessed and / or whether it was related to an initial user action when the deep link URL is accessed from the web content where the user was directed by the commissioner application that accessed the custom flow URL. Further, there is no global key to use for encrypting this information and no mechanism for key exchange specified, so the commissioning passcode, if included at all, would need to be passed as plain text. In other words, a custom commissioning client attempting to return to the initial commissioner would have to provide the passcode without secrecy to an application that could potentially be untrusted if the link has multiple possible handlers.

[0013] This problem is typically solved by establishing authenticated channel secrecy using an end-to-end mechanism or by relying on out-of-band communication between enterprises or peer-to-peer. In some networking standards (e.g., Matter), since a commissioner application from any one of multiple vendors may be used and since there may or may not be cloud components in the networking standard, there is no interoperable way to establish such a secure channel for transmitting information, and it cannot be guaranteed that the initial commissioner is reasonably certain of receiving trustworthy information from the correct source and that confidential credentials have not been leaked.

[0014] Protocols such as Weave and Matter physically own the passcode and establish a trust base point using a QR code or other challenge payload by using a Password-Authenticated Session Establishment (PASE) protocol based on Password-Authenticated Key Exchange (PAKE) for initial commissioning. In these protocols, the two peers have direct connectivity and there is no intermediary. The PAKE protocol strongly attempts to establish the absence of a man-in-the-middle attack (MITM) or relay through the protocol's characteristics.

[0015] Generally, key sharing between parties is based in part on the sharing of non-personal information and uses schemes such as Diffie-Hellman and Elliptic Curve Diffie-Hellman key sharing. The manner of protecting return communication via an application uniform resource locator relates to the use of a trust anchor (a fixed responder access URL obtained by a trusted means) and a URL for the transmission of any element of the protocol. Instead of directly exchanging messages between two peers, actions encompassing the steps of the protocol described herein enable the transmission of secret information with authenticity and integrity in a round trip, yet are triggered by access to a specially crafted URL that need not be secret.

[0016] In other aspects, protecting return communications via an application uniform resource locator describes communications across an application, whether over the Internet or not, and perhaps between processes of a device, that do not rely on the Hypertext Transfer Protocol (HTTP) and / or Hypertext Transfer Protocol Secure (HTTPS), where the same entity did not develop the device's initiator and / or responder, and where the initiator (commissioner) does not need to communicate out-of-band information directly other than accessing the responder access URL. By techniques for protecting return communications via an application uniform resource locator, the initiator can reach the responder with a personal authentication query embedding a return URL using a single URL. These techniques enable the initiator to reach the responder locally within a home area network or within a single device (e.g., a smartphone communicating between applications on the smartphone using these techniques), regardless of whether the initiator and responder communicate over the Internet. Techniques for protecting return communications via an application uniform resource locator abstract by location (scheme, authority, path) and convey the transport hops that need to be traversed between the initiator and responder, whether those hops are local or remote. These techniques enable the initiator to recover data from the responder in an end-to-end authenticated and privacy-protected manner.

[0017] Exemplary Environment FIG. 1 shows an exemplary network environment 100 that can implement various aspects of protecting return communication via an application uniform resource locator. The network environment 100 includes a home area network (HAN), such as the HAN 200 described below with respect to FIG. 2. The HAN includes wireless network devices 102 disposed around a structure 104, such as a house, and is connected by one or more wireless network technologies and / or wired network technologies as described below. The HAN includes a border router 106 that connects the HAN to an external network 108, such as the Internet, via a home router or access point 110 (a wireless local area network (WLAN) access point 110).

[0018] To provide user access to functions implemented using the wireless network devices 102 within the HAN, the cloud service 112 connects to the HAN via a secure tunnel 114 through the external network 108 and the access point 110 via the border router 106. The cloud service 112 uses a web-based application programming interface (API) 118 to facilitate communication between the HAN and an Internet client 116, such as an app on a mobile device.

[0019] The HAN may include one or more wireless network devices 102 that function as a hub 120. The hub 120 may be a general-purpose home automation hub or a hub for a specific purpose such as a security hub, an energy management hub, an HVAC hub, etc. The functionality of the hub 120 may also be integrated into any wireless network device 102 such as a smart thermostat device or a border router 106. In addition to hosting a controller on the cloud service 112, the controller may be hosted on any hub 120 within the structure 104 such as the border router 106. The controller hosted on the cloud service 112 can be dynamically moved to a hub 120 within the structure 104, such as moving an HVAC zone controller to a newly installed smart thermostat.

[0020] By hosting functionality on the hub 120 within the structure 104, reliability can be improved when the user's Internet connection is unreliable, the latency of operations that would normally need to connect to the cloud service 112 can be reduced, and system and regulatory constraints regarding local access between wireless network devices 102 can be met.

[0021] The wireless network devices 102 of the HAN may be from a single manufacturer that also provides the cloud service 112, or the HAN may include wireless network devices 102 from partners. These partners may also provide a partner cloud service 122 that provides services related to their wireless network devices 102 via a partner web API 124. The partner cloud service 122 may optionally or additionally provide services to an Internet client 116 via a web-based API 118, the cloud service 112, and a secure tunnel 114.

[0022] The network environment 100 can be implemented on various hosts such as battery-powered microcontroller-based devices, line-powered devices, and servers that host cloud services. The protocols operating in the wireless network device 102 and the cloud service 112 provide many services that support the operation of the home automation experience in the network environment 100. These services include, but are not limited to, real-time distributed data management and subscriptions, control of commands and responses, real-time event notifications, logging and storage of historical data, cryptographically controlled security groups, time synchronization, network and service pairing, and software updates.

[0023] FIG. 2 illustrates an exemplary home area network system (e.g., a Matter network, a Weave network, a Fabric network) that can implement various ways to protect return communication via an application uniform resource locator. A home area network (HAN) 200 (Matter network 200) includes a wireless mesh network 202 (e.g., a Thread network) and Wi-Fi device(s) 210. HAN 200 may also include a wired network device (e.g., Ethernet® device(s) 214). The wireless mesh network 202 includes a router 206 and end devices 208. The router 206 and the end devices 208 each include a mesh network interface for communication via the mesh network 202. The router 206 receives and transmits packet data via the mesh network interface. The router 206 also routes traffic across the mesh network 202. The end devices 208 can communicate using the mesh network 202 but lack the ability to route traffic within the mesh network 202 beyond simply forwarding it to their parent router 206. For example, a battery-powered sensor is one type of end device 208. Each Wi-Fi device 210 includes a Wi-Fi network interface for communication via the Wi-Fi network. The Wi-Fi device 210 and / or the Ethernet device 214 can include a home automation device and a device including an application for controlling Matter devices (e.g., a smartphone, a tablet, a network-connected speaker).

[0024] The ecosystem controller 216a (e.g., a Matter controller) can include a border router 106, and further the border router is included within the wireless network mesh network 202. The border router 106 includes a mesh network interface for communication via the mesh network 202 and a Wi-Fi network interface for communication via the Wi-Fi network 204, or the border router 106 uses the Wi-Fi network interface of the ecosystem controller 216a for communication via the Wi-Fi network 204. The border router 106 routes packets between devices within the wireless mesh network 202 and the access point 110, and the access point can forward the packets to other devices within the HAN 200. The border router 106 also routes packets between devices of the mesh network 202 and external network nodes (e.g., cloud service 112) via an external network 108 such as the Internet through the home router or access point 110.

[0025] The HAN 200 includes one or more ecosystem controllers 216 that provide an interface between devices from an ecosystem vendor and the access point 110. For example, the ecosystem controller 216a provides an interface between the mesh network 202 (Thread network) and the access point 110. Optionally, the HAN 200 can include other ecosystem controllers such as the ecosystem controller 216b to interface with devices from other ecosystem vendors. Further, other devices from another IoT network 218 (e.g., non-Matter compliant ecosystem devices) can be connected to the access point 110 by a Matter gateway 220 that provides connectivity to devices within the other IoT network 218 for a Matter compliant application.

[0026] Devices within the mesh network 202, Wi-Fi device(s) 210, Ethernet device(s) 214, ecosystem controller 216, and Matter gateway 220 communicate with each other using a standard IP routing configuration via a transport protocol such as, for example, the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP).

[0027] Protection of Return Communication via Application Uniform Resource Locator To commission a participating device (target device), the commissioning device (initiator) needs to recover secrets and / or other relevant data (target payload, responder payload) from the responder so that it can further access the target device. The responder can be any suitable device that can store and provide secrets and / or other relevant data (such as cloud service 112, wireless network device, border router 106, hub 120, Internet client device, smartphone, etc.). The initiator trusts the responder and provides the responder with an initiator response URL that, when accessed, will transmit the required target payload. The responder may or may not trust the initiator depending on the content of the responder access URL (as described below with respect to FIG. 5). The initiator obtains a responder access URL that it expects to be trustworthy. When the responder access URL is obtained, the final response of the target payload is triggered and returns to the initiator via an extended version of the initiator response URL (extended initiator response URL) transmitted from the initiator to the responder. The initiator trusts the responder to provide the correct target payload (e.g., "provide_access_1e074ec02eb2b452322736f565b90236") to the responder, and the target payload must be impossible to recover by any entity other than the initiator and the responder. Encryption and authentication ensure that any tampering of the target payload between the responder and the initiator is detectable.

[0028] Figure 3 shows exemplary data transactions and control transactions between entities that can implement various ways to protect return communication via an application uniform resource locator. Initial parameters of the commissioning process are predefined (e.g., defined in a standard document specifying a communication protocol). In an aspect, a symmetric cryptosystem that supports authenticated encryption with associated data (AEAD) is used for message encryption and authentication by both the initiator and the responder. The key length is KL bits long. An asymmetric cryptosystem that supports Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) is used by both the initiator and the responder. A key derivation function (KDF) algorithm is specified to be used by the initiator and the responder.

[0029] At 310, the responder 304 generates a fixed responder access URL (e.g., https: / / responder.example.com / responder_access?responder_pk=BHi7mFxXpV1GRQlhM75RochDaMm9m7g-Ha7CsCCPNb71XdXRmdlD3xFWpIJsY7ZiXZ1YiYv3fOCgiThi4htGdjk%3D). The responder 304 may be an application on a cloud service or web service (e.g., cloud service 112), a device on a home area network (e.g., wireless network device 102, border router 102, hub 120, etc.), or a commissioning device (e.g., Internet client 116, smartphone, etc.). For example, the generation of the responder access URL includes the responder 304 generating a long-term key pair for the responder access URL and making the responder access URL accessible. In an aspect, the responder access URL is fixed and includes a well-known encoding of the public key associated with the secret key held by the responder 304 within its query field. Optionally or additionally, the responder access URL may convey the type of cipher suite associated with the public key within its format. In other aspects, instead of a well-known encoding of the public key itself (such as a direct key within the format or a certificate embedding the key), there may be other identifiers that, when combined, enable the initiator 302 to determine the location of the public key associated with the responder 304. For example, the initiator 302 may be able to recover the key separately from the URL, such as from the same initiator trust database 306 or a database other than the database from which the responder access URL was obtained, based on information encoded in the responder access URL or information known to the initiator 302 from other interactions with participating devices.

[0030] At 315, the responder 304 issues a responder access URL to a reliable location where the initiator 302 can access it. For example, the responder 304 stores the responder access URL in an initiator trust database 306, such as a database maintained by the manufacturer of the participating device or another accessible service provider.

[0031] At 320, the initiator 302 retrieves the responder access URL from the initiator trust database 306. At 325, the initiator 302 obtains an extended responder access URL, for example, https: / / responder.example.com / responder_access?responder_pk=BHi7mFxXpV1GRQlhM75RochDaMm9m7g-Ha7CsCCPNb71XdXRmdlD3xFWpIJsY7ZiXZ1YiYv3fOCgiThi4htGdjk%3D&nonce=-sxunDvMVACCYuu0sw%3D%3D&initiator_pk=BO5nDogkrc-9AB-Yl0c3UEMCaBg3p8BzCN8sWo7AmmBaq9SPgAhVLZKfeDrJ7CWgB2eGLeUFQAwi3UKaifiT6To%3D&initiator_payload=pDPar2dVBdMwj2gbs4iPCENuoWqAmfhBtdqfaFE1Gg2KY4pqKWJ7xs4oHrgo9n1YTPBx3bP8fdoysT4_gbu3JJNzgGSG1Aim0F6-J16DfPZl4P2N7c54KS2F2KEjecUVE_6YK65kBwoIq6j7gxFz-qdMqcvP3GAWptz1XE2RkgnP-AKw6g8yHacwm1drOB50zOFkjzw0eC3HPRrsvTQ1xoHDBSH6-bsTUBPjnWbh from the initially retrieved responder access URL. The generation of the extended responder access URL will be described below with respect to FIG. 4. At 330, the initiator accesses the extended responder access URL generated by the responder 304.

[0032] At 335, in response to the initiator 302 accessing the extended responder access URL, the responder 304 processes the extended responder access URL, authenticates the extended responder access URL, and generates a responder payload as described below with respect to FIG. 5. At 340, the responder generates an extended initiator response URL and transmits the responder payload to the initiator 302 as described below with respect to FIG. 6. For example, the responder 304 extracts the initiator response URL from the initiator payload (e.g., https: / / initiator.example.com / initiator_response?example_token=s4i0yhcQUxci6-Z0gKOFAA%3D%3D&example_field=7144 provide_access_1e074ec02eb2b452322736f565b90236), and the responder 304 extends the extracted initiator response URL to create an extended initiator response URL.

[0033] At 345, the initiator 302 can directly access the extended initiator response URL from the responder 304. In an alternative form, at 350, the responder 304 provides the extended initiator response URL to the proxy intermediary 308, and at 355, the initiator 302 accesses the extended initiator response URL from the proxy intermediary 308. At 360, the initiator 302 recovers the responder payload and completes the commissioning process as described below with respect to FIG. 7.

[0034] FIG. 4 shows exemplary data transactions and control transactions among entities for the generation (at 325) of an extended responder access URL that can implement various ways of protecting return communication via an application uniform resource locator. The operations described with respect to FIG. 4 use a predetermined cipher suite and key length KL as described above.

[0035] At 405, the initiator 302 generates an initiator temporary asymmetric cryptographic key pair that is compatible with the responder 304's public key cipher suite obtained at 320 with the responder access URL for Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH). The initiator's temporary key pair includes a temporary private key and a temporary public key. At 410, the initiator 302 generates a random nonce (e.g., fa:cc:6e:9c:3b:cc:54:00:82:62:eb:b4:b3) suitable for use with an AEAD (Authenticated Encryption with Associated Data) target cipher algorithm. The initiator 302 encodes the generated nonce into a suitable representation such as a predetermined query argument added to the query existing in the responder access URL.

[0036] At 415, using DH or ECDH, the initiator 302 derives a shared secret (e.g., a4:84:e5:7b:3d:96:93:1c:a1:7e:2f:d7:55:9d:de:43:be:a8:e6:77:03:08:f7:fd:0a:01:32:23:2f:fb:e0:0b) using the ephemeral secret key generated at 405 and the responder public key obtained at 320. This derived shared secret is the session key share. In a first alternative form, the initiator 302 uses nonces, as well as salts and / or other information, as well as the shared secret, and a key derivation function (e.g., HMAC-based Extract-and-Expand Key Derivation Function (HKDF)) to generate key material of twice the key length in bits from the shared secret, half of which bits are the key from the initiator to the responder (e.g., 20:05:d4:00:0c:72:9f:57:34:30:97:1f:26:26:ef:90), and the other half of the bits are the key from the responder to the initiator (e.g., c5:12:b8:41:cc:e6:44:64:78:6c:89:ab:d8:ae:20:52). In a second alternative form, the initiator 302 uses a key derivation function to generate a single symmetric key of KL bits that is generated and reused in both directions between the initiator 302 and the responder 304. Optionally or additionally, the initiator 302 uses nonces, as well as salts and / or other information, as well as the shared secret to generate the single symmetric key.

[0037] At 420, the initiator 302 adds the ephemeral public key to the query present in the responder access URL in a format suitable for use by the responder 304. For example, the initiator 302 adds the ephemeral public key in a URL-encoded format, a URL-safe base64 format of the Distinguished Encoding Rule (DER), or the raw version format of the public key.

[0038] At 425, the initiator 302 generates an appropriate initiator response URL (e.g., https: / / initiator.example.com / initiator_response?example_token=s4i0yhcQUxci6-Z0gKOFAA%3D%3D&example_field=7144) that is accessed along with the response, and this URL contains any appropriate data that the initiator 302 needs to have returned to itself upon response. Optionally, at 430, the initiator 302 encodes other appropriate information for querying the responder 304 as a responder query (e.g., provide_access_1e074ec02eb2b452322736f565b90236). At 435, the initiator 302 encodes a payload called the initiator payload (e.g., https: / / initiator.example.com / initiator_response?example_token=s4i0yhcQUxci6-Z0gKOFAA%3D%3D&example_field=7144 provide_access_1e074ec02eb2b452322736f565b90236), and this payload is understandable by the responder 304 and includes the initiator response URL and, if used, the optional responder query.

[0039] At 440, the initiator 302 encrypts the initiator payload into an initiator-payload-ciphertext-and-tag tuple using a predetermined AEAD algorithm (e.g., the Advanced Encryption Standard Counter using CBC-MAC (AES-CCM) defined in NIST 800-38C, Recommendations for Block Cipher Mode of Operation: The CCM Mode for Authentication and Confidentiality, Section 6.1). The encryption key used is either the key from the initiator to the responder or a single symmetric key (as described at 415), depending on the session key sharing method. The nonce used for encryption is the nonce value generated at 410. The additional data used for encryption is the entire extended responder access URL up to the end of the query after being extended with the nonce (at 410) and the initiator ephemeral public key (at 420) (the fragment field is omitted). The plaintext to be encrypted is the binary string of the initiator payload (encoded at 435).

[0040] At 445, the initiator 302 adds the initiator-payload-ciphertext-and-tag tuple to the query in the responder access URL as a pre-defined URL query argument in a form suitable for use by the responder 304, e.g., URL-encoded URL-safe base64 after concatenating them. The initial responder access URL is now ready to be used as the extended responder access URL at 330. The initiator 302 can access the extended responder access URL using a web browser or any other suitable technology capable of handling the scheme of the extended responder access URL.

[0041] Figure 5 shows exemplary data transactions and control transactions among entities for the processing (at 335) of an extended responder access URL that can implement various ways of protecting return communication via an application uniform resource locator. The operations described with respect to Figure 5 use a pre-determined cipher suite and key length KL as described above.

[0042] At 505, the responder 304 extracts and decrypts the initiator-payload-ciphertext-and-tag tuple and removes it from the query. The responder 304 discards the fragment field from the received extended responder access URL. The initiator-payload-ciphertext-and-tag tuple is the last item in the query. The responder 304 saves the additional data URL (the responder access URL with the nonce and the initiator's ephemeral public key added) described at 440. The responder 304 extracts the nonce from the additional data URL according to a predetermined encoding format. The responder 304 extracts the initiator ephemeral public key from the additional data URL according to a predetermined encoding format and saves the initiator-payload-ciphertext-and-tag.

[0043] At 510, using DH or ECDH, responder 304 derives a shared secret using the private key associated with its fixed public key (associated with the responder access URL used so far and shared with initiator 302 at 320) and the temporary public key of the initiator extracted at 505. This is the responder side of session key sharing and is performed using a method symmetric to the method used at 415. In a first alternative, responder 304 uses nonces, as well as salts and / or other information, and a key derivation function (e.g., HKDF) to generate key material of twice the key length in bits (2*KL) from the shared secret, with half the bits being the key from the initiator to the responder and the remaining half of the bits being the key from the responder to the initiator. In a second alternative, responder 304 uses a key derivation function to generate a single symmetric key of length KL bits that is generated and reused in both directions between initiator 302 and responder 304.

[0044] At 515, responder 304 uses a predetermined AEAD algorithm (e.g., AES-CCM as defined in NIST800-38C section 6.1) to decrypt and authenticate the initiator payload. The nonce used for decryption is the nonce extracted at 505. The additional data used is the URL saved at 505. The ciphertext used is the ciphertext extracted at 505. The tag to be verified is the extracted tag 505. The key used is the key from the initiator to the responder obtained at 510.

[0045] At 520, responder 304 determines whether the authentication was successful. If the authentication fails, responder 304 terminates further operation at 525 and does not trust any subsequent data from initiator 302's session. If the authentication is successful, responder 304 proceeds to recover the initiator payload at 530.

[0046] At 530, the responder 304 recovers the initiator payload by extracting the initiator response URL from the initiator payload and, if a responder query exists, extracting the responder query from the initiator payload. Optionally, at 535, if a responder query exists, the responder 304 uses the responder query along with the remainder of the responder access URL to determine what information to return to the initiator 302 when the initiator response URL is accessed. At 540, the responder 304 generates the responder payload to send back to the initiator 302.

[0047] FIG. 6 shows exemplary data transactions and control transactions among entities for generating (at 340) a responder payload that can implement various aspects of protecting return communication via an application uniform resource locator. The operations described with respect to FIG. 6 use a predetermined cipher suite and key length KL as described above.

[0048] At 605, when a single symmetric key is used, the responder 304 derives the nonce from the responder to the initiator (e.g., 05:33:91:63:c4:33:ab:ff:7d:9d:14:4b:4c) using the method expected by both the initiator and the responder, such as by inverting all bits of the nonce extracted at 505 (e.g., taking the exclusive logical sum (XOR) with 0xFF for each octet). The nonce from the responder to the initiator is not transmitted because it can be deterministically calculated by the initiator 302 when processing the extended initiator response URL.

[0049] At 610, the responder 304 uses a predetermined AEAD algorithm (e.g., AES-CCM defined in NIST 800-38C section 6.1) to encrypt the responder payload into a responder-payload-ciphertext-and-tag tuple. The encryption key used is either the key from the responder to the initiator or the single symmetric key (derived at 510) depending on the session key sharing method. The nonce used for encryption is the nonce value from the responder to the initiator generated at 605. The responder 304 uses the entire initiator response URL up to the end of the query (omitting the fragment field) as additional data during encryption. The responder 304 encrypts the responder payload (from 535) as the plaintext to be encrypted.

[0050] At 615, the responder 304 URL-encodes the responder-payload-ciphertext-and-tag tuple in a form suitable for use by the initiator 302, such as the concatenated URL-encoded URL-safe base64 form, and adds it as a predefined URL query argument appended to the query in the initiator response URL. The initial responder access URL is now ready to be used at 330 as the extended responder access URL (e.g., https: / / initiator.example.com / initiator_response?example_token=s4i0yhcQUxci6-Z0gKOFAA%3D%3D&example_field=7144&responder_payload=Wl7BNkQU-Hsz5E14Gs5WNl9ID0sxjJgzg_FTRybnsKGxd2IyxKQpYwDGdlblkKoXPO0befTrxTOW4UvsPjgO).

[0051] Responder 304 can transmit the extended initiator response URL using a browser or other client capable of handling the URL's scheme and authority, perhaps via various out-of-band means and hops. The extended initiator response URL is valid for use as long as the initiator 302 that created the initiator response URL prior to the extension to the extended initiator response URL can access the underlying ephemeral key pair and recover the relevant cryptographic context from the data initially injected by the initiator 302 into the initiator response URL. Optionally or additionally, entities other than responder 304 can access the extended initiator response URL. The extended initiator response URL, including the responder payload, can be transmitted across several different hops over the application and network until it reaches an endpoint known to be able to access the URL given its scheme and authority.

[0052] Figure 7 shows exemplary data transactions and control transactions among entities for the processing (at 360) of an extended initiator response URL that can implement various ways of protecting return communication via an application uniform resource locator. The operations described with respect to Figure 7 use a pre-determined cryptographic suite and key length KL as described above.

[0053] At 705, initiator 302 has a responder-payload-ciphertext-and-tag tuple, e.g., 5a:5e:c1:36:44:14:f8:7b:33:e4:4d:78:1a:ce:56:36:5f:48:0f:4b:31:8c:98:33:83:f1:53:47:26:e7:b0:a1:b1:77:62:32:c4:a4:29:63:00:c6:76:56:e5:90:aa:17:3c:ed:1b:79:f4:eb:c5:33:96:e1:4b:ec:3e:38:0e Extract and decrypt it, and remove it from the query. The initiator 302 discards the fragment field from the received extended initiator response URL. The initiator 302 verifies the remaining part of the extended initiator response URL without the responder-payload-ciphertext-and-tag tuple and determines that it matches the initially generated initiator response URL. The initiator 302 uses the remaining part of the extended initiator response URL as additional data during authenticated decryption. The initiator 302 recovers the expected nonce and the required key that match those generated at 410 and 415 based on an indexed lookup from the data embedded in the recovered initiator response URL. The initiator 302 saves the response payload ciphertext and tag.

[0054] At 710, the initiator 302 uses a predetermined AEAD algorithm (e.g., AES-CCM defined in NIST 800-38C section 6.1) to decrypt and authenticate the responder payload. The nonce used for decryption is the nonce extracted at 705. The additional data used is the URL saved at 705. The ciphertext used is the ciphertext extracted at 705. The tag to be verified is the extracted tag 705. The key used is the key from the initiator to the responder obtained at 705.

[0055] At 715, the initiator 302 determines whether the authentication was successful. If the authentication fails, the initiator 302 terminates further operations at 720 and does not trust any subsequent data from the session of the responder 304. If the authentication is successful, the initiator 302 proceeds at 725 to recover the responder payload (e.g., provide_access_1e074ec02eb2b452322736f565b90236).

[0056] Exemplary method Exemplary methods 800 and 900 are described with reference to FIGS. 8 and 9 in accordance with one or more aspects of protecting return communication via an application uniform resource locator. In general, any of the components, modules, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Some operations of the exemplary methods can be described in the general context of executable instructions stored on a computer-readable storage device that is local and / or remote to a computer processing system, and embodiments can include software applications, programs, functions, and the like. Optionally or additionally, any of the functions described herein can be performed at least in part by one or more hardware logic components such as a field programmable gate array (FPGA), application specific integrated circuit (ASIC), application specific standard product (ASSP), system on chip system (SoC), complex programmable logic device (CPLD), etc., without limitation. The order in which method blocks are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order or omitted if they can also be combined in any order to implement a method or another method.

[0057] FIG. 8 shows an exemplary method(s) 800 of protecting return communication via an application uniform resource locator with respect to an initiator device that generally commissions a participant device to a home area network. At block 802, the initiator device (e.g., initiator 302) obtains a responder access uniform resource locator (URL). For example, the initiator device 302 obtains a responder access uniform resource locator (URL) from an initiator trust database (e.g., initiator trust database 306) as described above with respect to FIGS. 3 and 4.

[0058] In block 804, the initiator device generates an extended responder access URL using the obtained responder access URL. For example, the initiator device generates an extended responder access URL using the obtained responder access URL as described with respect to FIG. 4 above.

[0059] In block 806, the initiator device accesses the extended responder access URL on the responder (e.g., responder 304) to cause the responder to generate a responder payload. For example, the initiator accesses the extended responder access URL on the responder at 330.

[0060] In block 808, the initiator device accesses an extended initiator response URL that includes the generated responder payload. For example, the initiator device accesses an extended initiator response URL that includes the generated responder payload directly from the responder at 345, or via a proxy mediator (e.g., proxy mediator 308) as shown at 350 and 355.

[0061] In block 810, the initiator device recovers the responder payload and causes the participating device to be commissioned into the home area network on the initiator device. For example, the initiator device commissions the participating device to participate in the home area network (e.g., home area network 200) using the recovered responder payload.

[0062] FIG. 9 shows an exemplary method(s) 900 for protecting return communication via an application uniform resource locator with respect to a responder that generally generates commissioning information for commissioning a participant device to a home area network. At block 902, the responder issues a responder access uniform resource locator (URL). For example, the responder (e.g., responder 304) issues a responder access uniform resource locator (URL) at 315. The responder can issue the responder access URL to a database trusted by the initiator device (e.g., initiator device 302) (e.g., initiator trust database 306).

[0063] At block 904, the responder receives an extended responder access URL from the initiator device. For example, the initiator device accesses at 330 an extended responder access URL based on a responder access API received by the initiator device at 320.

[0064] At block 906, the responder extracts a responder-payload-ciphertext-and-tag tuple. For example, the responder extracts a responder-payload-ciphertext-and-tag tuple as described at 505.

[0065] At block 908, the responder decrypts the responder-payload-ciphertext-and-tag tuple. For example, the responder decrypts a responder-payload-ciphertext-and-tag tuple as described at 505.

[0066] At block 910, the responder derives a shared secret using a private key associated with the responder's public key and a temporary public key of the initiator device. For example, the responder derives a shared secret using a private key associated with the responder's public key and a temporary public key of the initiator device as described at 510.

[0067] In block 912, the responder decrypts and authenticates the initiator payload using an authenticated encryption with associated data (AEAD) algorithm. For example, the responder decrypts and authenticates the initiator payload using an authenticated encryption with associated data (AEAD) algorithm as described at 515.

[0068] In block 914, when the initiator payload is authenticated, the responder recovers the initiator payload. For example, if the responder can authenticate the initiator payload, the responder recovers the initiator payload as described at 530. If authentication fails, the responder terminates its operation on the extended responder access URL.

[0069] In block 916, the responder generates a responder payload to send to the initiator device. For example, based on successful authentication and extraction, the responder generates a responder payload to send to the initiator device. The generated responder payload provides the initiator device with information for completing the commissioning of the responder's home area network 200.

[0070] Exemplary Environments and Devices FIG. 10 shows an exemplary network environment 1000 that can implement the home area network 200 described with reference to FIG. 2 and various aspects for protecting return communication via an application uniform resource locator. Generally, the environment 1000 is implemented as part of a home or other type of structure having any number of wireless network devices and / or wired network devices configured for communication in a wireless network, including a home area network (HAN) 200. For example, the wireless network devices can include a thermostat 1002, a hazard detector 1004 (e.g., for smoke and / or carbon monoxide), a camera 1006 (e.g., indoor and outdoor), a lighting unit 1008 (e.g., indoor and outdoor), and any other type of wireless network device 1010 implemented inside and / or outside of the structure 1012 (e.g., within a home environment). In this example, the wireless network devices can also include any of the above-described devices such as the border router 106, and any device implemented as a router device 206, an end device 208, an ecosystem controller 216, and / or a Matter gateway 220.

[0071] In the environment 1000, any number of wireless network devices can be implemented for wireless interconnectivity to communicate and interact wirelessly with each other. The wireless network devices are modular devices, intelligent devices, multi-sensing devices, network-connected devices that can be seamlessly integrated with each other and / or with a central server or cloud computing system to provide for any of a variety of useful automation purposes and implementations. An example of a wireless network device that can be implemented as any of the devices described herein is illustrated and described with reference to FIG. 11.

[0072] In an embodiment, the thermostat 1002 can include a Nest (registered trademark) Learning Thermostat that detects ambient climate characteristics (e.g., temperature and / or humidity) and controls the HVAC system 1014 in a home environment. The learning thermostat 1002 and other network-connected devices "learn" by incorporating occupant settings into the device. For example, the thermostat learns the preferred temperature setpoints in the morning and evening, when the occupants of the structure are asleep or awake, and when the occupants are typically away from or at home.

[0073] The hazard detector 1004 can be implemented to detect the presence of a hazardous substance or a substance indicating a hazardous substance (e.g., smoke, fire, or carbon monoxide). In an example of wireless interconnection, the hazard detector 1004 may detect the presence of smoke indicating a fire within the structure, in which case the first hazard detector to detect the smoke can broadcast a low-power wake-up signal to all of the connected wireless net and network devices. Other hazard detectors 1004 can then receive the broadcast wake-up signal, initiate a high-power state for hazard detection, and be able to receive wireless communication of an alert message. Additionally, the lighting unit 1008 can receive the broadcast wake-up signal and operate within the detected hazard area to illuminate and identify the area of concern. In another example, the lighting unit 1008 operates in one lighting color to indicate the area or location of a problem within the structure, such as a detected fire or intrusion burglary, and operates in a different lighting color to indicate a safe area and / or an evacuation route from the structure.

[0074] In various configurations, the wireless network device 1010 can cooperate with the network-connected door lock system 1018 and include a passage interface device 1016 that detects and responds to a person's approach to or departure from a location such as an outer door of a structure 1012. The passage interface device 1016 can interact with other wireless network devices based on whether someone has approached or entered the smart home environment. The passage interface device 1016 can control doorbell functions, notify of a person's approach or departure via audio or visual means, and control settings on the security system, such as activating or deactivating the security system when the occupant enters or exits. The wireless network device 1010 can also include other sensors and detectors for detecting ambient lighting conditions, (e.g., using occupancy sensor 1020) for detecting room occupancy, and for controlling the output state and / or dim state of one or more lights. In some examples, the sensors and / or detectors can also control the power state or speed of a fan, such as ceiling fan 1022. Additionally, the sensors and / or detectors can detect occupancy within a room or enclosure and control the supply of power to an electrical outlet or electrical device 1024, such as when the room or structure is unoccupied.

[0075] Wireless network device 1010 may also include connected appliances and / or control systems 1026 such as refrigerators, stoves and ovens, washing machines, dryers, air conditioners, pool heaters 1028, irrigation systems 1030, security systems 1032, as well as other electronic and computing devices such as network-connected TVs, network-connected media streaming devices, entertainment systems, computers, intercom systems, garage door openers 1034, ceiling fans 1022, control panels 1036. When plugged in, the appliance, device, or system can notify itself to the home area network as described above and can be automatically integrated with the control devices and devices of the home area network such as within the home. Note that the wireless network device 1010 may include devices that are physically outside the structure but are located within the wireless communication range, such as a device that controls the swimming pool heater 1028 or the irrigation system 1030.

[0076] As described above, the mesh network 202 includes a border router 106 that interfaces outside the mesh network 202 for communication with an external network. The border router 106 is connected to an access point 110 that connects to a communication network 108 such as the Internet. A cloud service 112 connected via the communication network 108 provides services related to devices within the HAN 200 and / or services that use the devices. By way of example, the cloud service 112 may include applications such as connecting end-user devices 1038 such as smartphones and tablets to devices within the home area network, processing data obtained within the HAN 200 and presenting it to the end user, linking one or more devices within the HAN 200 to the user account of the cloud service 112, and provisioning and updating devices within the HAN 200. For example, a user can use a network-connected computer or portable device such as a mobile phone or tablet device to control a thermostat 1002 and other wireless network devices within the home environment. Further, the wireless network devices can communicate information to any central server or cloud computing system via the border router 106, the ecosystem controller 216, the Matter gateway 220, and / or the access point 110. Data communication can be carried out using any of various custom wireless protocols or standard wireless protocols (e.g., Wi-Fi, ZigBee for low power, 6LoWPAN, Thread, Matter, etc.) and / or by using any of various custom wired protocols or standard wired protocols (Ethernet, HomePlug, etc.).

[0077] Any of the wireless network devices within the HAN200 can function as a low-power node and a communication node to form the HAN200 within a home environment. Individual low-power nodes of the network can periodically send messages regarding what they detect, and other low-power nodes within the environment can repeat the messages (in addition to sending their own messages), thereby enabling communication of messages from node to node (i.e., device to device) throughout the home area network. The wireless network device can be implemented to conserve power, especially when battery-powered, receive messages using a low-power communication protocol, convert the messages to other communication protocols, and transmit the converted messages to other nodes and / or a central server or cloud computing system. For example, occupancy and / or ambient light sensors can detect the indoor occupants and measure the ambient light, and can activate a light source when the ambient light sensor 1040 detects that the room is dark and when the occupancy sensor 1020 detects that someone is indoors. Further, the sensor can include a low-power wireless communication chip (e.g., IEEE 802.15.4 chip, Thread chip, ZigBee chip) that periodically sends messages regarding room occupancy and the amount of light indoors, including an immediate message when the occupancy sensor detects the presence of a person indoors. As described above, these messages can be sent wirelessly, using the home area network, between nodes within the home environment (i.e., from network-connected device to network-connected device) or to a central server or cloud computing system via the Internet.

[0078] In other configurations, various wireless network devices may function as "trip wires" for an alarm system within a home environment. For example, even if an intruder avoids detection by alarm sensors placed on windows, doors, and other entry points of a structure or environment, an alarm can be triggered by receiving messages such as occupancy, movement, heat, sound, etc. from one or more of the low-power mesh nodes within the home area network. In other embodiments, the home area network can be utilized to automatically turn on and off the lighting unit 1008 as a person moves from room to room within a structure. For example, a wireless network device can detect the movement of a person through the structure and communicate corresponding messages via the nodes of the home area network. Other wireless network devices that receive these messages can act and / or cease operation accordingly using messages indicating which rooms are occupied. As referenced above, the home area network can also be utilized to provide emergency exit lighting, such as by turning on appropriate lighting units 1008 leading to safe exits. The light unit 1008 may also be turned on to indicate the direction of the exit route that a person should follow to safely exit the structure.

[0079] Various wireless network devices may also be integrated with and implemented to communicate with a wearable computing device 1042 used to identify and locate the occupants of a structure, and accordingly, can adjust systems such as temperature, lighting, sound, etc. In other embodiments, RFID detection (e.g., a person having an RFID bracelet, necklace, or key fob), synthetic vision technology (e.g., a video camera and a face recognition processor), voice technology (e.g., voice, sound pattern, vibration pattern recognition), ultrasonic sensor / imaging technology, and infrared or near-field communication (NFC) technology (e.g., a person wearing an infrared or NFC-enabled smartphone), along with a rule-based inference engine or artificial intelligence technology that derives useful conclusions from information detected regarding the location of the occupants within a structure or environment.

[0080] In other embodiments, the human - facing functions of the personal comfort area network, personal health area network, personal safety area network, and / or other service robots can be improved by logically integrating with other wireless network devices and sensors in the environment based on rule - based inference technology or artificial intelligence technology to achieve better performance of these functions. In an example related to an individual's health area, the system can use rule - based inference technology and artificial intelligence technology (e.g., using either a wireless network device or a sensor) to detect whether a pet in the home is moving towards the current location of the occupant. Similarly, when a hazard detector service robot is notified that the temperature level and humidity level are rising in the kitchen, it can temporarily increase the hazard detection threshold, such as the smoke detection threshold, under the inference that a slight increase in the surrounding smoke level is likely due to cooking activities rather than purely a dangerous situation. A service robot configured to perform any type of monitoring, detection, and / or service can be implemented as a mesh node device on the home area network in compliance with a wireless interconnection protocol for communicating on the home area network.

[0081] The wireless network device 1010 may also include a network - connected alarm clock 1044 for each individual occupant of a structure in a home environment. For example, an occupant can customize the alarm device and set the wake - up time for the next day or week. Artificial intelligence can be used to consider the occupant's reaction when the alarm goes off and make inferences about the preferred sleep pattern over time. Next, an individual occupant can be tracked within the home area network based on their unique signature, which is determined based on data obtained from sensors located within the wireless network, such as sensors including ultrasonic sensors, passive IR sensors, etc. The unique signature of an occupant can be based on a combination of movement patterns, voice, height, size, etc., and the use of face recognition technology.

[0082] In an example of wireless interconnection, the HVAC system can be efficiently controlled by associating an individual's wake-up time with the thermostat 1002, and the structure can be preheated or precooled to desired sleep and wake temperatures. Preferred settings can be learned over time, such as by incorporating the temperatures set on the thermostat before a person goes to bed and when they wake up. The collected data can also include the person's biometric metrics such as respiratory pattern, heart rate, movement, etc., and inferences are made in combination with data indicating when the person actually wakes up based on this data. Other wireless network devices can use the data to serve other automation purposes, such as adjusting the thermostat 1002 to preheat or precool the environment to a desired setting, or turning the light 1008 on or off.

[0083] In an embodiment, the wireless network device can also be used for detecting sound, vibration, and / or movement. For example, it can detect running water and make inferences about water usage in the home environment based on algorithms and mappings of water usage and consumption. This can be used to identify signatures or fingerprints of each water source in the home, and is also referred to as "audio fingerprint water usage". Similarly, the wireless network device can be used to detect minute sounds, vibrations, and / or movements caused by pests such as mice and other rodents, as well as termites, cockroaches, and other insects. The system can then notify the occupant of suspected pests in the environment, such as by using warning messages that help facilitate early detection and prevention.

[0084] Environment 1000 may include one or more wireless network devices that function as a hub 1046. The hub 1046 may be a general-purpose home automation hub or a hub for a specific purpose such as a security hub, an energy management hub, an HVAC hub, etc. The functionality of the hub 1046 may also be integrated into any wireless network device such as a network-connected thermostat device or a border router 106. By hosting functionality on the hub 1046 within the structure 1012, reliability can be improved when the user's Internet connection is unreliable, latency of operations that would normally need to connect to the cloud service 112 can be reduced, and system and regulatory constraints regarding local access between wireless network devices can be met.

[0085] Furthermore, the exemplary environment 1000 includes a network-connected speaker 1048. The network-connected speaker 1048 provides a voice assistant service that includes providing voice control and / or commissioning of network-connected devices. The functionality of the hub 1046 may be hosted within the network-connected speaker 1048. The network-connected speaker 1048 can be configured to communicate via a wireless mesh network 202, a Wi-Fi network 204, or both.

[0086] FIG. 11 shows an exemplary wireless network device 1100 that can be implemented as any of the wireless network devices within a home area network (Weave network) in accordance with one or more aspects for protecting return communications via the application uniform resource locator described herein. Device 1100 can be integrated with an electronic circuit, a microprocessor, memory, input / output (I / O) logic control, a communication interface, and components, as well as other hardware, firmware, and / or software to implement the device within the home area network. Further, wireless network device 1100 can be implemented using a variety of components, such as, for example, any number and combination of different components, as further described with reference to the exemplary devices shown in FIG. 12.

[0087] In this example, the wireless network device 1100 includes a low-power microprocessor 1102 and a high-power microprocessor 1104 (e.g., a microcontroller or a digital signal processor) that processes executable instructions. The device also includes input / output (I / O) logic control 1106 (e.g., to include an electronic circuit). The microprocessor can include components such as an integrated circuit, a programmable logic device, a logic device formed using one or more semiconductors, and other implementations in silicon and / or hardware such as a processor and memory system implemented as a system-on-chip (SoC). Optionally or additionally, the device can be implemented in any one or combination of software, hardware, firmware, or fixed logic circuitry that can be implemented in a processing circuit and a control circuit. The low-power microprocessor 1102 and the high-power microprocessor 1104 can also support one or more different device functions. For example, while the high-power microprocessor 1104 executes computationally intensive operations, the low-power microprocessor 1102 can manage simpler processes such as detecting danger or temperature from one or more sensors 1108. The low-power processor 1102 can also start or initialize the high-power processor 1104 for computationally intensive processes.

[0088] One or more sensors 1108 can be implemented to detect various characteristics such as acceleration, temperature, humidity, water, supply power, proximity, external movement, device movement, audio signals, ultrasonic signals, optical signals, fire, smoke, carbon monoxide, Global Positioning System (GPS) signals, radio frequency (RF), other electromagnetic signals or electromagnetic fields. Thus, sensors 1108 can include any one or a combination of a temperature sensor, a humidity sensor, a hazard-related sensor, a security sensor, other environmental sensors, an accelerometer, a microphone, an optical sensor, and further a camera (e.g., a CCD camera or a video camera), an active radiation sensor or a passive radiation sensor, a GPS receiver, and a radio frequency identification detector. In an embodiment, the wireless network device 1100 can include one or more primary sensors and one or more secondary sensors. For example, the primary sensors detect data that is central to the core operation of the device (e.g., detecting temperature with a thermostat or detecting smoke with a smoke detector), while the secondary sensors can detect other types of data (e.g., movement, light, or sound) that can be used for energy-efficient purposes or automation purposes.

[0089] The wireless network device 1100 includes a memory device controller 1110 and a memory device 1112 such as any type of non-volatile memory and / or other suitable electronic data storage device. The wireless network device 1100 can also include various firmware and / or software such as an operating system 1114 maintained as computer-executable instructions in the memory and executed by a microprocessor. The device software can also include a commissioning application 1116 that implements a manner of protecting return communication via an application uniform resource locator. The wireless network device 1100 also includes a device interface 1118 for interfacing with another device or peripheral component, and an integrated data bus 1120 that couples the various components of the wireless network device for data communication between the components. The data bus within the wireless network device can also be implemented as any one or combination of different bus structures and / or bus architectures.

[0090] The device interface 1118 can also receive input from a user and / or provide information to the user (e.g., as a user interface), and the received input can be used to determine set values. The device interface 1118 can also include mechanical or virtual components that respond to user input. For example, a user can mechanically move a sliding component or a rotatable component, or movement along a touchpad can be detected, and these movements can correspond to adjusting the settings of the device. With physically and virtually movable user interface components, the user can set set values along a part of a perceived continuum. The device interface 1118 can also receive input from any number of peripheral devices such as buttons, keypads, switches, microphones, and imaging devices (e.g., camera devices).

[0091] The wireless network device 1100 can include a network interface 1122, such as a wireless network interface or a home area network interface for communication with other wireless network devices within the home area network, and an external network interface for network communication, such as via the Internet. The wireless network device 1100 can also include a wireless radio system 1124 for wireless communication with other wireless network devices via the home area network interface and for multiple different wireless communication systems. The wireless radio system 1124 can include Wi-Fi, Bluetooth®, mobile broadband, BLE, Thread, Matter, and / or point-to-point IEEE 802.15.4. Each of the different wireless systems can include a wireless device, an antenna, and a chipset implemented for a particular wireless communication technology. The wireless network device 1100 can also include a power source 1126, such as a battery and / or for connecting the device to line voltage. Also, the AC power can be used to charge the device's battery.

[0092] FIG. 12 shows an exemplary system 1200 that includes an exemplary device 1202 that can be implemented as any of the wireless network devices that implement a mode of protecting return communication via an application uniform resource locator, as described with reference to FIGS. 1-11 above. The exemplary device 1202 can be any type of computing device, client device, mobile phone, tablet, communication, entertainment, game, media playback, and / or other type of device. Further, the exemplary device 1202 can be implemented as any other type of wireless network device configured for communication on a home area network, such as a thermostat, hazard detector, camera, light unit, commissioning device, router, border router, participant router, participating device, end device, leader, access point, and / or other wireless network devices.

[0093] Device 1202 includes a communication device 1204 that enables wired and / or wireless communication of device data 1206, such as data communicated between devices within the home area network, data received, data scheduled to be broadcast, data packets of data, data synchronized between devices, etc. The device data can include any type of communication data, as well as audio data, video data, and / or image data generated by applications running on the device. The communication device 1204 can also include a transceiver for mobile phone communication and / or network data communication.

[0094] In addition, device 1202 includes an input / output (I / O) interface 1208, such as a data network interface that provides connection links and / or communication links between the device and a data network (e.g., a home area network, an external network, etc.) and other devices. The I / O interface can be used to couple the device to any type of component, peripheral device, and / or accessory device. The I / O interface also includes a data input port, through which inputs such as any type of data, media content, and / or user input to the device, as well as any type of communication data, and audio data, video data, and / or image data received from any content and / or data source can be received.

[0095] Device 1202 includes a processing system 1210 that can be implemented at least partially in hardware, using any type of microprocessor, controller, etc. that processes executable instructions. The processing system can include components of other implementations in silicon and / or hardware, such as integrated circuits, programmable logic devices, logic devices formed using one or more semiconductors, and processors and memory systems implemented as system-on-chip (SoC). Optionally or additionally, the device can be implemented in any one or combination of software, hardware, firmware, or fixed logic circuitry that can be implemented in processing circuitry and control circuitry. Device 1202 can further include any type of system bus or other data and command transfer system that couples the various components within the device. The system bus can include any one or combination of different bus structures and architectures, as well as control lines and data lines.

[0096] Device 1202 also includes a computer-readable storage memory 1212 (computer-readable storage medium 1212), such as a data storage device, that can be accessed by the computing device and provides persistent storage of data and executable instructions (e.g., software applications, modules, programs, functions, etc.). The computer-readable storage memory described herein does not include propagated signals. Examples of computer-readable storage memory include volatile and non-volatile memory, fixed media devices and removable media devices, and any suitable media device or electronic data storage for maintaining data for access by the computing device. The computer-readable storage memory can include various embodiments of random access memory (RAM), read-only memory (ROM), flash memory, and other types of storage memory of various memory device configurations.

[0097] The computer-readable storage memory 1212 (computer-readable storage medium 1212) provides storage of device data 1206 and various device applications 1214, such as an operating system as a software application maintained on the computer-readable storage memory and executed by the processing system 1210. The device applications can also include a device manager, such as any form of control application, software application, signal processing and control module, code specific to a particular device, a hardware abstraction layer for a particular device, etc. In this example, the device applications also include, for example, a commissioning application 1216 that implements aspects of the initiator 302 that protects return communication via an application uniform resource locator when the exemplary device 1202 is implemented as any of the wireless network devices described herein.

[0098] Device 1202 also includes an audio and / or video system 1218 that generates audio data for the audio device 1220 and / or generates display data for the display device 1222. The audio device and / or display device includes any device that processes, displays, and / or otherwise renders image data such as audio data, video data, display data, and / or image content of digital photos. In an embodiment, the audio device and / or display device are integrated components of the exemplary device 1202. Alternatively, the audio device and / or display device are peripheral components external to the exemplary device. In an aspect, at least a portion of the techniques described for protecting return communications via an application uniform resource locator can be implemented in a distributed system such as on a "cloud" 1224 within the platform 1226. The cloud 1224 includes and / or represents a platform 1226 for services 1228 and / or resources 1230.

[0099] Platform 1226 abstracts the underlying functionality of hardware, such as server devices (e.g., included in Service 1228), and / or software resources (e.g., included as Resource 1230), and connects exemplary device 1202 to other devices, servers, etc. For example, Platform 1226 and / or Service 1228 may implement the aspects of Responder 304. Resource 1230 may also include applications and / or data that can be utilized while computer processing is executed on a server that is remote from exemplary device 1202. Further, Service 1228 and / or Resource 1230 may facilitate subscriber network services, such as via the Internet, a cellular network, or a Wi-Fi network. Platform 1226 may also abstract and scale resources, such as in the context of interconnected devices having functionality distributed throughout System 1200, to help serve the demand for Resource 1230 implemented via the platform. For example, the functionality may be implemented, in part, at exemplary device 1202 and via Platform 1226 that abstracts the functionality of Cloud 1224.

[0100] Several examples will be described below. Example 1: A method of commissioning a participant device to a home area network by an initiator device, comprising: obtaining a responder access uniform resource locator (URL); generating an extended responder access URL using the obtained responder access URL; accessing the extended responder access URL at the responder, wherein accessing causes the responder to generate a responder payload; accessing an extended initiator response URL that includes the generated responder payload; To recover the responder payload, by recovering the responder payload, the initiator device commissions the participant device to the home area network, the recovering, and performed by the initiator device The method including.

[0101] Example 2: The generating of the extended responder access URL is Generating an initiator temporary key pair including a temporary secret key and a temporary public key, and Deriving a shared secret using the temporary secret key of the generated initiator temporary key pair and the responder public key, and Adding the temporary public key to a query existing in the responder access URL, and Generating an initiator response URL accessed using a response, the initiator response URL including data returned to the initiator device within the response, the generating, and Encoding an initiator payload including the initiator response URL, and Encrypting the initiator payload into an initiator-payload-ciphertext-and-tag tuple, and URL-encoding the initiator-payload-ciphertext-and-tag tuple, and Adding the URL-encoded initiator payload ciphertext and tag tuple to the query existing in the responder access URL, and The method according to Example 1, including.

[0102] Example 3: The encoding of the initiator payload is Encoding the initiator payload including the initiator response URL and the responder query The method according to Example 2, including.

[0103] Example 4: Encrypting the initiator payload into the initiator-payload-ciphertext-and-tag tuple is using an authenticated encryption with associated data (AEAD) algorithm to encrypt the initiator payload into the initiator-payload-ciphertext-and-tag tuple and is the method according to Example 2.

[0104] Example 5: Generating a random nonce and generating a key from the initiator to the responder and a key from the responder to the initiator, wherein the generating uses a key derivation function, the random nonce, a shared secret, and a salt and / or other information to generate a number of bits twice the key length in bits, with half of the generated bits being the key from the initiator to the responder and the remaining half of the generated bits being the key from the responder to the initiator, the generating and is further included in the method according to any one of the preceding examples.

[0105] Example 6: Generating a symmetric key of the key length in bits used in both directions between the initiator device and the responder using a key derivation function and is further included in the method according to any one of the preceding examples.

[0106] Example 7: Accessing the responder access URL is accessing the responder access URL from an initiator trust database and is the method according to any one of the preceding examples.

[0107] Example 8: Recovering the responder payload is extracting the responder-payload-ciphertext-and-tag tuple and decrypting the responder-payload-ciphertext-and-tag tuple Deleting the responder-payload-ciphertext-and-tag tuple from the query field of the extended initiator response URL; Decrypting and authenticating the responder payload using an authenticated encryption (AEAD) algorithm with associated data; When the responder payload is authenticated, commissioning the participant device to the home area network using the responder payload; A method according to any one of the preceding embodiments, comprising:

[0108] Example 9: The method according to Example 8, wherein the home area network is a Matter network.

[0109] Example 10: The method according to any one of the preceding embodiments, wherein accessing the extended initiator response URL is accessing the extended initiator response URL from the responder, or accessing the extended initiator response URL from a proxy intermediary. A method according to any one of the preceding embodiments, comprising:

[0110] Example 11: A method for commissioning a participant device to a home area network by a responder, comprising: issuing a responder access uniform resource locator (URL); receiving an extended responder access URL from an initiator device; extracting an initiator-payload-ciphertext-and-tag tuple; decrypting the initiator-payload-ciphertext-and-tag tuple; deriving a shared secret using a private key associated with the public key of the responder and a temporary public key of the initiator device; decrypting and authenticating the initiator payload using an authenticated encryption (AEAD) algorithm with associated data; When the initiator payload is authenticated, recovering the initiator payload and generating a responder payload to be sent to the initiator device, wherein the responder performs the above, and the method includes the above.

[0111] Example 12: Based on recovering the initiator payload, determining that there is a responder query, and based on determining that there is a responder query, determining information to be sent back to the initiator device at the initiator response URL The method according to Example 11 further includes the above.

[0112] Example 13: Generating the responder payload includes deriving a nonce from the responder to the initiator, encrypting the responder payload into a responder-payload-ciphertext-and-tag tuple using the AEAD algorithm, URL-encoding the responder-payload-ciphertext-and-tag tuple, and adding the URL-encoded responder-payload-ciphertext-and-tag tuple to a query existing in the initiator response URL to generate an extended responder access URL The method according to Example 11 or Example 12 includes the above.

[0113] Example 14: Further providing the extended responder access URL for access by the initiator device The method according to Example 13 further includes the above.

[0114] Example 15: Providing the extended responder access URL to a proxy mediator that is effective for providing the extended responder access URL for access by the initiator device The method according to Example 13, further comprising

[0115] Example 16: An initiator device, a network interface, a processor, a computer-readable storage medium including instructions for instructing the initiator device to execute the method according to any one of Examples 1 to 10 in response to execution by the processor The initiator device comprising the same.

[0116] Example 17: The initiator device is a smartphone, a computer, or a network-connected speaker, The initiator device according to Example 16.

[0117] Example 18: A responder device, a network interface, a processor, a computer-readable storage medium including instructions for instructing the responder device to execute the method according to any one of Examples 11 to 15 in response to execution by the processor The responder device comprising the same.

[0118] Example 19: The responder device is a cloud service, a wireless network device, a border router, a hub, an Internet client device, or a smartphone The responder device according to Example 18.

[0119] Example 20: A computer-readable storage medium including instructions for instructing an apparatus to execute the method according to any one of Examples 1 to 15 in response to execution by a processor.

[0120] Aspects and / or methods for protecting return communication via an application uniform resource locator have been described in language specific to the features and / or methods, but the subject matter of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific functions and methods are disclosed as exemplary embodiments for protecting return communication via an application uniform resource locator, and other equivalent functions and methods are intended to be within the scope of the appended claims. Further, various different aspects have been described, and it should be understood that each of the aspects described can be implemented independently or in relation to one or more of the other aspects described.

Claims

1. A method for commissioning a participant device to a home area network by an initiator device, the method comprising the initiator device, where the initiator device obtains a responder access uniform resource locator (URL); uses the obtained responder access URL to generate an extended responder access URL; accesses the extended responder access URL with a responder, and by the accessing, the responder generates a responder payload, and the initiator device further accesses an extended initiator response URL including the generated responder payload; recovers the responder payload, and by the recovering the responder payload, the initiator device commissions the participant device to the home area network.

2. The generating of the extended responder access URL includes generating an initiator temporary key pair including a temporary secret key and a temporary public key; deriving a shared secret using the temporary secret key of the generated initiator temporary key pair and a responder public key; adding the temporary public key to a query existing in the responder access URL; generating an initiator response URL accessed using a response, where the initiator response URL includes data returned to the initiator device in the response, and the generating of the extended responder access URL further includes encoding an initiator payload including the initiator response URL; encrypting the initiator payload into an initiator-payload-ciphertext-and-tag tuple; URL-encoding the initiator-payload-ciphertext-and-tag tuple; adding the URL-encoded initiator payload ciphertext and tag tuple to the query existing in the responder access URL. The method according to claim 1.

3. The encoding of the initiator payload includes The method according to claim 2, comprising encoding the initiator payload including the initiator response URL and the responder query.

4. Encoding the initiator payload into the initiator-payload-ciphertext-and-tag tuple comprises: The method according to claim 2, comprising encrypting the initiator payload into the initiator-payload-ciphertext-and-tag tuple using an authenticated encryption with associated data (AEAD) algorithm.

5. Further comprising generating random nonces and generating a key from the initiator to the responder and a key from the responder to the initiator, wherein generating the key from the initiator to the responder and the key from the responder to the initiator comprises using a key derivation function, the random nonce, a shared secret, and a salt and / or other information to generate a number of bits twice the key length in bits, with half of the generated bits being the key from the initiator to the responder and the remaining half of the generated bits being the key from the responder to the initiator, according to any one of the preceding claims.

6. The method according to any one of the preceding claims, further comprising generating a symmetric key of a key length in bits for use in both directions between the initiator device and the responder using a key derivation function.

7. Accessing the responder access URL comprises: The method according to any one of the preceding claims, comprising accessing the responder access URL from an initiator trust database.

8. Recovering the responder payload comprises: Extracting a responder-payload-ciphertext-and-tag tuple; Decrypting the responder-payload-ciphertext-and-tag tuple; Deleting the responder-payload-ciphertext-and-tag tuple from a query field of the extended initiator response URL; Decrypting and authenticating the responder payload using an authenticated encryption with associated data (AEAD) algorithm; and When the responder payload is authenticated, commissioning the participant device to the home area network using the responder payload, according to any one of the preceding claims. ​

9. The method according to claim 8, wherein the home area network is a Matter network.

10. Said accessing the extended initiator response URL comprises accessing the extended initiator response URL from the responder, or accessing the extended initiator response URL from a proxy intermediary, the method according to any one of the preceding claims.

11. A method for commissioning a participant device to a home area network by a responder, comprising issuing a responder access uniform resource locator (URL); receiving an extended responder access URL from an initiator device; extracting an initiator-payload-ciphertext-and-tag tuple; decrypting the initiator-payload-ciphertext-and-tag tuple; deriving a shared secret using a private key associated with the public key of the responder and a temporary public key of the initiator device; decrypting and authenticating the initiator payload using an authenticated encryption with associated data (AEAD) algorithm; when the initiator payload is authenticated, recovering the initiator payload; generating a responder payload to be sent to the initiator device, the method comprising the responder.

12. Based on said recovering the initiator payload, determining that a responder query exists; further comprising, based on said determining that a responder query exists, determining information to be sent back to the initiator device at an initiator response URL, the method according to claim 11.

13. Said generating the responder payload comprises deriving a nonce from the responder to the initiator; encrypting the responder payload into a responder-payload-ciphertext-and-tag tuple using the AEAD algorithm; URL-encoding the responder-payload-ciphertext-and-tag tuple. Adding the URL-encoded responder-payload-ciphertext-and-tag tuple to a query existing in the initiator response URL to generate an extended responder access URL, the method according to claim 11 or claim 12.

14. The method according to claim 13, further comprising providing the extended responder access URL for access by the initiator device.

15. The method according to claim 13, further comprising providing the extended responder access URL to a proxy mediator that is effective for providing the extended responder access URL for access by the initiator device.

16. An initiator device, a network interface, a processor, and a computer-readable storage medium including instructions that, in response to execution by the processor, instruct the initiator device to execute the method according to any one of claims 1 to 10, an initiator device.

17. The initiator device is a smartphone, a computer, or a network-connected speaker, the initiator device according to claim 16.

18. A responder device, a network interface, a processor, and a computer-readable storage medium including instructions that, in response to execution by the processor, instruct the responder device to execute the method according to any one of claims 11 to 15, a responder device.

19. The responder device is a cloud service, a wireless network device, a border router, a hub, an Internet client device, or a smartphone, the responder device according to claim 18.

20. A computer-readable storage medium including instructions that, in response to execution by a processor, instruct an apparatus to execute the method according to any one of claims 1 to 15.

Images