METHOD FOR CONFIGURING ACCESS FOR A LIMITED USER INTERFACE (UI) DEVICE

Abstract

A method operable by a computing device for configuring access for a limited user interface (UI) device to a network service via a local network access point is disclosed. The method comprises the steps of: obtaining from the limited UI device a device identifier via a first out-of-band channel. The device identifier is provided to the network service via a secure network link. A zero knowledge proof (ZKP) challenge is received from the network service. Configuration information is provided to the limited-UI device via a second out-of-band channel, the configuration information including information sufficient to enable the limited-UI device to connect to the local network access point. The ZKP challenge is provided to the limited-UI device via the second out-of-band channel. A secure channel key is received from the network service indicating a successful response from the limited-UI device to the ZKP challenge; and provided to the limited-UI device enabling the limited-UI device to access the network service.

Claims

1. A computing device comprising: one or more processors; and one or more computer-readable media storing computer-executable instructions that, when executed, cause the one or more processors to perform operations comprising: receiving a challenge from a second computing device, over a first network path, wherein the challenge is associated with a network service; determining a challenge response associated with the challenge; transmitting the challenge response to the network service, over a second network path different from the first network path; receiving a key from the second computing device, over the first network path; establishing a secure link with the network service, using the key; and transmitting data to the network service via the secure link.

2. The computing device of claim 1, the operations further comprising: receiving, from the second computing device, a uniform resource locator (URL) associated with the network service, wherein transmitting the challenge response includes transmitting the challenge response to the URL.

3. The computing device of claim 1, wherein determining the challenge response comprises accessing firmware within the computing device configured to generate the challenge response.

4. The computing device of claim 1, the operations further comprising: receiving, from the second computing device, credential data associated with a local network, wherein transmitting the challenge response includes using the credential data to transmit the challenge response to the network service via the local network.

5. The computing device of claim 1, wherein the challenge is received from the second computing device via an out-of-band channel.

6. The computing device of claim 5, wherein transmitting the challenge response to the network service includes transmitting the challenge response via a computer network.

7. The computing device of claim 1, the operations further comprising: providing a device identifier to the second computing device, via an out-of-band channel, wherein the device identifier is provided to second computing device prior to receiving the challenge from the second computing device.

8. The computing device of claim 1, the operations further comprising: receiving a second challenge associated with the network service from the second computing device, wherein receiving the second challenge is based at least in part on transmitting a correct challenge response to the network service; determining a timeframe associated with receiving the second challenge, based at least in part on a time associated with transmitting the challenge response to the network service; and transmitting a second challenge response to the network service, based at least in part on determining that the second challenge was received within the timeframe.

9. The computing device of claim 1, the operations further comprising: receiving a second challenge associated with the network service from the second computing device; determining a timeframe associated with receiving the second challenge, based at least in part on a time associated with transmitting the challenge response to the network service; and initiating a time-out notification based at least in part on determining that the second challenge was received after the timeframe.

10. One or more non-transitory computer-readable media storing instructions executable by a processor, wherein the instructions, when executed, cause the processor to perform operations comprising: receiving a device identifier from an electronic device; transmitting the device identifier to a network service, via a computer network; receiving a challenge from the network service, via the computer network; providing the challenge to the electronic device, via an out-of-band channel receiving a key from the network service, via the computer network, wherein the key is associated with establishing a secure link to the network service; and providing the key to the electronic device.

11. The one or more non-transitory computer-readable media of claim 10, the operations further comprising: providing a uniform resource locator (URL) associated with the network service to the electronic device, via the out-of-band channel.

12. The one or more non-transitory computer-readable media of claim 10, the operations further comprising: providing credential data associated with a local computer network to the electronic device, via the out-of-band channel, wherein providing the key to the electronic device comprises transmitting the key via the local computer network.

13. The one or more non-transitory computer-readable media of claim 10: wherein the device identifier is received from the electronic device via a first out-of-band channel; and wherein the challenge is provided to the electronic device via a second out-of-band channel different from the first out-of-band channel.

14. The one or more non-transitory computer-readable media of claim 10, wherein transmitting the device identifier to the network service comprises: receiving authentication data from a user via an input interface; establishing a secure connection to the network service, over the computer network, based at least in part on the authentication data; and transmitting the device identifier via the secure connection.

15. The one or more non-transitory computer-readable media of claim 10, wherein receiving the device identifier from the electronic device comprises detecting a signal emitted from the electronic device using at least one of a camera, a microphone, a near-field communication (NFC) reader, or a radio-frequency ID (RFID) antenna.

16. A method comprising: receiving, by a server associated with a network service, a device identifier from a first computing device over a secure network link, wherein the device identifier is associated with a second computing device; determining, by the server, a challenge associated with the second computing device, based at least in part on the device identifier; transmitting, by the server, the challenge to the first computing device, over the secure network link; receiving, by the server, a challenge response from the second computing device; transmitting, by the server, a key to the first computing device, based at least in part on the challenge response; receiving, by the server, a request from the second computing device to establish a second secure network link, the request including the key; and establishing, by the server, the second secure network link with the second computing device.

17. The method of claim 16, wherein receiving the challenge response from the second computing device comprises receiving the challenge response via a non-secure network link.

18. The method of claim 16, wherein the second computing device comprises an Internet-of-Things (IoT) device.

19. The method of claim 18, further comprising: receiving monitoring data from the IoT device, via the second secure network link; and controlling operations of the IoT device, via the second secure network link, based at least in part on the monitoring data.

20. The method of claim 16, further comprising: determining a timeframe associated with transmitting a second challenge; and transmitting the second challenge to the first computing device within the timeframe, based at least in part on verifying that the challenge response received from the second computing device is a correct response.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] FIG. 1 illustrates a prior art approach to configuring an IoT type device; and

[0026] FIGS. 2(a) to 2(f) illustrate a method of configuring an IoT type device according to an embodiment of the present invention.

DETAILED DESCRIPTION

[0027] Referring now to FIG. 2(a), embodiments of the invention make use of a secured and authenticated full-feature device 20 to configure, secure and authenticate an IoT device 10a,10b,10c, in particular an IoT device with a limited-UI. Examples of full-feature device include a smartphone, tablet computer, laptop computer or indeed any computing device having the required UI and which can be brought into proximity with an IoT device to be configured. The required UI can comprise a display and keypad or touchscreen (not shown), camera 22 (for example, for imaging device tags or light signals), microphone (not shown, for detecting coded sound), speaker 24 (for example, for emitting coded sound) and/or Bluetooth, near-field communication (NFC) tag or radio frequency identifier (RFID) antennae (not shown).

[0028] By authenticated, we mean that the device 20 has obtained and/or holds at least sufficient credentials 26 to establish a connection to a network service 50 across a secure link via a local network 30 comprising either a wired or wireless LAN or combination thereof and including a local access point 40. Where the device 20 is a smartphone, it may already have application software, for example, an app, installed enabling it to connect to the network service 50 which is to supervise the IoT devices 10a . . . 10c on the local network 30. The configuration information for the local network, application software and any user credentials required to operate the application and establish the secure link can be regarded as part of the credentials 26.

[0029] The configuration process for the limited-UI device 10a is as follows:

[0030] A user first obtains with the smartphone 20, an identifier (ID) for the limited-UI device 10a using any one of a variety of out-of-band methods, such as scanning a visual tag with its camera 22, detecting an audio signal with a microphone (not shown), detecting a light signal emitted by the device 10a (again with the camera 22), detecting the device ID via a NFC tag, RFID tag, or other ways in which the new limited-UI device 10a may communicate the device ID with the electronic device 20. It is noted that while Bluetooth radio signal or Wi-Fi Direct handshake could also be used by the electronic device 20 to obtain the ID from the new enrollee device 10a, such mechanisms may not be regarded as sufficiently secure for some implementations as they may be regarded as prone to wireless signal eavesdropping.

[0031] In one example, the limited-UI device 10a is a smart light bulb. The smart light bulb can have a visual tag printed on it (or on the packaging, or insert in the packaging), such as a barcode, matrix code, two-dimensional code. A common example of a barcode that may be used for a new enrollee device may be a Quick Response (QR) Code®. The full-UI device 20 may detect the QR Code (or similar visual tag) using the camera 22 and obtain the device ID by decoding the QR Code.

[0032] If the device 10a is the first device for the network service 50 being added to the local network 30, the device 20 may not have the required application software installed. However, imaging a QR code may provide the device 20 with sufficient information to obtain and install this application software before proceeding. On the other hand, if the application software is installed on the device 20, it may be manually instantiated by the user before imaging the QR code (or acquiring the device ID otherwise); or it may be automatically instantiated in response to imaging the QR code.

[0033] The device ID may be a manufacturer-configured model number or device key for the new enrollee device. In one embodiment, the ID is a combination of a device model number and a production batch number. The device ID is typically not unique to a single device, but instead the device may belong to a production batch that shares a common manufacturing process and device firmware. In addition to the device ID, other information may also be encoded on the QR Code, such as a management URL, name and/or model of the new enrollee device 10a, or other information relevant to the configuration, management, or utilization of the new enrollee device 10a.

[0034] The second stage involves the smartphone application software communicating the device ID to the network service 50, for example, a cloud based service via its secure link to the service. As explained, the service 50 can be accessed via application software installed on the smartphone that establishes a secure connection to the cloud service 50 and is authenticated by the smartphone device. As an example, the device could be an iPhone or similar Android device and the authentication could be provided, using a password, smartcard or any biometric including fingerprint authentication capability of the device. Thus, the smartphone can be part of a Key-chained Cloud Service (KCS) and the cloud service associates the new IoT device 10a with the same user and keychain.

[0035] Note that communication between the device 20 and the cloud service 50 secured using HTTPS or similar by default. Thus, the smartphone communications with the cloud service would not be accessible by any compromised devices on the local network 30.

[0036] After verifying the user and keychain, the cloud service 50 provides the smartphone 20 with a zero-knowledge protocol (ZKP) challenge, FIG. 2(b). This first ZKP challenge is based on the device ID provided previously. While this is not a true private key, it is only used in this initial stage to establish a more secure peer-to-peer connection.

[0037] For details of ZKP challenge/response protocols see, for example, Grzonkowski, Slawomir, et al. “Extending web applications with a lightweight zero knowledge proof authentication.” Proceedings of the 5th international conference on Soft computing as transdisciplinary science and technology. ACM, 2008. [Available online at: http://www.cs.nyu.edu/˜zaremba/docs/zkp.pdf]

[0038] Note that employing such a protocol ensures that local credentials need not be provided by the device 20 to the cloud service 50—it is just sufficient that the device 20 establish that it possesses the required credentials to access the network service 50 via the local network 30 and so allow the IoT device 10a to subsequently access the local network 30 in order that it access the cloud service 50.

[0039] The third stage of the process requires that the smartphone 20 communicate with the limited-UI device 10a, FIG. 2(c). As the limited-UI device 10a is not yet connected to the local network 30, the smartphone 20 must provide it with configuration information as well as the ZKP challenge. Note that the smartphone 20 itself does not have knowledge of how to generate a challenge response—this is embedded within the firmware of the limited-UI device 10a.

[0040] In one embodiment, this communication is again out-of-band, although not necessarily using the same channel as for acquiring the device ID originally, in order to keep the limited-UI device 10a secure. Thus, of the modes of communication previously described in relation to FIG. 2(a), the preferred modes for providing the configuration information and ZKP challenge to the limited-UI device 10a are for the smartphone 20 to generate a coded or modulated audio signal, if the limited-UI device 10a is responsive to audio, or a code or modulated light signal, if the limited-UI device 10a has light-sensing capabilities, or NFC pulses if the device 10a provides an NFC sensing capability. Other communications, such as Bluetooth, may be used depending on the level of security required.

[0041] Note that, as a typical use case is within a user's home, and as the home environment is considered to be private, it is not likely that local visual or audio signal would be intercepted. Thus, these relatively insecure communications modes can, in fact, provide better security within the home environment than a local network connection which may expose communications packets to a compromised network device or home access point.

[0042] The configuration information provided by the smartphone 20, which is already connected to the local network 30, to the limited-UI device 10a comprises a SSID (service set identifier) and password for the local network 30. The limited-UI device 10a can then proceed to configure itself so that it may connect to Internet using the AP 40 as a gateway. The smartphone 20 also provides the first ZKP challenge to the device 10a as well as a response URL.

[0043] At this point the limited-UI device 10a is TCP/IP connected but is not yet configured for its underlying services.

[0044] At the same time as it is connecting to the local network 30, the limited-UI device 10a processes the ZKP challenge and generates a response. As soon as it is connected to the local network 30, it searches for the response URL and transmits the response to the ZKP challenge. If the response is correct, the cloud service 50, may optionally generate additional challenges and the limited-UI device 10b may generate responses to these. These additional challenges essentially involve a repetition of the steps of FIG. 2(c) and are not shown separately.

[0045] In one embodiment, a first additional challenge will be generated within a certain timeframe of the initial response to confirm the link between cloud service 50 and the limited-UI device 10a. If this challenge is not generated then the device 10a will time-out and signal to the user (by blinking a LED or sending a message to the smartphone application software) that the connection was not correctly established. Additional error messages may be provided to the smartphone application software.

[0046] Referring to FIG. 2(d), after the cloud service 50 determines the device 10a is valid, it next generates a secure channel key and transmits this to the smartphone 20 which then transmits the key to the limited-UI device 10a, FIG. 2(e). Note than in a conventional secure link, this key exchange would be performed directly between the cloud service 50 and the limited-UI device 10a, but this can expose the link to various attack modalities such as man-in-the-middle. Furthermore, as limited-UI devices will have less computational power than, for example, a smartphone 20, they will be slower to respond, thus giving an attacker more time to break the encryption. Transmitting the secure channel key via the smartphone ensures the network transport is over an existing secure channel. This is at the risk of using a relatively unsecured communication between the smartphone 20 and the limited-UI device 10a to transmit the key, however as this communication is within the consumer's home, the limited risk is considered acceptable.

[0047] The limited-UI device 10a, may then request and establish a secure channel with the cloud service 50.

[0048] Referring to FIG. 2(f), after the secure channel is established the cloud service 50 can provide additional configuration information to the limited-UI device 10a through the secure link between the cloud service 50 and the limited-UI device 10a.

[0049] In one embodiment, the cloud service 50 can also generate configuration panel information (not shown) for the smartphone application software, again provided through the first secure link between the cloud service 50 and the smartphone 20, and enables the smartphone 20 to securely configure the limited-UI device 10a without allowing other local devices to eavesdrop. Thus the effective communication between smartphone and the limited-UI device is now via the cloud service, rather than over the local network.

[0050] In alternative embodiments the limited-UI device can be linked with a plurality of other devices through the cloud service (rather than directly over the local network) to form a secure communications group and employ techniques as described in WO 2014/131038 with the additional benefits of device security. Multiple devices may be controlled from the smartphone employing techniques as described in WO 2014/131035 with the additional benefit of device security. Similarly these devices may engage in context aware action and collaborative intelligence coordinated from the cloud service employing techniques as described in WO 2014/131029 and WO 2014/131015 with the added benefit of robust device security.

[0051] The cloud service can periodically broadcast ZKP challenges to devices to ensure they are still active on the network and are able to authenticate themselves by answering challenges. The use of such a ZKP proof authentication in combination with conventional SSH (Secure Shell) communications channels, or equivalent, can provide greatly improved security for Internet-of-Things home systems.