阅读说明：本技术 用于将装置连接到局域网的基于服务器的设置 (Server-based setup for connecting devices to a local area network ) 是由 A·M·帕萨利亚 A·罗斯 P·J·埃利斯 于 2020-02-21 设计创作，主要内容包括：描述了用于将安全数据网络的凭证提供到计算装置的技术。在一实例中,系统存储所述计算装置与用户账户之间的关联。所述用户账户还与所述安全数据网络的凭证相关联。所述系统接收所述计算装置的证书,且基于所述证书确定所述计算装置与所述用户账户之间的所述关联。此外,所述系统基于所述关联被确定而认证所述计算装置以向所述计算装置发送数据,其中此数据是基于所述系统的私钥来验证的。所述系统基于所述数据接收所述计算装置对所述凭证的请求且将所述凭证发送到所述计算装置。(Techniques for provisioning credentials of a secure data network to a computing device are described. In an example, a system stores an association between the computing device and a user account. The user account is also associated with credentials of the secure data network. The system receives credentials of the computing device and determines the association between the computing device and the user account based on the credentials. Further, the system authenticates the computing device to send data to the computing device based on the association being determined, where this data is verified based on a private key of the system. The system receives a request for the credentials by the computing device based on the data and sends the credentials to the computing device.)

1. A method implemented by one or more servers to provide a password for a secure Local Area Network (LAN) to a computing device, access to the secure LAN being provided by a wireless router, the method comprising:

storing a list associating one or more public keys with one or more user accounts;

storing a user account including a user identifier, a Service Set Identifier (SSID) of the secure LAN, and a password of the secure LAN;

storing a private key of the one or more servers and a mapping between the private key and a product classification of the computing device;

receiving a public key of the computing device, the product classification of the computing device, and the user identifier in response to a scanner scanning a barcode associated with the computing device;

updating the list to include the public key and the user account;

receiving, via the wireless router, a certificate for the computing device, the certificate including the public key of the computing device, wherein the wireless router and the computing device are connected over an open LAN, and wherein the certificate is sent from the computing device over the open LAN;

authenticating the computing device by performing Transport Layer Security (TLS) authentication using the certificate;

determining from the list that the public key included in the certificate is associated with the user account;

accessing the private key by determining from the mapping that the private keys of the one or more servers are associated with the product classification of the computing device;

sending a first encrypted Hypertext transfer protocol (HTTPS) response to a first HTTPS request of the computing device, the first HTTPS request sent from the computing device over the open LAN, the first HTTPS response being signed with the private key of the one or more servers and sent from the one or more servers to the computing device over the open LAN via the wireless router;

receiving, from the wireless router, a second HTTPS request from the computing device, the second HTTPS request including the SSID of the secure LAN; and

sending the password from the secure LAN of the user account in a second HTTPS response to the computing device over the open LAN via the wireless router.

2. One or more computer-readable storage media storing instructions that, when executed by one or more processors of a system, cause the system to perform operations comprising:

storing an association between a computing device and a user account, the user account associated with a local area network;

receiving a certificate of the computing device;

determining the association between the computing device and the user account based at least in part on the credentials;

authenticating the computing device based at least in part on the association being determined;

sending, to the computing device, data signed with a private key of the system based at least in part on the computing device being authenticated;

receiving, based at least in part on the data, a request for credentials of the local area network by the computing device; and

sending the credential to the computing device based at least in part on the request.

3. The one or more computer-readable storage media of claim 2, wherein each of the certificate and the request is received via a data connection between the computing device and a wireless router of a second local area network, wherein each of the data and the certificate is sent to the computing device via the data connection.

4. The one or more computer-readable storage media of claim 2, wherein each of the certificate and the request is received via a data connection between the computing device and a second computing device over a second local area network, and wherein the operations further comprise:

receiving barcode data associated with the computing device; and

requesting the second computing device to set up the second local area network for a period of time based at least in part on the barcode data being received.

5. The one or more computer-readable storage media of claim 2, wherein the operations further comprise:

receiving, from a barcode associated with the computing device, first data regarding a public key of the computing device and second data regarding the user account in response to a scan of the barcode by a remote device, wherein the association between the computing device and the user account is generated based at least in part on the first data and the second data.

6. The one or more computer-readable storage media of claim 2, wherein the operations further comprise:

receiving barcode data from a barcode associated with the computing device from a mobile device, the barcode data comprising a Personal Identification Number (PIN), wherein the association between the computing device and the user account comprises the PIN based at least in part on the barcode data; and

receiving a hash of the PIN from the computing device, wherein authenticating the computing device is based at least in part on the certificate, the PIN associated with the computing device, and the hash of the PIN.

7. The one or more computer-readable storage media of claim 2, wherein the operations further comprise:

storing a plurality of private keys including the private key;

storing a mapping between the plurality of private keys and a computing device type and a range of product numbers for the computing device type; and

signing the data with the private key based at least in part on a type of the computing device, a product number of the computing device, and the mapping.

8. The one or more computer-readable storage media of claim 2, wherein the system is a backend server storing credentials for a local area network, wherein the data comprises a message received in an HTTPS request from the computing device, and wherein the data is signed by generating a hash from the message and encrypting the hash with the private key of the system.

9. A computing device, comprising:

one or more processors; and

one or more memories storing a certificate of the computing device and a public key of a server, the one or more memories further storing instructions that, when executed by the one or more processors, cause the computing device to:

establishing a first data connection to a first Local Area Network (LAN);

sending the certificate to the server via the first data connection;

receiving data from the server via the first data connection, the data being signed with a private key of the server based at least in part on the certificate;

authenticating the server by verifying the data based at least in part on the public key of the server;

requesting credentials for a second LAN from the server via the first data connection;

receiving the credentials from the server via the first data connection; and

establishing a second data connection to the second LAN based at least in part on the credentials.

10. The computing device of claim 9, wherein execution of the instructions further causes the computing device to store a Service Set Identifier (SSID) of the first LAN, wherein the first LAN is a hidden network, and wherein the first data connection is established based at least in part on the SSID from the one or more memories.

11. The computing device of claim 9, wherein data traffic to and from the computing device over the first LAN is restricted based at least in part on one or more of: a throughput of the data traffic, a destination of the data traffic, an origin of the data traffic, or a number of computing devices connected to the first LAN.

12. The computing device of claim 9, wherein execution of the instructions further causes the computing device to:

detecting an identifier of a secure LAN comprising the second LAN;

sending a request to the server for credentials for the secure LAN; and

receiving one or more of the credentials from the server based at least in part on an association between one or more of the secure LANs and a user account, wherein the one or more of the credentials comprise the credentials of the second LAN.

13. The computing device of claim 9, wherein execution of the instructions further causes the computing device to:

detecting an identifier of a secure LAN comprising the second LAN and a third LAN;

sending a request to the server for credentials for the third LAN;

receiving a response from the server that the credentials of the third LAN are unavailable; and

sending a request to the server for the credentials of the second LAN based at least in part on the response.

14. The computing device of claim 9, wherein execution of the instructions further causes the computing device to store a plurality of public keys of the server and an indication to authenticate the server using a public key of the plurality of public keys, wherein verifying the data is based at least in part on the indication.

15. The computing device of claim 9, wherein execution of the instructions further causes the computing device to:

sending, over the second LAN to a second server, a first indication that the public key is used in association with establishing the second data connection;

receiving a second indication from the second server that the public key is not trusted; and

terminating the second data connection to the second LAN based at least in part on the second indication.

Background

Most computing devices, such as consumer electronic devices, support wireless connectivity. Typically, computing devices are connected to wireless access points that provide access to a data network. In many cases, the data network is a secure home network and is accessible to the computing device based on credentials, such as a password. In these cases, different techniques may be used to create a secure wireless home network. For example, Wi-Fi protected setup (WPS) is a network security standard that allows users to connect computing devices to secure wireless home networks via wireless access points. WPS technology and other connection technologies generally rely on user input at the computing device and/or wireless access points to establish the connection.

Drawings

Various embodiments according to the present disclosure will be described with reference to the figures, in which:

FIG. 1 illustrates an example of connecting a computing device to a secure data network according to an embodiment of the present disclosure;

FIG. 2 illustrates an example of associating a computing device with a user, according to an embodiment of the present disclosure;

FIG. 3 illustrates an example of mutual device and server authentication in accordance with an embodiment of the present disclosure;

FIG. 4 illustrates an example of provisioning credentials of a secure data network from a server to a computing device according to an embodiment of the present disclosure;

FIG. 5 illustrates another example of authenticating and providing credentials for a secure data network according to an embodiment of the present disclosure;

FIG. 6 illustrates an example of a computing device configured to be configured by a provider device to connect to a secure data network, in accordance with an embodiment of the present disclosure;

fig. 7 illustrates an example of a computing device configured as a provider device to facilitate communication between a provider device and a cloud server, in accordance with an embodiment of the present disclosure;

fig. 8 illustrates an example of a cloud server configured to authenticate a vendor device and provide credentials for a secure data network in accordance with an embodiment of the present disclosure;

FIG. 9 shows an example of a sequence diagram between a supplier device, and a server connecting the supplier device to a secure data network, according to an embodiment of the present disclosure;

FIG. 10 shows an example of a flow for connection of a provider device to a secure data network, according to an embodiment of the present disclosure;

FIG. 11 illustrates an example of a flow for a server to provide credentials of a secure data network to a provisioned device, according to an embodiment of the present disclosure; and

fig. 12 shows a computer architecture diagram illustrating an example computer architecture, according to an embodiment of the present disclosure.

Detailed Description

In the following description, various embodiments will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that embodiments may be practiced without these specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the described embodiments.

Embodiments of the present disclosure are particularly directed to a server-based setup process for automatically connecting a computing device to a secure data network, such as a secure Local Area Network (LAN). Server-based provisioning allows a wireless connection to be established in a secure manner and without user input at the computing device and/or another device of the secure data network during the provisioning process. In an example, a computing device establishes a data connection with a provider computing device, such as a wireless access point, over a different data network. Such a provider computing device may manage data communications between the computing device and a backend system, such as a cloud server. In particular, outbound data traffic from the computing device is received by the provider computing device over a different data network and sent to the backend system. Inbound data traffic to the computing device is received by the provider computing device from the backend system and transmitted to the computing device over a different data network. Data communication involves a credential exchange between a computing device and a backend server for mutual authentication. Additionally, the back-end system further authenticates the computing device based on an existing association between the computing device and the user account. Similarly, the computing device further authenticates the backend system based on the digital signature, where this digital signature is received as part of the data communication. This further layer of authentication adds security to the setup process by helping to prevent man-in-the-middle type network attacks. Once authentication is complete, the computing device may request credentials for the secure data network from the backend system via the provider computing device. Upon determining that the identifier of the secure data network and its credentials are associated with the user account, the back-end system sends the credentials to the computing device via the provider computing device. The computing device, in turn, connects to the secure data network by establishing a data connection with an access point of the secure data network using the credentials.

To illustrate, consider an example of a secure home network that includes a router and a first Voice Controlled Multimedia Device (VCMD) of a user. A second VCMD would be connected to this network. In this example, both VCMDs have registered with the service provider under a user account, where this user account is maintained on the cloud server. When the first VCMD connects to the secure home network for the first time, a Service Set Identifier (SSID) and password for the connection are stored under the user account. When the second VCMD is registered under the user account, the registering includes storing at least a portion of a public key of the second VCMD under the user account. In addition, the router provides access to a hidden open network with a predefined SSID, where data traffic on this network can be restricted based on a set of restrictions.

Upon first power-up, or optionally upon detecting that a data connection with the home network has not been set up, the second VCMD enters Wi-Fi setup mode. In this mode, the second VCMD determines the predefined SSID, its digital certificate, and the network address of the cloud server from its local memory, and automatically connects to the router through the hidden open network. The second VCMD also sends its digital certificate in encrypted hypertext transfer protocol (HTTPS) addressed to the cloud server. The router receives this request and forwards the request to the cloud server based on the restrictions on the outbound traffic allowed to the cloud server. The router receives back the digital certificate of the cloud server in an HTTPS response addressed to the second VCMD and forwards the HTTPS response to the second VCMD based on a restriction to allow inbound traffic from the cloud server to the second VCMD. Given the two digital certificates, the second VCMD and the cloud server perform mutual Transport Layer Security (TLS) authentication.

Next, the cloud server determines that the public key from the received digitally signed second VCMD matches at least a portion of the public key stored under the user account. Thus, the cloud server further authenticates the second VCMD based on this match and generates a digital signature by encrypting the data with the cloud server's private key. The private key may be one of a plurality of private keys of the cloud server, and in particular, a type that may be used for the second VCMD. This digital signature is sent to the second VCMD via the router. In response, the second VCMD accesses a public key corresponding to the private key, where this public key and other public keys of the cloud server are stored in local memory of the second VCMD. The second VCMD verifies the digital signature by using the public key of the cloud server. Upon successful verification, the second VCMD further authenticates the cloud server.

Once authentication is complete, the second VCMD sends another HTTPS request addressed to the cloud server via the router. This request includes the SSID of the secure home network, is received by the router by hiding the open network, and is forwarded to the cloud server based on restrictions that allow it to do so. In response, the cloud server determines a password for the secure home network from the user account and sends this credential in an HTTPS response addressed to the second VCMD. The HTTPS request is received by the second VCMD subject to the restriction of allowing the inbound traffic. Thus, the second VCMD disconnects from the router by hiding the open network and establishes a new data connection with the router on the secure home network by using the password.

The server-based setup process for automatically connecting a computing device to a secure data network provides a number of technical improvements over conventional techniques for setting up data connections. For example, this setup process may be performed automatically without involving user input. In particular, once a computing device is registered under a user account associated with credentials of a secure data network, a user may only need to power up the computing device for such device to communicate with backend systems and connect to the secure data network. In addition, this setup can be performed securely by relying on multiple layers of authentication, including layers that reduce the risk of or prevent man-in-the-middle attacks. In addition, other devices on the secure data network may be protected by restricting inbound and outbound traffic to and from the computing device when different data networks are used for authentication and credential reception. The use of multiple private keys and corresponding public keys of the backend system also allows limiting the impact of private key compromise and may support key rotation. These and other technical improvements will be further described and will be apparent from the description of the figures herein below.

Using a server-based setup process, a user may obtain a computing device that is registered with a backend system under a user account. Upon power-up and without credentials for the user's secure home Wi-Fi network, the computing device connects to a nearby open Wi-Fi network and uses this network to communicate with backend systems that store credentials. The back-end system identifies the computing device and the user account. Upon mutual authentication, the backend system sends the credentials to the computing device. The computing device is then disconnected from the open Wi-Fi network and connected to the secure home Wi-Fi network.

FIG. 1 illustrates an example of connecting a computing device to a secure data network according to an embodiment of the present disclosure. In general, a computing device is first associated with a user account, then connects to a server over a different network for authentication, and once authenticated, receives credentials from the server to connect to a secure data network. Fig. 1 illustrates this method in stages.

As illustrated, at an initial stage, a device-to-user account association 110 is generated. The device-to-user account association 110 supports subsequent cloud-based settings of the connection in a secure manner. The cloud-based setup, in turn, may involve multiple phases, including one phase for device and server authentication 140 and one phase for device to LAN connection 170. Device and server authentication 140 relies on the device-to-user account association 110 to ensure that the device authenticates to the server and completes the server-to-device authentication. The device-to-LAN connection 170 occurs once authentication is complete and involves data exchange with respect to the secure LAN so that the device can connect to the secure LAN. In each of these stages, different computing components are involved as described further herein below.

In an initial phase, server 112 receives data about computing device 142 from remote device 114. This data generally identifies computing device 142 and includes information that is unique to computing device 142 and that can be used for authentication, such as a public key of computing device 142 or a portion of such a public key. The data may also identify a user account of the user obtaining (e.g., purchasing) the computing device 142. The user account may store credentials for secure network 172. In general, credentials, such as a password, for the secure network 172 from the computing device are required before the computing device can join the secure network 172, where such credentials are part of the protected access to the secure network 172 at the communication link. In an example, secure network 172 represents a secure home network for different computing devices of the user. In an illustrative example, upon purchase of the computing device 142 under a user account, data may be generated and stored (e.g., encoded) in a label 116 (e.g., a barcode) attached to a container 118 (e.g., a box) that houses the computing device 142 (or directly attached to the computing device 142). As part of providing computing device 142 to the user, remote device 114 is used to scan tag 116 and read and send data to server 112. In response, server 112 generates and stores device-to-user account association 110. For example, server 112 updates the user account to store some or all of the received data, including the device identifier, the type of computing device 142, and the public key, or portions thereof. Also at this stage, the public key of server 112 is loaded onto computing device 142 (e.g., as part of manufacturing or provisioning computing device 142). Further details regarding the computing components and the interactions between them in this initial phase are further described with respect to FIG. 2.

At the next stage, the user receives the computing device 142 (e.g., receives the container 118 and unpacks the computing device 142 from it). The user then powers on the computing device 142. If computing device 142 determines that it is not already connected to the home network (e.g., the device is first powered on), computing device 142 determines from its local memory the SSID that hides open network 144. The computing device 142 then establishes a data connection with the wireless router 146 of the open, hidden network 144, thereby joining the hidden, open network 144. Wireless router 146 has been communicatively coupled with server 112 and may send data received from computing device 142 over a data connection to server 112 and may send data received from server 112 over a data connection to computing device 142. In an example, wireless router 146 may impose restrictions on inbound and outbound data traffic to and from computing device 142 to ensure that the data connection with computing device 142 is properly and securely used.

The exchange of data between computing device 142 and server 112 via wireless router 146 includes computing device 142 sending its device digital certificate to server 112 and server 112 sending its server digital certificate to computing device 142 for mutual authentication. Additionally, server 112 may retrieve the public key of computing device 142 from the device digital certificate and compare and match this key to data about computing device 142 under the user account. If a match exists, the server 112 determines that the computing device 142 has been authenticated and generates a digital signature by encrypting the data with its private key. The digital signature is sent to computing device 142, and in response, computing device 142 verifies the digital signature with the public key of server 112, where this key is available from local memory of computing device 142. Upon verification, computing device 142 determines that the server has also been authenticated. Further details regarding the computing components and the interactions between them in this initial phase are further described with respect to FIG. 3.

Once device and server authentication 140 is complete, computing device 142 and server 112 may continue to exchange data to receive credentials for secure network 172 while computing device 142 is still hidden from open network 144. At this point, the computing device 142 disconnects from the hidden open network 144 and uses the credentials to connect to the secure network 172 via the wireless router 146, thereby joining the secure data network 172 (e.g., the home network of the user's computing device). Restrictions on inbound and outbound data traffic will no longer apply, and computing device 142 may also interact with the computing device and access computing services on other data networks 174 in addition to server 112.

In the illustrative example, the computing device 142 detects the SSID of the secure data network 172 and sends a request to the server 112 for a password corresponding to the SSID via a data connection to the wireless router 146 over the hidden open network 144. In response, the server may determine that the SSID is associated with (e.g., stored on) the user account, retrieve the password (e.g., from the user account), and send it back to the computing device 142 via the wireless router 146 and by hiding the data connection on the open network 144. Upon receiving the credentials, the computing device 142 terminates the data connection and joins the secure data network 172 by establishing a new data connection with the wireless router 146 using the SSID and password. Further details regarding the computing components and the interactions between them in this initial phase are further described with respect to FIG. 4.

For clarity of explanation, FIG. 1 describes stages involving particular computing components. However, embodiments of the present disclosure are not so limited. For example, the server 112 may be a computing component of a cloud server and/or a backend system that includes one or more servers. The functionality of the server-based setup process may be distributed within the backend system. In another example, the computing device 142 need not be connected to the same wireless router to join the hidden open network 144 and the secure data network 172. For example, two different routers may be used, one on each of the two data networks. In another example, devices other than routers may be used. For example, the computing device 142 may be connected to an access point on the secure data network 172. Alternatively, another computing device of a user who has registered under a user account that has joined the secure data network 172 may serve as an access point to the hidden open network 144. In general, such a computing device and wireless router 146 described herein above are examples of provider devices with which the computing device 142 communicates to exchange data with the server 112 for authentication and receipt of credentials for the secure data network 172. In yet another example, a different type of network may be used instead of hiding open network 144. For example, such a data network may simply be an open network (rather than hidden) that broadcasts an SSID (in which case computing device 142 need not pre-store such SSID in its memory). In another example, the data network may be a public network with a personal web portal. In this case, the data exchange with the server 112 may be performed by requesting transmission of the relevant data via a Domain Name Service (DNS). These and other variations are further illustrated in conjunction with the following figures.

Fig. 2 illustrates an example of associating a computing device with a user, according to an embodiment of the present disclosure. The association of the computing device with the user may be performed to generate a device-to-user account association, similar to the device-to-user account association 110 of FIG. 1, which in turn is available during server-based setup of the connection of the computing device to the secure data network. Fig. 2 shows two examples for generating this association. In a first example, shown as beginning in the top portion of fig. 2, a user obtains (e.g., purchases) a computing device from a service provider, where the user has a user account with the service provider. In this first example, the service provider may generate the association. In a second example, shown starting in the bottom portion of fig. 2, a user obtains a computing device from a third party. In this example, the user (or a third party) may generate the association. Other examples for generating a device to user account are also possible, including, for example, conventional online registration of a computing device under a user account.

In a first example, a user subscribes to the computing device 210 from a service provider (e.g., purchases online from the service provider's website). Computing device 210 is an example of computing device 142 of fig. 1. In general, computing device 210 may be any suitable user device that includes one or more processors, one or more memories, and one or more interfaces for executing one or more applications, interacting with a user, interfacing with a remote computing device, and the like. For example, computing device 210 may be a VCMD, which represents a smart speaker, smart plug, multimedia streaming device, or any other device hosting a smart personal assistant service, power management service, streaming service, and/or other application that provides a smart personal assistant service in response to a wake word and is capable of different interactions including content playing, providing real-time information, and performing tasks and routines. In other illustrations, computing device 210 may be a mobile handset, a tablet computer, a desktop computer, a smart television, a digital video recorder, or any other user device having one or more processors, one or more memories, and one or more interfaces.

In the service provider's storage facility, computing device 210 may be added to container 220 for delivery to the user. The barcode 230 may be attached to the container 220 (e.g., to an outer surface of such container 220) and may encode data related to the computing device 210 (e.g., a product number, a public key, or a portion thereof, and/or a type of the computing device 210, where the type may be a product classification, such as VCMD, smart plug, etc.). Optionally, the barcode may also encode data about the user account of the user. A remote device 240, such as a scanner at a storage facility (e.g., a handheld scanner or a product scanner in a workstation of the storage facility), performs a barcode scan 232 to read barcode data 234 (e.g., data encoded in barcode 230). The remote device 240 is communicatively coupled with a server 250 (or more generally, a backend system) of the service provider and sends the barcode data 234 to this server 250. In the illustration, the remote device 240 is on the same network as a central computer that manages the user's purchase orders. Barcode data 234 is sent from remote device 240 to this central computer and the central computer sends it to server 250. Transmitted barcode data 234 includes, for example, a public key of computing device 210 (shown as device public key 236) or a portion of device public key 236 encoded in barcode 230. Other data may also be included, such as a product number (e.g., serial number) and/or a product classification of the computing device 210. The product classification may represent the type of computing device 210, such as whether computing device 210 is a VCMD, smart plug, multimedia streaming device, and so forth. For clarity in this disclosure, the product classification of a computing device may be referred to as the type of computing device. Additionally, if barcode 230 encodes data about a user account, barcode data 234 may include an identifier 238 of the user account. Otherwise, server 250 may receive identifier 238 separately from barcode data 234. For example, another barcode attached to the container 220 and/or printed in the purchase order encodes the identifier 238. Upon scanning of this barcode, the remote device 240 reads the identifier 238 from this barcode and sends to the server 250. Additionally or alternatively, the identifier 238 may be sent from the central computer based on a purchase by a user of the computing device and based on this central computer receiving the barcode data 234 from the remote device 240.

Server 250, in turn, receives barcode data 234 and identifier 238 of the user account and associates 212 computing device 210 with the user account. For example, the server 250 looks up a user account based on the identifier 238 of the user account and adds some or all of the barcode data 234 to this account, including the device public key 236 (or a portion thereof), the product number, and/or the device type. Additionally or alternatively, server 250 may update a list associating device public keys with user accounts. This list is referred to herein as a public key-user account list. For example, the device public key 236 (or portions thereof) may be added as a key, and the identifier 238 may be added as a value in a public key-user account list. In general, the server 250 may be implemented as dedicated server hardware, as server-based software running on general-purpose hardware, and/or as a cloud-based computing service. Server 250 may be a computing component of a back-end system of a service provider, where the back-end system may store user accounts for different users and provide computing services (e.g., multimedia streaming) to the user's computing device based on the user accounts. Although the embodiment shown in fig. 2 is provided with respect to bar codes and bar code scanners, other data entry methods and systems may be utilized, including Radio Frequency Identifiers (RFID) or the like.

In a first example, rather than using a product scanner, the remote device may be the user's mobile device 250, such as a smartphone. The mobile device 250 may execute a mobile application (e.g., an "app") to communicate with a backend system of a service provider based on a user login to a user account on the mobile application. In this example, the user may receive a container that includes the computing device 210 and a paper sheet 222 (e.g., paper, color sheet, user manual, etc.). This sheet 222 contains a bar code 224 similar to bar code 230 encoding the above data. In addition, the barcode 224 may encode a Personal Identification Number (PIN)238 that may be used to further authenticate the computing device 210, as shown in connection with the following figures. The sheet 222 may, but need not, be attached to the computing device 210. Upon opening the container (shown in fig. 2 as the open container 226), the user retrieves the computing device 210 and the paper sheet 222 and performs a barcode scan 252 of the barcode 224 using the mobile application (e.g., to capture an image of the barcode 224). The mobile application, in turn, reads the encoded data and sends barcode data 254 to server 250. The transmitted barcode data 254 includes, for example, the device public key 236 (or a portion thereof) and the PIN 238. Other data, such as the product number and/or type of computing device 210, may also be included. Additionally, if barcode 230 encodes data about a user account, barcode data 234 may include an identifier 238 of the user account. Otherwise, this identifier 238 is determined based on the user login to the user account.

Here again, server 250 receives barcode data 254 and identifier 238 of the user account and associates 212 computing device 210 with the user account. For example, the server 250 looks up a user account based on the identifier 238 and adds some or all of the barcode data 254 to this account, including the device public key 236 (or a portion thereof), the PIN 238, the product number, and/or the device type.

Fig. 3 illustrates an example of mutual device and server authentication according to an embodiment of the present disclosure. As illustrated, computing device 310 establishes a data connection with wireless router 320 to join hidden open network 330. Once on the hidden open network 330, the computing device 310 and the server 340 may exchange data via the wireless router 320 for authenticating 318 the server 340 to the computing device 310 and for authenticating 344 the computing device 310 to the server 340. Computing device 310, wireless router 320, hidden open network 330, and server 340 are examples of computing device 142, wireless router 146, hidden open network 144, and server 112, respectively, of fig. 1.

In an example, wireless router 320 manages access of computing devices to hidden open network 330 and to inbound and outbound traffic to and from such computing devices on hidden open network 330. In general, the hidden open network 330 has an SSID, but does not require a password for access (and thus, this data network is referred to as "open"). Wireless router 320 also does not advertise (e.g., broadcast) the SSID (and, thus, this data network is also referred to as "hidden"). Hidden open network 330 may support various data communication protocols including Wi-Fi protocol and transport control protocol and internet protocol (TCP/IP protocol).

The service provider of the server 340 may define the SSID (e.g., by referring the hidden open network 330 to "SSID _ example" or some other name) and restrictions on using the hidden open network 330. The SSID and restrictions may be pre-stored in a memory of the wireless router 320 if the wireless router 320 is designed, manufactured, and/or provided by a service provider. On the other hand, if the wireless router 320 is designed, manufactured, and/or provided by a third party, the service provider may store the SSID and restrictions in a Software Development Kit (SDK) or configuration file for download to the wireless router 320. In both cases, once installed at the user location, wireless router 320 may manage access to hidden open network 330 with an SSID based on the restrictions in addition to managing access to the home data network.

Similarly, and prior to providing the computing device 310 to the user, the SSID (and other application-level restrictions) may be pre-stored in local memory of the computing device 310. In particular, if the computing device 310 is designed, manufactured, and/or provided by a service provider, the SSID may be pre-stored in a local memory of the computing device 310 during the manufacturing process or after manufacture but before shipment. On the other hand, if the computing device 310 is designed, manufactured, and/or provided by a third party, the service provider may store the SSID in a Software Development Kit (SDK) or configuration file for download to the computing device 310.

Additionally, the service provider may define the number "N" (e.g., ten) of public keys of the servers 340 that should be stored on the computing device 310 ("N" server public keys), and may identify one of these public keys that should be used by the computing device 340 to authenticate the servers 340. Such a public key may be selected based on the type of computing device 310 (e.g., VCMD, smart plug, multimedia streaming device, etc.). Thus, the "N" server public keys, as well as an indication of the particular server public key to be used for server authentication, are loaded (directly or through an SDK or configuration file) onto and stored in the local memory of the computing device 310 prior to being provided to the user.

In instances where the device-to-user account association is generated by the user (or a third party) rather than the service provider, such association also includes the PIN. The PIN may be used in an additional layer of authentication. In this case, and prior to providing the computing device 310 to the user, the service provider may define a PIN (e.g., a randomly generated string of a particular length). This PIN is loaded (directly or through an SDK or configuration file) onto the local memory of the computing device 310 and stored therein prior to being provided to the user.

After being provided to the user and in the powered-on state, computing device 310 may determine that a data connection to the home data network has not been set up (e.g., after this device is first powered on). Based on this determination, computing device 310 determines the SSID from its local memory and establishes a data connection to wireless router 320 by, for example, using the SSID as a name that hides open network 330 and using a particular security protocol (e.g., WPA/WPA2 personal).

Now that computing device 310 has joined hidden open network 330, such computing device 310 can exchange data with server 340 via wireless router 320 for authentication. In particular, wireless router 320 sends outbound data from computing device 310 to server 340 and sends inbound data from server 340 to computing device 310. This and other data traffic is subject to limitations stored on the wireless router 320. In general, the restrictions represent firewalls that restrict data traffic to ensure that the hidden open network 330 is used correctly and securely and that any impact on the home data network (also managed by the wireless router 320) is minimized or prevented.

In an example, the restrictions limit hiding a total number of computing devices on the open network 330, a data throughput and a duration of a data connection between the computing device 310 and the wireless router 320, a destination address of outbound traffic from the computing device 310 (e.g., such destination address may be limited to a network address of the server 340), and/or a source address of inbound traffic (e.g., such source address may be limited to a network address of the server 340). Data traffic to and from computing device 310 is communicated that satisfies the restrictions; otherwise, the data traffic is filtered out.

In the illustration, the restriction allows the hidden open network 330 to access Dynamic Host Configuration Protocol (DHCP) on port 67 over User Datagram Protocol (UDP) on a router to access a particular whitelist IP address on port 443 over TCP. The restriction may also deny computing devices on the home data network from communicating with computing devices on the hidden open network 330, and vice versa. For computing devices on hidden open network 330, the restrictions may deny these computing devices from communicating with each other and with internal router endpoints, as well as access router setup interfaces. The restriction may also give lower priority to hiding packets on the open network 330 than packets on the home data network. The limitation may also limit the maximum number of computing devices that can be simultaneously connected to the hidden open network 330 to a particular number. When there are no customer endpoints, the limit may necessitate disconnecting at least a predetermined number of the oldest computing devices, provided that these devices have been connected for more than a certain amount of time. If they have been connected for less than the certain amount of time, the limit may specify that no action should be taken because the devices may be actively supplying. The limit may also specify that disconnected computing devices should not be brought back onto the hidden open network 330 for at least a certain amount of time. In addition, the limitation may limit the maximum download/upload rate for hiding open network 330 to a particular bit rate and limit the maximum data transfer to a particular amount of data for a day.

Based on the restrictions, data is exchanged between the computing device and the server 340 via the wireless router 320 for authentication. The exchanged data may be carried by HTTP requests and responses. In an example, computing device 310 sends its device digital certificate 312 to server 340 and receives server digital certificate 342 from server 340. The two certificates 312 and 342 may be used in mutual TLS authentication.

Upon completion of TLS authentication, HTTPS communication may be performed between computing device 310 and server 340. The server 340 may also retrieve the device public key 314 from the device digital certificate 312, look up the user account or public key-user account list, and determine a match (e.g., match the device public key 314 with the public key (or portion thereof) of the computing device 310 associated with the user account of the user, or determine that the device public key 314 is on the public key-user account list). If a match exists, the server 340 determines that the computing device 310 is authenticated. If multiple matches exist (e.g., device public key 314 matches two or more user accounts), server 340 may reject the match (e.g., computing device 310 is not authenticated) or may require additional authentication. In an example, the additional authentication involves server 340 determining the most recent association between public key 314 and the user account and authenticating computing device 310 if it corresponds to such user account. In another example, server 340 may send an authentication challenge and may authenticate computing device 310 based on a response to this challenge. For example, the authentication challenge may have to go through a user login to a user account via an application on the mobile device and a confirmation from the mobile device of the user's ownership of the computing device 310.

In response, the server 340 selects a private key from the "N" private keys defined for and available to the server 340 (e.g., the "N" server private keys), and generates a digital signature 346 with the server private key in an HTTPS response. A similar digital signature may be generated and used in conjunction with HTTPS requests and responses from the server 340 to the computing device 310. The "N" server private keys correspond to the "N" server public keys stored in the memory of computing device 310. The selected server private key corresponds to the server public key stored in the memory of the computing device 310 and is indicated as available in the authentication. In general, server 340 stores "N" server private keys and a mapping of the "N" server private keys to computing device types. In an example, the mapping is additionally or alternatively specific to a range of product numbers for the computing device, where such mapping indicates that a particular server private key applies to a particular range of product numbers. Given the type of computing device 310 (e.g., VCMD, smart plug, multimedia streaming device, etc.) and/or the product number of the computing device 310, the server 340 determines from the mapping the particular server private key that should be used for the digital signature 346.

The computing device 310 receives the digital signature 346, determines the particular server public key, and verifies the digital signature 346 with this key. If the digital signature 346 is verified, the computing device 310 determines that the server 340 is authenticated.

In instances where the device-to-user account association is generated by the user (or a third party) rather than the service provider, the PIN may also be used in an additional layer of authentication. In particular, once computing device 310 authenticates server 340 based on TLS and digital signature authentication, computing device 310 may request and receive a temporary token from server 340. Computing device 310 uses the temporary token to generate a hash of the PIN (shown as PIN hash 316) and sends PIN hash 316 to server 340. In response, server 340 verifies PIN hash 316 to further authenticate computing device 310.

As described above, multiple layers of authentication are possible (e.g., TLS, digital signatures, association of device public keys with user accounts, and PIN hashes). It is possible to use any of these authentication layers. It is also possible to use a combination or all of these authentication layers and provide increased security.

Although fig. 3 illustrates the use of wireless router 320 to provide and manage access to hidden open network 330, embodiments of the present disclosure are not so limited. Indeed, the other computing device 322 may do so. In particular, the computing device 322 may have been previously obtained by the user and provisioned to access the user's secure home network. This computing device 322 may be the same or different type as computing device 310 (e.g., VCMD, smart plug, multimedia streaming device, etc.). Upon a user obtaining computing device 310 (to be provisioned) and upon generating a device-to-user association for computing device 310, server 340 may send data indicative of such association and instructions to execute provisioning functionality to computing device 322. These instructions may trigger the computing device 322 to set up a hidden open network 322 and impose restrictions on inbound and outbound traffic to and from the computing device 310 for a predetermined period of time (e.g., within one week after the association is made).

Furthermore, fig. 3 shows the data exchange occurring partly over a hidden open network and by using HTTPS requests and responses. However, embodiments of the present disclosure are not so limited. Indeed, the computing device 310 may detect a nearby visible open network (e.g., a data network that broadcasts its SSID and does not require a password) and the SSID of such a network need not be pre-stored on the computing device 310. Fig. 3 shows this network as an open network 350 managed by a wireless router 360. Computing device 310 and server 340 may exchange the data described above for authentication via wireless router 360. In this case, wireless router 360 may not store and apply the restrictions.

FIG. 4 illustrates an example of provisioning credentials for a secure data network from a server to a computing device according to an embodiment of the present disclosure. In particular, computing devices and servers have exchanged data and authenticated each other using data, in part, over open data networks (hidden or visible). Next, the computing device and the server may continue to exchange data, in part, over the open data network, where the data from the computing device identifies one or more secure LANs and the data from the server may contain one or more credentials for some or all of these secure LANs. At this point, the computing device disconnects from the open data network and joins one of the secure LANs.

As illustrated, computing device 410 is in data communication with server 440 via wireless router 420, where computing device 410 has joined a hidden open network 430 managed by wireless router 420. Computing device 410, wireless router 420, hidden open network 430, and server 440 are examples of computing device 310, wireless router 320, hidden open network 330, and server 340, respectively, of fig. 3.

Once authentication is complete, the computing device 410 may detect a nearby secure network 450 (e.g., a nearby Wi-Fi LAN network, each secured by credentials such as a password). While still on the hidden open network 430, the computing device 410 requests 412 the server 440 to provide credentials for the secure network 450. For example, computing device 410 sends an HTTPS request to server 440 via wireless router 420, where wireless router 420 subjects such request to a restriction. The HTTPS request contains an identifier of secure network 450 (shown in figure 4 as secure network SSID 414). In response, server 440 may determine that secure network 450 has been associated with a user account of computing device 410 (e.g., the SSID of secure network 450 is stored under the user account), and may retrieve credentials for secure network 450 (e.g., a password for the SSID stored under the user account). The server 440 then provides 442 the credentials to the computing device via the wireless router 420, where the wireless router 420 also subjects this response to restrictions. For example, server 440 sends an HTTPS response that includes a credential (e.g., shown in fig. 4 as secure network credential 444).

Once computing device 410 receives secure network credentials 444, computing device 410 disconnects from wireless router 420, thereby leaving hidden open network 430. Computing device 410 then reconnects to wireless router 420 (or any other device managing access to secure network 450) by using secure network SSID 414 as the name of secure network 450, using secure network credentials 444 as the password for secure network 450, and using a particular security protocol (e.g., WPA/WPA2 personal) to establish a new data connection, thereby joining secure network 450. From this point on, the restrictions on inbound and outbound data traffic will no longer apply, and the computing device 410 may interact with the computing device and access computing services on other data networks 460 in addition to the server 112.

For clarity of illustration, fig. 4 shows the computing device 410 detecting a secure network 450. However, embodiments of the present disclosure are not so limited, and similarly apply when multiple secure networks are detected. In this case, different techniques of requesting credentials for such networks are possible.

In one example technique, the computing device 410 selects a particular secure network of the detected secure networks based on a set of factors. These factors include, for example, signal strength and data throughput of the secure network. Subsequently, computing device 410 may request credentials for this particular secure network from server 440. If this network is already associated with the user account, the server 440 returns credentials and the computing device 410 joins the secure network. Otherwise, server 440 may return a response indicating that the credential is not available (or may not return a response at all). In this case (negative response or lack of response), the computing device may select the next secure network and repeat the request. This selection, request, and response process may repeat until the computing device 410 successfully joins one of the secure networks or after attempting and failing to join all of these networks. In another example, the selection of the secure networks may be random or may follow an alphabetical order of the names of the detected secure networks. In yet another example, the computing device 410 may send an HTTPS request or HTTPS requests to identify the secure networks to the server 440, receive an HTTPS response or HTTPS responses from the server 440, and then select (based on factors, randomly, alphabetically, etc.) one of the secure networks to join.

Here again, and similar to fig. 3, the same wireless router 420 need not be used to hide the open network 430 and the secure network 450. Indeed, different wireless routers and/or computing devices that have been provisioned and added to secure network 450 may be used to provide and manage access to hidden open network 430, while wireless router 420 may be used to provide and manage access to secure network 450.

FIG. 5 illustrates another example of authenticating and providing credentials for a secure data network according to an embodiment of the present disclosure. In this example, rather than a wireless router connected to an open network (e.g., as seen or hidden in fig. 3 and 4), computing device 510 may be connected with a wireless router 520 on a public network 530 having an active portal. The active portal may have to be user-entered prior to establishing a connection (e.g., in an illustrative example, such provided network 530 may be provided by an entity such as a store or hotel, and may have to be user-entered for access, such as a customer membership card number or hotel room number and/or hotel guest name). In this case, the DNS request is used to pass relevant authentication data and network data between the computing device and the server 540 without requiring the computing device 510 to join the public network 530. Once authentication is complete and once the computing device 510 receives credentials for the secure network 560 from the server 540, the computing device 510 may connect to the wireless router 550 on the secure network 560 to subsequently gain access to other data networks 570 in addition to the server 540.

Here, computing device 510, wireless routers 520 and 550, and server 540 are examples of computing device 410, wireless router 420, and server 440, respectively, of fig. 4. One difference compared to fig. 4 is that each piece of authentication data and network data is pre-mapped to a domain (or sub-domain) having a particular domain name. The domain name may encode or represent the piece of data. Rather than exchanging the piece of data itself, computing device 510 and server 540 exchange DNS requests that are resolved to a domain name, and thereby indicate the piece of data.

For example, the authentication data may include a device digital certificate 512, a device public key 514, a PIN hash 516, a server digital certificate 542, and a digital signature 544, similar to the device digital certificate 312, the device public key 314, the PIN hash 316, the server digital certificate 342, and the digital signature 346 of fig. 3, respectively. The network data may include secure network SSID518 and secure network credential 546, which may be similar to secure network SSID 414 and secure network credential 444 of fig. 4, respectively. Each of the device public key 514, PIN hash 516, server digital certificate 542, digital signature 544, secure network SSID518, and secure network credentials 546 may be mapped to a domain (or sub-domain) and indicated via a DNS request.

Fig. 6 illustrates an example of a computing device configured to be configured by a provider device 600 to connect to a secure data network, in accordance with an embodiment of the present disclosure. The provisioned device 600 represents a computing device that is not yet configured but is connected to a secure network and is being provisioned via server-based settings to automatically connect to the secure network. Computing device 142 of fig. 1, computing device 210 of fig. 2, computing device 310 of fig. 3, computing device 410 of fig. 4, and computing device 510 of fig. 5 are examples of vendor-supplied devices 600.

As illustrated, vendor device 600 includes a processor 610 (or multiple processors), a network interface card 620 (or multiple network interface cards), and a memory 630 (or multiple memories). In an example, barcode 640 may also be attached to supplier device 600 (e.g., to a housing of supplier device 600).

The memory 630 stores a device digital certificate 632, an open network SSID 634, an "N" server public key 636, and code for setting up the application 638. The setup application 638, when executed by the processor 610, runs and provides functionality to join an open data network, perform authentication, receive credentials for a secure data network, and join a secure data network. The setup application 638 may also impose application-level restrictions on inbound and outbound data traffic of the provider device over the open data network (e.g., by restricting any outbound traffic to a predefined address of the server). Such restrictions and predefined addresses for the server may also be stored in memory 630.

Fig. 7 illustrates an example of a computing device configured as a provider device 700 to facilitate communication between a provider device and a cloud server, in accordance with an embodiment of the present disclosure. The provider device 700 represents a computing device that manages access to an open network and may connect with a provider device and a server to support provisioning of the provider device. Wireless router 146 of fig. 1, wireless routers 320 and 360 of fig. 3, wireless router 420 of fig. 4, and wireless router 520 of fig. 5 are examples of a provider device 700. Other types of devices may also be used as supplier devices. For example, a computing device that was previously a provider device and successfully provisioned to join the secure network may be configured as a provider device.

As illustrated, provider device 700 includes a processor 710 (or multiple processors), a network interface card 720 (or multiple network interface cards), and a memory 730 (or multiple memories). Memory 730 stores network restrictions 732 to manage inbound and outbound traffic to and from a provisioned device over an open data network. Memory 730 may also contain code for a network application to manage access to an open data network. Where the provider device 700 also manages access to the secure data network, the memory 730 may also include code for the same or another network application to manage such access.

Fig. 8 illustrates an example of a cloud server 800 configured to authenticate a vendor-supplied device and provide credentials for a secure data network, in accordance with an embodiment of the present disclosure. Server 800 dedicated server hardware, server-based software running on general purpose hardware, cloud-based computing services hosted on hardware in a data center. In general, server 800 represents a computing component of a service provider's backend system, where the backend system may store user accounts for different users and provide computing services (e.g., multimedia streaming) to the user's computing device based on the user accounts. Server 112 of fig. 1, server 250 of fig. 2, server 340 of fig. 3, server 440 of fig. 4, and server 540 of fig. 5 are examples of server 800.

As illustrated, server 800 includes a processor 810 (or multiple processors), a network interface card 820 (or multiple network interface cards), and a memory 830 (or multiple memories).

Memory 830 stores a server's digital certificate (shown as server certificate 831). In addition, the server stores "N" private keys (shown as server private key 832) and a mapping 833 of server private key 832 to device types. Mapping 833 associates each device type with a server private key. Additionally or alternatively, mapping 833 associates each arrival of a computing device product number with a server public key. In general, the digital server certificate 831 is used to authenticate the server 800 to the provider device. Depending on the type of the vendor device (e.g., its product classification) and/or the vendor device's product number (e.g., its serial number), server 800 also selects one of the "N" private keys based on mapping 833 and encrypts the data with the selected server private key to generate a digital signature. The digital signature is used to further authenticate the server 800 to the supplier apparatus.

Further, memory 830 stores a user account 834 (or multiple user accounts for different users). In general, user account 834 stores data relating to the user, computing services available to the user, and the user's computing devices, including any vendor devices. In an example of data related to a supplied device, user account 834 stores a device public key 835 (or portion thereof) of the supplied device and optionally other data such as a product number and/or type of the supplied device. This data represents an association between the supplier device and the user account. Additionally, user account 834 stores identifiers and credentials for secure networks that the user may access (shown as SSID and password 836) (or multiple identifiers and credentials if the user may access multiple secure networks). Once authentication is performed successfully, the server 800 may send the credentials to the vendor-supplied device. As explained above herein, in addition to or instead of storing device public keys 835 under user accounts, a public key-user account list may be used. In particular, such a list may be stored in memory 830 and public key 835 may be associated with user account 834 (and likewise, other public keys with the same user account 834 and/or other user accounts).

The memory 830 may also store code for a server-based setup service (shown as setup service 838). Upon execution of the code by the processor 810, the setup service 838 runs instantly and provides functionality to authenticate the server 800 to the provider device, authenticate the provider device, and send the relevant credentials to the provider device.

Fig. 9 shows an example of a sequence diagram 900 between a supplier device, and a server connecting the supplier device to a secure data network, according to an embodiment of the present disclosure. The supplier device, and server are the supplier device 600 of fig. 6, the supplier device 700 of fig. 7, and the server 800 of fig. 8, respectively. In general, providers provide and manage access to open data networks. The supplier device and the server exchange authentication data and network data, while the supplier device is on an open network. Upon receiving the network data, the provisioned device disconnects from the open data network and joins the secure data network based on credentials from the secure data network for the network data. The secure data network need not be provided and managed by the provider device.

Sequence diagram 900 begins with a detection of a connection setup trigger by a provider device (e.g., its setup application). This trigger causes the vendor device to automatically begin server-based provisioning to receive and connect with credentials for the secure network. In one example, the trigger may be a first power-up by the supplier device. Another trigger may be the detection that the home network is not set for the provider device or that the previously set home network is no longer accessible or available. Yet another example may be a user input that triggers a connection setting, such as a hard button on the supplier device or a soft button displayed on the screen of the supplier device.

Next, the provisioned device accesses the pre-stored identifier of the open data network (e.g., the SSID of this network) from its local memory. This may be the case when the open data network is hidden. However, if the open data network is visible, the device may receive its identifier via a broadcast from this network.

The device then establishes a data connection with the provider device to join the open data network. For example, the provisioned device uses the SSID as the name of an open data network and requests access to this network from the provisioning device using a particular security protocol (e.g., WPA/WPA2 personal).

Once on the open data network, the offered device may communicate with the server via the offering device. The communication may include HTTP requests and responses and may be subject to any restrictions stored by the provider device. The provider device and the server perform mutual TLS authentication. For example, the vendor device sends its device digital certificate to the server and the server sends its server digital certificate to the computing device for TLS authentication. Once TLS authentication is performed, a secure communication channel may be established and communications may include HTTPS requests and responses.

In addition to, independent of, or instead of TLS mutual authentication, the provider device and the server may also perform device-user account association based authentication and PIN hash based authentication by exchanging relevant data via the provider device. In the example of prior authentication, the server may retrieve the device public key from the device digital certificate of the supplicant device and may compare this key to a device public key (or portion thereof) stored under a user account associated with the supplicant device or may look up a public key-user account list to find a match. If the comparison indicates a match, the server determines that the provider device is authenticated. In response, HTTPS data from the server (e.g., data in each or some request and response) is signed with the server private key, thereby creating a digital signature. The digital signature is received by the supplicant device (e.g., in a corresponding HTTPS request or response) and verified based on the server public key stored in memory of the supplicant device. In the latter example of authentication, the supplicant device stores the PIN and requests and receives a temporary token from the server. The provisioned device then generates a PIN hash based on the hash of the PIN and the nonce, and sends the PIN hash to the server. The server verifies the PIN hash by hashing the PIN stored for the vendor device under the user account.

Next, the provisioned device requests credentials for the secure data network while still on the open data network. For example, the supplicant device detects an identifier of the secure data network (e.g., its SSID) and sends an HTTPS request to the server via the supplicant device. In response, the server looks up the user account, determining a match between the identifier and an identifier of the secure data network stored under the user account. Based on the match, the server retrieves from the user account the credential corresponding to the matching secure data network and sends this credential in an HTTPS response.

The credential is received by the provider device. For example, HTTPS responses are passed from the provider device to the provider device while the provider device is still on the open data network.

Upon receiving the credentials, the provisioned device establishes a new data connection with the provisioner device (or an associated device on the secure data network) to join the secure data network. For example, the provisioned device terminates the existing data connection, thereby leaving the open data network. The provisioned device also uses the SSID as the name of the secure data network, and the credential as a password, and requests access to this network from the provider device using a particular security protocol (e.g., WPA/WPA2 personal).

Fig. 10 to 11 show an example flow of server-based setup for a connection to a secure network. Similar to the provisioned device 600 of fig. 6, the provisioned device is described as performing operations of the example flow of fig. 10, and similar to the server 800 of fig. 8, the server is described as performing operations of the example flow of fig. 11. The instructions for performing the operations may be stored as computer-readable instructions on one or more non-transitory computer-readable media of an associated computing component (e.g., the provisioned device of fig. 10 and the server of fig. 11). When stored, the instructions represent programmable modules containing code or data that can be executed by one or more processors of an associated computing component. Execution of such instructions configures the relevant computing components to perform the specific operations shown in the corresponding figures and described herein. Each programmable module combined with a respective processor represents means for performing a respective operation. While the operations are shown in a particular order, it should be understood that the particular order is not necessary and that one or more operations may be omitted, skipped, and/or reordered.

Fig. 10 illustrates an example of a flow for connection of a provider device to a secure data network according to an embodiment of the present disclosure. As illustrated, the example flow begins at operation 1002, where a provider-subject device establishes a first data connection with a provider device on a first data network. In an example, the first data network is a nearby Wi-Fi open data network that may be hidden or visible. If hidden, the provider device determines the SSID of this network from its local memory and requests access thereto from the provider device.

At operation 1004, the provider device sends a device digital certificate of the provider device to the server. In an example, the device digital certificate is accessed by the provider device from its local memory. In addition, the provider-side device determines the network address of the server from its local storage. The vendor device generates an HTTP request destined for the network address and includes a device digital certificate. The HTTP request is sent from the supplier device over a data connection with the supplier device. The provider device routes the HTTP request to the server, depending on applicable constraints.

At operation 1006, the server digital certificate is received by the provider device. In one example, this certificate is sent from the server in an HTTP response destined for the provider device. The provider device routes the HTTP response to the provider device, depending on applicable constraints.

At operation 1008, the provider device authenticates the server based on the server digital certificate. In an example, this authentication involves performing TLS authentication by verifying the identity of the server and certificate authority from the server digital certificate. Once TLS authentication is performed, HTTPS communication may occur between the provisioned device and the server via the provider device and subject to limitations.

At operation 1010, the digital signature of the server is received by the provider device. In an example, HTTPS data (e.g., data in each HTTPS request, some of the HTTPS requests, each HTTPS response, or some of the HTTPS responses from the server) is signed with the server private key of the server. Signed HTTPS data is referred to herein as a digital signature. In general, the server generates a one-way hash of the HTTPS data to be signed and encrypts the hash with the server private key. This resulting digital signature may be included in a corresponding HTTPS request or HTTPS response. The digital signature is sent from the server to the supplier device (e.g., in a corresponding HTTPS request or response). The provider device routes the digital signature to the provider-subject device, depending on applicable constraints. To illustrate, upon completion of TLS authentication, the supplicant device sends an HTTPS request to the server (e.g., a request including a random or specific message) and the server sends back an HTTPS response to this request. The HTTPS response is signed with the server private key and routed to the supplicant device. In this case, the server may generate a hash from the message included in the HTTPS request and encrypt this hash with the server private key to generate the digital signature of the server. The digital signature is included in the HTTPS response. Further, and as described in connection with the next operations of the flow, the server's HTTPS responses are signed with the server private key, including those responses used to send the transient token and credential. Such signatures also represent digital signatures (e.g., digital signatures based on a hash of the nonce, digital signatures based on a credential) that may be verified by the vendor device as another layer of server authentication.

At operation 1012, the vendor device authenticates the server further based on the digital signature. In an example, the vendor device accesses the server's public key from its local memory and verifies the digital signature. In general, the supplicant device decrypts the hash from the digital signature with the server public key, generates a hash from the digital signature (or a hash of a message from the supplicant device if the corresponding HTTPS request includes such message), and compares the two hashes to determine a match. In the illustration, the local memory stores "N" server public keys. The local memory may also store an indication of one of the "N" server public keys that is to be used for digital signature verification. The vendor device selects this particular server public key based on the indication. In another example, this indication is not stored. In effect, the provider device selects the server public key and attempts to verify the digital signature with the selected public key. If successful, the digital signature is verified. If decryption fails, the provider device selects the next server public key and attempts verification, and so on, until the digital signature is successfully verified or until all "N" server public keys have been attempted. If the decryption failure persists, the provider device does not further authenticate the server.

At operation 1014, the provisioned device requests a temporary token from the server. In an example, the vendor device stores a PIN that can be used to further authenticate itself to the server. For this further authentication, the supplicant device sends an HTTPS request for the nonce, where this request is destined for the server. The provider device routes the HTTPS request to the server, depending on the applicable restrictions.

At operation 1016, the provisioned device receives a temporary token from the server. In one example, the nonce is sent from the server in an HTTPS response destined for the provider device. Depending on applicable constraints, the supplier device routes the HTTPS response to the supplier device. As explained above herein, the temporary token may also be signed with the server private key and the resulting digital signature may be included in the HTTPS response.

At operation 1018, the vendor device sends a hash of the PIN to the server based on the nonce. In an example, the supplicant device hashes the PIN and nonce and sends an HTTPS request that includes the hash. The HTTPS request is destined for the server and, depending on the applicable restrictions, the provider device routes the HTTPS request to the server. Operations 1014 and 1018 are shown in dashed lines to indicate that these operations apply when a PIN is available. As described above, the PIN may be generated during an initial state of associating the provider device with the user account. Further, the hash may be sent based on the server public key only after successful verification of the digital signature received under operation 1016.

At operation 1020, the provider device detects one or more data networks. In one example, a provider device detects a nearby Wi-Fi secure LAN by identifying the SSIDs of the nearby Wi-Fi secure LAN and determining that these data networks are secure.

At operation 1022, the supplicant apparatus sends one or more requests for one or more network credentials to the server. In one example, a single secure data network is detected. In this case, the supplicant device sends an HTTPS request including the SSID of this secure data network while still on the first data network. The HTTPS request is destined for the server and, depending on the applicable restrictions, the provider device routes the HTTPS request to the server. In another example, multiple secure data networks are detected. In this case, the provisioned device may select one of these data networks and send an HTTPS request to the server identifying the selected data network. Alternatively, the provider device may send a single HTTPS request that includes the SSID of the detected secure data network or a subset thereof. In yet another embodiment, the supplier device sends a plurality of HTTPS requests, each request identifying one or more of the detected secure data networks.

At operation 1024, the provisionee device receives one or more credentials from the server. As in the above example with respect to detecting a single secure data network, the server detects that such network should be accessible to the computing device based on an association between an identifier of such network and a user account. The server sends an HTTPS response containing the credential. The HTTPS response is destined for the supplicant device, and depending on applicable restrictions, the supplicant device routes the HTTPS response to the supplicant device. If multiple secure data networks are destined for a server, the server similarly determines that a subset of these networks should be accessible to the computing device and sends its credentials in one or more HTTPS responses. As explained above herein, the credentials included in the HTTPS response may also be signed by the server private key and the resulting digital signature may be included in the HTTPS response.

At operation 1026, the provider device establishes a second data connection with the wireless router on the second data network. In one example, the second data network is one of the detected secure networks for which credentials were received, and the provider device establishes a second data connection to join the secure data network. The provider device terminates the first data connection and leaves the first data network. The provisioned device also uses the SSID as the name of the secure data network, and the credential as a password, and requests access to this network from the wireless router using a particular security protocol (e.g., WPA/WPA2 personal). Further, the second data connection may be established based on the server public key only after successful verification of the digital signature received at operation 1024.

In the case when multiple secure data networks are detected, the provider device may request its credentials once (e.g., with one or more HTTPS requests) or may sequentially select a secure data network, request its credentials, and if no credentials are received, select the next secure data network until either the credentials are received or the list of detected secure data networks is exhausted.

Additionally, once the second data connection is established, the provider apparatus may perform additional operations to determine whether the second data connection is set based on communication with a trusted server and/or based on a server private key that has not been compromised. In an example, the vendor device sends an indication to the second server that it uses to set the server public key for the second data connection. This indication may be sent over the second data network in an HTTPS request, where the HTTPS request includes the server public key or at least a portion thereof. The second server may maintain a revocation list of public keys corresponding to private keys that have been compromised or correspond to untrusted servers. Upon receiving the HTTPS request, the second server determines whether there is a match with one of the keys from the revocation list. A match indicates that the server public key used by the provider device is untrusted and should be revoked. If no match is found, this server public key may be trusted and usable. The second server sends an indication to the provider device as to whether the server public key is not trusted depending on the match. The indication may be sent in an HTTPS response received by the provider device over the secure LAN. From the HTTPS response, the vendor device determines whether the server public key is not trusted and should be revoked, or is trusted and available for use. In the former case, the provider device terminates the second data connection and thus leaves the second data network. In the latter case, the supplied device does not terminate the second data connection and therefore remains on the second data network. Additionally, upon determining that the server public key is not trusted and should be revoked, the second server may identify a second server public key that is trusted and that has been stored in memory of the vendor device. An identifier of this second server public key may be sent in the HTTPS response. Thus, upon leaving the second data network, the provider device may resume the process of connecting to the secure data network by instead relying on the second public key.

Fig. 11 illustrates an example of a flow for a server to provide credentials of a secure data network to a provisioned device, according to an embodiment of the present disclosure. In an example, flow begins at operation 1102, where the server stores "N" server private keys and a mapping between private keys and device types. For each type of vendor device (e.g., product classification), the mapping indicates a particular server private key from among the "N" server private keys used to generate the digital signature.

At operation 1104, the server stores the network identifier and credentials under the user account. In an example, a user's computing device has been provisioned and connected to a secure data network. As part of this provisioning, the identifier and credentials (e.g., SSID and password) for the secure network are stored under the user account of the user. If multiple secure data networks are accessible to this or other computing devices of the user, the corresponding identifiers and credentials are similarly stored under the user account.

At operation 1106, the server receives data identifying the provider device and the user account from the remote device. In an example, the remote device is a scanner of a service provider or a mobile device of a user. Data is sent from the remote device based on a scan of a barcode associated with the supplied device (e.g., attached to a container of the supplied device, printed on paper attached to the container, inserted in the container, or attached to the supplied device). The data includes any one or combination of a device public key (or portion thereof) of the supplier device, an identifier of the user account or user, a product number of the supplier device, a product classification and a PIN of the supplier device.

At operation 1108, the server associates the provider device with the user account based on the received data. In an example, the server determines a user account based on the user account or an identifier of the user, and updates the user account to store the device public key (or portion thereof), the product number, the product classification, and/or the PIN.

At operation 1110, the server receives a device digital certificate of the supplier device. In an example, the provider device is on a first data network managed by the provider device. The supplicant device sends an HTTP request that includes a device digital certificate. This HTTP request is destined for the server, and depending on applicable restrictions, the provider device routes the HTTP request to the server.

At operation 1112, the server authenticates the provisioned device based on the device digital certificate and sends a server digital certificate of the server to the provisioned device. In one example, authentication involves performing TLS authentication by verifying the identity of the supplier device and the certificate authority from the device digital certificate. For mutual TLS authentication, the server also generates an HTTP response destined for the vendor device and containing the server digital certificate. The HTTP response is sent to the supplicant device, and depending on applicable restrictions, the supplicant device routes the HTTPs response to the supplicant device. The server digital certificate is used by the provider device to authenticate the server. Upon mutual TLS authentication, HTTPS communication may be performed between the server and the vendor device.

At operation 1114, the server determines a device public key of the vendor device. In an example, the server retrieves the device public key from the received device digital certificate.

At operation 1116, the server determines an association between the provider device and the user account based on the device digital certificate. In an example, the server uses the device public key from the device digital certificate to search for and find a user account (e.g., by searching the user account or searching a public key-user account list), thereby determining that the vendor device has been associated with the user account.

At operation 1118, the server further authenticates the vendor device. In one example, the server uses the determination that the association between the supplier device and the user account already exists as another layer of authenticating the supplier device. In another example, the server claims that the provider device is further authenticated based on a match of the device public key from the device digital certificate and the device public key stored in the user account.

At operation 1120, the server accesses a server private key of the server based on the type of the vendor device. In an example, the server determines the type of the supplicant device from data stored in the user account or HTTPS data received from the supplicant device (whereby the supplicant device identifies its type to the server). The server uses the device type lookup mapping and determines the server private key. In another example, the product number of the supplier device is additionally or alternatively used to select the server private key. In particular, the mapping may further map the vendor device product number range with the server private key.

At operation 1122, the server generates a digital signature based on the server private key from the "N" private keys. In an example, a server receives an HTTPS request including a message from a provisioned device. The server prepares and sends an HTTPS response signed with the server private key. In the illustration, the server generates a hash of the message and encrypts the hash with the server private key, thereby generating a digital signature that may be included in the HTTPS response. Further, and as described in connection with the next operations of the flow, the HTTPS request and the response of the server are signed with the server private key, including the request and the response to send the transient token and the credential. Such signatures also represent digital signatures (e.g., digital signatures based on a hash of the nonce, digital signatures based on a credential) that may be verified by the vendor device as another layer of server authentication.

At operation 1124, the server sends the digital signature to the supplier device. In an example, the server sends an HTTPS response to the HTTPS request (as in the illustrative example under operation 1122), where this response is destined for the vendor device and includes a digital signature. The HTTPS response is sent to the supplicant device, and depending on the applicable restrictions, the supplicant device routes the HTTPS response to the supplicant device.

At operation 1126, the server receives a request for a nonce from a provisioned device. In an example, this request is sent from the supplicant device as an HTTPS request in response to authentication of the server by the supplicant device. In the illustration, this authentication may include verification by the vendor device of the digital signature sent under operation 1124, where the verification relies on the server public key. The HTTPS request is destined for the server and, depending on the applicable restrictions, the provider device routes the HTTPS request to the server.

At operation 1128, the server sends the temporary token to the provisioned device. In one example, the server generates an HTTPS response that includes the nonce and is destined for the vendor device. Additionally, a digital signature may be generated based on a hash of the nonce and the server private key and may be included in the HTTPS response. The HTTPS response is sent to the supplicant device, and depending on the applicable restrictions, the supplicant device routes the HTTPS response to the server.

At operation 1130, the server receives a hash of the PIN from the vendor device. In an example, this PIN hash is generated by the supplicant device based on the PIN and the nonce, and is sent from the supplicant device to the server in an HTTPS request. This PIN hash may be received only after the digital signature is verified by the provider device from operation 1128 based on the server public key, as appropriate. The HTTPS request is destined for the server and, depending on the applicable restrictions, the provider device routes the HTTPS request to the server.

At operation 1132, the server further authenticates the vendor device based on the hash of the PIN. In an example, the server verifies the PIN hash by hashing the PIN stored for the vendor device (e.g., under the user account) and comparing whether the hashes match.

At operation 1134, the server receives one or more requests for network credentials from the provisioned device. In an example, a server receives an HTTPS request originating from and routed by a provider device. The HTTPS request contains an identifier of the secure data network (e.g., the SSID of the secure Wi-Fi LAN). In another example, the HTTPS request contains multiple identifiers, each identifier for a different secure data network. In yet another example, a server receives a plurality of HTTPS requests, each HTTPS request identifying one or more secure data networks.

At operation 1136, the server determines a match to the network identifier under the user account. In an example, the server retrieves an identifier of the secure data network from the received HTTPS request and uses this identifier to look up the user account and find a match. The server determines credentials from a user account of the matching secure data network. If multiple secure network identifiers are identified in one or more HTTPS requests, the server performs a similarity matching process to determine any additional matches and corresponding credentials.

At operation 1138, the server sends the one or more network credentials to the provisioned device. In an example, the server generates and sends an HTTPS response that includes a credential matching the secure data network. The HTTPS response is destined for the supplicant device, and depending on applicable restrictions, the supplicant device routes the HTTPS response to the supplicant device. In the case of matching multiple secure data networks, the same HTTPS response or multiple HTTPS responses may be sent to the supplicant device, each of which may contain one or more of the corresponding credentials. Further, the credentials included in the HTTPS response may be signed with the server private key, and the resulting digital signature may be included in the HTTPS response for further authentication by the vendor device.

Fig. 12 shows a computer architecture diagram illustrating an example computer architecture, according to an embodiment of the present disclosure. This architecture may be used to implement some or all of the systems described herein. The computer architecture shown in fig. 12 illustrates a conventional server computer, workstation, desktop computer, laptop computer, tablet computer, network appliance, personal digital assistant ("PDA"), electronic reader, digital cellular telephone, or other computing device, and may be used to execute any aspect of the software components presented herein.

The computer 1200 includes a backplane 1202 or "motherboard" which is a printed circuit board to which numerous components or devices may be connected by way of a system bus or other electrical communication path. In an illustrative embodiment, one or more central processing units ("CPUs") 1204 operate in conjunction with a chipset 1206. CPU 1204 may be a standard programmable processor that performs the arithmetic and logical operations necessary for the operation of computer 1200.

The CPU 1204 performs operations by switching from one discrete physical state to the next discrete physical state by manipulating switching elements that distinguish and change these states. A switching element may generally include electronic circuitry that maintains one of two binary states, such as a flip-flop, and electronic circuitry that provides an output state based on a logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractors, arithmetic logic units, floating point units, and the like.

A chipset 1206 provides an interface between the CPU 1204 and the rest of the components and devices on the backplane 1202. The chipset 1206 may provide an interface to a random access memory ("RAM") 1208, which serves as the main memory in the computer 1200. The chipset 1206 may further provide an interface to a computer-readable storage medium, such as read only memory ("ROM") 1210 or non-volatile RAM ("NVRAM"), for storing basic routines that help to start the computer 1200 and transfer information between various components and devices. The ROM 1210 or NVRAM may also store other software components necessary for the operation of the computer 1200 according to embodiments described herein.

The computer 1200 may operate in a networked environment using logical connections to remote computing devices and computer systems via a network, such as a local network 1220. The chipset 1206 may include functionality to provide network connectivity via a NIC 1212, such as a gigabit ethernet adapter. The NIC 1212 is capable of connecting the computer 1200 to other computing devices over the network 1220. It should be appreciated that there may be multiple NICs 1212 in the computer 1200 connecting the computer to other types of networks and remote computer systems.

The computer 1200 may be connected to a mass storage device 1218 that provides non-volatile storage for the computer. The mass storage device 1218 may store system programs, application programs, other program modules, and data that have been described in greater detail herein. The mass storage device 1218 may be connected to the computer 1200 through a storage controller 1214 connected to a chipset 1206. The mass storage device 1218 may be comprised of one or more physical memory units. Storage controller 1214 may be connected through a serial attached SCSI ("SAS") interface, a serial advanced technology attachment ("SATA") interface, a fibre channel ("FC") interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The computer 1200 may store data on the mass storage device 1218 by transforming the physical state of physical memory units to reflect the information being stored. The particular transformation of physical state may depend on various factors in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage unit, whether the mass storage device 1218 is characterized as a primary or secondary storage device, and so forth.

For example, the computer 1200 may store information to the mass storage device 1218 by issuing instructions through the storage controller 1214 to alter the magnetic characteristics of a particular location within the disk drive unit, the reflective or refractive characteristics of a particular location in the optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in the solid state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this description. Computer 1200 may further read information from mass storage device 1218 by detecting physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the mass storage device 1218 described above, the computer 1200 may also access other computer readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will appreciate that a computer-readable storage medium can be any available medium that provides non-transitory storage of data and that can be accessed by the computer 1200.

By way of example, and not limitation, computer-readable storage media may comprise volatile and nonvolatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically erasable programmable ROM ("EEPROM"), flash memory or other solid state memory technology, compact disc ROM ("CD-ROM"), digital versatile disc ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information in a non-transitory manner.

The mass storage device 1218 may store an operating system 1230 to control the operation of the computer 1200. According to one embodiment, the operating system includes a LINUX operating system. According to another embodiment, the operating system comprises from Microsoft (MICROSOFT) corporationThe SERVER operating system. According to other embodiments, the operating system may comprise a UNIX or SOLARIS operating system. It should be appreciated that other operating systems may also be utilized. The mass storage device 1218 may store other systems or applications and data utilized by the computer 1200. The mass storage device 1218 may also store other programs and data not specifically identified herein.

In one embodiment, the mass storage device 1218 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into the computer 1200, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer 1200 by specifying how the CPU 1204 transitions between states as described above. According to one embodiment, the computer 1200 may access a computer-readable storage medium storing computer-executable instructions that, when executed by the computer 1200, perform the various routines described above. The computer 1200 may also include a computer-readable storage medium for performing any of the other computer-implemented operations described herein.

The computer 1200 may also include one or more input/output controllers 1216 for receiving and processing input from a number of input devices, such as a keyboard, mouse, touchpad, touch screen, electronic stylus, or other type of input device. Similarly, the input/output controller 1216 may provide output to a display, such as a computer monitor, flat panel display, digital projector, printer, plotter, or other type of output device. It should be appreciated that the computer 1200 may not include all of the components shown in fig. 12, may include other components not explicitly shown in fig. 12, or may utilize an architecture completely different than that shown in fig. 12. It should also be appreciated that many computers, such as computer 1200, may be combined to embody aspects of the various techniques disclosed herein.

Examples of embodiments of the present disclosure may be described in view of the following clauses:

clause 1. a method implemented by one or more servers to provide a password for a secure Local Area Network (LAN) to a computing device, access to the secure LAN being provided by a wireless router. The method includes storing a list associating one or more public keys with one or more user accounts. The method also includes storing a user account including a user identifier, a Service Set Identifier (SSID) of the secure LAN, and a password of the secure LAN. The method also includes storing a private key of the one or more servers and a mapping between the private key and a product classification of a computing device.

The method also includes receiving, in response to a scanner scanning a barcode associated with the computing device, a public key of the computing device, a product classification of the computing device, and a user identifier. The method also includes updating the list to include the public key and the user account. The method also includes receiving, via the wireless router, a certificate of the computing device, the certificate including a public key of the computing device, wherein the wireless router and the computing device are connected over an open LAN, and wherein the certificate is sent from the computing device over the open LAN. The method also includes authenticating the computing device by performing Transport Layer Security (TLS) authentication using the certificate. The method also includes determining from the list that the public key included in the certificate is associated with the user account. The method also includes accessing the private key of the one or more servers by determining from the mapping that the private key is associated with a product classification of the computing device. The method also includes sending a first encrypted hypertext transfer protocol (HTTPS) response to a first HTTPS request of the computing device, the first HTTPS request sent from the computing device over the open LAN, the first HTTPS response signed with a private key of the one or more servers and sent from the one or more servers to the computing device over the open LAN via the wireless router. The method also includes receiving, from the wireless router, a second HTTPS request from the computing device, the second HTTPS request including an SSID of the secure LAN. The method also includes sending, via the wireless router, a password from the secure LAN of the user account in a second HTTPS response to the computing device over the open LAN.

The method of clause 1, wherein the SSID and password are stored in a user account based on a data connection between a second computing device to a secure LAN via a wireless router, and wherein the second computing device is associated with a user account.

Clause 3. the method of any of clauses 1-2, wherein the wireless router and the computing device are connected over the open LAN based on a predefined SSID of the open LAN stored on the computing device, wherein the first HTTPS request is received based on a first restriction that limits outbound traffic from the computing device over the open LAN to first traffic destined for the one or more servers, and wherein the first HTTPS response is sent based on a second restriction that limits inbound traffic to the computing device over the open LAN to second traffic originating from the one or more servers.

Clause 4. one or more computer-readable storage media storing instructions that, when executed by one or more processors of a system, cause the system to perform operations. The operations include storing an association between a computing device and a user account, the user account associated with a local area network. The operations also include receiving a certificate of the computing device. The operations also include determining an association between the computing device and a user account based at least in part on the credentials. The operations also include authenticating the computing device based at least in part on the association being determined. The operations also include sending, to the computing device, data signed with a private key of the system based at least in part on the computing device being authenticated. The operations further include receiving, based at least in part on the data, a request for credentials of a local area network by a computing device. The operations also include sending credentials to the computing device based at least in part on the request.

Clause 5 the one or more computer-readable storage media of clause 4, wherein each of the certificate and the request is received via a data connection between the computing device and the wireless router of the second local area network, wherein each of the data and the credentials are sent to the computing device via the data connection.

Clause 6. the one or more computer-readable storage media of any of clauses 4-5, wherein each of the certificate and the request is received via a data connection between the computing device and a second computing device over a second local area network, and wherein the operations further comprise: receiving barcode data associated with a computing device; and requesting the second computing device to set up a second local area network for a period of time based at least in part on the barcode data being received.

Clause 7. the one or more computer-readable storage media of any of clauses 4-6, wherein the operations further comprise: first data regarding a public key of the computing device and second data regarding a user account are received from the barcode in response to scanning of the barcode associated with the computing device by the remote device, wherein an association between the computing device and the user account is generated based at least in part on the first data and the second data.

Clause 8. the one or more computer-readable storage media of any of clauses 4-7, wherein the operations further comprise: receiving, from a mobile device, barcode data from a barcode associated with a computing device, the barcode data including a Personal Identification Number (PIN), wherein an association between the computing device and a user account includes the PIN based at least in part on the barcode data.

Clause 9. the one or more computer-readable storage media of clause 8, wherein the operations further comprise: receiving a hash of the PIN from the computing device, wherein authenticating the computing device is based at least in part on the certificate, the PIN associated with the computing device, and the hash of the PIN.

Clause 10. the one or more computer-readable storage media of any of clauses 4-9, wherein the operations further comprise: storing a plurality of private keys including a private key; storing a mapping between the plurality of private keys and a type of computing device and a range of product numbers for the type of computing device; and signing the data with a private key based at least in part on the type of computing device, the product number of the computing device, and the mapping.

Clause 11. the one or more computer-readable storage media of any of clauses 4-10, wherein the system is a backend server storing credentials for a local area network, wherein the data comprises a message received in an HTTPS request from a computing device, and wherein the data is signed by generating a hash from the message and encrypting the hash with a private key of the system.

Clause 12. a computing device, comprising: one or more processors; and one or more memories storing the certificate of the computing device and the public key of the server, the one or more memories further storing instructions that, when executed by the one or more processors, cause the computing device to perform operations. The operations include establishing a first data connection to a first Local Area Network (LAN). The operations also include sending the certificate to a server via a first data connection. The operations also include receiving data from the server via the first data connection, the data signed with a private key of the server based at least in part on the certificate. The operations also include authenticating the server by verifying the data based at least in part on a public key of the server. The operations also include requesting credentials of the second LAN from the server via the first data connection. The operations also include receiving credentials from the server via the first data connection. The operations further include establishing a second data connection to a second LAN based at least in part on the credentials.

Clause 13 the computing device of clause 12, wherein execution of the instructions further causes the computing device to store a Service Set Identifier (SSID) of the first LAN, wherein the first LAN is a hidden network, and wherein the first data connection is established based at least in part on the SSID from the one or more memories.

Clause 14. the computing device of any of clauses 12-13, wherein data traffic to and from the computing device over the first LAN is restricted based at least in part on one or more of: a throughput of the data traffic, a destination of the data traffic, an origin of the data traffic, or a number of computing devices connected to the first LAN.

Clause 15. the computing device of any of clauses 12-14, wherein execution of the instructions further causes the computing device to: detecting an identifier of a secure LAN including the second LAN; sending a request to a server for credentials for a secure LAN; and receiving one or more of the credentials from the server based at least in part on the association between the one or more of the secure LANs and the user account, wherein the one or more of the credentials comprise credentials of the second LAN.

Clause 16. the computing device of any of clauses 12-15, wherein execution of the instructions further causes the computing device to: detecting an identifier of a secure LAN including the second LAN and the third LAN; sending a request to the server for credentials for the third LAN; receiving a response from the server that credentials of the third LAN are unavailable; and sending a request to a server for credentials for the second LAN based at least in part on the response.

Clause 17 the computing device of any of clauses 12-16, wherein execution of the instructions further causes the computing device to store a plurality of public keys of the server and an indication to authenticate the server using a public key of the plurality of public keys, wherein verifying the data is based at least in part on the indication.

Clause 18. the computing device of any of clauses 12-17, wherein execution of the instructions further causes the computing device to: sending, to the second server over the second LAN, a first indication that the public key is used in association with establishing the second data connection; receiving a second indication from the second server that the public key is not trusted; and terminate the second data connection to the second LAN based at least in part on the second indication.

Clause 19. the computing device of any of clauses 12-18, wherein the first data connection is established with the wireless router of the first LAN based, at least in part, on a first Service Set Identifier (SSID) of the first LAN stored on the computing device, and wherein the second data connection is established with the wireless router based on a second SSID of the second LAN and detection of the credentials.

Clause 20. the computing device of any of clauses 12-19, wherein the first data connection is established with a second computing device of the first LAN based, at least in part, on a first Service Set Identifier (SSID) of the first LAN stored on the computing device, and wherein the second data connection is established with a wireless router of the second LAN based, at least in part, on a second SSID of the second LAN and detection of credentials.

The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the disclosure as set forth in the claims.

Other variations are within the spirit of the present disclosure. Accordingly, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof have been shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention as defined in the appended claims.

The use of the terms "a" and "an" and "the" and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" are to be construed as open-ended terms (i.e., meaning "including, but not limited to,") unless otherwise noted. The term "connected" is to be understood as being partially or fully contained, attached, or joined together, even in the presence of an intermediate. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., "such as") provided herein, is intended merely to better illuminate embodiments of the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

Preferred embodiments of this disclosure are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, this invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.