Web storage based IoT device protect mechanism

Described embodiments provide systems and methods for provisioning disk images on remote devices. Described is a device configured to connect to a pre-configured network upon device start-up, transmit a request to a server at a pre-configured network address, receive a response containing a disk image for the device, and populate a memory component of the device with the disk image received. Described is a server configured to, responsive to receiving a request from a device, authenticate the request, identify a disk image corresponding to the device, and transmit the disk image to the device. These systems and methods are well suited for improving security and integrity of deployed special-purpose devices, e.g., as may be used for an “Internet of Things” deployment.

BACKGROUND

Network accessible computing systems, e.g., servers in a data center, provide various services over a network (e.g., the Internet). These systems are sometimes referred to as “cloud based” or “in the cloud” in reference to their off-premises location within the network (which is often depicted in figures as a cloud). Cloud-based services may be hosted on servers owned or managed by a third-party, e.g., under a tenancy or co-tenancy arrangement. The third-party providing the hardware (or time on shared hardware) may be referred to as a cloud-services provider. Cloud-based services provide a variety of conveniences, including the ability to quickly provision new services, the ability to provide services and functionality to network-connected customers in a variety of contexts, and the ability to seamlessly migrate data between network-connected devices.

A variety of special-purpose devices have been developed that extend back-end server functionality into locations beyond the data center. These devices effectively extend the reach of network (or the cloud) into specific locations in close proximity to real world applications. Collections or networks of these devices (“things”) are sometimes referred to as “the Internet of Things,” or “IoT.” IoT devices may be found deployed in a variety of contexts including farms, industrial centers (e.g., factories), commercial facilities (e.g., warehouses and retail stores), distribution lines, vehicles (e.g., delivery trucks, trains, cars, etc.), entertainment centers (e.g., movie theaters and amusement parks), office buildings, hotels and conference centers, and domestic home settings. Examples of IoT devices include, but are not limited to, environmental monitoring devices such as thermometers, smoke detectors, light detectors, motion detectors, and humidity detectors that provide environmental sensor data back to the servers via the network. Examples of IoT devices further include, but are not limited to, control devices such as thermostats, auditory or visual alarms, light switches, door locks, automatic doors, pet food dispensers, and other devices that can receive instructions or configurations from servers via the network.

IoT devices, once deployed, can be difficult to manage. Initially, software installed on the devices can only be upgraded using mechanisms implemented prior to distribution. Furthermore, the device may use an operating system and/or device drivers that may be difficult to modify once deployed. Security flaws and bugs in these systems may be difficult to quickly fix, and may be impossible to test once deployed.

IoT devices are typically intended to be simplified special-purpose devices. Additional components and hardware that are not necessary to the purpose of a given IoT device add cost and risk to the deployment of the IoT device. It can be beneficial to identify components that could be omitted from a device to reduce these costs and risks.

An IoT device that has been deployed may be accessed by third parties. The device, once deployed, may be physically controlled by a third party. The device may be using a third-party network for communication with the servers. The device may be compromised or physically accessed by malicious parties. Once an IoT device has been modified (or hacked), it may be difficult to detect that the device has been modified, it may be difficult to reverse the modifications, and it may result in a larger compromise. For example, a hacked IoT device on a network may introduce vulnerabilities to other devices on the network.

These and other technical problems are addressed by the subject matter described.

SUMMARY

Described embodiments provide systems and methods for protecting the integrity of computing devices, such as Internet of Things (“IoT”) devices, by remotely provisioning disk images on the deployed devices. By remotely controlling all software managed behavior of the device, any flaws in a deployed device are automatically corrected. Any unauthorized modifications made to the software are removed simply by restarting the device. In some embodiments, the device is configured to periodically refresh the disk image, effectively forcing these restarts.

In at least one aspect, described is a system for provisioning disk images on remote devices. The system includes a device having a volatile memory component, a processor configured to execute instructions from the volatile memory component, and a network interface controller configured to connect to a pre-configured network upon device start-up, transmit a request to a server at a pre-configured network address, receive a response containing a disk image for the device, and populate the volatile memory component with the disk image received. The system further includes a server configured to, responsive to receiving the request from the device, authenticate the request, identify the disk image corresponding to the device, and transmit the disk image to the device.

In some embodiments, the system includes a data storage device storing one or more disk images for the remote devices. The server is configured to identify the disk image from the data storage device based on either a device identifier specific to the device or a device type corresponding to the device. In some embodiments, the device is configured to periodically request, from the server, a refresh of the disk image, receive a replacement disk image, and populate the volatile memory component with the replacement disk image received. Populating the volatile memory component with the replacement disk image replaces any previously received disk image.

In at least one aspect, described is a method of provisioning a disk image on a remote device. The method includes receiving, by a server from a device, a request for a disk image suitable for operation of the device. The method includes authenticating, by the server, the request, and identifying a disk image corresponding to the device. The method includes transmitting the identified disk image to the device responsive to the request.

In at least one aspect, described is a method of booting a device absent a device-local disk image. The method includes transmitting, by a device during an initialization or boot-up phase, to a pre-configured network address corresponding to a server, a request for a disk image suitable for operation of the device. The method includes receiving the disk image from the server and populating a memory element of the device with the received disk image, the disk image including operation code for the device. The method includes executing the operation code for the device, from disk image stored in the memory element of the device.

DETAILED DESCRIPTION

The subject matter described covers topics that, among other things, enables a disk image for a device to be remotely provisioned from a server. By moving the disk image from the device to the server, the device no longer needs non-volatile memory and can be constructed with just volatile memory components if desired. On boot-up or initialization, the device requests the disk image from the server and populates its memory with the disk image. Although referred to throughout this document as a “disk” image, the disk image need not precisely correspond to a “disk,” and in some embodiments is a device image that includes instructions for operation of the device. In some embodiments, the image includes a comprehensive set of instructions for operation of the device, i.e., everything needed to run the device other than the initialization processes described herein. The device receives and stores the disk image, and then runs from the stored disk image. In some embodiments, the device is further configured to periodically refresh the disk image. Because the disk image is managed at the server, a modification to the image at the device (e.g., by a hacker or other malicious user) will not persist past a re-start and will be removed periodically, e.g., in embodiments with a periodic refresh.

FIG. 1Adepicts an illustrative network environment100, in accordance with an illustrative embodiment. The network environment100includes a deployment network104a, a production network104b, and one or more other networks such as a transit network104c(the deployment network104a, the production network104b, and the transit network104care referred to generally as networks104). Within the network environment100, client devices120(e.g., Internet of Things (“IoT”) devices) communicate with servers150, and the servers150provide one or more network services to the client devices120. As shown inFIG. 1A, servers150are situated in the production network104b. The client devices120communicate with the servers150via the deployment network104awhich may pass data directly to the production network104bor pass data through one or more intermediary networks, e.g., through the transit network104c. Network communications between the client devices120and the servers150flow through network devices144such as switches, routers, hubs, filters, firewalls, gateways, and so forth. For example, the deployment network104aincludes an access point142that directs traffic from client devices120to the servers150(e.g., via network device144). The servers150include a device disk image host server150configured to supply disk images to client devices120, e.g., as described herein. In some embodiments, the device disk image host server150sources these disk images from a data storage system166. The stored data168may include, for example, an association of device identifiers (or device types) paired with corresponding device disk images. As described in more detail below, the device disk image host server150may receive a disk image request from a client device120, use the data storage system166to identify a suitable disk image from the stored data168, and return the identified disk image to the requesting client device120.

Suitable examples of client devices120include various processor-based devices that execute instructions for interactions with servers150via a network104. Some example client devices120are “Internet of Things” (“IoT”) devices. For example, some example client devices120are passive monitoring devices such as thermometers, hydrometers, barometers, smoke detectors, light sensors, and the like. Some example client devices120receive input from a user and/or present output to the user. For example, the client device120may be any kind of computing device, including, e.g., a desktop computer, a laptop or notepad computer, a thin client, a mobile device such as a tablet or electronic “pad,” a smart phone or data phone, a “smart” watch or other wearable, a gaming system, an Internet Radio, or any other device capable of the functions described herein. The client devices120are capable of exchanging information with other computing devices via a network104(e.g., via the deployment network104a). For example, a client device120may exchange information over the network104using protocols in accordance with the Open Systems Interconnection (“OSI”) layers, e.g., using an OSI layer-4 transport protocol such as the User Datagram Protocol (“UDP”) or the Transmission Control Protocol (“TCP”), layered over an OSI layer-3 network protocol such as Internet Protocol (“IP”), e.g., IPv4 or IPv6. In some embodiments, the client device120supports network communication using Secure Socket Layer (“SSL”) or Transport Layer Security (“TLS”), which encrypts communications layered over a reliable transport protocol (such as TCP). In some embodiments, the client device120is a thin-client, or functions as a thin-client, executing a thin-client protocol or remote-display protocol such as the Independent Computing Architecture (“ICA”) protocol created by Citrix Systems, Inc. of Fort Lauderdale, Fla. The ICA protocol allows presentation at the client device120of software executing remotely (e.g., at a server150), as though the remotely executed software were executed locally on the client device120. In some embodiments, one or more of the servers150with which the client devices120communicate supports a custom instruction set, e.g., an application programming interface (“API”), and a custom application executed on the client device120implements the API. An application can implement an API using, for example, a library such as a dynamic link library (“DLL”) or a software development kit (“SDK”) provided to the application's developer.

In some embodiments, the client device120includes one or more hardware elements for facilitating data input and data presentation. In some embodiments, the client device120is implemented using special purpose logic circuitry, e.g., an application specific integrated circuit (“ASIC”). In some embodiments, the client device120is implemented using a system on a chip (“SoC”) semiconductor device that includes at least one processor (or microprocessor) core. In some embodiments, the client device120is implemented using a general purpose computing processor.FIG. 1B, described in more detail below, illustrates a computing device101that, in some configurations, is suitable for use as a client device120.

The networks104a,104b, and104c(referred to generally as a network104) link devices for communication. In some embodiments, data flows through the network104as a flow of data packets in accordance with the OSI layers, e.g., as a TCP or ICA flow. An illustrative network104is the Internet; however, other networks may be used. Each network104a,104b, and104cmay be an autonomous system (“AS”), i.e., a network that is operated under a consistent unified routing policy (or at least appears to from outside the AS network) and is generally managed by a single administrative entity (e.g., a system operator, administrator, or administrative group). A network104may be composed of multiple connected sub-networks or AS networks. Networks may include one or more network devices144propagating data through the network. Networks meet at boundary nodes, e.g., gateway nodes, routers, or multi-homed computing devices. A network104may include wired links, optical links, and/or radio links. A network104may include a telephony network, including, for example, a wireless telephony network implementing a wireless communication protocol such as the Global System for Mobile Communications (“GSM”), Code Division Multiple Access (“CDMA”), Time Division Synchronous Code Division Multiple Access (“TD-SCDMA”), Long-Term Evolution (“LTE”), or any other such protocol. A wireless network (such as a Wi-Fi network or a wireless telephony network) may use one or more radio receivers for access to the network. The access point142is an example of a network node at which the client device120may connected to the deployment network104a. The network104may be public, private, or a combination of public and private networks. Each of the networks104a,104b, and104cmay be any type and/or form of data network and/or communication network.

The network devices144are network nodes that forward network data (e.g., data packets) between other network nodes. Suitable examples of network devices144include switches, routers, hubs, multi-homed computing devices, or any other device used for network communications. A network device144may include two or more network interfaces (or physical “ports,” which should not be confused with transport protocol ports) and logic circuitry for identifying, for particular data, an egress interface connected to another device that will move the particular data towards a destination. In some embodiments, the network devices144direct traffic based on routing configuration data to forward data towards traffic destinations. In some embodiments, the network devices144forward data according to routing tables. In some embodiments, the network devices144forward data according to a configuration, e.g., a configuration set by a software defined network (“SDN”) controller. In some embodiments, a network device144includes a content-addressable memory (“CAM”) or ternary content-addressable memory (“TCAM”), used in identifying egress interfaces for routing data. In some embodiments, a network device144implements additional network functionality, or directs traffic through additional network nodes providing network functionality. For example, a network device144may pass traffic through a firewall, a network address translator (“NAT”), a network filter, or some other node providing network functionality.

The access point142is an example network device that serves as a connection from the client device120to the deployment network104a. Examples of an access point142include a wireless network base (also referred to as a “Wi-Fi hot spot”), a wired connection point (e.g., a router, switch, or hub), or any other connection point. In some embodiments, the client device120connects to the deployment network104avia a telephony protocol, e.g., a mobile phone data service protocol, and the access point142is a telephone network node. In some embodiments, the client device120is preconfigured to connect to a particular access point142(or to one of a specific set of access points142) on start up. In some embodiments, the access point142is a specialized “hub” device configured specifically to receive network connection requests from specific client devices120(e.g., from a specific model of client device120).

One or more servers150may be logically grouped (e.g., as a server farm), and may either be geographically co-located (e.g., on premises) or geographically dispersed (e.g., cloud based) from client devices120and/or other servers150. In some embodiments, a server150or group of servers150executes one or more applications on behalf of one or more of client devices120(e.g., as an application server). In some embodiments, the servers150provide functionality such as, but not limited to, file server, gateway server, proxy server, or other similar server functions. In some embodiments, client devices120may seek access to hosted applications on servers150. In some embodiments, a network device144or a server150may provide load balancing across multiple servers150to process requests from client devices120, act as a proxy or access server to provide access to the one or more servers150, provide security and/or act as a firewall between a client120and a server150, provide Domain Name Service (“DNS”) resolution, provide one or more virtual servers or virtual internet protocol servers, and/or provide a secure virtual private network (“VPN”) connection from a client120to a server150, such as a secure socket layer (“SSL”) VPN connection and/or provide encryption and decryption operations. One particular network function is hosting device disk images. The servers150include a device disk image host server150configured to supply disk images to client devices120, e.g., as described herein. In some embodiments, the device disk image host server150sources these disk images from a data storage system166.

In described embodiments, client devices120, network devices144, servers150(including the authentication server160), and other devices shown inFIG. 1Amay be deployed as (or executed on) any type and form of computing device, such as any desktop computer, laptop computer, or mobile device capable of communication over at least one network104and performing the operations described herein. For example, the client devices120, servers150, and other devices may each correspond to one computer, a plurality of computers, or a network of distributed computers such as the computing device101shown inFIG. 1B.

As shown inFIG. 1B, a computing device101may include one or more processors103, volatile memory122(e.g., RAM), non-volatile memory128, user interface (UI)123, one or more communications interfaces114(e.g., a network interface card (“NIC”) and/or a radio transmitter, e.g., for Wi-Fi or NFC communications), and a communication bus105. The user interface123may include hardware for a graphical user interface (“GUI”)124(e.g., a touchscreen, a display, etc.), one or more input/output (“I/O”) devices126(e.g., a mouse, a keyboard, a speaker, etc.). Non-volatile memory128stores an operating system115, one or more applications118, and data117such that, for example, computer instructions of operating system115and/or applications118are executed by processor(s)103out of volatile memory122. In some embodiments, a client device120may be implemented without non-volatile memory128; the elements traditionally stored in non-volatile memory128in such embodiments may be stored in volatile memory122, e.g., provisioned from a server150as described herein. Data117may be entered using an input device of GUI124or received from I/O device(s)126. Various elements of the computing device101may communicate via communication bus105. The computing device101as shown inFIG. 1Bis shown merely as an example, as client devices120, servers150(including the authentication server160), and other network devices144may be implemented by any computing or processing environment and with any type of machine or set of machines that may have suitable hardware and/or software capable of operating as described herein.

The processor(s)103may be implemented by one or more programmable processors executing one or more computer programs to perform the functions of the system. As used herein, the term “processor” describes an electronic circuit that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard coded into the electronic circuit or soft coded by way of instructions held in a memory device. A “processor” may perform the function, operation, or sequence of operations using digital values or using analog signals. In some embodiments, the “processor” can be embodied in one or more of an application specific integrated circuit (“ASIC”), microprocessor, digital signal processor, microcontroller, field programmable gate array (“FPGA”), programmable logic arrays (“PLA”), multi-core processor, or general-purpose computer processor with associated memory. The “processor” may be analog, digital, or mixed-signal. In some embodiments, the “processor” may be one or more physical processors or one or more “virtual” (e.g., remotely located or cloud-based) processors.

The non-volatile memory128may include one or more of a hard disk drive (“HDD”), solid state drive (“SSD”) such as a Flash drive or other solid state storage media, or other magnetic, optical, circuit, or hybrid-type storage media. In some embodiments, the non-volatile memory128includes read-only memory (“ROM”). In some embodiments, storage may be virtualized, e.g., using one or more virtual storage volumes, such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes. In some embodiments, a client device120may be implemented without non-volatile memory128; the elements traditionally stored in non-volatile memory128in such embodiments may be stored in volatile memory122, e.g., provisioned from a server150as described herein.

The communications interface114may include one or more interfaces to enable the computing device101to access a computer network104such as a LAN, a WAN, or the Internet through a variety of wired and/or wireless or cellular connections. In some embodiments, the communications interface114includes one or more network connection points (ports) and an interface controller. Network connection points may be wired connection points (e.g., Ethernet ports) or wireless (e.g., radio circuitry for Wi-Fi or mobile network communications).

FIG. 1Cis a block diagram of an example computing device execution environment102, in accordance with an illustrative embodiment. The environment102includes the processor/hardware layer110of an example computing device101(e.g., a client device120or server150) and the software instructions run by the processor/hardware layer110. In brief overview, the processor/hardware layer110includes a basic input/output system (“BIOS”)112hardcoded in a restricted circuit that is either read-only memory (“ROM”)116or a re-writeable memory that can only be rewritten using a secured instruction set. The BIOS112is immutable, or functionally immutable. In addition to the BIOS112, the processor/hardware layer110may include a ROM116encoded with a boot-up process for connecting to a network access point142and requesting a device disk image from a server150. The environment102includes an operating system kernel175that provides operating system resources170such as device drivers178. In some embodiments, the operating system provides for management of a filesystem162. The operating system facilitates execution of software185on the processor/hardware layer110. In some embodiments, the operating system may provide one or more virtualization or emulation layers between the software185and the processor/hardware layer110. In some embodiments, software185may be written or compiled in a form requiring a runtime environment180. For example, software185written in JAVA may be compiled into JAVA bytecode suitable for execution in a java virtual machine (“JVM”) represented inFIG. 1Cas the runtime environment180. As described herein, the device disk image provided to a client device120by the server150may include all of the instructions needed for the client device120to run the operating system and software over the processor/hardware layer110.

FIG. 2is a ladder diagram for an example data exchange200used in an illustrative embodiment. As shown inFIG. 2, a client device120transmits210an image request to a server150. The server150authenticates220the request and identifies230the device type or device identifier for the device making the request. Authentication220and device identification230may be performed by the server150in any order and/or in parallel. The server150looks-up240the image, e.g., from a data storage system166. For example, the server150may request a database search from the data storage system166. The data storage system166then returns250a disk image and the server150sends260the disk image back to the requesting client device120. The client device120stores270the disk image and boots280the device using the stored disk image. In some embodiments, the client device120may periodically request290an update of the disk image, effectively repeating the exchange200.

FIG. 3is a flowchart for an example method300of booting a device absent a device-local disk image. In broad overview of the method300, at stage310, the device (e.g., a client device120) initializes itself from read-only memory (e.g., from a BIOS112or other ROM116). At stage320, the device connects to a local network (e.g., a deployment network104ain which the device is deployed). For example, in some embodiments, the device connects to the local network at stage320using pre-configured instructions, e.g., from the BIOS112or ROM116. At stage330, the device transmits a disk image request to a disk image host server (e.g., a server150). The disk image host server will identify and return a disk image suitable for use by the device. At stage360, the device receives the disk image via the local network connection. At stage370, the device stores the received disk image and, at stage380, loads or boots the device using the stored disk image. In some embodiments, the device will periodically repeat the method300, starting from stage320or from stage330, to refresh the stored disk image with a replacement image.

Referring toFIG. 3in more detail, at stage310, the device (e.g., a client device120) initializes itself from read-only memory (e.g., from a BIOS112or other ROM116). In some embodiments, the BIOS112and/or ROM116contain enough information to perform the method300.

At stage320, the device connects to a local network (e.g., an access point142for a deployment network104ain which the device is deployed). For example, in some embodiments, the device connects to the local network at stage320using pre-configured instructions, e.g., from the BIOS112or ROM116. In some embodiments, the device is pre-configured with a set of possible networks that it can connect to (e.g., for automated network discovery). In some embodiments, the device is pre-configured with a set of identifiers for acceptable access points142. In some embodiments, the access point142is a specialized device configured to accept network join requests from the device. In some embodiments, the device joins any available open network. In some embodiments, the device joins any available Wi-Fi network. In some embodiments, the device joins any available network and applies a sequence of passwords until it successfully connects to a network. The sequence of passwords may be stored in an immutable form, e.g., in the ROM116.

At stage330, the device transmits a disk image request to a disk image host server (e.g., a server150). The disk image host server will identify and return a disk image suitable for use by the device. In some embodiments, the disk image host server is at a pre-configured network address. In some embodiments, the pre-configured network address is one of a list of network addresses stored in an immutable form by the device, e.g., in ROM116, and the device is configured to iterate through the list until successfully interacting with the server. In some such embodiments, the list of network addresses includes at least one fixed network address in an internet protocol (“IP”) version 4 (“IPv4”) or version 6 (“IPv6”) format. In some embodiments, the list of network addresses includes at least one uniform resource locator (“URL”) that resolves, by dynamic name server (“DNS”) look-up, to the server.

In some embodiments, the device establishes a secure communication channel with the server, e.g., a virtual private network (“VPN”), a secure socket layer (“SSL”), or HTTPS. In some embodiments, the device pings the server and the server responds with a standard or custom protocol handshake to establish the secure communication channel. In some embodiments, communication proceeds without establishing a secure communication channel.

In some embodiments, the request at stage330includes an authentication token or other proof of authenticity. The server is configured to authenticate the request based on the authentication token or proof of authenticity. In some embodiments, the request includes a security credential, e.g., an encrypted token. In some embodiments, the server will respond to the request at stage330with a challenge and the device responds to the challenge to prove authenticity. In some embodiments, the server generates a challenge, sends the challenge back to the device, receives a response to the challenge from the device, and authenticates the request based on the challenge response. An example of a challenge and challenge response is for the server to encrypt a random number using a first secret key and require the device to respond with the same random number either decrypted or encrypted using a second secret key. The encryption may use shared keys (where the device and the server both have the same secret key) or use a pair of keys (e.g., an asymmetrical encryption scheme where one key in the pair is used to decrypt content encrypted using the other key in the pair). In some embodiments, each device has a deterministic sequence generator (e.g., a linear feedback shift register, “LFSR”) and sends the next number in the sequence with each request. The server authenticates the request if the included LFSR sequence number is correct. In some such embodiments, the device encrypts the LFSR sequence number, e.g., using a shared key (or a one time key). In some embodiments, the server tolerates one or more skipped numbers in the LFSR sequence, e.g., to accommodate missed requests. Other authentication sequences may likewise be used.

At stage360, the device receives the disk image via the local network connection. In some embodiments, the server sends the disk image to the device directly. In some embodiments, the server sends the device a pointer to the disk image, e.g., a uniform resource locator (“URL”), and the device obtains the disk image by fetching it from the pointed-to location.

At stage370, the device stores the received disk image. In some embodiments, the device writes the received disk image to non-volatile memory128. In some embodiments, the device writes the received disk image to volatile memory122.

In some embodiments, the device validates the received disk image. Just as the server authenticates the request, the device authenticates the server and the data supplied by the server. In some embodiments of the system, the device includes a cryptographic certificate for validating disk images, and the device is configured to validate the disk image using the cryptographic certificate. For example, the disk image may include a hash of the disk image encrypted with a private key held by a signing authority and the certificate includes a corresponding public key. The device uses the public key to decrypt the hash and then compares the decrypted hash to a hash of the received disk image. If they match, the device may determine that the disk image is valid.

At stage380, the device loads or boots the device using the stored disk image. In some embodiments, the device mounts the memory element storing the disk image as a primary data device (e.g., a main drive). In some embodiments, the device starts an operating system encoded in the disk image. In some embodiments, the device executes instructions included in the disk image to create an execution environment102.

In some embodiments, the device will periodically repeat the method300, starting from stage320or from stage330, to refresh the stored disk image with a replacement image. For example, in some embodiments, the device is configured to replace or refresh the disk image at regular intervals (e.g., every hour, every four hours, every eight hours, every twelve hours, every twenty-four hours, every week, every month, etc.). In some embodiments, the device generates a signature for the provisioned disk image (e.g., a hash of the disk image, or a hash combined with metadata such as a last provisioned timestamp) and sends the signature to the device disk image host server with the disk image request. The server may then analyze the signature to determine if a new disk image should be provisioned. For example, if the hash doesn't match a hash of the corresponding disk image at the server end and/or if the timestamp exceeds a threshold max runtime for a provisioned image. If the analysis indicates that a new disk image should be sent, the server then transmits the disk image and the device continues with stage360receiving the image. It overwrites the previously provisioned image and restarts or reloads from the newly provisioned image. In some embodiments, the server always sends a new disk image without such analysis.

FIG. 4is a flowchart for an example method400of provisioning a disk image on a remote device. In broad overview of the method400, at stage410, the server (e.g., a device disk image host server such as a server150) receives a disk image request from a device (e.g., a client device120). At stage420, the server authenticates the request and at stage430determines a device type, or device identifier, for the device. At stage440, the server identifies a disk image corresponding to the determined device type or device identifier and at stage450obtains a copy of the identified disk image. At stage460, the server (or another data server, e.g., a cache, operating at the direction of the server) transmits the disk image to the device.

Referring toFIG. 4in more detail, at stage410the server (e.g., a device disk image host server such as a server150) receives a disk image request from a device (e.g., a client device120). In some embodiments, the request is an initialization request. In some embodiments, the request is a refresh request. In some embodiments, the request includes an a credential for authentication, e.g., an identifier and password pair or an authentication token. In some embodiments, the request includes a timestamp. In some embodiments, the request is submitted in a secured session, e.g., as an HTTPS request.

At stage420, the server authenticates the request. In some embodiments, the request includes a security credential, e.g., an encrypted token. In some embodiments, the server generates a challenge, sends the challenge back to the device, receives a response to the challenge from the device, and authenticates the request based on the challenge response. An example of a challenge and challenge response is for the server to encrypt a random number using a first secret key and require the device to respond with the same random number either decrypted or encrypted using a second secret key. The encryption may use shared keys (where the device and the server both have the same secret key) or use a pair of keys (e.g., an asymmetrical encryption scheme where one key in the pair is used to decrypt content encrypted using the other key in the pair). In some embodiments, each device has a deterministic sequence generator (e.g., a linear feedback shift register, “LFSR”) and sends the next number in the sequence with each request. The server authenticates the request if the included LFSR sequence number is correct. In some such embodiments, the device encrypts the LFSR sequence number. In some embodiments, the server tolerates one or more skipped numbers in the LFSR sequence, e.g., to accommodate missed requests. Other authentication sequences may likewise be used.

At stage430, the server determines a device type, or device identifier, for the device. In some embodiments, stage430happens before, or concurrently with, stage420. At stage430, the server determines the information needed to look-up the correct corresponding device disk image. In some embodiments, this information is a device-specific implementation unique identifier, corresponding to only one deployed device (e.g., in some embodiments, the device disk image is unique to specific devices). For example, in some such implementations, the server uses one or more of a network address (e.g., an IPv4 or IPv6 address) for the device, uses a media access controller (“MAC”) address for the device, uses an assigned number included in the request (e.g., a unique serial number encoded in ROM116), or some combination thereof. In some implementations, the device disk image is generalized to a set of devices of the same type. For example, in some such implementations, any device of the same type (e.g., a particular model of IoT sensor or controller) can use the same disk image. In some such implementations, the server first identifies the specific device and then looks up the type for the identified device, e.g., from a mapping. In some implementations, the server identifies the device type without uniquely identifying the device.

At stage440, the server identifies a disk image corresponding to the determined device type or device identifier. Based on the device type or device identifier, the server identifies a corresponding device disk image. In some embodiments, the server uses a data storage system166to identify a device disk image from data168stored in the system166. In some embodiments, the server queries a database. In some embodiments, the server consults a look-up table. In some embodiments, the server performs the look-up in a cache. In some such embodiments, if the requested disk image isn't in cache, the server then falls back to a secondary search. In some embodiments, the look-up results in a pointer to a disk image, e.g., a uniform resource locator (“URL”). In some embodiments, the look-up results in a file name.

At stage450, the server obtains a copy of the identified disk image and at stage460, the server (or another data server, e.g., a cache, operating at the direction of the server) transmits the disk image to the device. In some embodiments, the server fetches the disk image from a data storage device166. In some embodiments, the server skips step450. For example, if the disk image is available at a URL, the server may return the URL to the device and the device then fetches the image from the URL. In some embodiments, the server causes another server to transmit the device disk image to the device.

The systems and methods described may be used in a variety of embodiments. For example, and without limitation:

In at least one aspect, the above describes a system for provisioning disk images on remote devices. The system includes a device having a volatile memory component, a processor configured to execute instructions from the volatile memory component, and a network interface controller configured to connect to a pre-configured network upon device start-up, transmit a request to to server at a pre-configured network address, receive a response containing a disk image for the device, and populate the volatile memory component with the disk image received. The system further includes a server configured to, responsive to receiving the request from the device, authenticate the request, identify the disk image corresponding to the device, and transmit the disk image to the device.

In some embodiments, the system includes a data storage device storing one or more disk images for the remote devices. The server is configured to identify the disk image from the data storage device based on either a device identifier specific to the device or a device type corresponding to the device. In some embodiments, the device is configured to periodically request, from the server, a refresh of the disk image, receive a replacement disk image, and populate the volatile memory component with the replacement disk image received. Populating the volatile memory component with the replacement disk image replaces any previously received disk image.

In some embodiments of the system, the disk image includes an operating system for the device and software to be executed by the device. In some such embodiments, the device is configured to boot the operating system from the volatile memory component after populating the volatile memory component with the disk image received responsive to the request.

In some embodiments of the system, the pre-configured network address is one of a list of network addresses stored in an immutable form by the device, and the device is configured to iterate through the list until successfully interacting with the server. In some such embodiments, the list of network addresses includes at least one fixed network address in an internet protocol (“IP”) version 4 (“IPv4”) or version 6 (“IPv6”) format. In some embodiments, the list of network addresses includes at least one uniform resource locator (“URL”) that resolves, by dynamic name server (“DNS”) look-up, to the server.

In some embodiments of the system, the device includes a cryptographic certificate, and the device is configured to validate the disk image using the cryptographic certificate. In some embodiments, the request includes an authentication token and the server is further configured to authenticate the request based on the authentication token.

In some embodiments, the server is configured to identify the disk image corresponding to the device by: identifying, from the request, a media access control (“MAC”) address for the device, identifying a device type based on the MAC address for the device, and identifying a disk image corresponding to the identified device type. In some embodiments, the server is configured to identify the disk image corresponding to the device by querying a database mapping a device identifier to the disk image. In some embodiments, the device identifier is a media access control (“MAC”) address for the device. In some embodiments, the server is configured to identify the MAC address from the request.

In some embodiments of the system, one or more processors in the server are configured to execute instructions encoded on non-transitory computer-readable media.

In at least one aspect, the above describes a method of provisioning a disk image on a remote device. The method includes receiving, by a server from a device, a request for a disk image suitable for operation of the device. The method includes authenticating, by the server, the request, and identifying a disk image corresponding to the device. The method includes transmitting the identified disk image to the device responsive to the request.

In some embodiments of the method of provisioning a disk image, the disk image includes an operating system for the device and software to be executed by the device.

In some embodiments of the method of provisioning a disk image, the server identifies, from the request, a media access control (“MAC”) address for the device; identifies a device type based on the MAC address for the device; and identifies a disk image corresponding to the identified device type. In some embodiments, the server identifies the disk image corresponding to the device by querying a database mapping a device identifier to the disk image. In some embodiments, the device identifier is a media access control (“MAC”) address for the device. In some embodiments of the method, the server identifies the MAC address from the request. In some embodiments, the request includes an authentication token, and the server authenticates the request based on the authentication token.

In at least one aspect, the above describes a method of booting a device absent a device-local disk image. The method includes transmitting, by a device during an initialization or boot-up phase, to a pre-configured network address corresponding to a server, a request for a disk image suitable for operation of the device. The method includes receiving the disk image from the server and populating a memory element of the device with the received disk image, the disk image including operation code for the device. The method includes executing the operation code for the device, from disk image stored in the memory element of the device.

Some embodiments of the method of booting the device include validating the received disk image using a cryptographic certificate stored in an immutable form at the device.

Some embodiments of the method of booting the device include mounting the memory element of the device as a primary data storage device.

Some embodiments of the method of booting the device include transmitting, to the server, a second request to refresh the memory element of the device; receiving a replacement disk image responsive to the second request; populating the memory element of the device with the received replacement disk image; and reinitializing the device using the replacement disk image. In some such embodiments, the replacement disk image is a revised disk image. In some embodiments, the device transmits the second request responsive to a predetermined amount of time having elapsed. In some embodiments, the second request includes an identifier of the provisioned disk image. In some such embodiments, the identifier includes a hash of the provisioned disk image.

In at least one aspect, these methods may be encoded as computer-readable instructions for execution by one or more processors. The computer-readable instructions can be encoded on non-transitory computer-readable media. The computer-readable instructions can be encoded in read-only memory.

It will be further understood that various changes in the details, materials, and arrangements of the parts that have been described and illustrated herein may be made by those skilled in the art without departing from the scope of the following claims.