Securing return communication via Application Uniform Resource Locators

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 priority to U.S. Provisional Patent Application No. 63 / 364,017, filed May 2, 2022, the disclosure of which is incorporated herein by reference in its entirety. [Background technology]

[0002] The use of wireless networking to connect devices to each other and to cloud-based services is becoming increasingly common for sensing environmental conditions, controlling equipment, and providing information and alerts to users. Many devices on wireless networks are designed to operate for long periods on battery power, limiting the computing, user interface, and radio resources available to the devices.

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

[0004] This summary is provided to introduce simplified concepts of securing return communications via application uniform resource locators, generally related to commissioning a device onto a home area network. The simplified concepts are further described in the detailed description below. This summary is not intended to identify essential features of the claimed invention, nor is it intended for use in determining the scope of the claimed invention.

[0005] In an aspect, methods, devices, systems, and means for securing return communications via an application uniform resource locator are described for commissioning a participant device into a home area network by an initiator device, where within 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 the extended initiator response URL containing the generated responder payload and recovers the responder payload, and with the recovery of the responder payload, the initiator device commissions the participant device into the home area network.

[0006] In an aspect, methods, devices, systems, and means for securing return communications via an application uniform resource locator are described for commissioning a participant device to a home area network by a responder, where the responder issues a responder access uniform resource locator (URL) and receives an extended responder access URL from the 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 private key associated with the initiator device's ephemeral public key, and decrypts and authenticates the initiator payload using an authenticated encryption with associated data (AEAD) algorithm. Once 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. This summary is provided to introduce the subject matter that is further described in the detailed description and drawings. As such, this summary should not be considered to describe essential features, nor should it be used to limit the scope of the claimed subject matter.

[0008] Aspects of securing return communications via application uniform resource locators are described with reference to the following drawings, in which the same numbers are used throughout to reference like features and components. [Brief explanation of the drawings]

[0009] [Figure 1] 1 illustrates an exemplary network environment in which various aspects of securing return communications via application uniform resource locators may be implemented. [Figure 2]1 illustrates an exemplary home area network system in which various aspects of securing return communications via application uniform resource locators may be implemented. [Figure 3] 1 illustrates exemplary data and control transactions between devices in accordance with aspects of securing return communications via an application uniform resource locator. [Figure 4] 1 illustrates exemplary data and control transactions between devices in accordance with aspects of securing return communications via an application uniform resource locator. [Figure 5] 1 illustrates exemplary data and control transactions between devices in accordance with aspects of securing return communications via an application uniform resource locator. [Figure 6] 1 illustrates exemplary data and control transactions between devices in accordance with aspects of securing return communications via an application uniform resource locator. [Figure 7] 1 illustrates exemplary data and control transactions between devices in accordance with aspects of securing return communications via an application uniform resource locator. [Figure 8] 1 illustrates an exemplary method for securing return communications via an application uniform resource locator, in accordance with aspects of the technology described herein. [Figure 9] 1 illustrates an exemplary method for securing return communications via an application uniform resource locator, in accordance with aspects of the technology described herein. [Figure 10] 1 illustrates an exemplary environment in which a home area network may be implemented in accordance with aspects of the technology described herein. [Figure 11] 1 illustrates an exemplary wireless network device that may be implemented in a home area network in accordance with one or more aspects of the techniques described herein. [Figure 12]1 illustrates an example system having example devices capable of implementing aspects of securing return communications via an application uniform resource locator. DETAILED DESCRIPTION OF THE INVENTION

[0010] This specification describes techniques and devices for providing secure communications for commissioning devices into home area networks (smart home networks), such as Matter® networks, Thread® networks, and Weave® networks. For example, setting up a device using the Matter protocol requires an onboard payload containing a passcode. Any entity capable of communicating with the device via the setup interface (e.g., Wi-Fi®, Thread, BLE) can use this passcode to become the administrator (commissioner) of that participating device.

[0011] Most Matter setup flows are standard Matter protocol flows, using an initial passcode scanned from a QR code on a device joining the network. However, some Matter setup flows are custom commissioning flows. In these custom commissioning flows, the device being set up is not fully prepared to allow the Matter setup (commissioning) protocol to proceed. Rather, the requirement is that the commissioning application must obtain a 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 direct the user to that URL, which is typically a webpage containing additional instructions for the commissioning process. Upon completing the custom manual steps described in the custom flow URL with the assistance of instructions or additional installed applications, the device enters a state that allows the commissioner to proceed with setting up the device.

[0012] A key issue with this scheme is that there is no way to return from the initial URL to the application with the commissioning passcode needed to continue the commissioning process, possibly without manual user intervention across several applications. If a deep link URL is accessed from web content to which the user is directed by a commissioner application that accesses a custom flow URL, there is no way to be sure when the callback URL is accessed and / or whether it is related to an initial user action. Furthermore, because there is no single global key used to encrypt this information and no key exchange mechanism is specified, the commissioning passcode, if included at all, would have to be passed as plaintext. In other words, a custom commissioning client attempting to return to the initial commissioner would have to provide the passcode in private to a potentially untrusted application if the link has multiple possible handlers.

[0013] This problem is typically solved by establishing authenticated channel confidentiality using an end-to-end mechanism or by relying on business-to-business or peer-to-peer out-of-band communication. Because some networking standards (e.g., Matter) may use commissioner applications from any one of multiple vendors, and because networking standards may or may not have a cloud component, there is no interoperable way to establish such a secure channel to convey information, and the initial commissioner cannot be reasonably confident that they are receiving trusted information from the correct source and cannot guarantee that sensitive credentials have not been leaked.

[0014] Protocols such as Weave and Matter establish a root of trust using a QR code or other challenge payload by requiring physical possession of the passcode and using the Password Authenticated Session Establishment (PASE) protocol, which is 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 man-in-the-middle (MITM) or relaying through the properties of the protocol.

[0015] Typically, key agreement between the 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 agreement. Aspects of securing return communications via Application Uniform Resource Locators involve the use of trust anchors (fixed responder access URLs obtained by trusted means) and URLs for conveying all elements of the protocol. Instead of direct messaging between two peers, the actions encompassing the steps of the protocol described herein are triggered by the access of specially crafted URLs that do not need to be secret, yet allow for the round-trip conveyance of secret information with authenticity and integrity.

[0016] In other aspects, securing return communications via application uniform resource locators describes communication across applications, and possibly between device processes, regardless of whether they are over the Internet, that does not rely on Hypertext Transfer Protocol (HTTP) and / or Hypertext Transfer Protocol Secure (HTTPS), where the same entity did not develop the initiator and / or responder for the device, and where there is no need for direct communication of out-of-band information beyond the initiator (commissioner) accessing the responder access URL. The techniques for securing return communications via application uniform resource locators allow an initiator to utilize a single URL to reach a responder with a personal authentication query embedded in the return URL. These techniques allow an initiator to reach a responder within a home area network or locally within a single device (e.g., a smartphone using these techniques to communicate between applications on the smartphone), regardless of whether the initiator and responder communicate over the Internet. Techniques for securing return communications via application uniform resource locators abstract by location (scheme, authority, path) and convey the transport hops that must be crossed between initiator and responder, regardless of whether those hops are local or remote. These techniques enable initiators to recover data from responders in an end-to-end authenticated and privacy-preserving manner.

[0017] Example Environment 1 illustrates an exemplary network environment 100 in which various aspects of securing return communications via application uniform resource locators may be implemented. The network environment 100 includes a home area network (HAN), such as HAN 200, described below with respect to FIG. 2. The HAN includes wireless network devices 102 located around a structure 104, such as a home, and connected by one or more wireless 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 (wireless local area network (WLAN) access point 110).

[0018] To provide user access to functionality implemented using wireless network devices 102 within the HAN, cloud services 112 connect to the HAN via border routers 106 through secure tunnels 114 through external networks 108 and access points 110. Cloud services 112 use web-based application programming interfaces (APIs) 118 to facilitate communication between the HAN and internet clients 116, such as apps on mobile devices.

[0019] A HAN may include one or more wireless network devices 102 that function as hubs 120. The hubs 120 may be general-purpose home automation hubs or application-specific hubs such as security hubs, energy management hubs, or HVAC hubs. The functionality of the hubs 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 the controller on the cloud service 112, the controller may be hosted on any hub 120 within the structure 104, such as a border router 106. A 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] Hosting functionality on a hub 120 within a structure 104 can improve reliability when a user's internet connection is unreliable, reduce latency for operations that would normally require connecting to a cloud service 112, and satisfy system and regulatory constraints regarding local access between wireless network devices 102.

[0021] The wireless network devices 102 of a HAN may be from a single manufacturer that also provides cloud services 112, or a HAN may include wireless network devices 102 from partners. These partners may also provide partner cloud services 122 that provide services related to their wireless network devices 102 via partner web APIs 124. Partner cloud services 122 may optionally or additionally provide services to internet clients 116 via web-based APIs 118, cloud services 112, and secure tunnels 114.

[0022] The network environment 100 can be implemented on a variety of hosts, such as battery-powered microcontroller-based devices, line-powered devices, and servers hosting cloud services. Protocols operating on the wireless network devices 102 and cloud services 112 provide many services that support the operation of home automation experiences in the network environment 100. These services include, but are not limited to, real-time distributed data management and subscription, command and response control, real-time event notification, historical data logging and storage, 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) in which various aspects of protecting return communications via application uniform resource locators can be implemented. The 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. The HAN 200 may also include wired network devices (e.g., Ethernet device(s) 214). The wireless mesh network 202 includes a router 206 and end devices 208. The router 206 and end devices 208 each include a mesh network interface for communicating over 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. End devices 208 are devices that can communicate using mesh network 202 but lack the ability to route traffic within mesh network 202 beyond simply forwarding it to its 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 communicating over the Wi-Fi network. Wi-Fi devices 210 and / or Ethernet devices 214 may include home automation devices and devices that include applications for controlling Matter devices (e.g., smartphones, tablets, network-connected speakers).

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

[0025] The HAN 200 includes one or more ecosystem controllers 216 that provide an interface between devices from ecosystem vendors and the access point 110. For example, ecosystem controller 216a provides an interface between the mesh network 202 (a Thread network) and the access point 110. Optionally, the HAN 200 may include other ecosystem controllers, such as ecosystem controller 216b, to interface with devices from other ecosystem vendors. Additionally, other devices from another IoT network 218 (e.g., non-Matter-enabled ecosystem devices) can connect to the access point 110 by way of a Matter gateway 220, which provides Matter-enabled applications with connectivity to devices in the other IoT network 218.

[0026] The devices in the mesh network 202, Wi-Fi device(s) 210, Ethernet device(s) 214, ecosystem controller 216, and Matter gateway 220, communicate with each other via transport protocols such as User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) using standard IP routing configurations.

[0027] Securing return communication via Application Uniform Resource Locators To commission a participating device (target device), the commissioning device (initiator) needs to recover secrets and / or other relevant data (interested payload, responder payload) from the responder so that it can further access the target device. The responder is any suitable device capable of storing and providing secrets and / or other relevant data (e.g., cloud service 112, wireless network device, border router 106, hub 120, internet client device, smartphone, etc.). The initiator trusts the responder and provides it with an initiator response URL that, once accessed, will carry the required interest payload. The responder may or may not trust the initiator depending on the contents 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 trusted. Obtaining the Responder Access URL triggers the final response of the target payload, which is returned to the initiator via an extended version of the Initiator Response URL (Extended Initiator Response URL) communicated from the initiator to the responder. The initiator trusts the responder to provide it with the correct target payload (e.g., "provide_access_1e074ec02eb2b452322736f565b90236"), and the target payload must be impossible to recover by any entity other than the initiator and responder. Encryption and authentication ensure that tampering with the target payload between the responder and the initiator is detectable.

[0028] Figure 3 illustrates exemplary data and control transactions between entities that can implement various aspects of securing return communications via application uniform resource locators. Initial parameters of the commissioning process are predefined (e.g., defined in a standards document specifying the communications protocol). In aspects, a symmetric cryptosystem supporting authenticated encryption with associated data (AEAD) is used for message encryption and authentication by both the initiator and responder. The key length is KL bits. An asymmetric cryptosystem supporting Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) is used by both the initiator and responder. Key derivation function (KDF) algorithms are specified for use by the initiator and 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 a cloud 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 an application on a commissioning device (e.g., internet client 116, smartphone, etc.). For example, generating 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 in its query field a well-known encoding of a public key associated with a private key held by the responder 304. Optionally or additionally, the responder access URL may convey in its format the cipher suite type associated with the public key. In other aspects, instead of a well-known encoding of the public key itself (such as the key directly in a format or a certificate with that key embedded), there may be other identifiers that, when combined, allow the initiator 302 to determine the location of the public key associated with the responder 304. For example, information encoded in the responder access URL or information known to the initiator 302 from other interactions with participating devices could allow the initiator 302 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 is obtained.

[0030] At 315, the responder 304 publishes the responder access URL in a trusted location accessible to the initiator 302. 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 a 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 retrieves the extended responder access URL, e.g., https: / / responder.example.com / responder_access?responder_pk=BHi7mFxXpV1GRQlhM75RochDaMm9m7g-Ha7CsCCPNb71XdXRmdlD3xFWpIJsY7ZiXZ1YiYv3fOCgiThi4htGdjk%3D&nonce=-sxunDvMVACCYuu0sw%3D%3D&initiator_pk=BO5nDogkrc-9AB-Yl0c3UEMCaBg3p8BzCN8sWo7AmmBaq9SPgAhVLZKfeDrJ7CWgB2eGLeUFQ Awi3UKaifiT6To%3D&initiator_payload=pDPar2dVBdMwj2gbs4iPCENuoWqAmfhBtdqfaFE1Gg2KY4pqKWJ7xs4oHrgo9n1YTPBx3bP8fdoysT4_gbu3JJNzgGSG1Aim0F 6-J16DfPZl4P2N7c54KS2F2KEjecUVE_6YK65kBwoIq6j7gxFz-qdMqcvP3GAWptz1X E2RkgnP-AKw6g8yHacwm1drOB50zOFkjzw0eC3HPRrsvTQ1xoHDBSH6-bsTUBPjnWbh from the initially obtained responder access URL. The generation of the extended responder access URL is described below with respect to Figure 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 to authenticate the extended responder access URL and generate a responder payload, as described below with respect to Figure 5. At 340, the responder generates an extended initiator response URL and communicates the responder payload to the initiator 302, as described below with respect to Figure 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 expands the extracted initiator response URL to create an expanded initiator response URL.

[0033] At 345, the initiator 302 can access the extended initiator response URL directly from the responder 304. In the alternative, 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.

[0034] 4 illustrates exemplary data and control transactions between entities for the generation (at 325) of an enhanced responder access URL that can implement various aspects of securing return communications 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 ephemeral asymmetric cryptographic key pair for Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH) compatible with the cipher suite of the responder's 304 public key generated at 310 and retrieved at 320 in the responder access URL. The initiator's ephemeral key pair includes an ephemeral private key and an ephemeral 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) symmetric cryptographic algorithm. The initiator 302 encodes the generated nonce into an appropriate representation, such as a predefined query argument, to be appended to the query present at 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 temporary private 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, the initiator 302 uses the nonce, salt and / or other information, the shared secret, and a key derivation function (e.g., an HMAC-based Extract-and-Key Derivation Function (HKDF)) to generate double the key length bits of keying material from the shared secret, half of which are an initiator-to-responder key (e.g., 20:05:d4:00:0c:72:9f:57:34:30:97:1f:26:26:ef:90) and half of which are a responder-to-initiator key (e.g., c5:12:b8:41:cc:e6:44:64:78:6c:89:ab:d8:ae:20:52). In a second alternative, 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 a nonce, as well as salt and / or other information, and a shared secret, to generate the single symmetric key.

[0037] At 420, the initiator 302 appends the temporary 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 appends the temporary public key in a URL-encoded format, a Distinguished Encoding Rules (DER) URL-safe base64 format, or a raw version of the public key format.

[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) to be accessed with the response, which URL includes any appropriate data the initiator 302 needs returned to it in the response. Optionally, at 430, the initiator 302 encodes other appropriate information to query 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), which is understandable by the responder 304 and contains the initiator response URL and, if used, an optional responder query.

[0039] In 440, the initiator 302 encrypts the initiator payload into an initiator-payload-ciphertext-and-tag tuple using a predetermined AEAD algorithm (e.g., Advanced Encryption Standard with CBC-MAC (AES-CCM) as 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 an initiator-to-responder key or a single symmetric key (as described in 415), depending on the session key agreement method. The nonce used for encryption is the nonce value generated in 410. The additional data used for encryption is the entire extended responder access URL (omitting the fragment field) up to the end of the query after being extended with the nonce (in 410) and the initiator ephemeral public key (in 420). The plaintext to encrypt is the binary string of the initiator payload (encoded in 435).

[0040] At 445, the initiator 302 URL-encodes and appends the initiator-payload-ciphertext-and-tag tuples as predefined URL query arguments to the query in the responder access URL in a format suitable for use by the responder 304, such as URL-encoded URL-safe base64 after concatenation. The initial responder access URL is now ready to be used as the enhanced responder access URL at 330. The initiator 302 can access the enhanced responder access URL using a web browser or any other suitable technology that can handle the scheme of the enhanced responder access URL.

[0041] 5 illustrates exemplary data and control transactions between entities for processing (at 335) an enhanced responder access URL that can implement various aspects of securing return communications via an application uniform resource locator. The operations described with respect to FIG. 5 use a predetermined cipher suite and key length KL, as described above.

[0042] In 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 initiator's ephemeral public key appended) described in 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, the responder 304 derives a shared secret using the private key associated with its fixed public key (associated with the previously used responder access URL and shared with the initiator 302 at 320) and the initiator's ephemeral public key extracted at 505. This is the responder's side of the session key agreement and is performed using a method symmetrical to that used at 415. In a first alternative, the responder 304 uses the nonce, and salt and / or other information, and the shared secret, a key derivation function (e.g., HKDF) to generate twice the key length bits of keying material (2*KL) from the shared secret, with half the bits being the initiator-to-responder key and the other half being the responder-to-initiator key. In a second alternative, the 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 the initiator 302 and the responder 304 .

[0044] At 515, the responder 304 decrypts and authenticates the initiator payload using a predetermined AEAD algorithm (e.g., AES-CCM as defined in NIST 800-38C section 6.1). The nonce used for decryption is the nonce extracted at 505. The additional data used is the URL stored at 505. The ciphertext to use is the ciphertext extracted at 505. The tag to verify is the extracted tag 505. The key to use is the initiator-to-responder key obtained at 510.

[0045] At 520, the responder 304 determines whether the authentication was successful. If the authentication failed, the responder 304 terminates further operation at 525 and does not trust any subsequent data from the session of the initiator 302. If the authentication was successful, the 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 is present, extracting the responder query from the initiator payload. Optionally, at 535, if a responder query is present, 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 a responder payload to send back to the initiator 302.

[0047] 6 illustrates exemplary data and control transactions between entities for generating (at 340) a responder payload that can implement various aspects of securing return communications 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, if a single symmetric key is used, the responder 304 derives the responder-to-initiator nonce (e.g., 05:33:91:63:c4:33:ab:ff:7d:9d:14:4b:4c) using a method expected by both the initiator and the responder, such as by inverting all bits of the nonce extracted at 505 (e.g., XORing each octet with 0xFF). The responder-to-initiator nonce is not transmitted because it can be calculated deterministically by the initiator 302 when processing the extended initiator-response URL.

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

[0050] At 615, the responder 304 URL-encodes the responder-payload-ciphertext-and-tag tuple in a format suitable for use by the initiator 302, such as a concatenated URL-encoded URL-safe base64 format, and appends 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 as the extended responder access URL at 330 (e.g., https: / / initiator.example.com / initiator_response?example_token=s4i0yhcQUxci6-Z0gKOFAA%3D%3D&example_field=7144&responder_payload=Wl7BNkQU-Hsz5E14Gs5WNl9ID0sxjJgzg_FTRybnsKGxd2IyxKQpYwDGdlblkKoXPO0befTrxTOW4UvsPjgO).

[0051] The responder 304 can communicate the extended initiator response URL using a browser or other client that can process the URL's scheme and permissions, possibly 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 it before it was expanded into the extended initiator response URL has access to the underlying ephemeral key pair and can recover the associated cryptographic context from data that the initiator 302 initially injected into the initiator response URL. Optionally or additionally, entities other than the responder 304 can access the extended initiator response URL. The extended initiator response URL containing the responder payload can traverse several different hops across applications and networks until it reaches an endpoint known to be able to access the URL given its scheme and permissions.

[0052] 7 illustrates exemplary data and control transactions between entities for processing (at 360) an extended initiator response URL that can implement various aspects of securing return communications via an application uniform resource locator. The operations described with respect to FIG. 7 use a predetermined cipher suite and key length KL, as described above.

[0053] At 705, the initiator 302 receives 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:a 1: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 , and removes it from the query. The initiator 302 discards the fragment field from the received extended initiator response URL. The initiator 302 examines the remainder of the extended initiator response URL, without the responder-payload-ciphertext-and-tag tuples, and determines that it matches the initially generated initiator response URL. The initiator 302 uses the remainder of the extended initiator response URL as additional data during authentication decryption. The initiator 302 recovers the expected nonce and necessary keys, matching those generated in 410 and 415, based on lookups indexed from data embedded within the recovered initiator response URL. The initiator 302 saves the response payload ciphertext and tag.

[0054] At 710, the initiator 302 decrypts and authenticates the responder payload using a predetermined AEAD algorithm (e.g., AES-CCM as defined in NIST 800-38C section 6.1). 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 verify is the extracted tag 705. The key used is the initiator-to-responder key obtained at 705.

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

[0056] Exemplary Methods Exemplary methods 800 and 900 are described with reference to FIGS. 8 and 9 according to one or more aspects of protecting return communications 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 may be described in the general context of executable instructions stored on computer-readable storage devices that are local and / or remote to a computer processing system, and implementations may include software applications, programs, functions, and the like. Optionally or additionally, any of the functionality described herein can be performed, at least in part, by one or more hardware logic components, such as, but not limited to, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), and the like. The order in which the method blocks are described is not intended to be limiting, and any number of the described method blocks can be combined in any order or omitted to implement a method or another method.

[0057] 8 illustrates example method(s) 800 for securing return communications via an application uniform resource locator, generally with respect to an initiator device commissioning 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 the 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] The initiator device generates an extended responder access URL using the obtained responder access URL in block 804. For example, the initiator device generates an extended responder access URL using the obtained responder access URL as described above with respect to FIG.

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

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

[0061] In block 810, the initiator device recovers the responder payload and causes the initiator device to commission the joining device into the home area network. For example, the initiator device uses the recovered responder payload to commission the joining device to join the home area network (e.g., home area network 200).

[0062] 9 illustrates example method(s) 900 for securing return communications via an application uniform resource locator, typically with respect to a responder generating commissioning information for an initiator device to commission a participant device onto a home area network. At block 902, the responder publishes a responder access uniform resource locator (URL). For example, the responder (e.g., responder 304) publishes the responder access uniform resource locator (URL) at 315. The responder can publish the responder access URL to a database (e.g., initiator trust database 306) trusted by the initiator device (e.g., initiator device 302).

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

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

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

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

[0067] At 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] If the initiator payload is authenticated, the responder recovers the initiator payload in block 914. For example, if the responder can authenticate the initiator payload, the responder recovers the initiator payload as described in 530. If the authentication fails, the responder terminates the operation for 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 to complete the commissioning of the responder into home area network 200.

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

[0071] Environment 1000 may implement any number of wireless network devices for wireless interconnection to wirelessly communicate and interact with one another. The wireless network devices are modular, intelligent, multi-sensing, network-connected devices that can seamlessly integrate with one another and / or with a central server or cloud computing system to provide any of a variety of useful automation purposes and implementations. An example of a wireless network device that may be implemented as any of the devices described herein is shown and described with reference to FIG. 11.

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

[0073] The hazard detectors 1004 can be implemented to detect the presence of hazardous materials or materials indicative of hazardous materials (e.g., smoke, fire, or carbon monoxide). In a wireless interconnection example, the hazard detectors 1004 may detect the presence of smoke indicative of a fire within a structure. In this case, the hazard detector that first detects the smoke can broadcast a low-power wake-up signal to all connected wireless network devices. Other hazard detectors 1004 can then receive the broadcasted wake-up signal, initiate a high-power state to detect the hazard, and receive wireless communication of an alert message. Additionally, lighting units 1008 can receive the broadcasted wake-up signal and activate within the area of ​​the detected hazard to illuminate and identify the problem area. In another example, the lighting units 1008 can activate one lighting color to indicate a problem area or location within the structure, such as a detected fire or burglary, and activate a different lighting color to indicate safe locations and / or escape routes from the structure.

[0074] In various configurations, the wireless network device 1010 may include an aisle interface device 1016 that works in coordination with a network-connected door lock system 1018 to detect and respond to a person's approach or departure from a location, such as an exterior door of the structure 1012. The aisle interface device 1016 may interact with other wireless network devices based on whether someone approaches or enters the smart home environment. The aisle interface device 1016 may control doorbell functions, notify the approach or departure of a person via audio or visual means, and control settings on a security system, such as arming or disabling the security system when an occupant enters or exits. The wireless network device 1010 may also include other sensors and detectors to detect ambient lighting conditions, detect room occupancy (e.g., with an occupancy sensor 1020), and control the power state and / or dim state of one or more lights. In some examples, the sensors and / or detectors may also control the power state or speed of a fan, such as a ceiling fan 1022. Additionally, sensors and / or detectors may detect occupancy within a room or enclosure and control the supply of power to electrical outlets or electrical devices 1024, such as when the room or structure is unoccupied.

[0075] The wireless network devices 1010 may also include connected appliances and / or control systems 1026, such as refrigerators, stoves and ovens, washers, dryers, air conditioners, pool heaters 1028, irrigation systems 1030, and security systems 1032, as well as other electronic and computing devices, such as network-connected televisions, network-connected media streaming devices, entertainment systems, computers, intercom systems, garage door openers 1034, ceiling fans 1022, and control panels 1036. When plugged in, the appliances, devices, or systems announce themselves to the home area network as described above and can automatically integrate with the home area network controls and devices within the home, etc. Note that the wireless network devices 1010 may also include devices that are physically outside the structure but within wireless communication range, such as devices controlling the swimming pool heater 1028 or irrigation system 1030.

[0076] As described above, the mesh network 202 includes a border router 106 that interfaces for communication with external networks outside the mesh network 202. The border router 106 connects 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 and / or using the devices in the HAN 200. By way of example, the cloud service 112 may include applications for connecting end user devices 1038, such as smartphones, tablets, etc., to devices in the home area network; processing and presenting data acquired by the HAN 200 to an end user; linking one or more devices in the HAN 200 to a user account with the cloud service 112; provisioning and updating devices in the HAN 200; and the like. For example, a user may use a network-connected computer or portable device, such as a mobile phone or tablet device, to control the thermostat 1002 and other wireless networked devices in a home environment. Additionally, wireless network devices can communicate information to any central server or cloud computing system via border routers 106, ecosystem controllers 216, Matter gateways 220, and / or access points 110. Data communication can be accomplished using any of a variety of custom or standard wireless protocols (e.g., Wi-Fi, ZigBee for low power, 6LoWPAN, Thread, Matter, etc.) and / or by using any of a variety of custom or standard wired protocols (Ethernet, HomePlug, etc.).

[0077] Any of the wireless network devices in the HAN 200 can function as low-power nodes and communication nodes to form the HAN 200 in a home environment. Individual low-power nodes in the network can periodically send out messages about what they are sensing, and other low-power nodes in the environment can repeat the messages (in addition to sending their own messages), thereby communicating messages from node to node (i.e., device to device) throughout the home area network. Wireless network devices can be implemented to conserve power, especially when battery-powered, by receiving messages using a low-power communication protocol, translating the messages to other communication protocols, and sending the translated messages to other nodes and / or a central server or cloud computing system. For example, occupancy and / or ambient light sensors can detect occupants in a room and measure ambient light, activating a light source when the ambient light sensor 1040 detects that the room is dark and the occupancy sensor 1020 detects that someone is in the room. Additionally, the sensors may include low-power wireless communication chips (e.g., IEEE 802.15.4 chips, Thread chips, ZigBee chips) that periodically send out messages regarding the occupancy of a room and the amount of light in the room, including instantaneous messages when the occupancy sensor detects the presence of a person in the room. As noted above, these messages may be transmitted wirelessly using a home area network between nodes in the home environment (i.e., from network-connected device to network-connected device) or over the Internet to a central server or cloud computing system.

[0078] In other configurations, various wireless network devices may act as "tripwires" for alarm systems within a home environment. For example, if an intruder evades detection by alarm sensors placed at windows, doors, and other entry points into a structure or environment, an alarm may be triggered by receiving occupancy, motion, heat, sound, or other messages from one or more low-power mesh nodes within the home area network. In other implementations, the home area network may be utilized to automatically turn on and off lighting units 1008 as a person moves from room to room within a structure. For example, wireless network devices may detect a person's movement through the structure and communicate corresponding messages via nodes in the home area network. Using messages indicating which rooms are occupied, other wireless network devices receiving these messages may activate and / or deactivate accordingly. As referenced above, the home area network may also be utilized to provide exit lighting in an emergency, such as by turning on appropriate lighting units 1008 leading to safe exits. Light units 1008 may also be turned on to indicate the direction of an exit route a person should take to safely exit the structure.

[0079] Various wireless network devices may also be implemented to integrate with and communicate with wearable computing devices 1042 that are used to identify and locate occupants of a structure, and can adjust temperature, lighting, sound systems, etc. accordingly. In other implementations, RFID detection (e.g., a person wearing an RFID bracelet, necklace, or key fob), synthetic vision technology (e.g., a video camera and facial recognition processor), audio 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 rule-based inference engines or artificial intelligence techniques that draw useful conclusions from sensed information regarding the location of occupants within a structure or environment.

[0080] In other embodiments, the human-interaction functions of a personal comfort zone network, personal health zone network, personal safety zone 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 reasoning or artificial intelligence techniques to achieve better performance of these functions. In an example related to the personal health zone, a system can use rule-based reasoning and artificial intelligence techniques (e.g., using one of the wireless network devices and sensors) to detect whether a household pet is moving toward the occupant's current location. Similarly, when a hazard detector service robot is notified of elevated temperature and humidity levels in the kitchen, it can temporarily increase its hazard detection threshold, such as a smoke detection threshold, under the inference that a slight increase in ambient smoke levels is likely due to cooking activities rather than a purely dangerous situation. Service robots configured to perform any type of monitoring, detection, and / or service can be implemented as mesh node devices on a home area network by conforming to a wireless interconnection protocol for communicating over 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 a wake-up time for the next day or week. Artificial intelligence can be used to consider the occupant's response when the alarm sounds and make inferences about preferred sleep patterns over time. Individual occupants can then 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, including ultrasonic sensors, passive IR sensors, and the like. An occupant's unique signature can be based on a combination of movement patterns, voice, height, size, etc., and the use of facial recognition technology.

[0082] In a wireless interconnection example, an individual's wake-up time can be correlated with the thermostat 1002 to efficiently control an HVAC system to preheat or precool a structure to desired sleep and wake temperature settings. Preferred settings can be learned over time, such as by capturing the temperature set on the thermostat before the person goes to bed and when they wake up. Collected data can also include biometric indicators of the person, such as breathing patterns, heart rate, and movement, and inferences can be made based on this data in combination with data indicating when the person will actually wake up. Other wireless networked 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 lights 1008 on or off.

[0083] In embodiments, wireless network devices can also be used to detect sound, vibration, and / or motion, for example, to detect running water and make inferences about water use in a home environment based on algorithms and mapping of water usage and consumption. This can be used to identify signatures or fingerprints of each water source, etc., within a home, also known as "audio fingerprint water use." Similarly, wireless network devices can be used to detect subtle sounds, vibrations, and / or motions from pests such as rats and other rodents, as well as termites, cockroaches, and other insects. The system can then notify occupants of suspected pests in their environment, such as with warning messages to help facilitate early detection and prevention.

[0084] The environment 1000 may include one or more wireless network devices functioning as a hub 1046. The hub 1046 may be a general-purpose home automation hub or a specialized hub such as a security hub, energy management hub, or HVAC hub. 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. Hosting the functionality on the hub 1046 within the structure 1012 can improve reliability when a user's internet connection is unreliable, reduce latency for operations that would normally require connecting to a cloud service 112, and satisfy system and regulatory constraints regarding local access between wireless network devices.

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

[0086] 11 illustrates an exemplary wireless network device 1100 that may be implemented as any of the wireless network devices in a home area network (Weave network) in accordance with one or more aspects of protecting return communications via an application uniform resource locator described herein. Device 1100 may be integrated with electronic circuitry, a microprocessor, memory, input / output (I / O) logic control, communication interfaces, and components, as well as other hardware, firmware, and / or software to implement a device within a home area network. Additionally, wireless network device 1100 may be implemented using a variety of components, e.g., any number and combination of different components, as further described with reference to the exemplary device illustrated 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 digital signal processor) that process executable instructions. The device also includes input / output (I / O) logic control 1106 (e.g., to include electronic circuitry). The microprocessor may include components of integrated circuits, programmable logic devices, logic devices formed using one or more semiconductors, and other implementations in silicon and / or hardware, such as processor and memory systems implemented as a system-on-a-chip (SoC). Optionally or additionally, the device may be implemented with any one or combination of software, hardware, firmware, or fixed logic circuits, which may be implemented in the processing and control circuits. The low-power microprocessor 1102 and the high-power microprocessor 1104 may also support one or more different device functions of the device. For example, the high-power microprocessor 1104 may perform computationally intensive operations, while the low-power microprocessor 1102 may manage simpler processes, such as detecting hazards or temperature from one or more sensors 1108. The low-power processor 1102 may also wake up or initialize the high-power processor 1104 for computationally intensive processes.

[0088] The one or more sensors 1108 can be implemented to detect various characteristics such as acceleration, temperature, humidity, water, power supply, proximity, external motion, device movement, audio signals, ultrasonic signals, light signals, fire, smoke, carbon monoxide, Global Positioning Satellite (GPS) signals, radio frequency (RF), other electromagnetic signals or fields, etc. Thus, the sensors 1108 can include any one or combination of temperature sensors, humidity sensors, hazard-related sensors, security sensors, other environmental sensors, accelerometers, microphones, light sensors, and even cameras (e.g., CCD cameras or video cameras), active or passive radiation sensors, GPS receivers, and radio frequency identification detectors. In embodiments, wireless network device 1100 may include one or more primary sensors and one or more secondary sensors, where, for example, the primary sensors detect data 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 may detect other types of data (e.g., motion, light, or sound) that can be used for energy efficiency 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 may also include various firmware and / or software, such as an operating system 1114, maintained by the memory as computer-executable instructions and executed by the microprocessor. The device software may also include a commissioning application 1116 that implements aspects of protecting return communications 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 includes 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 may also be implemented as any one or combination of different bus structures and / or bus architectures.

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

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

[0092] 12 illustrates an example system 1200 including an example device 1202 that can be implemented as any of the wireless network devices that implement aspects of protecting return communications via an application uniform resource locator, as described with reference to FIGS. 1-11 above. The example device 1202 can be any type of computing device, client device, mobile phone, tablet, communication, entertainment, gaming, media playback, and / or other type of device. Additionally, the example device 1202 can be implemented as any other type of wireless network device configured for communication over a home area network, such as a thermostat, hazard detector, camera, light unit, commissioning device, router, border router, participant router, participant device, end device, reader, access point, and / or other wireless network device.

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

[0094] Device 1202 also includes input / output (I / O) interfaces 1208, such as a data network interface, that provide a connectivity and / or communication link between the device and a data network (e.g., a home area network, an external network, etc.) and other devices. The I / O interfaces can be used to couple the device to any type of component, peripheral, and / or attached device. The I / O interfaces also include data input ports through which any type of data, media content, and / or input, such as user input to the device, can be received, as well as any type of communication data, and audio, video, and / or image data received from any content and / or data source.

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

[0096] The device 1202 also includes 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 that provides persistent storage of data and executable instructions (e.g., software applications, modules, programs, functions, etc.). Computer-readable storage memory as described herein does not include propagating signals. Examples of computer-readable storage memory include volatile and non-volatile memory, fixed and removable media devices, and any suitable media device or electronic data storage that maintains data for access by a computing device. The computer-readable storage memory can include various implementations of random access memory (RAM), read-only memory (ROM), flash memory, and other types of storage memory in various memory device configurations.

[0097] The computer-readable storage memory 1212 (computer-readable storage medium 1212) provides storage for 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 may also include a device manager, any type of control application, software application, signal processing and control module, code that is specific to a particular device, a hardware abstraction layer for a particular device, etc. In this example, the device applications also include a commissioning application 1216 that implements aspects of the initiator 302, for example, securing return communications 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 audio device 1220 and / or generates display data for display device 1222. The audio 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 a digital photo. In embodiments, the audio and / or display device are integrated components of exemplary device 1202. Alternatively, the audio and / or display device are external, peripheral components of the exemplary device. In aspects, at least some of the techniques described for securing return communications via application uniform resource locators may be implemented in a distributed system, such as on a “cloud” 1224 within platform 1226. Cloud 1224 includes and / or represents platform 1226 for services 1228 and / or resources 1230.

[0099] Platform 1226 abstracts underlying functionality of hardware, such as server devices (e.g., included in services 1228), and / or software resources (e.g., included as resources 1230) and connects exemplary device 1202 with other devices, servers, etc. For example, platform 1226 and / or services 1228 may implement aspects of responder 304. Resources 1230 may also include applications and / or data available while computer processing is executed on a server remote from exemplary device 1202. Furthermore, services 1228 and / or resources 1230 may facilitate subscriber network services, such as over the Internet, a cellular network, or a Wi-Fi network. Platform 1226 may also serve to abstract and scale resources to service demand for resources 1230 implemented via the platform, such as in aspects of interconnected devices with functionality distributed throughout system 1200. For example, functionality may be implemented in part in exemplary device 1202 and via platform 1226, which abstracts functionality of cloud 1224.

[0100] Some examples are 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 acquired responder access URL; accessing the extended responder access URL with a responder, whereby the responder generates a responder payload; accessing an extended initiator response URL containing the generated responder payload; recovering the responder payload, wherein recovering the responder payload causes the initiator device to commission the participant device to the home area network; the initiator device The method comprising:

[0101] Example 2: The generating of the extended responder access URL comprises: generating an initiator ephemeral key pair including a ephemeral private key and a ephemeral public key; deriving a shared secret using the ephemeral private key and the responder public key of the generated initiator ephemeral key pair; appending the temporary public key to a query present in the responder access URL; generating an initiator response URL that is accessed with the response, the initiator response URL including data that is returned to the initiator device in the response; encoding an initiator payload including an initiator response URL; encrypting the initiator payload into an initiator-payload-ciphertext-and-tag tuple; URL encoding the initiator-payload-ciphertext-and-tag tuple; appending the URL-encoded initiator payload ciphertext and tag tuple to the query present in the responder access URL; The method of Example 1, comprising:

[0102] Example 3: The encoding of the initiator payload includes: encoding the initiator payload to include the initiator response URL and a responder query; The method of Example 2, comprising:

[0103] Example 4: The encrypting of the initiator payload into the initiator-payload-ciphertext-and-tag tuple comprises: Encrypting the initiator payload into an initiator-payload-ciphertext-and-tag tuple using an authenticated encryption with associated data (AEAD) algorithm. The method of Example 2, comprising:

[0104] Example 5: Generating a random nonce; generating an initiator-to-responder key and a responder-to-initiator key, said generating using a key derivation function, the random nonce, a shared secret, and salt and / or other information to generate twice the number of key length bits, half of the generated bits being the initiator-to-responder key and the other half of the generated bits being the responder-to-initiator key; The method of any one of the preceding examples, further comprising:

[0105] Example 6: Using a key derivation function to generate a key length bit symmetric key to be used in both directions between the initiator device and the responder The method of any one of the preceding examples, further comprising:

[0106] Example 7: The accessing of the responder access URL accessing the responder access URL from an initiator trust database; The method of any one of the preceding examples, comprising:

[0107] Example 8: The recovering the responder payload comprises: extracting a responder-payload-ciphertext-and-tag tuple; decrypting the responder-payload-ciphertext-and-tag tuple; removing 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; commissioning the participant device to the home area network using the responder payload if the responder payload is authenticated; The method of any one of the preceding examples, comprising:

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

[0109] Example 10: The accessing of the extended initiator response URL includes: accessing the extended initiator response URL from the responder; or Accessing the extended initiator response URL from a proxy intermediary The method of any one of the preceding examples, comprising:

[0110] Example 11: A method of commissioning a participant device to a home area network by a responder, comprising: publishing a responder access uniform resource locator (URL); receiving an extended responder access URL from the 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 responder's public key and a temporary public key of the initiator device; decrypting and authenticating the initiator payload using an authenticated encryption with associated data (AEAD) algorithm; recovering the initiator payload if the initiator payload is authenticated; generating a responder payload to send to the initiator device; The responder The method comprising:

[0111] Example 12: Determining that a responder query exists based on the recovering the initiator payload; determining information to send back to the initiator device in an initiator response URL based on determining that the responder query exists; The method of Example 11, further comprising:

[0112] Example 13: The generating of 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; appending the URL-encoded responder-payload-ciphertext-and-tag tuple to the query present in the initiator response URL to generate an enhanced responder access URL; The method of Example 11 or Example 12, comprising:

[0113] Example 14: Providing the extended responder access URL for access by the initiator device The method of Example 13, further comprising:

[0114] Example 15: Providing the extended responder access URL to a proxy intermediary effective to provide the extended responder access URL for access by the initiator device The method of Example 13, further comprising:

[0115] Example 16: An initiator device, comprising: A network interface; a processor; a computer-readable storage medium comprising instructions that, when executed by the processor, direct the initiator device to perform the method of any one of Examples 1 to 10; The initiator device.

[0116] Example 17: The initiator device Smartphone, computer, or It is a network-connected speaker, The initiator device of example 16.

[0117] Example 18: A responder device, comprising: A network interface; a processor; a computer-readable storage medium comprising instructions that, in response to execution by the processor, direct the responder device to perform the method of any one of Examples 11 to 15; The responder device.

[0118] Example 19: The responder device Cloud services, wireless network devices, border routers, Hub, Internet client device, or Smartphone 19. The responder device of Example 18, wherein

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

[0120] Although aspects of securing return communications via an application uniform resource locator have been described in feature- and / or method-specific language, the subject matter of the appended claims is not necessarily limited to the particular features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations of securing return communications via an application uniform resource locator, and other equivalent features and methods are intended to be within the scope of the appended claims. Furthermore, it should be understood that a variety of different aspects have been described, and that each described aspect can be implemented independently or in conjunction with one or more of the other described aspects.

Claims

1. 1. A method of commissioning a participant device into a home area network by an initiator device, the method including the initiator device, the 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 with a responder, wherein said accessing causes said responder to generate a responder payload; and said initiator device further: accessing an extended initiator response URL containing the generated responder payload; and recovering the responder payload, wherein by recovering the responder payload, the initiator device commissions the participant device into the home area network.

2. The generating of the extended responder access URL includes: generating an initiator ephemeral key pair including a ephemeral private key and a ephemeral public key; deriving a shared secret using the ephemeral private key and the responder public key of the generated initiator ephemeral key pair; appending the temporary public key to a query present in the responder access URL; generating an initiator response URL that is accessed using the response, the initiator response URL including data that is returned to the initiator device in the response, and the generating the extended responder access URL further includes: encoding an initiator payload including an initiator response URL; encrypting the initiator payload into an initiator-payload-ciphertext-and-tag tuple; URL-encoding the initiator-payload-ciphertext-and-tag tuple; and appending the URL-encoded initiator payload ciphertext and tag tuple to the query present in the responder access URL.

3. The encoding of the initiator payload comprises: The method of claim 2 , further comprising encoding the initiator payload to include the initiator response URL and a responder query.

4. The encrypting the initiator payload into the initiator-payload-ciphertext-and-tag tuple comprises:

3. The method of claim 2, comprising encrypting the initiator payload into an initiator-payload-ciphertext-and-tag tuple using an authenticated encryption with associated data (AEAD) algorithm.

5. generating a random nonce; and generating an initiator-to-responder key and a responder-to-initiator key, wherein generating the initiator-to-responder key and the responder-to-initiator key comprises using a key derivation function, the random nonce, a shared secret, and salt and / or other information to generate twice a number of key length bits, wherein half of the generated bits are an initiator-to-responder key and the other half of the generated bits are a responder-to-initiator key.

6. The method of claim 1 , further comprising using a key derivation function to generate a symmetric key of key length bits to be used in both directions between the initiator device and the responder.

7. The accessing of the responder access URL includes: The method of claim 1 , further comprising accessing the responder access URL from an initiator trust database.

8. recovering the responder payload comprises: extracting the responder payload-ciphertext-and-tag tuple; decrypting the responder payload-ciphertext-and-tag tuple; removing 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 if the responder payload is authenticated, commissioning the participant device to the home area network using the responder payload.

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

10. The accessing of the extended initiator response URL includes: accessing the extended initiator response URL from the responder; or The method of claim 1 , comprising accessing the extended initiator response URL from a proxy intermediary.

11. 1. A method of commissioning a participant device into a home area network by a responder, comprising: publishing a responder access uniform resource locator (URL); receiving an extended responder access URL from the 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 responder's public key and a temporary public key of the initiator device; Decrypting and authenticating the initiator payload using an Authenticated Encryption with Associated Data (AEAD) algorithm; recovering the initiator payload if the initiator payload is authenticated; generating a responder payload to send to the initiator device.

12. determining, based on the recovering the initiator payload, that a responder query exists; The method of claim 11 , further comprising: determining information to send back to the initiator device in an initiator response URL based on the determining that the responder query exists.

13. generating a responder payload, 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 appending the URL-encoded responder payload-ciphertext-and-tag tuple to a query present in an initiator response URL to generate an extended initiator response URL.

14. The method of claim 13 , further comprising providing the extended initiator response URL for access by the initiator device.

15. 14. The method of claim 13, further comprising providing the extended initiator response URL to a proxy intermediary effective to provide the extended initiator response URL for access by the initiator device.

16. an initiator device, A network interface; a processor; a computer-readable storage medium comprising instructions that, when executed by the processor, direct the initiator device to perform the method of any one of claims 1 to 10.

17. The initiator device Smartphone, computer, or 17. The initiator device of claim 16, wherein the initiator device is a network-connected speaker.

18. a responder device, A network interface; a processor; a computer-readable storage medium comprising instructions that, when executed by said processor, direct said responder device to perform the method of any one of claims 11 to 15.

19. the responder device Cloud services, wireless network devices, border routers, Hub, Internet client device, or 20. The responder device of claim 18, wherein the responder device is a smartphone.

20. A program comprising instructions for directing an apparatus to carry out a method according to any one of claims 1 to 10, when executed by a processor.

21. A program comprising instructions for instructing an apparatus to perform a method according to any one of claims 11 to 15 in response to execution by a processor.

Images