Patent Description:
Accordingly, there is a need for new systems, methods, and media for securing connections to IoT devices.

Document <CIT> discloses a client device configured to detect user requests to utilize IoT devices, and allow each IoT device access only upon user authorization or request.

In accordance with some embodiments, mechanisms (which can include systems, methods, and media) for securing connections to Internet of Things (IoT) devices are provided.

In some embodiments, these mechanisms can intercept in-bound traffic to IoT devices, block the traffic unless a user has indicated that the traffic is to be allowed or the user has logged in when attempting to connect from a browser, and, when a user has indicated that a traffic is to be allowed, pass traffic to the IoT device for a specified period of time.

In some embodiments, these mechanisms thereby make users aware of in-bound traffic to IoT devices in their homes and let the users control the traffic without needing to deal with the complexities of router firewall rules and/or policies.

Turning to <FIG>, an example <NUM> of hardware for securing connections to Internet of Things (IoT) devices in accordance with some embodiments of the disclosed subject matter is shown. As illustrated, hardware <NUM> can include an IoT device management server <NUM>, a communication network <NUM>, a user router <NUM>, a user computer <NUM>, a user media device <NUM>, and user Internet-of-Things (IoT) devices <NUM> and <NUM>.

IoT device management server <NUM> can be any suitable server for managing IoT devices. For example, in some embodiments, IoT device management server <NUM> can be any server for managing IoT devices and can perform any suitable functions, such as processes <NUM> and <NUM> of FIG.

Communication network <NUM> can be any suitable combination of one or more wired and/or wireless networks in some embodiments. For example, in some embodiments, communication network <NUM> can include any one or more of the Internet, a mobile data network, a satellite network, a local area network, a wide area network, a telephone network, a cable television network, a WiFi network, a WiMax network, and/or any other suitable communication network.

In some embodiments, communication network <NUM> and the devices connected to it can form or be part of a wide area network (WAN).

IoT device management server <NUM> and user router <NUM> can be connected by one or more communications links <NUM> to communication network <NUM>. The communications links can be any communications links suitable for communicating data among IoT device management server <NUM>, user router <NUM>, and communication network <NUM>, such as network links, dial-up links, wireless links, hard-wired links, any other suitable communications links, or any suitable combination of such links.

User router <NUM> can be any suitable router. For example, in some embodiments, user router <NUM> can be any router for routing traffic between user computer <NUM>, user media device <NUM>, user Internet-of-Things (IoT) devices <NUM> and <NUM>, and/or the Internet, and can perform any suitable functions such as process <NUM> of FIG.

User computer <NUM> can be any suitable computer, such as a desktop computer, a laptop computer, a tablet computer, a smart phone, and/or any other suitable computer device, and can perform any suitable functions such as processes <NUM> and <NUM> of FIG.

User media device <NUM> can be any suitable device for streaming media, such as a media player box, a media player dongle (which can stream video and audio, video only, or audio only), a smart television, etc..

User IoT devices <NUM> and <NUM> can be any suitable Internet of Things devices, such as internet protocol cameras, smart smoke alarms, smart thermostats, smart locks, alarms, sensors, light bulbs, hubs, smart speakers, and/or any other device that can be connected to a computer network.

User computer <NUM>, user media device <NUM>, and user IoT devices <NUM> and <NUM> can be connected by one or more communications links <NUM> to user router <NUM>. The communications links can be any communications links suitable for communicating data among user computer <NUM>, user media device <NUM>, user IoT devices <NUM> and <NUM>, user router <NUM>, such as network links, dial-up links, wireless links, hard-wired links, any other suitable communications links, or any suitable combination of such links.

In some embodiments, user computer <NUM>, user media device <NUM>, user IoT devices <NUM> and <NUM>, communications links <NUM>, and user router <NUM> can form or be part of a local area network <NUM>.

Although one IoT device management server <NUM>, one user router <NUM>, one user computer <NUM>, one user media device <NUM>, and two user IoT devices <NUM> and <NUM> are shown in <FIG> to avoid over-complicating the figure, any suitable numbers (including zero in some embodiments) of these devices can be used in some embodiments.

IoT device management server <NUM>, user router <NUM>, user computer <NUM>, user media device <NUM>, and/or user IoT devices <NUM> and <NUM> can be implemented using any suitable hardware in some embodiments. For example, in some embodiments, IoT device management server <NUM>, user router <NUM>, user computer <NUM>, user media device <NUM>, and/or user IoT devices <NUM> and <NUM> can be implemented using any suitable general-purpose computer or special-purpose computer. For example, a user IoT device, such as a smart lock or smart camera, can be implemented using a special-purpose computer. Any such general-purpose computer or special-purpose computer can include any suitable hardware. For example, as illustrated in example hardware <NUM> of FIG. <NUM>, such hardware can include hardware processor <NUM>, memory and/or storage <NUM>, an input device controller <NUM>, an input device <NUM>, display/audio drivers <NUM>, display and audio output circuitry <NUM>, communication interface(s) <NUM>, an antenna <NUM>, and a bus <NUM>.

Hardware processor <NUM> can include any suitable hardware processor, such as a microprocessor, a micro-controller, digital signal processor(s), dedicated logic, and/or any other suitable circuitry for controlling the functioning of a general-purpose computer or a special purpose computer in some embodiments.

Memory and/or storage <NUM> can be any suitable memory and/or storage for storing programs, data, and/or any other suitable information in some embodiments. For example, memory and/or storage <NUM> can include random access memory, read-only memory, flash memory, hard disk storage, optical media, and/or any other suitable memory.

Input device controller <NUM> can be any suitable circuitry for controlling and receiving input from a device in some embodiments. For example, input device controller <NUM> can be circuitry for receiving input from a touch screen, from one or more buttons, from a voice recognition circuit, from a microphone, from a camera, from an optical sensor, from an accelerometer, from a temperature sensor, from a near field sensor, and/or any other type of input device.

Display/audio drivers <NUM> can be any suitable circuitry for controlling and driving output to one or more display/audio output circuitries <NUM> in some embodiments. For example, display/audio drivers <NUM> can be circuitry for driving an LCD display, a speaker, an LED, or any other type of output device.

Communication interface(s) <NUM> can be any suitable circuitry for interfacing with one or more communication networks, such as network <NUM> as shown in <FIG>. For example, interface(s) <NUM> can include network interface card circuitry, wireless communication circuitry, and/or any other suitable type of communication network circuitry.

Antenna <NUM> can be any suitable one or more antennas for wirelessly communicating with a communication network in some embodiments. In some embodiments, antenna <NUM> can be omitted when not needed.

Any other suitable components can additionally or alternatively be included in hardware <NUM> in accordance with some embodiments.

Turning to FIG. <NUM>, an illustration of examples <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> of processes that can be performed in accordance with some embodiments. As illustrated, process <NUM> can be executed by user router <NUM> in some embodiments, processes <NUM> and <NUM> can be executed by IoT device management server <NUM> in some embodiments, and process <NUM> and <NUM> can be executed by a user device <NUM>, <NUM>, <NUM>, or <NUM> in some embodiments.

As shown, process <NUM> begins by intercepting in-bound traffic destined for an IoT device at <NUM>. The traffic can be determined as being destined for an IoT device in any suitable manner, such as based on a fingerprint of an IoT device. For example, in some embodiments, a fingerprint of an IoT device can identify MAC address(es) of the device, a host name associated with the device, network discovery probes (e.g., UpnP, MDNS (Bonjour), NetBIOS, and SNMP) used by the device, open ports on the device, user agents used by the device, DNS requests made by the device, DHCP vendor and vendor options used by the device, and network characteristics (e.g., domains visited, content of packets sent/received, interpacket arrival rate, TTL, etc.) of the device, and/or any other observable trait of the device or a combination of all traits mentioned above. In some embodiments, any device that is not a desktop computer, laptop computer, tablet computer, or mobile phone can be designated as being an IoT device.

Traffic can be intercepted in any suitable manner. For example, traffic can be intercepted using a transparent proxy (e.g., TPROXY) or by using iptables REDIRECT.

Next, at <NUM>, process <NUM> can determine whether there is a timer is active for the traffic received at <NUM>. This determination can be made in any suitable manner in some embodiments. For example, in some embodiments, a timer can be determined as being active for traffic when the timer designates an IoT device to which the traffic is destined, when the timer is for a traffic type (e.g., hyper-text transfer protocol (http) traffic, non-http traffic, or any other suitable type of traffic) corresponding to the traffic, and/or when the timer corresponds to any other characteristic of the traffic.

If a timer for the traffic is determined to be active at <NUM>, then, at <NUM>, process <NUM> can pass the traffic to the corresponding IoT device at <NUM> and then loop back to <NUM>. The traffic can be passed to the IoT device in any suitable manner. For example, a transparent proxy can forward the traffic to the IoT device.

Otherwise, if it is determined at <NUM> that a timer for the traffic is not active, then, at <NUM>, process <NUM> can determine whether the traffic is http traffic or non-http traffic. This determination can be made in any suitable manner, such as by determining a destination port number identified in the traffic. More particularly, for example, traffic can be determined to be http traffic if it is directed to a port usually used for http traffic, such as port <NUM>, port <NUM>, port <NUM>, and/or any other suitable port, in some embodiments.

If it is determined at <NUM> that the traffic is http traffic, then at <NUM>, process <NUM> can determine whether the traffic is from a browser. This determination can be made in any suitable manner in some embodiments. For example, in some embodiments, this determination can be made by inspecting a http user agent header in the traffic to determine if the traffic is from a browser.

If it is determined at <NUM> that the traffic is from a browser, then at <NUM>, process <NUM> can redirect a connection attempt in the traffic to process <NUM> so that the user of the browser is required to log in. This redirection can be performed in any suitable manner.

As shown in process <NUM>, at <NUM>, the process detects the redirection. This detection can be made in any suitable manner.

Then, at <NUM>, process <NUM> can perform a user login. This user login can be performed in any suitable manner. For example, as shown, at <NUM>, process <NUM> can send a login request to process <NUM>, which can receive the login request from process <NUM> at <NUM>. Next, process <NUM> can receive user credentials and/or multifactor authentication (MFA) information at <NUM>. Process <NUM> can then provide the user credentials and/or MFA information to server <NUM> at <NUM> and end at <NUM>.

At <NUM>, process <NUM> can then determine whether the login is valid. This determination can be made in any suitable manner, such as by comparing the user credentials and MFA information to credentials and MFA information stored in a secure database.

If at <NUM> process <NUM> determines that the login is valid, it can then notify user router <NUM> at <NUM> and then end at <NUM>. As shown, process <NUM> can receive this notice of login at <NUM>.

Otherwise, if at <NUM> process <NUM> determines that the login is not valid, then, at <NUM>, process <NUM> can determine if the maximum login attempts have been made. If not, process <NUM> can loop back to <NUM>. Otherwise, process <NUM> can log the login attempt activity at <NUM> and end at <NUM>.

Referring back to process <NUM>, after receiving the notice of login at <NUM>, process <NUM> can start a timer for the IoT device for the traffic type (e.g., http or non-http traffic). This timer can have any suitable duration in some embodiments, including a duration from <NUM> to <NUM> seconds, <NUM> to <NUM> minutes, <NUM> to <NUM> hours, <NUM> day to <NUM> days, <NUM> year to <NUM> years, and/or an infinite duration.

After starting the time, process <NUM> can then branch to <NUM> at which the traffic can be passed to the IoT device as described above. The traffic can be passed in any suitable manner, such as by instructing a transparent proxy to forward the traffic.

If the traffic is determined to not be from a browser at <NUM>, or if the traffic is determined to not be http traffic, then at <NUM>, process <NUM> can block the traffic and notify server <NUM>. The traffic can be blocked and the notification can be made in any suitable manner. For example, a transparent proxy can be instructed to block the traffic.

As shown in process <NUM>, server <NUM> can receive the notification from <NUM> at <NUM>. This notification can be received in any suitable manner.

Then, at <NUM>, process <NUM> can alert a user device that the traffic is blocked and receive instruction on what to do with the blocked traffic. This can be performed in any suitable manner. For example, as shown in process <NUM>, at <NUM>, the receiver can receive an alert that the traffic is blocked (e.g., as a push notification to the user device), present that alert to a user as a pop-up notification on the user device, request instructions on what to do about the blockage (e.g., approve of block, enable traffic for a certain duration (e.g., from <NUM> to <NUM> seconds, <NUM> to <NUM> minutes, <NUM> to <NUM> hours, <NUM> day to <NUM> days, <NUM> year to <NUM> years, and/or an infinite duration), and receive the instructions. Then, process <NUM> can instruct the server in accordance with the user's instructions at <NUM> and end at <NUM>.

Once the instructions have been received by process <NUM> at server <NUM> from process <NUM>, process <NUM> can instruct user router <NUM> accordingly at <NUM> and end at <NUM>. Process <NUM> on user router <NUM> can wait for and receive these instructions at <NUM>.

At <NUM>, process <NUM> can then determine whether to continue blocking the traffic. If so, process <NUM> can log the activity at <NUM> and then end at <NUM>. Otherwise, process <NUM> can branch to <NUM> and proceed as described above.

It should be understood that at least some of the above described blocks of the process of FIG. <NUM> can be executed or performed in any order or sequence not limited to the order and sequence shown in and described in the figure. Also, some of the above blocks of the process of FIG. <NUM> can be executed or performed substantially simultaneously where appropriate or in parallel to reduce latency and processing times. Additionally or alternatively, some of the above described blocks of the process of FIG. <NUM> can be omitted.

In some embodiments, any suitable computer readable media can be used for storing instructions for performing the functions and/or processes herein. For example, in some embodiments, computer readable media can be transitory or non-transitory. For example, non-transitory computer readable media can include media such as non-transitory magnetic media (such as hard disks, floppy disks, and/or any other suitable magnetic media), non-transitory optical media (such as compact discs, digital video discs, Blu-ray discs, and/or any other suitable optical media), non-transitory semiconductor media (such as flash memory, electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and/or any other suitable semiconductor media), any suitable media that is not fleeting or devoid of any semblance of permanence during transmission, and/or any suitable tangible media. As another example, transitory computer readable media can include signals on networks, in wires, conductors, optical fibers, circuits, any suitable media that is fleeting and devoid of any semblance of permanence during transmission, and/or any suitable intangible media.

Claim 1:
A system for securing connections to Internet of Things, IoT, devices (<NUM>, <NUM>), comprising a server (<NUM>) on the Internet (<NUM>), said server comprising:
a memory (<NUM>); and
a hardware processor (<NUM>) coupled to the memory and configured at least to:
receive (<NUM>, <NUM>), at the server, a notification that indicates that first inbound traffic from the Internet has been blocked (<NUM>) at a router (<NUM>), wherein the first inbound traffic was destined for a first IoT device (<NUM>, <NUM>);
in response to receiving, at the server, the notification, send (<NUM>, <NUM>), from the server to a user device (<NUM>) distinct from the server, an alert that indicates that the first inbound traffic has been blocked;
receive (<NUM>, <NUM>), at the server, first instructions from the user device indicating to unblock the first inbound traffic; and
in response to receiving, at the server, the first instructions, send (<NUM>, <NUM>), from the server to the router, second instructions to unblock the first inbound traffic.