Server-based setup for connecting the device to a local area network

Abstract

Techniques for providing credentials for a secure data network to a computing device are described. In one example, a system stores an association between the computing device and a user account. The user account is also associated with the credentials for the secure data network. The system receives a certificate from the computing device and, based on the certificate, determines the association between the computing device and the user account. Furthermore, based on the determined association, the system authenticates the computing device to send data to the computing device, wherein the data is verified based on a private key of the system. Based on the data, the system receives a request from the computing device for the credentials and sends the credentials to the computing device.

Description

Background Art

[0001] Most computing devices, such as consumer electronics, support wireless connectivity. Typically, a computing device connects to a wireless access point that provides 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, various technologies can 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 a computing device to a secure wireless home network via a wireless access point. WPS technology and other connection technologies generally rely on user input at the computing device and / or the wireless access point to establish a connection. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various embodiments according to the present disclosure will be described with reference to the drawings, in which:

[0003] Figure 1 An example of connecting a computing device to a secure data network according to an embodiment of the present disclosure is shown;

[0004] Figure 2 An example of associating a computing device with a user according to an embodiment of the present disclosure is shown;

[0005] Figure 3 illustrates an example of mutual device and server authentication according to an embodiment of the present disclosure;

[0006] Figure 4 An example of providing credentials for a secure data network from a server to a computing device according to an embodiment of the present disclosure is shown;

[0007] Figure 5 Another example of authenticating and providing credentials for a secure data network according to an embodiment of the present disclosure is shown;

[0008] Figure 6 illustrates an example of a computing device configured as a provisioned device to connect to a secure data network in accordance with an embodiment of the present disclosure;

[0009] Figure 7 An example of a computing device configured as a provider device to facilitate communication between a provisioned device and a cloud server according to an embodiment of the present disclosure is shown;

[0010] Figure 8 shows an example of a cloud server configured to authenticate a provisioned device and provide credentials for a secure data network according to an embodiment of the present disclosure;

[0011] Figure 9An example of a sequence diagram illustrating a provisioned device, a provider device, and a server connecting the provisioned device to a secure data network according to an embodiment of the present disclosure;

[0012] Figure 10 An example of a process for connection of a provisioned device to a secure data network according to an embodiment of the present disclosure is shown;

[0013] Figure 11 An example of a process illustrating a server providing credentials for a secure data network to a provisionee device according to an embodiment of the present disclosure; and

[0014] Figure 12 A computer architecture diagram illustrating an example computer architecture is shown according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0015] In the following description, various embodiments are described. For purposes of explanation, specific configurations and details are set forth to provide a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that the embodiments can be practiced without these specific details. Furthermore, well-known features may be omitted or simplified to avoid obscuring the described embodiments.

[0016] 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 setup allows for secure wireless connection establishment without requiring user input at the computing device and / or another device on the secure data network during the setup process. In one example, a computing device establishes a data connection with a provider computing device, such as a wireless access point, over a different data network. This provider computing device manages data communications between the computing device and a backend system, such as a cloud server. Specifically, 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 communications involve the exchange of credentials between the computing device and the backend server for mutual authentication. Additionally, the backend system further authenticates the computing device based on an existing association between the computing device and a user account. Similarly, the computing device further authenticates the backend system based on a digital signature received as part of the data communication. This additional layer of authentication adds security to the setup process by helping to prevent man-in-the-middle network attacks. Once authentication is complete, the computing device can request credentials for the secure data network from the backend system via the provider computing device. After determining that the secure data network's identifier and its credentials are associated with the user account, the backend 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 the secure data network's access point using the credentials.

[0017] To illustrate, consider the example of a secure home network that includes a router and a user's first voice-controlled multimedia device (VCMD). A second VCMD is about to connect to this network. In this example, both VCMDs are registered with a service provider under a user account, where this user account is maintained on a cloud server. When the first VCMD first connects to the secure home network, the service set identifier (SSID) and password used for the connection are stored under the user account. When the second VCMD is registered under the user account, the registration includes storing at least a portion of the second VCMD's public key under the user account. Additionally, 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.

[0018] Upon initial power-up, or optionally upon detecting that a data connection to the home network has not yet been established, the second VCMD immediately 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 via the hidden open network. The second VCMD also sends its digital certificate in an encrypted Hypertext Transfer Protocol (HTTPS) message addressed to the cloud server. The router receives this request and, based on the restrictions on outbound traffic allowed to the cloud server, forwards it to the cloud server. The router receives the cloud server's digital certificate in an HTTPS response addressed to the second VCMD and, based on the restrictions on inbound traffic allowed from the cloud server to the second VCMD, forwards the HTTPS response to the second VCMD. Given the two digital certificates, the second VCMD and the cloud server perform mutual Transport Layer Security (TLS) authentication.

[0019] Next, the cloud server determines that the second VCMD's public key from the received digital signature matches at least a portion of the public key stored under the user account. Based on this match, the cloud server further authenticates the second VCMD and generates a digital signature by encrypting data with the cloud server's private key. This private key can be one of multiple private keys of the cloud server and specifically specific to the type of the second VCMD. This digital signature is sent to the second VCMD via the router. In response, the second VCMD accesses the public key corresponding to the private key, which is stored in the second VCMD's local memory along with the cloud server's other public keys. The second VCMD verifies the digital signature using the cloud server's public key. Upon successful verification, the second VCMD immediately authenticates the cloud server.

[0020] Once authentication is complete, the second VCMD sends another HTTPS request, via the router, addressed to the cloud server. This request contains the SSID of the secure home network. The router receives it via the hidden open network and, based on restrictions allowing this, forwards it to the cloud server. In response, the cloud server determines the password for the secure home network from the user account and sends this credentials in an HTTPS response addressed to the second VCMD. The second VCMD receives this HTTPS request under the restrictions allowing this inbound traffic. Consequently, the second VCMD disconnects from the router via the hidden open network and establishes a new data connection with the router on the secure home network using the password.

[0021] A server-based setup process for automatically connecting a computing device to a secure data network offers numerous technical improvements over conventional techniques for setting up data connections. For example, this setup process can be automated without requiring user input. Specifically, once a computing device is registered under a user account associated with credentials for a secure data network, the user need only power on the computing device used for that device to communicate with the backend system and connect to the secure data network. Furthermore, 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. Furthermore, by restricting inbound and outbound traffic to and from the computing device when different data networks are used for authentication and credential reception, other devices on the secure data network can be protected. The use of multiple private keys and corresponding public keys of the backend system also limits the impact of private key compromise and supports key rotation. These and other technical improvements will be further described and will become apparent from the accompanying drawings.

[0022] Using a server-based setup process, a user obtains a computing device registered with a backend system under their user account. Upon powering on and lacking credentials for the user's secure home Wi-Fi network, the computing device instantly connects to a nearby open Wi-Fi network and uses this network to communicate with the backend system, which stores the credentials. The backend system identifies the computing device and the user account. After mutual authentication, the backend system sends the credentials to the computing device. The computing device then disconnects from the open Wi-Fi network and connects to the secure home Wi-Fi network.

[0023] Figure 1 An example of connecting a computing device to a secure data network according to an embodiment of the present disclosure is shown. Generally, the 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 the secure data network. Figure 1 This method is shown in several stages.

[0024] As illustrated, in the initial phase, a device-to-user account association 110 is generated. The device-to-user account association 110 supports the subsequent cloud-based setup of the connection in a secure manner. The cloud-based setup may, in turn, involve multiple phases, including one for device and server authentication 140 and one 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 with the server and completes server-to-device authentication. The device-to-LAN connection 170 occurs once authentication is complete and involves exchanging data about the secure LAN so that the device can connect to the secure LAN. Each of these phases involves different computing components, as further described herein below.

[0025] During the initial phase, server 112 receives data about computing device 142 from remote device 114. This data generally identifies computing device 142 and includes information unique to computing device 142 and usable 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 who obtained (e.g., purchased) computing device 142. The user account may store credentials for secure network 172. Generally, secure network 172 credentials, such as a password, are required from the computing device before it can join secure network 172, where such credentials are part of protected access to secure network 172 over a communication link. In one example, secure network 172 represents a secure home network for a user's various computing devices. In an illustrative example, upon purchasing 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) housing computing device 142 (or directly to 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 providing computing device 142). Figure 2 Additional details regarding the computing components and the interactions between them in this initial phase are further described.

[0026] In the next phase, the user receives computing device 142 (e.g., receives container 118 and unpacks computing device 142 therefrom). The user then powers on computing device 142. If computing device 142 determines that it is not already connected to a home network (e.g., the device is being powered on for the first time), computing device 142 determines the SSID of hidden open network 144 from its local memory. Computing device 142 then establishes a data connection with wireless router 146 of hidden network 144, thereby joining hidden open network 144. Wireless router 146 is already communicatively coupled to server 112 and can send data received from computing device 142 over the data connection to server 112, and can send data received from server 112 over the data connection to computing device 142. In one example, wireless router 146 can 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 used correctly and securely.

[0027] The data exchange 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 with the data about computing device 142 under the user account. If a match exists, server 112 determines that 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 the local memory of computing device 142. Upon verification, computing device 142 immediately determines that the server has also been authenticated. With respect to Figure 3 Additional details regarding the computing components and the interactions between them in this initial phase are further described.

[0028] Once the device and server authentication 140 is complete, the computing device 142 and the server 112 can continue to exchange data to receive credentials for the secure network 172 while the computing device 142 is still on the hidden 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 user's computing device's home network). Restrictions on inbound and outbound data traffic no longer apply, and the computing device 142 can also interact with computing devices and access computing services on other data networks 174 in addition to the server 112.

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

[0030] For the sake of clarity, Figure 1The description involves multiple stages involving specific computing components. However, embodiments of the present disclosure are not so limited. For example, server 112 may be a cloud server and / or a computing component of a back-end system comprising one or more servers. The functionality of the server-based setup process may be distributed within the back-end system. In another example, computing device 142 does not need to connect to the same wireless router to join hidden open network 144 and secure data network 172. For example, two different routers may be used, one for each of the two data networks. In another example, a device other than a router may be used. For example, computing device 142 may connect to an access point on secure data network 172. Alternatively, another computing device of a user registered under a user account that has already joined secure data network 172 may serve as an access point to hidden open network 144. Generally speaking, the computing device and wireless router 146 described above are examples of provider devices with which computing device 142 communicates to exchange data with server 112 for authentication and receipt of credentials for secure data network 172. In yet another example, a different type of network may be used instead of hidden open network 144. For example, this data network can simply be an open network (rather than hidden) that broadcasts an SSID (in which case computing device 142 does not need to pre-store this SSID in its memory). In another example, the data network can be a public network with a personal portal. In this case, data exchange with server 112 can be performed by sending the relevant data via a Domain Name Service (DNS) request. These and other variations are further illustrated in conjunction with the following figures.

[0031] Figure 2 An example of associating a computing device with a user according to an embodiment of the present disclosure is shown. Associating a computing device with a user may be performed to generate a device-to-user account association, similar to Figure 1 The device-to-user account association 110 is made available during server-based setup of the computing device's connection to the secure data network. Figure 2 Two examples for making this association are shown. Figure 2 In a first example, starting in the top portion of FIG, 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 create the association. Figure 2 In the second example, starting at the bottom portion of FIG, a user obtains a computing device from a third party. In this example, the user (or third party) can create the association. Other examples for creating a device to a user account are also possible, including, for example, conventional online registration of a computing device under a user account.

[0032] In a first example, a user orders a computing device 210 from a service provider (eg, purchases it online from the service provider's website). The computing device 210 is Figure 1 142 . In general, computing device 210 can 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 can be a VCMD, which represents a smart speaker that provides an intelligent personal assistant service in response to a wake word and is capable of different interactions including playing content, providing real-time information, and performing tasks and routines, a smart plug, a multimedia streaming device, or any other device that hosts an intelligent personal assistant service, a power management service, a streaming service, and / or other applications. In other illustrations, computing device 210 can be a mobile phone, a tablet computer, a desktop computer, a smart TV, a digital video recorder, or any other user device with one or more processors, one or more memories, and one or more interfaces.

[0033] At the service provider's storage facility, computing device 210 may be added to container 220 for delivery to the user. A barcode 230 may be attached to container 220 (e.g., to an exterior surface of such container 220) and may encode data related to computing device 210 (e.g., a product number, a public key or a portion thereof, and / or the type of computing device 210, which may be a product classification such as a VCMD, smart plug, etc.). Optionally, the barcode may also encode data related to the user's user account. A remote device 240, such as a scanner at the storage facility (e.g., a handheld scanner or a product scanner at a workstation at the storage facility), performs a barcode scan 232 to read barcode data 234 (e.g., data encoded in barcode 230). Remote device 240 is communicatively coupled to a server 250 (or, more generally, a backend system) of the service provider and transmits barcode data 234 to such server 250. In the illustration, remote device 240 is on the same network as the central computer that manages the user's purchase order. Barcode data 234 is sent from remote device 240 to this central computer, which then sends it to server 250. The sent barcode data 234, for example, includes the public key of computing device 210 (shown as device public key 236) encoded in barcode 230, or a portion of device public key 236. Other data may also be included, such as a product number (e.g., serial number) and / or product classification of computing device 210. The product classification may indicate the type of computing device 210, such as whether computing device 210 is a VCMD, smart plug, multimedia streaming device, etc. 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 regarding a user account, barcode data 234 may include an identifier 238 for the user account. Otherwise, server 250 may receive identifier 238 separately from barcode data 234. For example, another barcode attached to container 220 and / or printed on the purchase order may encode identifier 238. Upon scanning of this barcode, remote device 240 reads identifier 238 from this barcode and sends to server 250. Additionally or alternatively, 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 barcode data 234 from remote device 240.

[0034] Server 250 then receives barcode data 234 and an identifier 238 for the user account and associates computing device 210 with the user account 212. For example, server 250 searches for the user account based on the identifier 238 and adds some or all of barcode data 234 to the account, including device public key 236 (or a portion thereof), product number, and / or device type. Additionally or alternatively, server 250 may update a list that associates device public keys with user accounts. This list is referred to herein as a public key-user account list. For example, device public key 236 (or a portion thereof) may be added as a key, and identifier 238 may be added as a value in the public key-user account list. Generally, 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 service provider's backend system, where this backend system may store user accounts for different users and provide computing services (e.g., multimedia streaming) to the users' computing devices based on the user accounts. although Figure 2 The embodiments shown in are provided with respect to bar codes and bar code scanners, but other data entry methods and systems may be utilized, including radio frequency identifiers (RFID) or the like.

[0035] In a first example, rather than using a product scanner, the remote device may be a 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 service provider's backend system based on a user login to a user account on the mobile application. In this example, the user may receive a container containing a computing device 210 and a paper sheet 222 (e.g., paper, a brochure, a user manual, etc.). This paper sheet 222 contains a barcode 224, similar to the barcode 230, that encodes the above data. Additionally, 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 conjunction with the following figures. The paper sheet 222 may, but need not, be attached to the computing device 210. After opening the container (in Figure 2224 and a paper sheet 222 and uses the mobile application to perform a barcode scan 252 of the barcode 224 (e.g., to capture an image of the barcode 224). The mobile application, in turn, reads the encoded data and sends the barcode data 254 to the server 250. The sent barcode data 254 includes, for example, the device public key 236 (or a portion thereof) and a PIN 238. Other data may also be included, such as the product number and / or type of the computing device 210. Additionally, if the barcode 230 encodes data regarding a user account, the barcode data 234 may include an identifier 238 for the user account. Otherwise, this identifier 238 is determined based on the user's login to the user account.

[0036] Here again, the server 250 receives the barcode data 254 and the identifier 238 of the user account and associates the computing device 210 with the user account 212. For example, the server 250 looks up the 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.

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

[0038] In one example, wireless router 320 manages access by computing devices to hidden open network 330 and access to inbound and outbound traffic to and from such computing devices on hidden open network 330. Generally, hidden open network 330 has an SSID but does not require a password for access (and therefore, such data networks are referred to as "open"). Wireless router 320 also does not advertise (e.g., broadcast) the SSID (and therefore, such data networks are also referred to as "hidden"). Hidden open network 330 can support various data communication protocols, including Wi-Fi and the Transmission Control Protocol and Internet Protocol (TCP / IP).

[0039] The service provider of server 340 may define the SSID (e.g., by referring to hidden open network 330 as "SSID_example" or some other name) and restrictions regarding the use of hidden open network 330. If wireless router 320 is designed, manufactured, and / or provided by the service provider, the SSID and restrictions may be pre-stored in the memory of wireless router 320. On the other hand, if 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 wireless router 320. In either case, once installed at the user's location, in addition to managing access to the home data network, wireless router 320 may also manage access to hidden open network 330 having the SSID based on the restrictions.

[0040] Similarly, and before the computing device 310 is provided to the user, the SSID (and other application-level restrictions) may be pre-stored in the local memory of the computing device 310. Specifically, if the computing device 310 is designed, manufactured, and / or provided by a service provider, the SSID may be pre-stored in the local memory of the computing device 310 during the manufacturing process or after manufacturing 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.

[0041] Additionally, the service provider may define a number "N" (e.g., ten) of the public keys of the server 340 that should be stored on the computing device 310 (the "N" server public keys), and may identify one of these public keys that should be used by the computing device 340 to authenticate the server 340. This 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, along with an indication of the specific server public key to be used for server authentication, are loaded (directly or via an SDK or configuration file) onto and stored in the local memory of the computing device 310 before being provided to the user.

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

[0043] After being provided to the user and in a powered-on state, computing device 310 may determine that a data connection to the home data network has not yet been set up (e.g., after the device is powered on for the first time). 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 the name of the hidden open network 330 and using a particular security protocol (e.g., WPA / WPA2 Personal).

[0044] Now that computing device 310 has joined hidden open network 330, this computing device 310 can exchange data with server 340 via wireless router 320 for authentication. Specifically, wireless router 320 sends outbound data from computing device 310 to server 340 and inbound data from server 340 to computing device 310. This data traffic and other data traffic are subject to restrictions stored on wireless router 320. Generally, the restrictions represent a firewall that constrains data traffic to ensure that hidden open network 330 is used correctly and securely and to minimize or prevent any impact on the home data network (also managed by wireless router 320).

[0045] In one example, the restrictions limit the total number of computing devices on the hidden open network 330, the data throughput and duration of the data connection between the computing device 310 and the wireless router 320, the destination address of outbound traffic from the computing device 310 (for example, this destination address may be limited to the network address of the server 340), and / or the source address of inbound traffic (for example, this source address may be limited to the network address of the server 340). Data traffic to and from the computing device 310 that meets the restrictions is passed; otherwise, the data traffic is filtered out.

[0046] In the illustration, the restriction allows hidden open network 330 to access the Dynamic Host Configuration Protocol (DHCP) on the router via User Datagram Protocol (UDP) on port 67, and to access specific whitelisted IP addresses via TCP on port 443. The restriction may also deny computing devices on the home data network from communicating with computing devices on hidden open network 330, and vice versa. For computing devices on hidden open network 330, the restriction may deny these computing devices from communicating with each other, with internal router endpoints, and from accessing router configuration interfaces. The restriction may also give packets on hidden open network 330 lower priority than packets on the home data network. The restriction may also limit the maximum number of computing devices that can be connected to hidden open network 330 simultaneously to a specific number. When there are no client endpoints, the restriction may require disconnecting at least a predetermined number of the oldest computing devices if 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 restriction may specify that no action should be taken, as these devices may be actively provisioning. The restriction may also specify that disconnected computing devices should not be allowed back onto hidden open network 330 for at least a certain amount of time. Additionally, the restrictions may limit the maximum download / upload rate for the hidden open network 330 to a specific bit rate and limit the maximum data transfer to a specific amount of data per day.

[0047] 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 via HTTP requests and responses. In one example, the computing device 310 sends its device digital certificate 312 to the server 340 and receives a server digital certificate 342 from the server 340. These two certificates 312 and 342 can be used in mutual TLS authentication.

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

[0049] In response, server 340 selects a private key from the "N" private keys defined and available to server 340 (e.g., "N" server private keys) and generates a digital signature 346 over HTTPS with the server private key. Similar digital signatures can be generated and used in conjunction with HTTPS requests and responses from server 340 to 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 computing device 310 and indicated as available in the authentication. In general, server 340 stores the "N" server private keys and a mapping of the "N" server private keys to computing device types. In one example, the mapping is additionally or alternatively specific to a range of product numbers of computing devices, wherein the mapping indicates that a particular server private key is applicable to a particular range of product numbers. Given the type of computing device 310 (eg, VCMD, smart plug, multimedia streaming device, etc.) and / or the product number of computing device 310 , server 340 determines from the mapping the specific server private key that should be used for digital signature 346 .

[0050] Computing device 310 receives digital signature 346, determines the particular server public key, and uses this key to verify digital signature 346. If digital signature 346 is verified, computing device 310 determines that server 340 is authenticated.

[0051] 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 can also be used in an additional layer of authentication. Specifically, once computing device 310 authenticates server 340 based on TLS and digital signature authentication, computing device 310 can 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.

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

[0053] Although Figure 3 While wireless router 320 is shown as being used to provide and manage access to hidden open network 330, embodiments of the present disclosure are not so limited. In practice, another computing device 322 may do so. Specifically, computing device 322 may have been previously acquired by the user and provisioned to access the user's secure home network. This computing device 322 may be of the same or a different type as computing device 310 (e.g., a VCMD, smart plug, multimedia streaming device, etc.). After the user acquires computing device 310 (to be provisioned) and a device-to-user association is created for computing device 310, server 340 may send data indicating this association and instructions to perform provisioning functionality to computing device 322. These instructions may trigger computing device 322 to set up hidden open network 322 within a predetermined time period (e.g., within one week of creating the association) and impose restrictions on inbound and outbound traffic to and from computing device 310.

[0054] also, Figure 3 The data exchange is shown as occurring partially over a hidden open network and using HTTPS requests and responses. However, embodiments of the present disclosure are not so limited. In practice, computing device 310 can detect nearby visible open networks (e.g., data networks that broadcast their SSIDs and do not require passwords) and the SSIDs of such networks do not need to be pre-stored on computing device 310. Figure 3 This network is shown as an open network 350 managed by a wireless router 360. Computing device 310 and server 340 may exchange the above data for authentication via wireless router 360. In this case, wireless router 360 may not store and apply restrictions.

[0055] Figure 4An example of providing credentials for a secure data network from a server to a computing device according to an embodiment of the present disclosure is shown. Specifically, the computing device and the server have already partially exchanged data over an open data network (either hidden or visible) and authenticated each other using the data. Next, the computing device and the server may continue to exchange data, partially 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 include 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.

[0056] As illustrated, computing device 410 is in data communication with server 440 via wireless router 420, wherein 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 respectively Figure 3 Instances of a computing device 310, a wireless router 320, a hidden open network 330, and a server 340.

[0057] Once authentication is complete, computing device 410 can detect nearby secure networks 450 (e.g., nearby Wi-Fi LAN networks, each protected by a credential such as a password). While still on hidden open network 430, computing device 410 requests 412 server 440 for credentials for secure network 450. For example, computing device 410 sends an HTTPS request to server 440 via wireless router 420, which subjects this request to restrictions. The HTTPS request includes an identifier for secure network 450 (e.g., a HTTPS address). Figure 4 414). In response, server 440 may determine that secure network 450 has been associated with the 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). Server 440 then provides 442 the credentials to the computing device via wireless router 420, which also subjects this response to restrictions. For example, server 440 sends a response containing the credentials (e.g., Figure 4 HTTPS response shown as secure network credentials 444).

[0058] 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 that manages access to secure network 450) by using secure network SSID 414 as the name of secure network 450, secure network credentials 444 as the password for secure network 450, and a specific security protocol (e.g., WPA / WPA2 Personal) to establish a new data connection, thereby joining secure network 450. From this point on, restrictions on inbound and outbound data traffic no longer apply, and computing device 410 can interact with computing devices and access computing services on other data networks 460 in addition to server 112.

[0059] For the sake of clarity, Figure 4 The computing device 410 is shown detecting one 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 for requesting credentials for such networks are possible.

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

[0061] Here too, and similarly Figure 3, the same wireless router 420 need not be used for both the hidden open network 430 and the secure network 450. In fact, different wireless routers and / or computing devices that have been provisioned and added to the secure network 450 can be used to provide and manage access to the hidden open network 430, while the wireless router 420 can be used to provide and manage access to the secure network 450.

[0062] Figure 5 Another example of authentication and provisioning credentials for a secure data network according to an embodiment of the present disclosure is shown. In this example, rather than connecting to an open network (e.g., Figure 3 and 4 Computing device 510 can connect to wireless router 520 on a public network 530 with a valid portal (visible or hidden in the example). The valid portal may require user input before establishing a connection (for example, in the illustrative example, the provided network 530 may be provided by an entity such as a store or hotel and may require user input, such as a customer loyalty card number or a hotel room number and / or a hotel guest name, in order to access it). In this case, DNS requests are used to transfer relevant authentication data and network data between the computing device and server 540 without requiring computing device 510 to join public network 530. Once authentication is complete and computing device 510 receives credentials for secure network 560 from server 540, computing device 510 can connect to wireless router 550 on secure network 560 to subsequently gain access to other data networks 570 in addition to server 540.

[0063] Here, the computing device 510, the wireless routers 520 and 550, and the server 540 are Figure 4 Instances of computing device 410, wireless router 420 and server 440. Figure 4 One difference is that each piece of authentication data and network data is pre-mapped to a domain (or subdomain) with a specific domain name. The domain name can encode or represent the piece of data. Instead of exchanging the piece of data itself, computing device 510 and server 540 exchange DNS requests that are resolved to the domain name and, in turn, indicate the piece of data.

[0064] 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 Figure 3 The network data may include a device digital certificate 312, a device public key 314, a PIN hash 316, a server digital certificate 342, and a digital signature 346. Figure 4Each of the device public key 514, PIN hash 516, server digital certificate 542, digital signature 544, secure network SSID 518, and secure network credential 546 may be mapped to a domain (or subdomain) and indicated via a DNS request.

[0065] Figure 6 An example of a computing device configured as a provisioned device 600 to connect to a secure data network according to an embodiment of the present disclosure is shown. The provisioned device 600 represents a computing device that has not yet been configured but is connected to a secure network and is being provisioned via server-based setup to automatically connect to the secure network. Figure 1 computing device 142, Figure 2 computing device 210, Figure 3 computing device 310, Figure 4 The computing device 410 and Figure 5 The computing device 510 is an example of the provisioned device 600 .

[0066] As illustrated, the provisioned 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 one example, a barcode 640 may also be attached to the provisioned device 600 (e.g., to the housing of the provisioned device 600).

[0067] Memory 630 stores a device digital certificate 632, an open network SSID 634, an "N" server public key 636, and code for a setup application 638. When executed by processor 610, setup application 638 runs and provides functionality for joining an open data network, performing authentication, receiving credentials for a secure data network, and joining a secure data network. Setup application 638 may also impose application-level restrictions on inbound and outbound data traffic for the provisioned device over the open data network (e.g., by restricting any outbound traffic to a predefined address of the server). Such restrictions and the predefined address of the server may also be stored in memory 630.

[0068] Figure 7 An example of a computing device configured as a provider device 700 to facilitate communication between a provisioned device and a cloud server according to an embodiment of the present disclosure is shown. The provider device 700 represents a computing device that manages access to an open network and can connect with provisioned devices and servers to support provisioning of provisioned devices. Figure 1 Wireless router 146, Figure 3 Wireless routers 320 and 360, Figure 4 Wireless router 420 and Figure 5 The wireless router 520 is an example of a provider device 700. Other types of devices may also be used as provider devices. For example, a computing device that was previously a provisioned device and successfully provisioned to join a secure network may be configured as a provider device.

[0069] As illustrated, the 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). The memory 730 stores network restrictions 732 to manage inbound and outbound traffic to and from the provisioned device on an open data network. The memory 730 may also include code for a network application to manage access to the open data network. If the provider device 700 also manages access to a secure data network, the memory 730 may also include code for the same or another network application to manage such access.

[0070] Figure 8 An example of a cloud server 800 configured to authenticate a provisioned device and provide credentials for a secure data network according to an embodiment of the present disclosure is shown. Server 800 may be dedicated server hardware, server-based software running on general-purpose hardware, or a cloud-based computing service hosted on hardware in a data center. Generally, server 800 represents the computing component of a service provider's backend system, where this backend system may store user accounts for different users and provide computing services (e.g., multimedia streaming) to the users' computing devices based on the user accounts. Figure 1 Server 112, Figure 2 Server 250, Figure 3 Server 340, Figure 4 Server 440 and Figure 5 Server 540 is an example of server 800 .

[0071] 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).

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

[0073] In addition, the memory 830 stores a user account 834 (or multiple user accounts for different users). Generally, the user account 834 stores data related to the user, the computing services available to the user, and the user's computing devices, including any provisioned devices. In the example of data related to a provisioned device, the user account 834 stores the device public key 835 (or a portion thereof) of the provisioned device and optionally other data such as the product number and / or type of the provisioned device. This data represents the association between the provisioned device and the user account. In addition, the user account 834 stores the identifiers and credentials (shown as SSID and password 836) of the secure networks accessible to the user (or multiple identifiers and credentials if the user has access to multiple secure networks). Once authentication is successfully performed, the server 800 can send the credentials to the provisioned device. As explained above in this document, in addition to or instead of storing the device public key 835 under the user account, a public key-user account list can be used. Specifically, such a list may be stored in memory 830 and may associate a public key 835 with a user account 834 (and likewise, other public keys with the same user account 834 and / or other user accounts).

[0074] The memory 830 may also store code for a server-based setup service, shown as setup service 838. When executed by the processor 810, the setup service 838 runs and provides functionality for authenticating the server 800 to the provisioned device, authenticating the provisioned device, and sending relevant credentials to the provisioned device.

[0075] Figure 9 An example of a sequence diagram 900 is shown between a provisioned device, a provider device, and a server that connects the provisioned device to a secure data network according to an embodiment of the present disclosure. The provisioned device, the provider device, and the server are Figure 6 The provided device 600, Figure 7The provider device 700 and Figure 8 Providers generally provide and manage access to an open data network. A provisioned device and the server exchange authentication data and network data while the provisioned device is on the open network. Upon receiving the network data, the provisioned device disconnects from the open data network and joins the secure data network based on the secure data network credentials from the network data. The secure data network does not need to be provisioned and managed by the provider device.

[0076] Sequence diagram 900 begins with the provisioned device (e.g., its setup application) detecting a connection setup trigger. This trigger causes the provisioned device to automatically begin server-based setup to receive credentials for the secure network and connect to it. In one example, the trigger may be the first power-up of the provisioned device. Another trigger may be detecting that no home network has been set up for the provisioned device or that a previously set home network is no longer accessible or available. Yet another example may be user input triggering the connection setup, such as a hard button on the provisioned device or a soft button displayed on the provisioned device's screen.

[0077] 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 is the case when the open data network is hidden. However, if the open data network is visible, the device can receive its identifier via a broadcast from this network.

[0078] 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 the open data network and requests access to this network from the provider device using a specific security protocol (e.g., WPA / WPA2 Personal).

[0079] Once on the open data network, the provisioned device can communicate with the server via the provider device. Communications can include HTTP requests and responses and are subject to any restrictions stored by the provider device. The provisioned device and server perform mutual TLS authentication. For example, the provisioned 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 is established, and communications can include HTTPS requests and responses.

[0080] In addition to, independently of, or in lieu of TLS mutual authentication, the provisioned device and server can also perform device-user account association-based authentication and PIN hash-based authentication by exchanging relevant data via the provisioned device. In the former authentication example, the server can retrieve the device public key from the provisioned device's device digital certificate and compare this key with the device public key (or portion thereof) stored under the user account associated with the provisioned device, or can search a public key-user account list for a match. If the comparison indicates a match, the server determines that the provisioned device is authenticated. In response, the server signs the HTTPS data from the server (e.g., data in each or a certain request and response) with the server's private key, thereby creating a digital signature. The provisioned device receives the digital signature (e.g., in the corresponding HTTPS request or response) and verifies it based on the server's public key stored in the provisioned device's memory. In the latter authentication example, the provisioned device stores the PIN and requests and receives a temporary token from the server. The provisioned device then generates a PIN hash based on a hash of the PIN and the temporary token and sends the PIN hash to the server. The server verifies the PIN hash by hashing the PIN stored under the user account for the provisioned device.

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

[0082] The provisioned device receives the credentials. For example, an HTTPS response is passed from the provider device to the provisioned device while the provisioned device is still on the open data network.

[0083] Once the credentials are received, the provisioned device establishes a new data connection with the provider device (or a related 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 credentials as the password, and requests access to this network from the provider device using a specific security protocol (e.g., WPA / WPA2 Personal).

[0084] Figures 10 to 11 Shows an example flow for server-based setup of a connection to a secure network. Figure 6The provider device 600 is described as executing Figure 10 The operation of the instance process is similar to Figure 8 The server 800 is described as executing Figure 11 The instructions for performing the operations may be stored as computer-readable instructions on a related computing component (e.g., Figure 10 The provided device and Figure 11 The instructions are stored on one or more non-transitory computer-readable media (e.g., a server). When stored, the instructions represent programmable modules containing code or data executable by one or more processors of the associated computing component. Execution of such instructions configures the associated computing component to perform the specific operations shown in the corresponding figures and described herein. Each programmable module, combined with a corresponding processor, represents a means for performing the corresponding operation. Although the operations are shown in a particular order, it should be understood that this particular order is not required, and one or more operations may be omitted, skipped, and / or reordered.

[0085] Figure 10 An example process for connecting a provisioned device to a secure data network according to an embodiment of the present disclosure is shown. As illustrated, the example process begins at operation 1002, where a provisioned device establishes a first data connection with a provider device on a first data network. In one example, the first data network is a nearby Wi-Fi open data network that can be hidden or visible. If hidden, the provisioned device determines the SSID of this network from its local memory and requests access to it from the provider device.

[0086] At operation 1004, the provisioned device sends its device digital certificate to the server. In one example, the provisioned device accesses the device digital certificate from its local storage. Furthermore, the provisioned device determines the network address of the server from its local storage. The provisioned device generates an HTTP request destined for the network address and includes the device digital certificate. The HTTP request is sent from the provisioned device via a data connection with the provider device. Subject to applicable restrictions, the provider device routes the HTTP request to the server.

[0087] At operation 1006, the provisioned device receives the server digital certificate. In one example, this certificate is sent from the server in an HTTP response destined for the provisioned device. Depending on applicable restrictions, the provider device routes the HTTP response to the provisioned device.

[0088] At operation 1008, the provisioned device authenticates the server based on the server digital certificate. In one example, this authentication involves performing TLS authentication by verifying the identity of the server and the certificate authority from the server digital certificate. Once TLS authentication is performed, HTTPS communication can occur between the provisioned device and the server via the provisioning device and is subject to restrictions.

[0089] At operation 1010, the provisioned device receives a digital signature from the server. In one 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's private key. Signed HTTPS data is referred to herein as a digital signature. Generally, the server generates a one-way hash of the HTTPS data to be signed and encrypts the hash with the server's private key. This resulting digital signature may be included in the corresponding HTTPS request or HTTPS response. The digital signature is sent from the server to the provisioned device (e.g., in the corresponding HTTPS request or response). Depending on applicable restrictions, the provisioning device routes the digital signature to the provisioned device. For illustration, upon completion of TLS authentication, the provisioned device immediately sends an HTTPS request to the server (e.g., a request containing a random or specific message), and the server returns an HTTPS response to this request. The HTTPS response is signed with the server's private key and routed to the provisioned 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's private key to generate the server's digital signature. The digital signature is included in the HTTPS response. Furthermore, and as described in conjunction with the subsequent operations of the flow, the server's HTTPS responses, including those used to send the temporary token and credentials, are signed with the server's private key. Such signatures also represent digital signatures that can be verified by the provisioned device as another layer of server authentication (e.g., a digital signature based on a hash of the temporary token, a digital signature based on the credentials).

[0090] At operation 1012, the provisioned device further authenticates the server based on the digital signature. In one example, the provisioned device accesses the server's public key from its local storage and verifies the digital signature. Generally, the provisioned device decrypts the hash from the digital signature using the server's public key, generates a hash from the digital signature (or, if the corresponding HTTPS request includes a message from the provisioned device, generates a hash of the message), and compares the two hashes to determine a match. In the illustration, the local storage stores "N" server public keys. The local storage may also store an indication of a specific server public key from the "N" server public keys to be used for digital signature verification. The provisioned device selects this specific server public key based on the indication. In another example, no such indication is stored. In practice, the provisioned device selects a 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 provisioned 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 decryption failures persist, the provisioned device will not further authenticate the server.

[0091] At operation 1014, the provisioned device requests a temporary token from the server. In one example, the provisioned device stores a PIN that can be used to further authenticate itself to the server. For this further authentication, the provisioned device sends an HTTPS request for the temporary token, with the request destined for the server. Depending on applicable restrictions, the provisioning device routes the HTTPS request to the server.

[0092] At operation 1016, the provisioned device receives the temporary token from the server. In one example, the temporary token is sent from the server in an HTTPS response destined for the provisioned device. Depending on applicable restrictions, the provisioning device routes the HTTPS response to the provisioned device. As explained above, the temporary token can also be signed using the server's private key, and the resulting digital signature can be included in the HTTPS response.

[0093] At operation 1018, the provisioned device sends a hash of the PIN based on the temporary token to the server. In one example, the provisioned device hashes the PIN and the temporary token and sends an HTTPS request containing the hash. The HTTPS request is destined for the server, and depending on applicable restrictions, the provisioning device routes the HTTPS request to the server. Operations 1014-1018 are shown in dashed lines to indicate that these operations apply when a PIN is available. As described above, the PIN can be generated during the initial state of associating the provisioned device with the user account. Furthermore, the hash can be sent only after successful verification of the digital signature received at operation 1016 based on the server public key.

[0094] At operation 1020, the provisioned device detects one or more data networks. In one example, the provisioned device detects nearby Wi-Fi secure LANs by identifying the SSIDs of the nearby Wi-Fi secure LANs and determining the security of the data networks.

[0095] At operation 1022, the provisioned device 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 provisioned device, while still on the first data network, sends an HTTPS request containing the SSID of this secure data network. The HTTPS request is destined for the server, and depending on applicable restrictions, the provisioning 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 identifying the selected data network to the server. Alternatively, the provisioned device may send a single HTTPS request containing the SSID of the detected secure data network or a subset thereof. In another embodiment, the provisioned device sends multiple HTTPS requests, each request identifying one or more of the detected secure data networks.

[0096] At operation 1024, the provisioned device receives one or more credentials from the server. As in the above example regarding detection of a single secure data network, the server detects an association between an identifier based on this network and a user account, and this network should be accessible to the computing device. The server sends an HTTPS response containing the credentials. The HTTPS response is destined for the provisioned device, and depending on applicable restrictions, the provider device routes the HTTPS response to the provisioned device. If multiple secure data networks are destined for the server, then the server similarly determines that a subset of these networks should be accessible to the computing device and sends their credentials in one or more HTTPS responses. As explained above in this document, the credentials included in the HTTPS response can also be signed with the server private key and the resulting digital signature can be included in the HTTPS response.

[0097] At operation 1026, the provisioned device establishes a second data connection with a wireless router on a second data network. In one example, the second data network is one of the detected secure networks for which the credentials were received, and the provisioned device establishes the second data connection to join the secure data network. The provisioned device terminates the first data connection, thereby leaving the first data network. The provisioned device also requests access to the secure data network from the wireless router using the SSID as the name and the credentials as the password, using a specific security protocol (e.g., WPA / WPA2 Personal). Furthermore, 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.

[0098] In the event that multiple secure data networks are detected, the provisioned device may request their credentials all at once (e.g., with one or more HTTPS requests) or may sequentially select a secure data network, request its credentials, and if credentials are not received, select the next secure data network until credentials are received or the list of detected secure data networks is exhausted.

[0099] Additionally, once the second data connection is established, the provisioned device may perform additional operations to determine whether the second data connection was established based on communication with a trusted server and / or based on a server private key that has not been compromised. In one example, the provisioned device sends an indication of its server public key used to set up the second data connection to the second server. This indication may be sent in an HTTPS request over the second data network, 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 immediately 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 provisioned device is untrusted and should be revoked. If no match is found, the server public key may be trusted and usable. The second server sends an indication to the provisioned device regarding whether the server public key is untrusted, depending on the match. This indication may be sent in an HTTPS response received by the provisioned device over the secure LAN. From the HTTPS response, the provisioned device determines whether the server public key is untrusted and should be revoked, or trusted and usable. In the former case, the provisioned device terminates the second data connection and thus leaves the second data network. In the latter case, the provisioned device does not terminate the second data connection and thus remains on the second data network. Furthermore, upon determining that the server public key is untrusted and should be revoked, the second server can immediately identify a trusted second server public key already stored in the provisioned device's memory. This second server public key identifier can be sent in the HTTPS response. Thus, after leaving the second data network, the provisioned device can immediately restart the process of connecting to the secure data network by relying on the second public key instead.

[0100] Figure 11 An example of a process for a server to provide credentials for a secure data network to a provisionee device according to an embodiment of the present disclosure is shown. In one example, the process begins at operation 1102, where the server stores "N" server private keys and a mapping between the private keys and device types. For each type of provisionee device (e.g., a product category), the mapping indicates a specific server private key from the "N" server private keys to use for generating a digital signature.

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

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

[0103] At operation 1108, the server associates the provisioned device with the user account based on the received data. In one example, the server determines the user account based on the user account or the user's identifier and updates the user account to store the device public key (or part thereof), product number, product classification, and / or PIN.

[0104] At operation 1110, the server receives a device digital certificate from a provisioned device. In one example, the provisioned device is on a first data network managed by the provisioning device. The provisioned device sends an HTTP request containing the device digital certificate. This HTTP request is destined for the server, and depending on applicable restrictions, the provisioning device routes the HTTP request to the server.

[0105] At operation 1112, the server authenticates the provisioned device based on the device digital certificate and sends the server's server digital certificate to the provisioned device. In one example, authentication involves performing TLS authentication by verifying the identity of the provisioned device and the certificate authority using the device digital certificate. For mutual TLS authentication, the server also generates an HTTP response destined for the provisioned device and including the server digital certificate. The HTTP response is sent to the provisioned device, and depending on applicable restrictions, the provisioning device routes the HTTPS response to the provisioned device. The provisioned device uses the server digital certificate to authenticate the server. After mutual TLS authentication, HTTPS communication can immediately be performed between the server and the provisioned device.

[0106] At operation 1114, the server determines the device public key of the provisionee device. In one example, the server retrieves the device public key from the received device digital certificate.

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

[0108] At operation 1118, the server further authenticates the provisioned device. In one example, the server uses the determination that an association already exists between the provisioned device and the user account as another layer of authentication for the provisioned device. In another example, the server declares the provisioned device further authenticated based on a match between the device public key from the device digital certificate and the device public key stored in the user account.

[0109] At operation 1120, the server accesses the server's server private key based on the type of the provisioned device. In one example, the server determines the type of the provisioned device from data stored in the user account or from HTTPS data received from the provisioned device (whereby the provisioned device identifies its type to the server). The server uses the device type to look up a mapping and determine the server private key. In another example, the product number of the provisioned device is additionally or alternatively used to select the server private key. Specifically, the mapping may further map a range of provisioned device product numbers to the server private key.

[0110] At operation 1122, the server generates a digital signature based on the server private key from the "N" private keys. In one example, the 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 diagram, the server generates a hash of the message and encrypts the hash with the server private key, thereby generating a digital signature that can be included in the HTTPS response. In addition, and as described in conjunction with the next operations of the process, the HTTPS request and the server's response are signed with the server private key, including the request and response used to send the temporary token and the credential. Such signatures also represent digital signatures that can be verified by the provisioned device as another layer of server authentication (e.g., a digital signature based on a hash of the temporary token, a digital signature based on the credential).

[0111] At operation 1124, the server sends the digital signature to the provisioned device. In one 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 provisioned device and includes the digital signature. The HTTPS response is sent to the provisioned device, and depending on applicable restrictions, the provisioning device routes the HTTPS response to the provisioned device.

[0112] At operation 1126, the server receives a request for a temporary token from the provisioned device. In one example, this request is sent from the provisioned device as an HTTPS request in response to the provisioned device's authentication of the server. In the illustration, this authentication may include verification by the provisioned device of the digital signature sent at operation 1124, where the verification relies on the server's public key. The HTTPS request is destined for the server, and depending on applicable restrictions, the provisioning device routes the HTTPS request to the server.

[0113] 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 temporary token and is destined for the provisioned device. Additionally, a digital signature may be generated based on a hash of the temporary token and the server's private key and included in the HTTPS response. The HTTPS response is sent to the provisioned device, and depending on applicable restrictions, the provisioning device routes the HTTPS response to the server.

[0114] At operation 1130, the server receives a hash of the PIN from the provisioned device. In one example, this PIN hash is generated by the provisioned device based on the PIN and a temporary token and sent from the provisioned device to the server in an HTTPS request. This PIN hash may be received only after the provisioned device verifies the digital signature from operation 1128, based on the server's public key, as appropriate. The HTTPS request is destined for the server, and depending on applicable restrictions, the provisioning device routes the HTTPS request to the server.

[0115] At operation 1132, the server further authenticates the provisioned device based on the hash of the PIN. In one example, the server verifies the PIN hash by hashing the PIN stored for the provisioned device (e.g., under a user account) and comparing the hashes for a match.

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

[0117] At operation 1136, the server determines a match with a network identifier under the user account. In one example, the server retrieves the 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 the credentials from the 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 similar matching process to determine any additional matches and corresponding credentials.

[0118] At operation 1138, the server sends one or more network credentials to the provisioned device. In one example, the server generates and sends an HTTPS response containing credentials matching the secure data network. The HTTPS response is destined for the provisioned device, and depending on applicable restrictions, the provisioning device routes the HTTPS response to the provisioned device. In the event of matching multiple secure data networks, the same HTTPS response or multiple HTTPS responses may be sent to the provisioned device, each of which may contain one or more of the corresponding credentials. Furthermore, the credentials included in the HTTPS response may be signed with the server's private key, and the resulting digital signature may be included in the HTTPS response for further authentication by the provisioned device.

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

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

[0121] The CPU 1204 performs operations by transitioning from one discrete physical state to the next by manipulating switching elements that distinguish and change these states. Switching elements may typically include electronic circuits that maintain one of two binary states (e.g., flip-flops) and electronic circuits that provide an output state based on a logical combination of the states of one or more other switching elements (e.g., 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.

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

[0123] The computer 1200 can operate in a networked environment using logical connections to remote computing devices and computer systems via a network, such as a local area network 1220. The chipset 1206 can include functionality for providing network connectivity via a NIC 1212, such as a Gigabit Ethernet adapter. The NIC 1212 can connect the computer 1200 to other computing devices via the network 1220. It should be appreciated that multiple NICs 1212 can be present in the computer 1200 to connect the computer to other types of networks and remote computer systems.

[0124] 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, which are described in greater detail herein. The mass storage device 1218 may be connected to the computer 1200 via a storage controller 1214 connected to the chipset 1206. The mass storage device 1218 may be comprised of one or more physical storage units. The storage controller 1214 may be connected via a serial attached SCSI ("SAS") interface, a serial advanced technology attachment ("SATA") interface, a fiber channel ("FC") interface, or other types of interfaces for physically connecting and transferring data between the computer and the physical storage units.

[0125] The computer 1200 can store data on the mass storage device 1218 by transforming the physical state of the physical storage units to reflect the information being stored. In different implementations of this specification, the specific transformation of the physical state may depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage units, whether the mass storage device 1218 is characterized as a primary storage device or a secondary storage device, etc.

[0126] For example, the computer 1200 can store information to the mass storage device 1218 by issuing instructions via the storage controller 1214 to change the magnetic properties of a specific location within a disk drive unit, the reflective or refractive properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical media are possible without departing from the scope and spirit of the present description, wherein the foregoing examples are provided merely to facilitate this description. The computer 1200 can further read information from the mass storage device 1218 by detecting the physical state or properties of one or more specific locations within the physical storage unit.

[0127] 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 computer-readable storage media may be any available media that provides storage of non-transitory data and that can be accessed by the computer 1200.

[0128] By way of example and not limitation, computer-readable storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are 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 devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.

[0129] The mass storage device 1218 may store an operating system 1230 for controlling the operation of the computer 1200. According to one embodiment, the operating system comprises a LINUX operating system. According to another embodiment, the operating system comprises an ARM® operating system from Microsoft Corporation. SERVER operating system. According to other embodiments, the operating system may include a UNIX or SOLARIS operating system. It should be understood that other operating systems may also be utilized. The mass storage device 1218 may store other system or application programs and data utilized by the computer 1200. The mass storage device 1218 may also store other programs and data not specifically identified herein.

[0130] 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 have access to 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 computer-readable storage media for performing any of the other computer-implemented operations described herein.

[0131] The computer 1200 may also include one or more input / output controllers 1216 for receiving and processing input from a number of input devices (e.g., a keyboard, mouse, touch pad, touch screen, electronic stylus, or other types of input devices). 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 understood that the computer 1200 may not include Figure 12 All components shown in the Figure 12 other components not explicitly shown in the Figure 12 It should also be appreciated that a number of computers, such as computer 1200, may be combined to embody aspects of the various techniques disclosed herein.

[0132] Examples of embodiments of the present disclosure may be described in terms of the following:

[0133] 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 comprises storing a list associating one or more public keys with one or more user accounts. The method further comprises storing a user account including a user identifier, a service set identifier (SSID) of the secure LAN, and a password for the secure LAN. The method further comprises storing a private key for the one or more servers and a mapping between the private key and a product classification of the computing device.

[0134] The method also includes receiving a public key of the computing device, a product classification of the computing device, and a user identifier in response to a scanner scanning a barcode associated with the computing device. The method also includes updating the list to include the public key and the user account. The method also includes receiving a certificate for the computing device via a wireless router, the certificate including the public key of the computing device, wherein the wireless router and the computing device are connected via an open LAN, and wherein the certificate is sent from the computing device via 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 keys of the one or more servers by determining from a mapping that the private keys are associated with the 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 being sent from the computing device via the open LAN, the first HTTPS response being signed with the private key of the one or more servers and being sent from the one or more servers via the open LAN to the computing device via the wireless router. The method also includes receiving a second HTTPS request from the computing device from the wireless router, the second HTTPS request including the SSID of the secure LAN. The method also includes sending the password of the secure LAN from the user account in a second HTTPS response to the computing device over the open LAN via the wireless router.

[0135] Clause 2. 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 and the secure LAN via a wireless router, and wherein the second computing device is associated with the user account.

[0136] Clause 3. A method according to any one of clauses 1 to 2, wherein the wireless router and the computing device are connected via an 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 via 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 via the open LAN to second traffic originating from the one or more servers.

[0137] 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 being associated with a local area network. The operations also include receiving a certificate for the computing device. The operations also include determining an association between the computing device and the user account based at least in part on the certificate. The operations also include authenticating the computing device based at least in part on the association being determined. The operations also include sending data signed with a private key of the system to the computing device based at least in part on the computing device being authenticated. The operations also include receiving a request from the computing device for credentials for the local area network based at least in part on the data. The operations also include sending the credentials to the computing device based at least in part on the request.

[0138] Clause 5. One or more computer-readable storage media as described in clause 4, wherein each of the certificate and the request is received via a data connection between the computing device and a wireless router of the second local area network, wherein each of the data and the credential is sent to the computing device via the data connection.

[0139] Clause 6. One or more computer-readable storage media according to any one of clauses 4 to 5, wherein each of the certificate and the request is received via a data connection between the computing device and a second computing device through a second local area network, and wherein the operation further includes: receiving barcode data associated with the computing device; and requesting the second computing device to set up a second local area network within a time period based at least in part on the receipt of the barcode data.

[0140] Clause 7. One or more computer-readable storage media according to any one of clauses 4 to 6, wherein the operation further comprises: receiving first data about a public key of a computing device and second data about a user account from a barcode in response to scanning of a barcode associated with the computing device by a remote device, wherein the association between the computing device and the user account is generated at least in part based on the first data and the second data.

[0141] Clause 8. One or more computer-readable storage media according to any one of clauses 4 to 7, wherein the operation further comprises: receiving barcode data from a mobile device from a barcode associated with a computing device, the barcode data comprising a personal identification number (PIN), wherein the association between the computing device and the user account comprises a PIN based at least in part on the barcode data.

[0142] Clause 9. One or more computer-readable storage media as described in 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.

[0143] Clause 10. One or more computer-readable storage media according to any one of clauses 4 to 9, wherein the operation further comprises: 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 of the computing device type; and signing the data with the private key based at least in part on the type of computing device, the product number of the computing device, and the mapping.

[0144] Clause 11. One or more computer-readable storage media according to any one of clauses 4 to 10, wherein the system is a back-end server that stores credentials for a local area network, wherein the data includes 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.

[0145] Clause 12. 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 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 the server via the 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 the public key of the server. The operations also include requesting credentials for a second LAN from the server via the first data connection. The operations also include receiving the credentials from the server via the first data connection. The operations also include establishing a second data connection to the second LAN based at least in part on the credentials.

[0146] Clause 13. A computing device according to clause 12, wherein execution of the instructions further causes the computing device to store a service set identifier (SSID) of a 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.

[0147] Clause 14. A computing device according to any of clauses 12 to 13, wherein data traffic from and to the computing device via the first LAN is limited based at least in part on one or more of: the volume of data traffic, the destination of the data traffic, the origin of the data traffic, or the number of computing devices connected to the first LAN.

[0148] Clause 15. A computing device according to any one of clauses 12 to 14, wherein execution of the instructions further causes the computing device to: detect an identifier of a security LAN that includes a second LAN; send a request for credentials for the security LAN to a server; and receive one or more of the credentials from the server based at least in part on an association between one or more of the security LANs and a user account, wherein the one or more of the credentials include credentials for the second LAN.

[0149] Clause 16. A computing device according to any one of clauses 12 to 15, wherein execution of the instructions further causes the computing device to: detect an identifier of a secure LAN including a second LAN and a third LAN; send a request for credentials for the third LAN to a server; receive a response from the server that the credentials for the third LAN are not available; and send a request for credentials for the second LAN to the server based at least in part on the response.

[0150] Clause 17. A computing device according to any one of clauses 12 to 16, wherein execution of the instructions further causes the computing device to store multiple public keys of the server and instructions to use a public key from the multiple public keys to authenticate the server, wherein verifying the data is based at least in part on the instructions.

[0151] Clause 18. A computing device according to any one of clauses 12 to 17, wherein execution of the instructions further causes the computing device to: send a first indication to a second server via a second LAN that the public key is to be used in association with establishing a second data connection; receive 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.

[0152] Clause 19. A computing device according to any of clauses 12 to 18, wherein the first data connection is established with a 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 detection of a second SSID and credentials of the second LAN.

[0153] Clause 20. A computing device according to any of clauses 12 to 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 detection of a second SSID and credentials of the second LAN.

[0154] Accordingly, the specification and drawings are to be regarded in an illustrative 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.

[0155] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof have been shown in the drawings and described above in detail. However, it should be understood that there is no intention to limit the invention to the particular 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.

[0156] Unless otherwise indicated herein or clearly contradicted by the context, the use of the terms "a", "an", "the" and similar indicators in the context of describing the disclosed embodiments (especially in the context of the appended claims) should be understood to cover the singular as well as the plural. Unless otherwise indicated, the terms "comprising", "having", "including" and "containing" should be understood as open-ended terms (i.e., meaning "including but not limited to"). The term "connected" should be understood to mean partially or completely contained within, attached to or joined together, even in the presence of intermediates. Unless otherwise indicated herein, the recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each individual value within the range, and each individual value is incorporated into the specification as if it were individually cited herein. Unless otherwise indicated herein or clearly contradicted by the context, all methods described herein can be performed in any suitable order. Unless otherwise required, the use of any and all examples or exemplary language provided herein (e.g., "such as") is merely intended to better illustrate the embodiments of the invention and does not impose a limitation on the scope of the invention. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

[0157] The preferred embodiments of the present disclosure are described herein, including the best mode for implementing the present invention known to the inventor. After reading the foregoing description, variations of those preferred embodiments may become apparent to those of ordinary skill in the art. The inventors expect that those skilled in the art will adopt these variations when appropriate, and the inventors intend to implement the present invention in a manner different from that specifically described herein. Therefore, the present invention includes all modifications and equivalents of the subject matter cited in the appended claims as allowed by applicable law. In addition, unless otherwise indicated herein or otherwise clearly contradicted by the content, the present invention encompasses any combination of the above-mentioned elements with all possible variations thereof.

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

Claims

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 for the secure LAN; storing private keys for the one or more servers and mappings between the private keys and product classifications of the computing devices; 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 via an open LAN, and wherein the certificate is sent from the computing device via the open LAN; authenticating the computing device by performing a Transport Layer Security (TLS) authentication using the certificate; determining from the list that the public key contained in the certificate is associated with the user account; accessing the private key by determining from the mapping that the private key of the one or more servers is associated with the product classification of the computing device; sending a first encrypted Hypertext Transfer Protocol (HTTPS) response to a first encrypted HTTPS request of the computing device, the first HTTPS request being sent from the computing device through the open LAN, the first HTTPS response being signed with the private key of the one or more servers and being sent from the one or more servers to the computing device through 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; as well as The password for the secure LAN from the user account is sent in a second HTTPS response to the computing device over the open LAN via the wireless router.

2. One or more non-transitory 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 being associated with a local area network, the local area network being associated with a network identifier; receiving a certificate for the computing device; determining the association between the computing device and the user account based at least on the credential; authenticating the computing device based at least on the association being determined; sending data to the computing device based at least on the computing device being authenticated; receiving a request from the computing device for credentials for the local area network after authenticating the system by the computing device, the authentication being based at least in part on the data, the credentials being different from the network identifier, wherein the authentication comprises: performing Transport Layer Security (TLS) authentication on the credentials received from the system, wherein success of the TLS authentication enables HTTPS communication between the computing device and the system; and authenticating signed HTTPS data received from the system; and The credentials are sent to the computing device based at least on the request.

3. The non-transitory computer-readable storage medium of claim 2 , wherein each of the certificate and the request is received from the computing device via a data connection between the computing device and the wireless router of a second local area network including the computing device and the wireless router, wherein each of the data and the credential is sent to the computing device via the data connection.

4. The non-transitory computer-readable storage medium 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; as well as The second computing device is requested to set up the second local area network within a time period based at least in part on the bar code data being received.

5. The non-transitory computer-readable storage medium of claim 2, wherein the operations further comprise: In response to a remote device scanning a barcode associated with the computing device, first data about a public key of the computing device and second data about the user account are received from the barcode, wherein the association between the computing device and the user account is generated at least in part based on the first data and the second data.

6. The non-transitory computer-readable storage medium of claim 2, wherein the operations further comprise: receiving, from a mobile device, barcode data from a barcode associated with the computing device, the barcode data including a personal identification number (PIN), wherein the association between the computing device and the user account includes the PIN based at least in part on the barcode data; as well as A hash of the PIN is received 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 non-transitory computer-readable storage medium of claim 2, 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 computing device types and a range of product numbers for the computing device types; as well as The data is signed 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 non-transitory computer-readable storage medium of claim 2, wherein the system is a back-end server that stores 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 a private key of the system.

9. A computing device comprising: one or more processors; as well as 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 associated with the network identifier; sending the certificate to the server via the first data connection; 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; authenticating the server by verifying the data based at least in part on the public key of the server; After the server is authenticated, requesting credentials for a second LAN from the server via the first data connection, the credentials being different from the network identifier, wherein the server is authenticated by: performing Transport Layer Security (TLS) authentication on the credentials received from the server, wherein success of the TLS authentication enables HTTPS communication between the computing device and the server; as well as authenticating signed HTTPS data received from the server; receiving the credentials from the server via the first data connection; as well as A second data connection is established 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 from and to the computing device via the first LAN is limited based at least in part on one or more of: a processing volume 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 including the second LAN; sending a request to the server for credentials for the secure LAN; and One or more of the credentials are received 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 include the credentials for 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 security LAN including the second LAN and the third LAN; sending a request for credentials of the third LAN to the server; receiving a response from the server that the credentials for the third LAN are unavailable; as well as A request for the credentials for the second LAN is sent to the server 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 from 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, to a second server via the second LAN, a first indication that the public key is to be 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 The second data connection to the second LAN is terminated based at least in part on the second indication.

Images