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.

Description:
FIELD 
       [0001]    The present invention relates to a method for configuring access for a limited user interface (UI) device to a network service via a local network access point. 
       BACKGROUND 
       [0002]    A Wi-Fi client device, for example, as defined by IEEE 802.11, goes through a setup process to associate/connect with a Wi-Fi Access Point (AP). The setup process typically includes the client device scanning for AP&#39;s within range, displaying AP&#39;s found within range of the client device on a display interface, receiving user selection of a displayed AP via an input interface, receiving/transmitting a network key or password (typically required by the AP) entered by the user via the input interface, and establishing a connection to the AP. If the network key is incorrect, an error message is displayed to the user. 
         [0003]    The Internet of Things (IoT) describes a wide range of emerging consumer devices that require network integration as part of their underlying functionality. For most such devices they must connect to a network, and the normal use case involves connecting to a local network AP. 
         [0004]    Many IoT devices will feature at least a rudimentary user interface (UI) comprising either a touch-screen; or keypad and screen, enabling a password to be entered to establish a secure wireless link with the local network. Additional device configuration may then be effected via the same user interface, including establishing a link to a local IoT supervisor or to a remote IoT server. Again, user entry of passwords and keycodes is prone to error and may be unacceptable to many consumers. 
         [0005]    At the same time, some limited-UI IoT devices, for example, web-cameras, security lights or sensors may lack one or both of an input interface and display interface and so do not readily provide a suitable user interface for such configuration. 
         [0006]    Current attempts to simplify Wi-Fi setup, such as Wi-Fi Protected Setup (WPS), either require PIN to be entered, or pressing buttons on the client device and AP at the same time, or both, while others send information to the client device without encryption, exposing the Wi-Fi network to snooping devices. Some IoT devices such as a simplicam web-camera from ArcSoft obtain required configuration information for connecting to a local AP using out-of-band channels, such as by imaging a QR code provided by an authorised user&#39;s smartphone; while others such as the HeeLight smart bulb obtain their control information through a coded/modulated sound burst provided by an authorised user&#39;s smartphone 
         [0007]    However, it is not alone sufficient for today&#39;s IoT devices to join a local network, they may also need to join some form of network service or, as becomes more common, an external Internet or Cloud service. There has been significant growth in such services to manage local network devices such as those in the home. Thus, once they are connected to the local network, individual devices need to access external URLs on the Internet via their local AP. 
         [0008]    Cyber-security is key for success of IoT. Consumers are already concerned with the security of their devices and major vendors have moved to securely encrypt all major device communication from mobile devices. Thus integrated e-mail services such as gmail and iOS-mail now provide end-to-end secured communications including providing two-factor authentication. 
         [0009]    Some manufacturers even provide an integrated security keychain across all of a consumer&#39;s registered devices. Thus, a user knows if a new device is added or rejoins their private cluster of devices. It is also possible, for this group of secured devices, to enable the sharing of services, content and application functionality within a group of users. This approach, known commercially as family sharing, is useful as it allows shared access to services, but also allows granularity at both the user and device levels. 
         [0010]    To ensure robust security and centralized authentication and service control, these services are cloud based and are typically linked to a payment mechanism such as a credit card. Such services will hereafter be referred to as Key-chained Cloud Services (KCS). Today, these offer best practice in consumer security for mobile device services. 
         [0011]    The challenge for IoT devices, is that each device is vulnerable until it becomes configured. Even if it will eventually establish a secure, encrypted communication with the cloud service, the initial configuration steps can be typically unsecured, as can the initial establishing of a TCP/IP link with the local network access point. 
         [0012]    WO2014/163877 teaches shifting the network setup functionality from a limited-UI device to a full-feature device. At first power up, when a reset button is pressed, or whenever the limited-UI client device cannot connect to the network, the limited-UI device enters a network setup mode that allows a full-feature device to connect to the limited-UI device. For example, if the network is Wi-Fi, the limited-UI device becomes an AP for the full-feature device or the limited-UI device goes into Ad-Hoc mode. 
         [0013]    WO2014/131038 teaches enabling communication among one or more IoT device groups. In particular, various heterogeneous IoT devices that may need to interact with one another in different ways may be organized into IoT device groups to support efficient interaction among the IoT devices. 
         [0014]    WO2014/131029 teaches enabling context aware actions among heterogeneous IoT devices including receiving, at an IoT device, data representing a context of each of a first set of IoT devices in an IoT network, receiving, at the IoT device, data representing a current state of each of a second set of IoT devices in the IoT network, and determining, by the IoT device, an action to perform at a target IoT based on the received data representing the context of each of the first set of IoT devices and the received data representing the current state of each of the second set of IoT devices. 
         [0015]    WO2014/131035 teaches controlling of IoT devices based on detecting a device and obtaining control information and associated rules for controlling the device. The control functions available to a smart controller can vary based on the condition of the various rules and/or the interaction of the various devices detected. 
         [0016]    WO2014/131015 teaches collaborative intelligence and decision making in an IoT device group. In particular, various IoT devices in the group may be interdependent, whereby a decision that one IoT device plans may impact other IoT devices in the group. Accordingly, in response to an IoT device planning a certain decision (e.g., to transition state or initiate another action), the IoT devices in the group may collaborate using distributed intelligence prior to taking action on the planned decision. For example, a recommendation request message may be sent to other IoT devices in the group, which may then analyze relationships within the IoT device group to assess potential impacts associated with the planned decision and respond to approve or disapprove the planned decision. Based on the responses received from the other IoT devices, the IoT device may then appropriately determine whether to take action on the planned decision. 
         [0017]    WO2014/131001 teaches determining an association among IoT devices includes receiving, at a first IoT device, an identifier of a second IoT device, obtaining, by the first IoT device, a schema of the second IoT device based on the identifier of the second IoT device, and determining, by the first IoT device, whether or not there is an association between the first IoT device and the second IoT device based on a schema of the first IoT device and the schema of the second IoT device, wherein the schema of the first IoT device comprises schema elements and corresponding values of the first IoT device and the schema of the second IoT device comprises schema elements and corresponding values of the second IoT device. 
         [0018]    WO2015/017268 teaches establishing a connection between first and second IoT devices. After a determination is made to execute a proximity detection procedure, the second IoT device outputs an audio emission and a data packet at substantially the same time. The first IoT device detects the audio emission via a microphone and receives the data packet. The first IoT device uses correlation information to correlate the detected audio emission with the data packet, whereby the correlation information is contained in the detected audio emission, the data packet or both. The first IoT device uses the correlation between the detected audio emission and the data packet to calculate a distance estimate between the first and second IoT devices. 
         [0019]    Referring to  FIG. 1 , WO2014/031542 teaches configuring a new enrollee device ( 140 ) for a communication network ( 120 ) including a network node ( 230 ) where an electronic device ( 110 ) obtains ( 250 ) a device password associated with the new enrollee device. The device password is provided ( 154 ) to a network registrar ( 130 ) to cause the network registrar to configure the new enrollee device for the communication network. The network registrar performs an enrollment process ( 226 ) based upon the device password and, optionally, provides feedback ( 160 ) to the electronic device to indicate whether or not the new enrollee device was successfully enrolled (i.e. added) to the communication network. 
       SUMMARY 
       [0020]    According to a first aspect of the present invention there is provided a method according to the claims. 
         [0021]    According to a second aspect, there is provided a method according to the claims. 
         [0022]    In further aspects, there are provided computing devices and computer program products which when executed on a computing device are arranged to perform the above methods. 
         [0023]    Note that because of the use of a ZKP protocol and a secure ephemeral link between a limited-UI device and a full feature device, the limited-UI device is able to connect to its service provider using the full feature device to establish its credentials with the service, but without either: revealing any user credentials or configuration information for the local AP to the cloud service; or exposing these credentials or configuration information locally while establishing the connection to the cloud service. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0024]      FIG. 1  illustrates a prior art approach to configuring an IoT type device; and 
           [0025]      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 
       [0026]    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  10   a , 10   b , 10   c,  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). 
         [0027]    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  10   a  . . .  10   c  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 . 
         [0028]    The configuration process for the limited-UI device  10   a  is as follows: 
         [0029]    A user first obtains with the smartphone  20 , an identifier (ID) for the limited-UI device  10   a  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  10   a  (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  10   a  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  10   a,  such mechanisms may not be regarded as sufficiently secure for some implementations as they may be regarded as prone to wireless signal eavesdropping. 
         [0030]    In one example, the limited-UI device  10   a  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. 
         [0031]    If the device  10   a  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. 
         [0032]    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  10   a,  or other information relevant to the configuration, management, or utilization of the new enrollee device  10   a.    
         [0033]    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  10   a  with the same user and keychain. 
         [0034]    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 . 
         [0035]    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. 
         [0036]    For details of ZKP challenge/response protocols see, for example, Grzonkowski, Sl/awomir, 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] 
         [0037]    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  10   a  to subsequently access the local network  30  in order that it access the cloud service  50 . 
         [0038]    The third stage of the process requires that the smartphone  20  communicate with the limited-UI device  10   a,    FIG. 2( c ) . As the limited-UI device  10   a  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  10   a.    
         [0039]    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  10   a  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  10   a  are for the smartphone  20  to generate a coded or modulated audio signal, if the limited-UI device  10   a  is responsive to audio, or a code or modulated light signal, if the limited-UI device  10   a  has light-sensing capabilities, or NFC pulses if the device  10   a  provides an NFC sensing capability. Other communications, such as Bluetooth, may be used depending on the level of security required. 
         [0040]    Note that, as a typical use case is within a user&#39;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. 
         [0041]    The configuration information provided by the smartphone  20 , which is already connected to the local network  30 , to the limited-UI device  10   a  comprises a SSID (service set identifier) and password for the local network  30 . The limited-UI device  10   a  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  10   a  as well as a response URL. 
         [0042]    At this point the limited-UI device  10   a  is TCP/IP connected but is not yet configured for its underlying services. 
         [0043]    At the same time as it is connecting to the local network  30 , the limited-UI device  10   a  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  10   b  may generate responses to these. These additional challenges essentially involve a repetition of the steps of  FIG. 2( c )  and are not shown separately. 
         [0044]    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  10   a.  If this challenge is not generated then the device  10   a  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. 
         [0045]    Referring to  FIG. 2( d ) , after the cloud service  50  determines the device  10   a  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  10   a ,  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  10   a,  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  10   a  to transmit the key, however as this communication is within the consumer&#39;s home, the limited risk is considered acceptable. 
         [0046]    The limited-UI device  10   a,  may then request and establish a secure channel with the cloud service  50 . 
         [0047]    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  10   a  through the secure link between the cloud service  50  and the limited-UI device  10   a.    
         [0048]    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  10   a  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. 
         [0049]    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. 
         [0050]    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.